KCon 2022 議題分享：自動化 API 漏洞挖掘

作者：周陽、呂竭@星闌科技PortalLab
原文鏈接：https://mp.weixin.qq.com/s/MCtwiT93Fo9Js9ekuD-8wA

演講者介紹

周陽

星闌科技安全研發工程師。具有豐富的漏洞研究及紅隊武器化經驗，歷經主機漏洞掃描、應用漏洞掃描、開源軟件供應鏈安全跟蹤以及漏洞情報管理平臺等多款產品建設，曾參與發現多個linux系統安全漏洞并收到工信部及其他部委致謝。目前專注于API安全研究以及自動化應用漏洞掃描方向。

呂竭

星闌科技安全服務工程師。曾就職于某大型央企，在攻防演練、甲方安全建設方面具有豐富經驗。目前專注于API漏洞挖掘方向，上報數十個SRC API高危/嚴重漏洞，獲得國內多個SRC月榜前十，字節SRC年榜第二。

議題內容

本次分享可以分為三個部分，首先我帶大家來了解一下為什么目前API的安全問題逐漸成為整個行業內討論的熱門話題，其次是分析API都有哪些攻擊面，從攻擊面入手來了解API所面臨的安全風險;最后，我們將分享API Fuzz方案以及一些實戰案例。

首先，讓我們來看看API攻擊崛起的原因。

我們目前正處于一個萬物互聯互通的時代，無論是從IaaS到SaaS，還是從PC到手機再到各種IoT設備，它們都接入了互聯網中進行數字交換，那么API這種數據交換方式也逐漸成為軟件連接“萬物” 的核心載體。API本質上是一種跨語言、跨架構的數據傳輸約定，API連接了不同層次、不同編程語言、不同廠商 所研發的軟件，讓數據可以跨應用軟件進行自由流動。同時隨著云計算、大規模分布式應用、移動互聯網以及IoT基礎設施的蓬勃發展。企業為了提升交付產品的能力，敏捷開發與DevOps也就應運而生。至此，軟件系統研發流 程從類似流水線作業的方式演化為組件并行開發生產，然后再集成的形式。與此同時，后端應用組件的解耦以及SOA架構的普及，使得API逐步成為連接各應用組件的事實標準。

在API高速發展的背景下，API的經濟與生態也逐漸成型，左圖是Gartner總結的API相關技術的成熟度曲線，我們可以看到這里面提到的技術已經有很多落地案例，包括API網關、API管理平臺與API交易市場。右圖是postman提出的API基礎設施生態，包括API解決方案廠商、APM廠商，研發效能廠商、云廠商、安全廠商以及新一代API網關廠商等等。在數字時代下，無論是互聯網的商業創新還是傳統企業的數字化轉型，它們都推動了API經濟的發展。尤其是對傳統行業而言，API就是其價值鏈全面數字化的關鍵所在。

接下來，讓我們把目光投向API的安全問題，這也是目前大家最關心的問題之一。根據API解決方案廠商Postman 統計，2021年度全球API數量增長為39%，API訪問量增長為56%，當下正處于我國數字化轉型的浪潮之中，可以看到我們國內的API增長速度甚至接近80%。隨著API高速發展的同時，我們看到API的安全問題也逐漸被暴露出來，API安全已經成為企業關注的焦點。例如:2020年7月，美國開放銀行泄露了700萬用戶的數據，其中包括用 戶的姓名，電話，家庭住址，出生年月等關鍵信息;2021年4月，Facebook在線業務API泄露的5億多用戶數據在暗網公開售賣，這些信息也包括用戶的姓名，電話，家庭住址等關鍵信息；同樣，像領英，一些大型電商平臺等等不同的行業，不同的領域的企業都產生過由API安全漏洞所引發的數據泄露事件，嚴重損害了相關企業和用戶權益。在此之前，數據泄露事件一般都是由于數據庫被拖庫或數據庫暴露公網導致的。而隨著API的快速增長，近年來我們看到由API導致的數據泄露事件也越來越多了。

下面簡單了解一下API都有哪些攻擊面。

首先，我們先來看一下API協議的類型，目前的IT基礎設施中各個層次都充滿了API的交互，那么我們本次分享內容主要討論應用層的API通信協議，按照使用量來看，目前使用最多的是RESTful API，然后是 webhooks、graphql等這些常見的API，也有像gRPC，MQTT這樣偏底層的API協議，這些API協議的異構性本身攜帶著一些安全問題，我們后面討論API Fuzz的時候也會涉及到協議解碼問題。

