回忆一次百转千回的应急响应 | 技术精选0127
2022-3-16 18:0:0 Author: mp.weixin.qq.com(查看原文) 阅读量:7 收藏
本文约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返回500id=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 -
往期推荐

记一次卑微的渗透测试

pwn入门之栈入门

MYSQL另类利用方式

长按下方图片即可关注
点击下方阅读原文，加入社群，读者作者无障碍交流
读完有话想说？点击留言按钮，让上万读者听到你的声音！

文章来源: http://mp.weixin.qq.com/s?__biz=MzAwMzYxNzc1OA==&mid=2247499059&idx=1&sn=adc19636a7bd4201d18fa99bcc960108&chksm=9b3adb82ac4d5294d8c9feefba01ad8ef10a7241792130dd1a28e3b3b11443e1a0cabd3380dd#rd
如有侵权请联系:admin#unsafe.sh