一次服务器被传webshell事件溯源

背景

web服务器使用SiteServer开源CMS为建站模板,该类cms属于漏洞高发区,频频会爆出高危漏洞。这次的应该是个在野0day。

起因

阿里云安骑士告警


webshell告警

溯源过程

  1. 可以看到阿里云安骑士报了存在服务器存在webshell,访问该链接,显示403,应该是触发了上传目录下可读可写不可执行的安全策略。我们取得了相关服务器的权限之后,在主机上进行漏洞影响范围和攻击溯源。
  2. 登上服务器首先对系统安全进行排查,查看隐藏用户以及计划人物以及登录日志,初步判断攻击者并没有通过webshell提升到系统的权限。
  3. 从服务器dump下机器最近10天的web访问记录到本地进行溯源分析。
  4. 找到攻击payload如下:
    payload

    三条payload分别对应获取UserNamePasswordPasswordSalt
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--

获取了管理员用户的用户名、密码密文以及密钥,解密之后可登陆管理后台。http://www.xxxx.cn/siteserver/login.aspx。通过日志可以看到,攻击者在登录管理后台后成功上传了木马文件。

upload

上传接口在后台就不展示了。简单的双写绕过文件后缀检测。
双写绕过

因为触发了之前配置的可读可写不可执行的策略,所以攻击者上传的木马访问是403,无法进一步攻击。
403

之后跟进攻击者的使用的ip以及上传木马时间节点之后的日志,并未发现有其他成功的进一步攻击事件。

攻击过程概述

此次攻击事件攻击链由一个未授权接口的sql注入以及后台文件上传漏洞构成。以下日志分析的时间为GMT+0,国内时间应该在此基础上加8小时:

  • 2020-10-19 18:44 IP为128.14.16.23攻击者通过siteserver的一个未授权访问接口的sql注入获取了管理员用户信息。
  • 2020-10-22 09:33 IP为198.176.51.185的攻击者通过siteserver的一个未授权访问接口的sql注入获取了管理员用户信息。这两次从请求时间间隔特征可以大致判断攻击已经自动化。
  • 2020-10-22 09:31 IP为128.14.16.23的攻击者通过后台的文件上传漏洞上传了avator.aspx的网站木马文件。
  • 2020-10-22 09:34 IP为198.176.51.185的攻击者通过后台的文件上传漏洞上传了avator.aspx的网站木马文件。
  • (北京时间)2020-10-22 17:31 阿里云安骑士预警存在webshell文件。

影响范围:

攻击者可以获取到该站点siteserver应用管理员
攻击者可以访问到对应的siteserver数据库数据

漏洞分析

通过整个攻击溯源分析可知,对应的攻击链为:接口未授权访问-->sql注入-->文件上传突破。其中接口未授权访问是最开始的一点,要在源头切断攻击链是最高效的。因此我们通过对日志的统计,发现该接口并不常用,20天没有正常的访问记录,便临时选择关闭该接口来暂时确保安全。此次主要针对sql注入的漏洞从代码层面看一看。

代码分析

从日志可以看到出现问题的是SiteServer/Ajax/ajaxCmsService.aspx文件调用的是一个编译好的dll文件。

aspx

dll文件

反编译改文件找到对应的代码块:
get请求

可以看到对应的http请求的函数为GetTitles出现sql注入的参数是title,该参数没有经过任何处理直接传到了执行sql的GetValueListByStartString函数中,定位到该函数:
sql函数

title参数对应这的startString参数。该参数也是没有经过任何处理就被传入GetInStr函数。查看该函数:
GetInStr

这个只是拼接一下两个参数并没有其他处理,所以回到上个执行sql的函数可以看到,参考一条注入日志,他所执行的sql语句为:

#SQL注入日志
http://www.xxxx.cn/SiteServer/Ajax/ajaxCmsService.aspx?type=GetTitles&publishmentSystemId=1&nodeId=1&title=a',0) > 0 union select TOP 2 PasswordSalt from bairong_Administrator--
#实际执行的SQL语句
SELECT xxx FROM *** WHERE NodeID = 1 AND CHARINDEX('a',0) > 0 union select TOP 2 PasswordSalt from bairong_Administrator-- ', 'Title') > 0

可以看到看一眼源码的话随意就可以成功注入。根据源码可知,此处都是直接拼接sql,解决方案就是不应该拼接sql,使用ORM的方式。

总结

此次攻击可以看到攻击链的源头是未授权访问,对这个接口以及同文件夹下的其他几个接口进行测试可知都存在未授权访问的情况,有可能也存在注入的漏洞。对日志分析也不存在这些接口的正常业务请求,推测是给其他接口内部调用,不应该对外开放。且这次虽然被上传了webshell但是因为之前的安全策略的完备,抵御住了攻击者下一步的攻击,减少了安全事件带来的损失。

你可能感兴趣的:(一次服务器被传webshell事件溯源)