接下來我們來看看API的攻擊面到底有哪些，這是OWASP給出的API安全所面臨的十大風險。根據我們實戰經驗總結出右邊這幾種關鍵問題。首先是越權，權限問題是API失陷或者數據泄露的最常見原因，包含垂直越權、水平越權和未授權訪問，比如通過未授權訪問的API拿到用戶數據。之后是敏感數據暴露，比如在API設計不當時，下游業務 方只需要兩個字段，但卻從上游的API接口中獲取到了10個字段，其中多余的字段可能會導致不必要的數據泄露。

接著是代碼漏洞，由于API后端是代碼邏輯實現的，因此API同樣會面臨應用安全領域的代碼漏洞，例如SQL注入，命令執行等，這些大多數情況都是由于業務開發者的疏忽所導致的。同樣像API網關、API管理平臺這類API基礎設施 自身的一些安全漏洞，會導致托管在其上的API受到影響。此外還存在一些不安全的業務配置以及業務風控領域的問題。

這些問題里面，最嚴重的是API越權問題，舉個例子，這是2021年12月爆發的SonarQube未授權下載源碼事件。導致源碼泄露的原因是，在默認配置的情況下，SonarQube缺少對API接口的訪問權限控制，攻擊者可利用該漏洞在未授權的情況下，通過訪問API/settings/values接口從而獲取到 SMTP、SVN、GitLab 等憑據，從而進一步獲取代碼倉庫中的源代碼，造成項目源代碼泄露。

同樣的，針對新的API基礎設施，它們也面臨著自身系統的API安全問題，這是前段時間披露出來的一個國外主流API平臺存在的未授權文件上傳漏洞，允許未經身份驗證的攻擊者通過上傳惡意JSP文件從而達到RCE。這就是通過攻陷API平臺本身從而威脅到其承載的API，同樣的，其他API基礎設施也出現過類似問題。比如Apache的APISIX，它之前bacth-requests插件存在權限繞過漏洞、Dashboard存在越權漏洞。本質上還是權限問題，可見權限對于API來講確實是一個不可忽視的安全風險。

那么我們反過來思考，導致API問題頻發的原因到底是什么?從API的生產者角度，也就是站在企業的角度來看有三點:一是大規模分布式系統及復雜應用架構帶來API數量迅猛增長，在業務增長的同時，我們是否針對API建立起完整的安全管理規范。二是基于API-First理念構建的研發流程，極短的迭代周期導致API變動跟蹤困難。三是傳統安全測試和防護工具對API風險收斂的失效，需要面對多種API協議之間的差異、以及頻繁變化的API、自定義的路徑等等都為API安全測試帶來困難。從攻擊者的視角來看，也可以分為三點：首先，API攻擊路徑更短，API可以直達數據而不必像傳統入侵那樣需要通過內網，進行好幾層侵入，最終才能拖取數據，API壓縮了攻擊鏈路；同時，在API生態迅猛 發展的背后，安全性是滯后的，這里有大量的API基礎設施的漏洞仍未被發掘；此外是云原生應用尤其是容器化、微服務大規模落地之后，API成為了不同系統模塊間主要的通信方式，因此在攻擊者視角是一件投入產出比很高的事情。

下面為大家介紹API Fuzz方案及實戰案例。

首先我們先從以下幾點了解一下傳統web Fuzz方法的弊端。

第一點就是API的路徑是自定義的，無法被漏掃發現。一般我們在對一個目標進行測試的時候可能會先用掃描器進行掃描，看看這個站點是否存在什么已知漏洞，或者使用路徑爆破工具去爆破一下看看是否存在什么敏感目錄，文件或者接口，但是這種基于爬蟲的web掃描和基于字典的爆破工具能獲取到的API路徑是不全的。我們只能通過請求返回的狀態碼來判斷這個API是否存在。

第二點是API參數結構復雜，不能直接插入payload。傳統的web Fuzz是基于get/post協議解析form表單，而API是存在多種協議格式， 多層嵌套的參數結構，還有參數內編碼等復雜場景的，所以以傳統的方式去做還不夠滿足使用者的需求。

