回忆一次百转千回的应急响应 | 技术精选0127


本文约2400字,阅读约需6分钟。


在一个月黑风高的夜晚,我正在召唤师峡谷“e往无前”。正当我即将达成“0/21”成就的时候,一个电话打了过来。

接起电话,是敬爱的领导。电话中说,有应急响应任务,需要火速支援。

工作大于游戏。我向队友表达歉意后,马不停蹄前往客户现场。

PS:事件发生时间距今较久,大家酌情参考~


1

初试

粗略看了一下,是asp+access的站点。源码有五个站点,原来是站被挂马了。我拿上D盾,对着源码一通乱扫。



看来运气不错。排除了级别1和2都是误报外,其它确定是“马儿”了。

看看规律,四个级别4分别在四个站点上,应该是后门。也就是说,先从级别5的站点入手。

接下来就是确认时间了。根据文件名大致判断一下,显示为2020年7月31日13时3分左右。

打开7月30号的日志,找一下文件名:



看上去时间还要更早一些。先把IP记录下来,看看这个IP第一次出现是在做什么:



原来是在跑注入。继续看看这个readnews.asp到底是什么:



好家伙,差点让我以为打开了asp靶场。看样子,注入的是一个入口了。

继续往下看,找到最后01:59的sqlmap记录:



发现了admin的访问记录。入侵者成功登录,并访问了ewebeditor,还换了个新IP。

看看这个IP访问了哪些资源:

catu_ex200731.log|grep "60.8.*.*"|awk '{print $5}'|sort|uniq-c|sort -nr|grep -v".gif"


我们对这些资源做一个记录,继续排查。

一般来说,上传的请求方式都是POST方式,那就看一下这个IP的POST请求有哪些:



只有两个登录的,看来入侵者又换IP了。再看看所有POST请求:



看样子后台有文件上传功能,估计入侵者把“马儿”上传上去getshell了。

看了一下两个有上传功能文件:

ImgUploadSave.asp”

“FileUpLoadSave.asp”

发现做了白名单校验......



难道入侵者不是从后台上传上去的吗?思路断了。

我反复翻看起日志,突然意识到方向似乎有些错误——自己理所当然的把“马儿”时间当成了入侵时间,这下得重新整理一下了。


2

几经波折

转变思路后,因为有源码和数据库,我决定先把环境搭起来看看:



花了点时间搭起来,也很快找到了注入点。学着入侵者拿sqlmap跑了一下,可恶,跑出表名和列名,dump失败了



挂个代理走到burp上:




返回了乱码。找源码看看:



居然有过滤规则。写得很简单,只过滤了小写敏感词和星号,sqlmap跑数据的时候调用了count(*),这就解释了为什么可以跑出表和列,跑不出数据了。

既然我们已经知道表名和列名,手工就可以拿数据了:



密码拿到,cmd5解出来,看了源码路径,找到后台地址:/admin/config/login.asp。

入侵者是什么时候找到后台的呢?把所有日志找出来看一下,确认为7月30号:



进了后台,功能很简单,旁边的上传功能我们已经确认过不是上传点了:



这时我看到了公告发布功能,应该就是之前看到的ewebeditor编辑器了:



看到文件上传源码的那一刻,我几乎泪目。果然是“任何情况下都不允许上传asp脚本文件”:



就在我以为上传成功已经近在眼前,现实却又给了我重重一击:



上传失败了,原来后端会二次校验后缀:



网上找了利用方式,ewebeditor的功能被精简了,都没利用上。

不过讲道理,我利用不上入侵者也应该利用不上(手动狗头)。


3

柳暗花明

在利用了很久没利用上,日志里也没找到线索之后,只能再次转变思路。

根据旁站那个“马儿”,看一下旁站日志情况,找到第一次“马儿”出现的位置:



同样是进了后台,使用了上传功能。

用相同的注入点进入后台:



可以看到最后几条注入语句:
id=923AND ASCW(MID((SELECTMIN(IIF(LEN(RTRIM(CVAR(userpwd)))=0,CHR(32),RTRIM(CVAR(userpwd))))FROM `admin` WHERE CVAR(userpwd)>CHR(32)),32,1))>48返回500
id=923AND ASCW(MID((SELECTMIN(IIF(LEN(RTRIM(CVAR(userpwd)))=0,CHR(32),RTRIM(CVAR(userpwd))))FROM `admin` WHERECVAR(userpwd)>CHR(32)),32,1))>49返回200

也就是说注入出密码md5的最后一位是ascii码49,即是字符1。

进入后台,映入眼帘的是熟悉kindeditor:



上传图片,改名,修改网页源码中fileHZ的value为asp,成功上传“马儿”!兄弟们,把公屏打在泪目上!



有了思路,根据上传路径寻找日志记录:




burp是我测试的,和日志可以说是一模一样。

这下就确认攻击入口了,接下去就是梳理攻击IP和时间线。

根据确认攻击的特征进行IP整理,比如可以根据注入的特征这样写:
catu_ex200730.log|grep "readnews.asp"|grep "sqlmap"|awk'{print $9}'|sort|uniq -c|sort-nr



最后将IP整理去重。

至此整理攻击时间线:

入侵者通过网站A找到了注入,并成功跑出密码,爆破出后台路径进入后台。

但后台功能和ewebeditor无法getshell,于是找到了旁站B,相同的注入点进入后台,利用kindeditor漏洞getshell,同时在服务器上的其它站点留下后门,上传大马等操作。

4

总结

本次应急由于拿到了源码,所以可以利用攻击思维反向排查攻击路径,比直接分析日志效率更高。

在用户目录还发现了earthworm等内网工具,但由于客户发现后被黑后,只保存了日志和源码备份,重置了服务器,将影响告知客户后,没有继续排查。

编写好应急报告后,清晨的阳光格外刺眼。点击发送,收工!



- END -

本文作者:酒仙桥六号部队

本文为安全脉搏专栏作者发布,转载请注明:https://www.secpulse.com/archives/175385.html

Tags:
评论  (0)
快来写下你的想法吧!

酒仙桥六号部队

文章数:105 积分: 865

提前看好文,搜索-微信公众号:酒仙桥六号部队

安全问答社区

安全问答社区

脉搏官方公众号

脉搏公众号