伺服器端請求偽造攻擊導致大量科技、工業和媒體組織信息泄露
摘要
伺服器端請求偽造（SSRF）是一個Web應用程序漏洞，可將攻擊者的請求重定向到防火牆後的內部網路或本地主機。由於使用了元數據API，因此SSRF對雲服務構成了特殊的威脅，這些元數據API允許應用程序訪問底層雲基礎架構的信息，例如配置、日誌和憑據。原本只能在本地訪問這些元數據API，但SSRF漏洞使得這些內容可以從網路進行訪問。另外，此類漏洞也繞過了容器的沙箱保護。可以說，SSRF無疑為內部網路偵查、橫向移動甚至是遠程代碼執行打開了一扇新的大門。
默認情況下，容器中的應用程序可以直接訪問其主機上的元數據API，從而實現一種特殊的容器逃逸方式。為了深入探究這一問題的嚴重性，Unit 42的研究人員仔細分析了Jira SSRF漏洞（CVE-2019-8451），並研究了該漏洞對於6個公有雲服務提供商（CSP）的影響。這一漏洞也是導致2019年7月Capital One數據泄露的罪魁禍首。
我們的漏洞掃描器發現：
1. 超過7000個公有雲中的Jira實例暴露在互聯網上；
2. 在7000多個Jira實例中，有45%（3152個）未安裝CVE-2019-8451的補丁或更新，容易受到此CVE的攻擊；
3. 在3152台易受攻擊的主機中，有56%（1779台）泄露了雲基礎架構的元數據。
根據NVD給出的信息，這個CVE漏洞最初是在v7.6中引入的，但是我們發現這個CVE實際上最早影響v4.3的版本（發佈於2011年3月），而並非v7.6（2017年11月）。泄露的元數據可以是內部網路配置，也可以是源代碼或憑據。受到這一漏洞影響的組織包括科技類、工業類和媒體類的企業。
伺服器端請求偽造
伺服器端請求偽造（SSRF）是一個Web應用程序漏洞，它會將惡意請求重定向到伺服器的受限資源。攻擊者通過欺騙易受攻擊的應用程序，將惡意請求轉發到任意域名，包括內部網路和本地主機，從而規避了防火牆。SSRF請求的最常見類型是HTTP，但其他有效的統一資源標識符（URI）方案，例如主機文件系統（file:////）、字典服務（dict://）、Redis服務（redis://）都可以實現。只要應用程序支持URI方案，攻擊者就可以訪問與易受攻擊伺服器具有信任關係的任何目標。攻擊者可以輕鬆到達目標，而無需進行任何其他身份驗證。
SSRF的根本原因在於，Web應用程序需要從另一個域名檢索資源來滿足請求，但是輸入URL未被正確清理，並允許攻擊者操縱自定義目標地址。在CVE-2019-8451中，容易受到攻擊的API /plugins/servlet/gadgets/makeRequest?url=endpoint從服務提供商終端獲取數據，以填充到小工具中。伺服器確實驗證了查詢字元串，並且僅允許白名單內的終端。但是，由於JiraWhiteList類中的邏輯錯誤，參數字元串中的@符號可以繞過白名單驗證。因此，發送到http://vulnerablehost.com/plugins/servlet/gadgets/makeRequest?url=http://vulnerablehost.com@http://targethost.com的請求將會重定向到targethost.com。因此，這個邏輯漏洞使攻擊者可以將HTTP請求發送到易受攻擊的伺服器可以訪問的任何目標。
公有雲中的元數據API
幾乎所有的雲服務提供商都會提供一個元數據API，這個API允許VM實例中的進程掌握特定於該VM的信息。元數據服務為應用程序提供了一種簡單的方法，可以了解其運行的環境，並相應地調整配置。元數據API提供了諸如實例ID、映像ID、私有IP、公有IP和網路配置之類的信息。有時，還會在元數據服務中放置VM啟動和關閉腳本，以便可以使用不同的設置創建基於同一映像的多個VM實例。一些CSP還允許應用程序將動態數據寫入元數據API，並將其用作臨時數據存儲。
元數據API只能從VM實例內部訪問，不對主機外部公開。儘管可以將任何私有IP分配給這個API，但大多數公有雲服務提供商都使用不可路由的（本地鏈接）IP地址169.254.169.254。舉例來說，一個進程可以在AWS EC2實例中發出curl命令，以檢索與該角色相關聯的安全憑證，如下圖所示：
curl
http://169.254.169[.]254/latest/meta-data/iam/security-credentials/role-name
默認情況下，任何用戶或進程都具有對元數據API的完全訪問許可權。一個有趣的發現是，即使是容器中的應用程序（例如：Docker、Kubernetes、ECS、EKS），也可以訪問主機的元數據API。從容器訪問主機元數據的這種場景既方便又危險。一方面，容器中的應用程序可以查詢主機元數據API，並使用附加的憑據來訪問其他雲服務，例如S3和RDS。另一方面，主機元數據APAI創建了一個容器「逃逸路徑」，允許容器化的應用程序直接訪問敏感的主機元數據。如果容器遭到破壞，攻擊者可以利用這個路徑來攻擊雲中的其他主機或其他服務。這樣一來，這一功能的潛在風險要高於收益，因為主機可以通過其他方式與容器共享數據，而不會暴露元數據。
從元數據API檢索憑證：
儘管元數據服務永遠不會暴露到互聯網上，但是它可能會被一些脆弱的、面向互聯網的應用程序間接暴露。SSRF漏洞實質上是將元數據服務暴露給整個互聯網。攻擊者可能使用泄漏的元數據進一步攻擊VPC中的其他主機，甚至接管整個雲基礎架構。其中，我們列舉了一些敏感的元數據，以及這些元數據可能產生的潛在影響。
1. IAM數據：可以用於訪問其他雲服務，例如S3 Bucket或容器註冊表。如果將管理員身份附加到實例，或者為該身份提供了過多的特權，那麼攻擊者還有可能會成功攻擊整個雲基礎架構。
2. 用戶數據：用戶指定的數據可以存儲在元數據中。VM啟動和關閉腳本通常也放置在用戶數據中。這些數據可以泄露VM能夠訪問的應用程序配置、VM配置以及其他雲資源。在腳本中，也經常能找到硬編碼的一些憑證。
3. VM映像ID：如果該映像是公開的，那麼惡意攻擊者就可以檢查VM並設計滲透策略。
4. 網路配置：這部分內容可能會泄露網路信息，例如VM的私有/公用IP、MAC地址、本地主機名、子網以及VPC。
為了防止濫用元數據API，一些雲服務提供商在元數據HTTP請求中需要檢查特殊的標頭。例如，Azure VM會檢查是否存在「Metadata: True」標頭，而Google Compute Engine檢查「Metadata-Flavor: Google」標頭。如果不包含特定標頭，HTTP請求將會被拒絕。標頭的強制要求有效阻止了SSRF訪問元數據API的漏洞，因為攻擊者無法控制重定向請求中的標頭。下面我們列舉了6個雲服務提供商的元數據API。
來自不同雲服務提供商的元數據API服務：
* 其中，GCP開始在元數據API V1中強制執行標頭要求。
公有雲中存在的CVE-2019-8451漏洞
為了了解SSRF對公有雲的真正影響，我們需要找到一個存在SSRF漏洞並且廣泛部署在公有雲中的應用程序。Jira引起了我們的注意，因為它存在2019年8月發現的SSRF漏洞CVE-2019-8451，並且在無需身份驗證的情況下就可以利用這個漏洞。儘管該漏洞對應的補丁立即被發布，但與業務運營緊密相關的Jira軟體很少會立即得到更新。系統管理員往往傾向於延遲應用補丁的時間，以避免業務運營的中斷。根據Shodan的搜索結果顯示，目前有大約25000個Jira實例暴露在互聯網上。然後，我們選取了Jira部署數量最多的6個雲服務提供商進行了研究。我們研究的目的是確定公有雲中易受CVE-2019-8451漏洞攻擊的Jira實例數量、這些Jira實例的可利用情況以及泄露元數據的主機數量。我們針對6個公有雲服務提供商找到了7002個Jira實例，下圖展示了Jira版本的分布情況。
公有雲中暴露的Jira版本統計：
考慮到CVE-2019-8451首先在v8.4中進行了修復，上圖中有80%的Jira實例版本都低於8.4%，如果沒有及時進行修復，則這些實例都容易受到攻擊。我們的掃描結果顯示，在7002個Jira實例中，有3152個（佔比45%）實例尚未打補丁，並且確認為是易受攻擊的。下圖展示了尚未修復漏洞的10個主要Jira版本。在3152個易受攻擊的Jira實例中，其中有1779個（佔比56%）實例泄露了主機的元數據。下面的表格中總結了所有雲服務提供商的統計信息。DigitalOcean客戶的元數據泄漏率最高，達到了93%，其次是Google Cloud客戶（80%）、阿里雲客戶（71%）、AWS客戶（68%）和Hetzner客戶（21%）。唯一的元數據泄漏數量為0的雲服務提供商是Microsoft Azure，因為它對元數據API標頭的嚴格要求有效阻止了所有SSRF請求。儘管GCP在最新的元數據API（v1）中強制執行標頭要求，但是如果未明確禁用舊版本API終端（v0.1和v1beta1），攻擊者就仍然可以使用舊版本API訪問到大多數元數據。
容易受到CVE-2019-8451攻擊的10個主要Jira版本：
公有雲中易受攻擊的主機數量和元數據泄漏數量：
從上圖中，我們還能得到一個額外發現，排名最高的10個Jira版本中，有2個（v7.3.6和v6.3.6）不在Jira發布的易受攻擊版本範圍之中。根據Jira和NVD發布的漏洞說明，CVE-2019-8451最初是在v7.6中引入，並且在v8.4中修復。但是，我們的掃描結果表明，這一範圍之外的許多版本也容易受到攻擊。為了找出受漏洞影響的真正版本範圍，我們檢查了導致SSRF的漏洞類JiraWhiteList。我們發現，從v4.3開始，這個只有一種方法的簡單Java類就已經存在於Jira中。對舊版本Jira軟體的進一步研究表明，該漏洞確實影響了早在8年前（2011年3月）發布的v4.3版本。
修復建議和最佳實踐
導致SSRF漏洞的根本原因，是缺少適當的輸入清理功能。為了從根本上解決問題，開發人員應該在將用戶輸入傳遞給應用程序邏輯之前，嚴格驗證用戶輸入的格式和模式。對於僅負責安裝和管理Web應用程序的系統管理員，我們提出了一些建議的預防性措施，可以緩解SSRF漏洞產生的潛在影響，具體包括：
1. 域名白名單：大多數應用程序僅需要於少數域名進行通信，例如資料庫和API網關。設置一個允許應用程序進行通信的域名白名單可能會大大減少攻擊者能夠攻擊的服務數量。
2. 零信任網路：一個應用程序永遠不應該僅僅因為它們位於同一個內部網路中，就信任另一個應用程序。如果目標服務需要身份驗證，那麼SSRF漏洞攻擊也就無法實現了。認證和授權應該實現在每個應用程序上。
3. Web應用程序防火牆（WAF）：WAF可以檢測HTTP請求中的異常模式或惡意內容。但是，WAF通常適用於為已知漏洞或具有明顯模式的攻擊（例如：SQL注入、XSS）而創建的規則。0-day漏洞可能仍然會繞過WAF。
4. 修復程序和更新：及時修復和更新應用程序，是防範任何漏洞的最簡單、最有效方法。但是，這種方式僅限於供應商提供了修復的支持。如果超出支持生命周期的應用程序，可能將不會收到更新。
如上文所述，元數據API也可以由雲服務提供商進行充分的保護。但是，如果雲服務提供商暫時沒有採取保護措施，雲用戶也可以採取如下預防措施以減少元數據泄漏的風險：
1. 啟用雲服務提供商的數據API保護：一些雲服務提供商提供可以配置的選項，可以保護元數據API。GCP用戶可以禁用舊版本的元數據API並強制執行HTTP標頭要求。DigitalOcean用戶可以在cloud-config腳本中禁用元數據API服務。
2. 阻止元數據IP：可以在VM內部創建防火牆規則，以完全阻止元數據API的IP。還可以創建更為精細的防火牆規則，以僅允許特定的應用程序或用戶訪問元數據API。
3. 元數據代理：元數據代理和aws-metadata-proxy等開源工具在本機元數據API上方創建一個新層，並為需要訪問元數據的應用程序提供粒度控制。
4. 最小特權IAM：IAM角色被附加到VM，以允許VM上的應用程序訪問其他雲服務。將IAM特許可權製為僅應用程序所需的服務是至關重要的。最小特權的做法可以最大限度地減少憑證暴露的風險。
總結
就目前而言，SSRF自身可能並不是一個嚴重的漏洞，但是當它與元數據API和雲基礎架構中的錯誤配置結合使用時，SSRF就為許多其他攻擊媒介打開了大門。諸如憑證和網路體系架構之類的敏感元數據可能會泄露，並且可能暴露諸如資料庫和存儲之類的內部服務。在最壞的情況下，整個雲基礎架構可能會受到威脅。這項研究僅以Jira漏洞CVE-2019-8451為例，說明了SSRF對雲基礎架構的影響，但還有數百種其他已知SSRF漏洞的應用程序都可以在雲中利用。我們發現雲服務提供商已經開始著手保護元數據API，但要完全實施可能還需要一些時間。因此，我們建議系統管理員或雲服務用戶使用VM系列和Prisma Cloud進行防護，VM系列通過應用程序流量分析來保護雲工作負載，Prisma Cloud在公有或私有雲環境中提供全棧監控。
註：本文翻譯自https://unit42.paloaltonetworks.com/server-side-request-forgery-exposes-data-of-technology-industrial-and-media-organizations/
