冰蝎3.0-分析系列 1-beta2-php

文章目录

1. 1. 前言

2. 2. PHP-webshell分析

3. 2.1. 错误密码通信过程

4. 2.2. 正确密码通信过程

5. 3. 特征分析

6. 3.1. HTTP头部特征

7. 3.2. 数据包长度

8. 4. 小结

1

前言

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

2

PHP-Webshell分析

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

特征分析

3.1.HTTP头部特征

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

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

3.2.数据包长度

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

4

小结

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

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

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

版权声明：

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

MS509简介：

MS509是中国电子科技网络信息安全有限公司（简称“中国网安”）旗下从事安全漏洞挖掘及利用方法研究的纯技术研究团队，研究方向包括WEB安全、红蓝对抗、移动安全、逆向分析、二进制安全、智能硬件（IOT）安全、工控安全、无线安全、APT攻击追踪溯源、安全编程等。 更多团队动态，尽在博客www.ms509.com；微博搜索 MS509。

加入我们：https://www.ms509.com/contact/

↓↓↓ 点击"阅读原文" 【查看更多信息】