这是最近发生的一个比较典型的案例,记录下来供大家参考. 该网站 Alexa 世界排名在 50K 左右,日均 PV 300K+ ,主要采用 Discuz! X2.5,订制了插件.

第一次发现入侵是因为下午我收到服务器监控报警,平常这个时候不是访问高峰,服务器过载不太正常,引起我怀疑.经过检查发现有人拿到了 Web 权限,挂了黑链,由于代码有问题,造成 PHP 进程宕死,最终触发了警报. 将黑链及后门清理干净,记录下了入侵发生时间: 4 月 20 日(几天前).由于 Discuz! 在 25 日爆出安全漏洞,我之前处理了很多 Discuz! 被入侵的事件,因此怀疑是不是这个 zero day .服务器上的日志没有记录到太有价值的信息,无法还原攻击过程,这给修复漏洞带来了麻烦.起初把目光聚集到该站订制的插件上.经过检查,并未发现问题.看来只好请君入瓮,在服务器上做了必要的布置,开启了更多的日志和入侵检测,静待猎物上门.

第二次对方再次光顾服务器,这次及时发现.相关日志整整 3G+ ,经过筛选,过滤掉 4000K+ 条的日志.狐狸露出了尾巴,问题出在 FastCgi 的类型解析漏洞.触发这个漏洞需要满足的条件其实挺多的:

  1. 不能启用远程附件.附件服务器一般都没有脚本执行权限.
  2. 在 PHP.ini 中不能设置 cgi.fix_pathinfo ,否则会覆盖关键变量.
  3. 必须是 Web Server + FastCgi 的架构. 恰巧都满足.

找到漏洞后修复就简单了,上面三点任意改掉一点就可以.