发现
客户公司有一台比较陈旧的winserver2008,上面跑着非常陈旧的SiteServer5.0,光是这几年处理被1day攻击,各种传马,小马拖大马应接不暇,隔几个月就要在这个跑马场里陪攻击者们冲刺一波,甚是精彩。比如这次溯源review也是非常精彩的。
review梳理攻击过程及各部分安全设备部署的表现
review的流程图大致如下:
HIDS-agent发现webshell
HIDS非常及时地发现了有恶意文件上传并邮件告警,这个表现给9.9分。
确认系统层面安全
首先简单确认系统用户,系统进程,计划任务等比较关键的地方没有问题。
排查IIS Log找到sql注入攻击入口
通过web-log查找被传的这个马的访问记录,顺着访问记录往前摸排,最终确定了攻击者的入口是ajaxCmsService.aspx,
我们排查出的攻击者使用的攻击向量如下,这三条payload分别对应获取到服务器的UserName、Password、PasswordSalt:
1 | http://www.xxxx.cn/SiteServer/Ajax/ajaxCmsService.aspx?type=GetTitles&publishmentSystemId=1&nodeId=1&title=a%27,0)%20%3E%200%20union%20select%20TOP%202%20Username%20from%20bairong_Administrator-- |
到这一步之后,攻击者就已经拿到了网站后台的权限。
找到webshell上传点
根据weblog的排查大马的post包上传记录,找到了后台上传文件接口,上传正常文件,抓包改包,通过双写绕过黑名单过滤,即可成功上传到upload目录下。
这两步实际上在现有的安全设备发展进展下,完全应该由waf来检测告警,但是很遗憾我们这台服务器前面并没有架设waf,或者接入云waf服务,可以说在应用层面上对攻击没有任何防御能力。
触发可写不可执行的安全策略
这是我第一次通过实战验证了安全策略的有效性,还是比较兴奋的,一定要记下来。这个CMS老版本来就有很多自动化的1day在各种攻击,我们也是加固过几次,上了一些安全策略,诸如可写目录不可知行,所有访问可写目录下的aspx请求全部重定向去主页等。
上传目录的web.config可做如下限制:
1 | <system.webServer> |
正因为我们之前上过策略,所以本次webshell是失效的,从log中也能看到访问的请求返回都是403。
漏洞复现
每次被攻击后我们都要进行溯源,加固, 该停用的停用,该修复的修复,安全策略更是上了一波又一波,没想到这次又被传马了,一时间我还有点接受不了,毕竟加固了那么多次还出问题,有点面子挂不住,终于下决心来一起看看源码,没想到这一看不得了,还真吓了我一跳。另一方面原因是,以往的攻击手法都其实都是的1day,可以在网上找到各种分析的案例,这次我居然没有搜到,所以更加怀疑了可能是个在野0day。
搭建环境
虚拟机起陈旧的版本是挺不容易的,在环境折腾这块实际上踩了不少的坑,我就直接把最终成功的版本信息整理一下发出来.
软件版本 | 注意的点 |
---|---|
WinServer2008_R2_enterprise_and_web_with_sp1 | 在多种带SP1的镜像上纠结选择 |
.NET Framework | 默认是2.0,要匹配CMS的版本首先安装4.0.然后切到4.5 |
IIS默认 | 网站目录的解析到SiteServer路径;以及对文件的权限配置 |
Mssql2008 | 默认安装即可 |
SiteServer5.1.15 | 5.0版本官方下不到了,5.1是我找到的最接近的版本 |
DLL分析软件ILSpy | 最新版 |
winServer镜像链接:
ed2k://|file|cn_windows_server_2008_r2_standard_enterprise_datacenter_and_web_with_sp1_vl_build_x64_dvd_617396.iso|3368962048|7C210CAC37A05F459758BCC1F4478F9E|/
.NET Framework4.0链接: https://www.microsoft.com/en-us/download/details.aspx?id=17851
.NET Framework4.5链接: https://download.microsoft.com/download/E/2/1/E21644B5-2DF2-47C2-91BD-63C560427900/NDP452-KB2901907-x86-x64-AllOS-ENU.exe
SiteServer5.1.15链接: https://codeload.github.com/siteserver/cms/zip/siteserver-v5.0.15
深入分析
打开ajaxCmsService.aspx文件只有简短的一句话,引用继承了一个dll文件
1 | <%@ Page language="c#" trace="False" enableViewState="False" Inherits="SiteServer.BackgroundPages.Ajax.AjaxCmsService" %> |
用ILSpy文件打开这个dll文件,层层跟进
到这里就可以拼语句了,我们直接上payload来拼一下
1 | type=GetTitles&publishmentSystemId=1&nodeId=1&title=a%27,0)%20%3E%200%20union%20select%20TOP%201%20Password%20from%20bairong_Administrator--%20 //payload |
1 | GetInstr(ColumName= Title;inStr=a',0) > 0 union select TOP 1 Password from bairong_Administrator-- ) |
1 | public static string GetInStr(string columnName, string inStr) |
最终语句会拼成如下,简单的union select:
1 | inStr = CHARINDEX('a',0) > 0 union select TOP 1 Password from bairong_Administrator-- )', {columnName}) > 0 |
相应的sqlmap-payload:
1 | sqlmap -u "http://198.18.93.154/SiteServer/Ajax/ajaxCmsService.aspx?type=GetTitles&publishmentSystemId=1&nodeId=1&title=a%27,0)%20%3E%200%20" |
影响范围及修复方案
- 攻击者可以获取到该站点siteserver应⽤管理员
- 攻击者可以访问到对应的siteserver数据库数据
常规sql注入的修复应考虑使用ORM,或者是预编译语句,避免用户的输入影响到最终数据库里的执行语句。
但在这个古老的版本代码中我们看到了大量的语句直接拼接,大量的接口未授权可直接访问,暂且把它用来学习和测试就好了。我相信在新版中肯定解决了这些很明显的安全问题,但是我们面对的现状就是旧版的上架系统还是有服务正在运行,所以还是要在现有的状况下给出紧急的修复方案,框架性质的漏洞直接修改是比较困难的,涉及的人力成本不亚于升级到新版,所以最紧急的修复措施应该是在中间件上加策略:
1. 停用高危的接口
2. 修改admin账户密码
3. 暂停后台对公网的开放
反编译了siteserver7.0的dll,已经更换为restful-api开发,且未发现有直接拼接语句的地方。