應急響應之文件上傳漏洞排查
前言
在進行年度總結的時候，發現七一重保的時候還進行過一次應急響應，是一起關于非法上傳事件的應急響應，在這里進行一下分析總結。
處置
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.x3，Apache是從右往左判斷后綴，如果為不可識別解析，就再往左判斷。比如 1.php.rar``.rar這種后綴是apache不可識別解析，apache就會把1.php.rar解析成php
修復
配置策略
由于軟件的修復需要一定時間，所以配置防火墻策略，禁止外網ip訪問swagger目錄和上傳路徑；
代碼修復
在代碼層面，將swagger、actuator和上傳文件接口配置訪問權限驗證；
總結
當遇到類似的應急響應事件后，可以按照以下幾個步驟進行處理：
- 1、先對需要處理的事件現場情況進行詳細的了解，與客戶商量先將受害服務器進行斷網關機處理，如果有主機安全管理設備，先對所有主機資產進行病毒查殺。
- 2、先將木馬文件、可疑文件保存本地，然后將服務器上的可疑文件進行清除。
- 3、分析木馬文件是哪種類型的木馬，會造成什么危害，再做出下一步處置。
- 4、排查服務器上的可疑項目，如文件排查、進程排查、內存排查等等，防止攻擊者留下后門。
5、分析漏洞成因，然后先使用waf、防火墻等設備緊急修復漏洞，再等研發人員來徹底修復漏洞。
