24

记一次IIS劫持处置

 4 years ago
source link: https://www.freebuf.com/articles/web/222060.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

晚上十一点四十,刚准备休息,收到朋友电话,其一个站点被入侵篡改,导致某web接口异常,帮忙远程处理。 

D盾一把梭:

网页篡改、服务器入侵类事件处理了几年,第一反应是服务器被提权,中了后门,占用CPU、内存等资源,导致站点无法工作。

对方管理员登录服务器后,TV链接到管理员电脑,查看为2008R2系统,采用IIS7.5作为web服务,web为.net4.0开发。

下载D盾( http://d99net.net/down/d_safe_2.1.5.4.zip )对着站点一把梭。

检测到一个一句话后门,访问路径: http://service.xxx.com/js/post.aspx .

经过IIS日志查询访问IP,均为香港IP和某存活检测蜘蛛,备份后门文件后删除。

查看账户,guest被克隆,备份注册表sam项后手动删除guest账户的键值。

查看提权常用的C:\Windows\temp、C:\Windows\debug目录,无任何熟悉的提权脚本和文件,瞬间怀疑人生。

ueYJru3.jpg!web

怀揣着忐忑的心,看了下目录权限和IIS权限,web目录everyone完全控制,IIS程序池标识为管理员账户!

2ieMvav.jpg!web

这完美的操作,完全不用提权呀。

诡异不断:

异事件一、发现被入侵后,WEB接口坏了

删除完webshell和克隆账户,上了啊D做临时防护,正准备让管理员修改密码并默默杀毒、我下线睡觉。告知站点api接口访问不了。访问接口地址为: http://service. 马赛克.com/app/xxx.ashx

查看web目录下app目录存在,文件存在,一访问却提示404找不到对象。

nUNNZrM.jpg!web

往app文件夹新建一个txt文件,访问,继续找不到对象。再次懵逼。

一般情况下IIS会对asp、php、aspx、ashx等设置处理程序映射。如下图,

V3Ifmyr.jpg!web

静态文件,html、txt、css这类默认不需要指定可执行文件处理。

静态文件也404找不到对象!第一反应,站点根目录web.config被篡改,对app路径做了URL重写。(.net的URL重写和J**A的URL路由类似,可直接由站点bin目录下的dll处理)

打开web.config查看,有伪静态规则转发请求到app目录下程序处理,但是未对/app/xxx这种路径做任何设置。

iqQJjqQ.jpg!web

异事件二、 Windows下IIS竟然区分大小写!

访问时候切换输入法,大写锁定,发生了奇迹。 http://xxx. 马赛克.com/APP/xxx.ashx这种路径竟可以正常请求到,简单测试,aPp、aPP、App都可以访问到。到这里基本确定是IIS上有程序作了URL处理。

rIZZZrU.jpg!web

管理员发了挂马详情:从百度搜索进入,即可看到非法信息。

整个过程瞬间清晰了,这不就简单的url劫持么,判断来路、路径,再选择性返回菠菜信息。常规套路。

rEFfa2e.jpg!web

诡异事件三、死活找不到跳转文件。

根据以往经验,查global.asax,一行一行看了2分钟,没有问题,再打开web.config看了2分钟,没有问题。

C:\Windows\System32\inetsrv\config目录(IIS7的站点配置均存储于此)下配置文件文件,搜索app关键词,没有问题。

点开微信,此刻,朋友圈已经开始下雪了。

啊D再次救场

看着朋友圈,回顾了整个过程:

 1、使用百度蜘蛛UA访问带app关键字的的URL会被挂马
 2、无挂马文件

到这里,基本确定是加载的dll扩展出了问题。

建立一个站点,指向IIS默认站点路径,修改百度UA后访问/appxxx验证,的确出现了卖菜信息。

AbEjqyA.jpg!web

n6jQRjY.jpg!web

点开啊D,进程查看,定位到web进程,w3wp.exe

z2MBRr7.jpg!web 加载了一个连公司信息和说明都有不起的dll。豁然开朗。

查:

查看IIS全局设置中isapi筛选器和模块设置,在模块功能下找到了真凶。

NzAj63F.jpg!web

U77NZzy.jpg!web杀:

找到问题后,处理就比较简单,右键删除模块,然后在配置本机模块功能下,选择刚才删除的模块名,删除、重启IIS即可。

uaqm2er.jpg!web

访问app路径验证,终于出现了久违的找不到对象提示。

jmym22R.jpg!web

简单分析:

通过在测试服务器上加载dll并触发事件,抓包查看到如下流量:

uIRb6ja.jpg!web 在条件满足(路径带app字样且UA为蜘蛛)情况下,IIS进程会请求 http://sc.xxxbt.com/xxx 路径,并返回请求到的内容。

viIBrqJ.jpg!web 到此,app接口恢复正常,挂马不复存在。

剩下的由管理员查杀后门,临时恢复业务,择日重新部署新系统并加固。

由于当年300百元拜师费没有拜逆向师傅,只能从流量层面做简单分析。

经测试,URL带app、hot字样,均会产生内容劫持,有遇到类似情况的可以参考处理。

感兴趣的可以下载dll文件做复现或分析:

链接: https://pan.baidu.com/s/1cBo6Nob7Uhv2PHg7ySYIQA

提取码: byiz

*本文作者:r41nbow,转载请注明来自FreeBuf.COM


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK