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

2013-11-27 +10 186569人围观 ,发现 28 个不明物体 WEB安全

随便说两句

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

一、诡异的请求

作为一名刚参加工作的新人,我的工作就是写报告和分析日志,什么日志呢,就是国内某云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、是谁在攻击。

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

这些评论亮了

  • 给点建议:最后的软植入点过于明显,不要提及余弦,zoomeye能显得更自然流畅一点。
    )16( 亮了
发表评论

已有 28 条评论

取消
Loading...
css.php