《一个路径牵出连环血案》之一“诡异的请求”

作为一名才毕业没多久就天天写各种报告的苦命文职专员，就在这里记录记录工作笔记来打发下无聊的日子吧。我把每天遇到好玩的整理发出来与大家分享，所谓独乐乐不如众乐乐^_^

一、诡异的请求

作为一名刚参加工作的新人，我的工作就是写报告和分析日志，什么日志呢，就是国内某云WAF里所有网站产生的请求日志。分析了日志写报告，写完报告又要分析日志，每天不是在写报告就是在分析日志。这周连写三天的报告了，已虚脱到无力吐槽。还好在下班之前搞定了，不然木木姐又得去帮我买麦当劳了(官方标配加班餐)。

三天没去分析攻击日志了，已惦记得心憔悴。放肆，这是在干嘛，我发现有一抹多的IP对N多的网站请求着同一个路径：

/data/in***.php(为了防止看官作恶，文件名隐藏了)

并且这几天的请求次数还真多，你们完蛋了，因为我要开始好好分析分析了。我敲了几条shell命令，把请求这个路径的日志行都单独地提炼了到了一个文本中——这样看上去会更加直观了些。

然后叫旁边正在卖力修BUG的P看了看。“你看，这是我刚导出的日志，它们都在请求这个路径，感觉这些请求好像有问题，这几天请求得有些频繁”，我指着屏幕说道。

“是扫描器吧，都返回的404”，P说道。

“不太像吧”，我答。

紧接着我用awk过滤掉那些影响视觉效果的日志列后继续分析。我发现每条日志都带有Referer，Referer是指向其他站点data/in***..php路径的URL。奇怪。

我随手抽了几个Referer里的URL放浏览器中访问，想看看是什么。这一看真不得了!瞬间被吓尿，阿门，竟然是Webshell(黑客放置在网站里的后门程序)!

随手剪张截图给大家看看：

看来，这些请求就是在尝试网站有没有Webshell!

为啥攻击者的脚本会把Webshell放在Referer里呢?是上帝的恩赐?还是黑客有意?或者是写扫描Webshell程序的人喝太高了，打错变量引起的BUG呢?不得而知，管他呢，重要的是，这里导出来竟有101个存活的Webshell。

我赶紧很不道德地打断了小组其他人的工作，叫他们过来看看。满屏幕的Webshell把他们也吓尿了。

短暂的唧唧歪歪后，我们决定：

1、 由我把一个月的日志中所有请求/data/in***.php的导出来做分析工作。

2、 找出用了某云WAF的网站，由P完成。

我在日志平台上敲了条Hive语句，然后去尿尿了下，回来日志已经全部导出来了。接着把日志里Referer取出来，做了去重统计后——30天，1185个Webshell，这个数字绝对够震撼!P那边进展也很快，把域名列表导出来后，跑了个检测脚本，很快就找出了几个用了加速服务的用户。

接着我继续做分析工作，想先碰碰运气，看能不能用字典把Webshell的登录密码跑出来。我用Python写了段破解Webshell登录密码的脚本，挂上以前收集来的Webshell密码字典列表，然后一个回车摁下去，然后死盯着屏幕，希望能有结果。

等待是漫长的，感觉时间仿佛死机了，让每一秒都在延迟。事实证明我的运气还是比较好的，字典里果然有。

既然这些Webshell是程序自动探测，所有Webshell的密码应该都通用。找了十来个Webshell做登录测试，每个Webshell都可以正常登陆。登陆进去后，我快速地做了一些样本采集之类的工作。

但一个问题困然着我们——究竟是何许人也，是谁批量干掉这么多网站?莫不成用的0day(未公开的漏洞)?要是0day又得发一笔了——光拿到Webshell就发了一大笔了。

仔细观察，发现这1000多个被黑的网站竟然全部用的DeDeCMS。那么攻击者应该是使用了DeDeCMS的漏洞进行攻击的。

我向大伙汇报了下成果。

“赶快先检查现有使用加速服务里所有DeDeCMS用户，有没有出现安全问题，优先保障用户的安全，具体攻击手段后续分析”，这时，旁边沉默很久的老杨发话了。

这时P分析也差不多了，“这些网站没多久才加入的，从日志来看，应该是被黑后，来这里寻求保护的”。

“把站点列表给XM，由他安排客服联系站长，另外X把分析分析那个Webshell，看能不能找出特征后把它拦截了，不准黑客访问。另外，为了站长们的安全，暂时先把/data/in***.php路径也给拦截了，不要让扫描器扫到”，F说道。

然后P利用之前分析的数据，结合北京研究部的数据，以及加速服务历史的数据做了个简单的统计，统计结果是：使用了DeDeCMS的网站，竟然有63%都被黑客攻击成功过。这个比例意味着——网站不及时打补丁、又没有开启云WAF，赤裸裸放在服务器上就肯定会被黑客攻击。

过了几分钟…

“找到特征了，Webshell的登录用的Cookie验证，我拿这段Cookie去跑了几天日志，没有误报的，现在就上规则”，X说道。

又过去几分钟…

“规则已经生效了，访问/data/in***.php被拦截了，我把Webshell换了个文件名放自己网站里，一登录就被拦截了”，P说。

“干得很漂亮，刚才我给余弦打了电话了，ZoomEye团队也进入应急了，你把日志样本发给他们”，F对我说。

“不错，Webshell的后续分析工作交给我来吧”，我说。

“好，下周你就负责把这些网站全部提权了，然后再拖库，哈哈。开玩笑的，交你了哈，弄完了写个分析报告”，F说道。

我们需要知道：

1、黑客是用什么手段攻击的;

2、是谁在攻击。

围绕着这两点，我的一段艰辛的分析就此展开了，途中遇到各种奇葩，待下次道来。