第三點是傳統的Web Fuzz工具生成的payload針對API場景很多是無效的。很多比如XSS問題，其實API攻擊場景是很少關注的，這樣web Fuzz工具在測試過程中會生成大量的無效請求，導致測試時的效率會比較低下，反而API的權限問題等真正需要關注的問題沒法有效發現。

我們針對以上提到的這些問題提出了一套新的自動化API Fuzz思路。我們先簡單的對這個思路進行一個概述。

首先從自動化漏洞測試的角度來看，第一步就是如何發現API資產。在發現API路徑方面我們有兩種方式，第一種是通過解析swagger文檔第二種是進行API通信流量分析，這兩種方式都可以得到確切的API路徑，參數結構，參數類型等信息，可以更全面的發現和了解目標站點存在的API，方便后續的測試工作。

然后是針對payload有效性的問題，我們通過對請求序列進行分析，獲取API請求的順序，并根據返回值確認API參數值的大概范圍，可以生成更精準的Fuzz向量，確保payload能夠正常傳遞到API后端。

最后，在API傳參復雜性的問題上，我們通過使用樹結構參數解析以及遞歸解碼的方式，對API進行值的變異，結構的變異，參數污染等等來提高漏洞發現的效率及準確性。

從獲取API資產角度，首先是Swagger文檔的解析。Swagger是一個規范和完整的框架，用于生成、描述、調用和可視化RESTful風格的API接口。我們可以從Swagger文檔中獲取API服務的很多重要的信息，例如basePath就是API的路徑，host域名，以及請求報文中包含的參數等信息，其中就有這個API有哪些參數，名字是什么，參數值的類型，請求的格式等等。并且他還會提供一些范例來進行一個請求的測試。使用起來非常的方便。

在swagger文檔中可以根據API的請求順序得到更精確的參數值信息。例如左上這個截圖是一個商店的功能，我們通過對/store/order這個API發起post請求創建訂單，然后從響應結果中獲取到訂單編號也就是orderId的值，通過參照獲取到的orderId參數值的格式，生成Fuzz向量，例如這是一個8位的數字格式，我們可以對后四位數字取隨機數。再對這個接口發起get請求測試其是否存在像越權查看別人訂單的漏洞。相同的，其他的參數也可以依次的使用此流程進行測試。

swagger文檔的存在非常便于業務的開發和測試，但是一旦泄露也是非常的危險。在實際的漏洞挖掘過程中，也經常可以遇到swagger文檔的泄露，其中還存在很多危害較高的API未授權漏洞。例如通過調試的功能去修改admin用戶的密碼，或者通過切換用戶的接口直接獲取admin用戶的token等等。

獲取API參數結構的第二種方法，就是通過代理獲取請求數據包，并根據不同的API風格對參數結構進行還原。由于代理流量中存在大量的重復訪問和一些靜態文件流量所以在做還原之前還需要進行一步篩選工作。

流量還原就是將API路徑作為根節點，其參數作為葉子節點的樹型結構邏輯，并通過統計的方式判斷URL path里哪些路徑是定值，哪些是可變參數。

通過這個例子可以輔助我們理解參數解析的樹狀結構，最左邊的圖是一個json格式的API參數，通過對參數進行分組然后展示為右邊這個樹狀結構圖。root作為API的根節點，下面分支為各級參數的支節點和葉子節點，這樣看上去非常的直觀，然后我們在這個基礎上再進行后續的對結構的變異和對節點的變異。

以樹結構為基礎的API Fuzz，可以按照以下四點實施對節點的變異。第一點按照數據類型注入payload，舉個例子，isVip節點是布爾類型的參數，原始值是false，那么我們可以將其替換為true之后觀察其響應包的變化，例如用戶是否從普通用戶變成了高權限用戶。第二點是注入通用型payload，類似在圖中name節點上在原值后面拼接SQL注入的payload，對每個參數都依次進行檢測再觀察響應的變化。第三點是畸形數據替換，他可以在第二點的基礎上加入一些控制字符，注釋符，運算符等用來繞過一些安全設備。最后一點是類型轉換，例如下面這個 count參數，他的類型是number數字類型，我們可以將他改為string類型，來觀察響應包的變化，有可能發現一些報錯信息或者50x相應，接下來可以手工進行測試。

在節點變異之后是對樹結構的變異。

