奇安信攻防社区-应急响应之文件上传漏洞排查

应急响应之文件上传漏洞排查

在进行年度总结的时候，发现七一重保的时候还进行过一次应急响应，是一起关于非法上传事件的应急响应，在这里进行一下分析总结。

处置：
===

1、查看基本情况
--------

在态势感知上可以看到，文件上传的详细情况，并且已经被攻击者利用成功，攻击者上传的是一个cer的文件格式，通过畸形解析漏洞，成功利用，试了一下发现是个未授权访问的路径。  
![](https://shs3.b.qianxin.com/attack_forum/2022/01/attach-142e4c5f4c0f28b77e6473a9f0b219772edf2505.png)  
查看攻击者的ip，是一个动态的国外恶意ip，未能从ip中获取更多信息。  
![](https://shs3.b.qianxin.com/attack_forum/2022/01/attach-36361559d98b0631f027653a84cc1850f5933d18.png)  
征得客户同意后登上被攻击的那台服务器，查看木马文件，发现是个asp的冰蝎木马，将木马进行了删除操作，然后进行了一些排查防止攻击者做了一些后渗透的工作。  
![](https://shs3.b.qianxin.com/attack_forum/2022/01/attach-3cd3725d9161ff8e8cad873d30e2a589c35d05ae.png)

2、排查可疑项目
--------

1、首先查看一下服务器的基本情况，查看一下开放端口，是否打开了高危端口，比如3389等，万幸得是这台服务器并未开启远程桌面。

```php
查看端口开发情况：
netstat -ano 
查看某个端口是否开放：
netstat -ano|findstr "port"
```

2 、排查可疑账户，运行输入`lusrmgr.msc`查看本地用户和组，账号以$结尾的为隐藏账户，未发现有隐藏账户。  
![](https://shs3.b.qianxin.com/attack_forum/2022/01/attach-f96a2daf30027923eeebe6cce6e0a33b75a0577f.png)  
3、查看是否有可疑的计划任务，PowerShell输入`Get-ScheduledTask`查看所有的计划任务，未发现有可疑的计划任务。  
![](https://shs3.b.qianxin.com/attack_forum/2022/01/attach-2faa7311e66163c755fc80b48f18296bbe7241f1.png)  
4、查看是否有可疑的进程，PowerShell输入`tasklist`查看所有进程信息，也可以在任务管理器中查看，未发现有可疑的进程。  
![](https://shs3.b.qianxin.com/attack_forum/2022/01/attach-d808000adebac6daff182939462a59df0590fded.png)  
5、查看是否有可以文件，查看C盘符下的temp或tmp目录下是否有可疑文件，未发现可疑文件。  
![](https://shs3.b.qianxin.com/attack_forum/2022/01/attach-89e8dd7a7171e13107eddba03587e24439593968.png)  
6、利用d盾等工具查找webshell，未发现有其他的webshell。  
7、查找内存马，使用的工具有dumpit、redline、ram capturer等，未发现内存马

分析：
===

1、漏洞成因
------

万幸没有发现其他的入侵痕迹，只有一个冰蝎马，已经被删除了，那么攻击者是如何找到这个未授权的上传路径呢？路径不是寻常的路径，不太可能通过fuzz或者字典获取，第一时间想到的是源码泄漏。  
扫描网站的目录，未发现存在源码泄漏，又在github上进行了搜索，也没有源码，排除了源码泄漏。  
千思万想中，突然想到了会不会是swagger未授权访问泄漏接口呢，扫了一下旁站，果然发现了一个swagger未授权访问。  
![](https://shs3.b.qianxin.com/attack_forum/2022/01/attach-3052c7d065bb19393f21b94f4ff4623249f5c14d.png)

2、swagger未授权访问
--------------

swagger未授权访问存在于spring框架下，如果有swagger未授权一般还会有actuator未授权，试了一下果然存在。  
![](https://shs3.b.qianxin.com/attack_forum/2022/01/attach-9701bec8f4200253b03c2061e3f1be03df6c5067.png)  
swagger-ui.html会被禁止访问，这时候可以尝试拼接/v2/api-docs进行访问

```php
常见路径
/v2/api-docs
/swagger-ui.html
/swagger
/api/swagger
/Swagger/ui/index
/api/swaggerui
/swagger/ui
/api/swagger/ui
/api/swagger-ui.html
/user/swagger-ui.html
/libs/swaggerui
/swagger/index.html
/swagger-resources/configuration/ui
/swagger-resources/configuration/security
/api.html
/druid/index.html
/sw/swagger-ui.html
/api/swagger-ui.html
/template/swagger-ui.html
/spring-security-rest/api/swagger-ui.html
/spring-security-oauth-resource/swagger-ui.html
/swagger/v1/swagger.json
/swagger/v2/swagger.json
/api-docs
/api/doc
/docs/
/doc.html
/v1/api-docs
/v3/api-docs
```

使用try out按钮可以直接进行发包测试。  
![](https://shs3.b.qianxin.com/attack_forum/2022/01/attach-42ab5ef71d99a5db4f2c9d00193225a87cc7f815.png)

3、攻击复现
------

发现网站存在黑名单限制，成功上传cer格式文件，  
![](https://shs3.b.qianxin.com/attack_forum/2022/01/attach-474c157c7bd6895caabaaef51ac907a63a60debb.png)  
利用IIS6.0解析漏洞，成功连上马子。  
![](https://shs3.b.qianxin.com/attack_forum/2022/01/attach-f45b884b5acfaa2d809ed3c0a3ec89b44c336d3d.png)

4、解析漏洞
------

### 4.1、IIS 6.0解析漏洞

1.目录解析  
`/xx.asp/xx.jpg`  
.asp、.asa命名的文件夹下任何文件都被IIS当作asp文件来解析并执行。  
2.文件解析  
`xx.asp;.jpg`  
比如 1.asp;.jpg ，会被服务器看成是1.asp  
3.解析类型  
IIS6.0默认的可执行文件除了asp还包含

```php
/1.asa
/1.cer  这个就是攻击者成功利用的IIS6.0解析漏洞，成功上传shell
/1.cdx
```

### 4.2、IIS 7.0/IIS 7.5/ Nginx &lt;8.03畸形解析漏洞

在默认`Fast-CGI`开启状况下,攻击者上传一个名为1.jpg，内容为  
`<?PHP fputs(fopen('shell.php','w'),'<?php eval($_POST[cmd])?>');?>`  
的文件，然后访问`1.jpg/.php`,在这个目录下就会生成一句话木马 shell.php

### 4.3、Nginx &lt;8.03 空字节代码执行漏洞

影响版:`0.5.,0.6., 0.7 <= 0.7.65, 0.8 <= 0.8.37`

Nginx 环境下，上传图片马，然后访问`xxx.jpg%00.php`，执行其中的代码

### 4.4、Apache解析漏洞

上传的文件命名为：`test.php.x1.x2.x3`，Apache是从右往左判断后缀，如果为不可识别解析,就再往左判断  
比如 `1.php.rar``.rar`这种后缀是apache不可识别解析,apache就会把1.php.rar解析成php

修复：
===

配置策略
----

由于软件的修复需要一定时间，所以配置防火墙策略，禁止外网ip访问swagger目录和上传路径；

代码修复
----

在代码层面，将swagger、actuator和上传文件接口配置访问权限验证；  
![](https://shs3.b.qianxin.com/attack_forum/2022/01/attach-91e99b7b8e748df827b872ed42c2c9af2b17adb8.png)

总结：
===

当遇到类似的应急响应事件后，可以按照以下几个步骤进行处理：  
1、先对需要处理的事件现场情况进行详细的了解，与客户商量先将受害服务器进行断网关机处理，如果有主机安全管理设备，先对所有主机资产进行病毒查杀。  
2、先将木马文件、可疑文件保存本地，然后将服务器上的可疑文件进行清除。  
3、分析木马文件是哪种类型的木马，会造成什么危害，再做出下一步处置。  
4、排查服务器上的可疑项目，如文件排查、进程排查、内存排查等等，防止攻击者留下后门  
5、分析漏洞成因，然后先使用waf、防火墙等设备紧急修复漏洞，再等研发人员来彻底修复漏洞。

发表于 2022-01-12 09:56:44
阅读 ( 10433 )
分类：应急响应

应急响应之文件上传漏洞排查

0 条评论