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

VSole2023-09-25 10:13:51

前言

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

处置

1、查看基本情况

在态势感知上可以看到,文件上传的详细情况,并且已经被攻击者利用成功,攻击者上传的是一个cer的文件格式,通过畸形解析漏洞,成功利用,试了一下发现是个未授权访问的路径。

查看攻击者的ip,是一个动态的国外恶意ip,未能从ip中获取更多信息。

征得客户同意后登上被攻击的那台服务器,查看木马文件,发现是个asp的冰蝎木马,将木马进行了删除操作,然后进行了一些排查防止攻击者做了一些后渗透的工作。

2、排查可疑项目

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


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


2 、排查可疑账户,运行输入lusrmgr.msc查看本地用户和组,账号以$结尾的为隐藏账户,未发现有隐藏账户。

3、查看是否有可疑的计划任务,PowerShell输入Get-ScheduledTask查看所有的计划任务,未发现有可疑的计划任务。

4、查看是否有可疑的进程,PowerShell输入tasklist查看所有进程信息,也可以在任务管理器中查看,未发现有可疑的进程。

5、查看是否有可以文件,查看C盘符下的temp或tmp目录下是否有可疑文件,未发现可疑文件。

6、利用d盾等工具查找webshell,未发现有其他的webshell。

7、查找内存马,使用的工具有dumpit、redline、ram capturer等,未发现内存马

分析

1、漏洞成因

万幸没有发现其他的入侵痕迹,只有一个冰蝎马,已经被删除了,那么攻击者是如何找到这个未授权的上传路径呢?路径不是寻常的路径,不太可能通过fuzz或者字典获取,第一时间想到的是源码泄漏。

扫描网站的目录,未发现存在源码泄漏,又在github上进行了搜索,也没有源码,排除了源码泄漏。

千思万想中,突然想到了会不会是swagger未授权访问泄漏接口呢,扫了一下旁站,果然发现了一个swagger未授权访问。

2、swagger未授权访问

swagger未授权访问存在于spring框架下,如果有swagger未授权一般还会有actuator未授权,试了一下果然存在。

swagger-ui.html会被禁止访问,这时候可以尝试拼接/v2/api-docs进行访问,常见路径有:


/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按钮可以直接进行发包测试。

3、攻击复现

发现网站存在黑名单限制,成功上传cer格式文件,

利用IIS6.0解析漏洞,成功连上马子。

4、解析漏洞

4.1 IIS 6.0解析漏洞

1. 目录解析,.asp、.asa命名的文件夹下任何文件都被IIS当作asp文件来解析并执行。


/xx.asp/xx.jpg

2. 文件解析,比如 1.asp;.jpg ,会被服务器看成是1.asp


xx.asp;.jpg

3. 解析类型IIS6.0,默认的可执行文件除了asp还包含


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

4.2 IIS 7.0/IIS 7.5/ Nginx <8.03畸形解析漏洞

在默认Fast-CGI开启状况下,攻击者上传一个名为1.jpg,内容如下的文件,然后访问1.jpg/.php,在这个目录下就会生成一句话木马shell.php


<?PHP fputs(fopen('shell.php','w'),'<?php eval($_POST[cmd])?>');?>

4.3 Nginx <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.x3Apache是从右往左判断后缀,如果为不可识别解析,就再往左判断。比如 1.php.rar``.rar这种后缀是apache不可识别解析,apache就会把1.php.rar解析成php

修复

配置策略

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

代码修复

在代码层面,将swagger、actuator和上传文件接口配置访问权限验证;

总结

当遇到类似的应急响应事件后,可以按照以下几个步骤进行处理:

  • 1、先对需要处理的事件现场情况进行详细的了解,与客户商量先将受害服务器进行断网关机处理,如果有主机安全管理设备,先对所有主机资产进行病毒查杀。
  • 2、先将木马文件、可疑文件保存本地,然后将服务器上的可疑文件进行清除。
  • 3、分析木马文件是哪种类型的木马,会造成什么危害,再做出下一步处置。
  • 4、排查服务器上的可疑项目,如文件排查、进程排查、内存排查等等,防止攻击者留下后门。

5、分析漏洞成因,然后先使用waf、防火墙等设备紧急修复漏洞,再等研发人员来彻底修复漏洞。

漏洞swagger
本作品采用《CC 协议》,转载必须注明作者和本文链接
Swagger-UI中存在跨站脚本漏洞,虽然该漏洞已在2020年末修复被修复,但截止2022年5月16日,研究人员仍然可以在Paypal、Atlassian、Microsoft、GitLab、Yahoo等网站中发现漏洞的实例。
一次简单的渗透测试记录
0x01 目标某平台系统0x02 流程0x03 测试拿到站点后先做信息收集,扫描目录看看有无敏感信息寥寥无几,没有任何信息,启动burpsuite打开网站走一遍流程。在创建目标处存在图片上传接口,上传shell试试。
0x01 确定目标无目标随便打,有没有自己对应的SRC应急响应平台不说,还往往会因为一开始没有挖掘到漏洞而随意放弃,这样往往不能挖掘到深层次的漏洞。所以在真的想要花点时间在SRC漏洞挖掘上的话,建议先选好目标。0x02 确认测试范围前面说到确定测什么SRC,那么下面就要通过一些方法,获取这个SRC的测试范围,以免测偏。
拿到一个系统后,很多情况下只有一个登录入口。如果想进一步得到较为高危的漏洞,只能去寻找权限校验相关的漏洞,再结合后台洞,最终得到一个较为满意的漏洞
扫描 REST API 中的漏洞
2020-09-03 17:04:24
许多复杂的Web应用程序都是使用REST API构建的。与整体Web应用程序和网站一样,Acunetix可以帮助您确保所有REST API的安全性。在本文中,您将学习如何使用OpenAPI,Swagger或WADL定义来发现和修复REST API中的漏洞:...
在进行年度总结的时候,发现七一重保的时候还进行过一次应急响应,是一起关于非法上传事件的应急响应,在这里进行一下分析总结。
我们最近在 Azure Cosmos DB 上发现了一个非常重要的漏洞,其中 Cosmos DB Notebooks 中缺少身份验证检查。我们将其命名为“CosMiss”。我们要感谢 Microsoft 的合作以及他们为保护此漏洞而采取的快速行动。Jupyter Notebooks 内置在 Azure Cosmos DB 中,供开发人员用于执行常见任务,例如数据清理、数据探索、数据转换和机器学习。据我们所知,获取 forwardingId 的唯一方法就是以经过身份验证的用户身份打开 Notebook。此外,客户使用此功能来检查来自 Cosmos DB 的数据以及可以使用其 API 集成的其他数据源。
挖掘方式很简单,既然系统通过检测Cookie等认证因子进行判断是否登录,那么只需要将认证因子删除,分析删除前后返回包的变化即可判断。)未使用cookie鉴权要挖掘越权类漏洞,不能局限于1、2个功能点。常见方式便是通过全局搜索userid、id、countid等字符,通过修改对应id值进行判断。
VSole
网络安全专家