从暗链到文件上传漏洞，一次一波三折的应急

一、起因

昨天收到上级通报，官方网站有暗链，通报截图如下：

HTML里确实有暗链，定性中危。第一反应是某位员工又直接复制粘贴的某个网页，连暗链一起贴了过来，或者误引用某个互联网上的网页，而那个站点因为某些原因现在变成了垃圾站点。于是建议网站管理员直接删除对应文章即可。

二、起火

不一会儿，网站管理员登录服务器后扔过来两张图：

第一张图如上，瞬时上传大量html文件；第二张图如下，每一个html里都是暗链。

这时候意识到事情不会像通报中的暗链那么简单，甚至有些严重，初步猜测是服务器已失陷，已经可以随时批量挂暗链刷流量！于是开始排查。鉴于单位里的安全设备比较贫瘠，无法查看全流量，干脆直接上机......根据文件上传的物理路径很容易找到上传点：

上传点有两处，第一处是kindeditor编辑器，做了后端验证，限制上传文件的格式，这时候开发已经改过代码，将html文件上传禁用了。

第二处是缩略图，直接拿哥斯拉试一下，结果连改包都没有用到就提示上传成功了......这时候心沉到了谷底......返回列表页面查看依然是显示之前的缩略图，然后服务器物理路径下也都是清一色的图片文件，这就说明是代码对文件做了过滤，要么直接忽略白名单以外的文件，要么强制加图片后缀，只不过存在功能性bug，没成功提示成功了。

紧接着对web各个目录都扫了一遍，没有发现马儿，中间件是IIS10.0也没有解析漏洞。针对其他目录，服务器上有卡巴斯基和D盾，免杀没那么容易。然后检测了一下内存马，也不存在：

之后查了查网络状态，没有发现外连IP；最后拿火绒剑看了一遍进程，配合云沙箱，也没有发现恶意程序，排查到这里可以将后门排除了，虚惊一场......那么那些html文件是从哪里来的？

三、岂会

既然没有webshell，那么入侵的途径就可能是弱口令+批量上传功能。联系管理员要了网站测试账号、数据库账号，先去网站上看看有没有登录日志：

有是有了，但只有四条，没有查看更多功能，真的只有四条......还是直接去数据库上看吧，询问得知登录日志表名叫loginfo：

进来一看，再次傻眼，大部分日志只记录到日期，没有记录登录的具体时间...... 由于登录时间与文件上传时间无法对应，那么以用户作为追踪起点的思路就断了。既然登录日志无法继续排查，本着死马当活马医的心态，那就只能从批量上传功能着手了。先放一张与开发的聊天截图：

如果开发说的是对的，那么本案死无对证。但是本人信念坚定，开发的话不能信。之前网站管理员已经找开发处理过文件限制的问题，又具体了解了一下。限制的方式是在kindeditor使用的文件上传接口里限制html。

开发说这是个配置文件，那么这个文件应该是不可被访问的，但事实却再次打了脸：

里面的Unicode编码解码后就是文件里的“请选择文件”提示。从这里可以看出，文件上传功能采用的是白名单策略，通报里的html已经被换行注释掉。但与其说这是个配置文件，不如说这就是那个接口文件......接下来的排查思路就应该是在这个页面上寻找批量上传功能。在经历了一番IPv6环境下代理无响应、内网路由排查、服务器SSL证书握手问题（期间还咨询了某尔北京总部）后，终于抓到了罪魁祸首：

1.office文件上传

2.音视频上传

3.图片上传

4.flash上传

并且每个文件都可以直接下载（如果换成html文件则可以直接打开）：

最重要的是，这个接口是可以未授权访问的！这就解释了前面为什么不需要webshell，也不需要弱口令！排查到这里基本可以结案了，但严谨起见，又对暗链文件做了一番对比：

这些相似度极高的html大小都在20-40KB之间，并且只有class为content的div内容不同，其余代码均相同，因此写个脚本来批量发送也就不难了。

四、启示

这次事件是kindeditor引发的未授权文件上传漏洞，可能就算有流量分析设备的支持也捕获不到异常行为，因为攻击者使用的就是网站的正常功能，大隐隐于市，毕竟未授权类漏洞在OWASP TOP10中常年居高不下。

至于防御，临时措施是用waf自定义规则，匹配路径和IP，只允许内网未授权访问，想要彻底解决，还是需要开发去修复。