同樣的，對樹結構的變異有三個方式。首先是可以替換object類型結構，替換單個節點或一整個子樹，這樣相當于傳統漏掃里的session替換，因為API的session身份持久化很多靠的是token而不是cookie。第二點是插入節點，就是在原有的結構基礎上增加新的葉子節點，這樣可以進行一些隱藏參數的探測，或者通過攜帶一些場景的認證后的權限字段繞過鑒權等。最后，可以進行節點的刪除，這個在后面的實戰案例中會提到，他或許可以繞過某些驗證措施。

通過這些方式改變原有的參數結構有時候會獲得意想不到的效果。

然后再介紹一下關于參數編碼問題與遞歸解碼器。實際環境中的請求體格式非常復雜，可能是表單類型字符串，json字符串，xml字符串等，這里面還可能傳遞路由，或者請求的字段存在不同的編碼方式，參數中存在嵌套/循環編碼模式，直接進行Fuzz無法起到預期的污染效果。

例如下面的這個例子，name等于一個base64編碼的字符串，直接在后面拼接sql注入的payload是不能成功的，因為多了一層base64的編碼，因此需要在對他進行解碼后拼接payload再按照原來的方式進行編碼，才能真實把payload傳遞到后端。這里為了做到自動化，還需要去識別各節點的編碼模式和層數，遍歷和組合所有節點，解碼注入payload，然后按照識別的模式重新組裝數據后再進行編碼，最后發包測試。

簡單的總結一下：API Fuzz就是通過給API提供非預期的輸入然后監控輸出中的異常來發現漏洞，并且在這個過程中不斷的調整和完善Fuzz向量來提高效率和命中率的這樣一個方案。下面我們來講一些漏洞Fuzz的實際案例來幫助我們理解一下之前講到的思路。

案例一，Fuzz出特定參數值實現零元購。這是在購買某項服務的時候，通過抓包可以看到這個post請求中包含4個參數。其中resourceID這個參數是采用的base64編碼，在購買頁面上可以看到這里是可以對用戶所屬的組進行選擇，所購買的服務的項目和價格也會隨著變化，其他三個參數的選擇不會影響訂單的金額，那么就對resourceID這個參數進行Fuzz，并且在對Fuzz出的值進行base64編碼，最后成功發現default這個可以免費購買服務。這個值在頁面的選項中是看不到的，屬于隱藏值，可能是在業務的迭代過程中被遺忘的，但是屬于一旦被利用可以直接對公司造成經濟損失的漏洞。

案例二，改變參數結構實現交易密碼的繞過。這也是在購買的情況下，這個是某個基金交易平臺。在購買基金的時候抓包，可以看到他存在tradepassword參數，也就是我們需要輸入交易密碼才可以完成交易。正常情況下我們需要輸入一個正確的交易密碼，輸入錯誤密碼會得到提示并且返回到輸入密碼的界面。但是當我們Fuzz工具嘗試將這個參數刪掉時發現請求能正常執行，并且放行后交易完成了。可以理解為這個業務的邏輯漏洞是當請求里沒有交易密碼這個參數了，他就不會去進行驗證了，繞過了一道安全措施，也就是說對參數結構的變異生效了。

第三個案例，參數解析插入payload實現rce。這是一個Maven倉庫管理器，某些版本存在一處任意EL表達式注入漏洞。但是當我們在進行Fuzz的時候，是假定不知道這個漏洞的觸發點，我們可以在請求的任意參數后面拼接這個payload，當我們發現返回的數據中執行了這個表達式，那么就代表此處存在漏洞。那么在這里我們可以看到，是因為我們的Fuzz系統能夠做到json內部細粒度的參數結構解析，才能精準的注入到這個位置，針對API的場景如果還在用HTTP post K-V的方式進行參數污染，是很難找到漏洞的。

第四個也是最后一個案例，這里我們看到，API同樣也受到傳統漏洞SQL注入的影響，原始的HTTP GET/POST API仍然有產出漏洞的空間，在我們的Fuzz工具中也針對這種基礎情況做了覆蓋。這里是一個存在SQL注入的API。在web頁通過點擊個人資料的查詢，即可看到自己的姓名，聯系方式，職位，部門是誰，還有公司郵箱等等的信息。根據userid和foldername來篩選數據。這時將filter里的條件注入即可列出所有員工的信息，造成一個比較嚴重的信息泄露。

那么今天為大家分享的內容就已經結束，感謝大家的觀看并歡迎反饋。

本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/1964/