標題：SSRF攻擊示例和緩解措施

https://hacker.bz/t/entry/15541-%E6%A8%99%E9%A1%8C%EF%BC%9Assrf%E6%94%BB%E6%93%8A%E7%A4%BA%E4%BE%8B%E5%92%8C%E7%B7%A9%E8%A7%A3%E6%8E%AA%E6%96%BD/

Followers

微信截图_20220507194114.png

服務器端請求偽造(SSRF)是一種可以用來使應用程序發出任意HTTP請求的攻擊。攻擊者使用SSRF 將來自互聯網上暴露的服務和Web 應用程序的請求代理到未暴露的內部終端。 SSRF是一個黑客反向代理，這些任意請求通常以內部網絡終端為目標，以執行從偵察到完成帳戶接管的任何操作。 SSRF以及XSS和CSRF，由於其普遍性和影響，已成為了最嚴重的web安全漏洞，SSRF是owasp十大漏洞之一。

什麼是SSRF?乍一看，添加從應用程序發出HTTP請求的功能似乎不需要進行安全審查。但是，只要你允許用戶控制HTTP請求的目標並提供用戶輸入，攻擊者就可以利用你的應用程序在內部網絡中的特權位置來實施攻擊。

SSRF漏洞Webhook就是一個很好的例子。通過設計，開發者希望用戶能夠控制webhook的目標地址。然而，這意味著攻擊者也可以控制目標地址。這允許攻擊者通過攻擊者控制的DNS 直接針對內部IP 地址或內部地址。

這意味著，無論你對敏感的內部服務或應用程序進行多麼嚴格的防火牆防護，如果你允許公開暴露的應用程序訪問這些內部應用程序並讓攻擊者控制HTTP 請求目標，攻擊就有可能找到通往這些敏感應用程序的路徑。

利用SSRFSSRF讓我們從一個充當在線hexdump 的簡單示例應用程序開始。應用程序接受URL，向API 發出請求，並輸出響應正文的十六進制轉儲。你可以在下圖中看到示例輸出以及此應用程序的源代碼。

HTTP hexdump 應用程序的示例輸出

但是，如果這個hexdump 應用程序可以通過網絡訪問敏感的內部應用程序，會發生什麼情況？例如，你可能正在遵循最佳實踐並使用內部秘密服務來安全地存儲應用程序所需的憑證，而不是將它們檢入源代碼中。

這正是上圖中的程序所模擬的。要運行此應用程序，請將上圖中的代碼保存在一個名為ssrf1.go 的文件中，然後輸入go run ssrf1.go 以運行該應用程序。

首先導航到http://localhost:8080?url=http://www.google.com 的應用程序以查看www.google.com 的hexdump。要觸發SSRF，請導航到http://localhost:8080?url=http://localhost:8081 以獲取內部秘密。

2.1.png

2.2.png

2.3.png

一個典型的SSRF漏洞示例

上圖中的程序運行hexdump 應用程序並模擬秘密服務的運行。雖然hexdump 應用程序綁定到所有接口，但秘密服務只綁定到loopback，這是一個不應該暴露在互聯網上的合理決定。

問題是hexdump 在本地運行並且可以向loopback（或任何其他內部終端）發出請求。只需將hexdump 指向http://localhost:8081 即可公開內部憑證，無論它是否偵聽任何公開公開的接口。

AWS上的SSRFAWS示例元數據服務(IMDSv1) 很好地說明了SSRF 的強大功能。事實上，研究人員Colin Percival稱其為EC2最危險的功能。

示例元數據服務非常有趣，因為它可以同時用於增提高和降低應用程序的安全性。

它可用於通過幫助你安全地管理秘密憑證生命週期來提高應用程序的安全性。你可以將IAM 角色附加到運行你的應用程序的示例，然後從示例元數據終端獲取你的憑證。示例終止後，這些憑證將被銷毀並頒發一組新憑證。從理論上講，這有助於秘密憑證的生命週期；它減少了可能在違規中暴露的憑證數量，並將憑證的生命週期縮短為示例的生命週期。

但是，如果你的應用程序容易受到SSRF的攻擊，那麼通過允許攻擊者也檢索你的示例的憑證，同樣的優勢也可以反過來對你不利。現在你可能會說，這對IMDSv1是正確的，但對IMDSv2不再是正確的。雖然這是真的，但默認情況下IMDSv1總是啟用的，因此它仍然是一個常見的普遍問題。

如果你熟悉AWS並且已經在使用IAM角色，你可以使用curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/$roleName來了解SSRF在你的應用程序中的致命程度。

如果你對AWS 不熟悉，可以使用下圖中的示例腳本來創建可用於查詢元數據終端的IAM 角色、VPC 和EC2 示例。不過你得付費，因此請確保在完成後關閉此示例。

3.1.png

3.2.png

3.3.png

3.4.png

3.5.png

3.6.png

創建顯示如何利用SSRF 和元數據終端所需的基礎設施（VPC、安全組和EC2 示例）的腳本

查詢元數據終端的截斷輸出SSRF允許攻擊者從你的基礎設施外部完全訪問這些數據

盲SSRF（Blind SSRF）盲SSRF 是SSRF 攻擊的一個子集。在前面的示例中，客戶端已經能夠看到對請求的響應。 Blind SSRF 是指你可以執行請求，但看不到響應。乍一看，它似乎是一個相當沒有危險的漏洞。但是，仍然可以執行一些有趣的攻擊。

一個例子是利用盲SSRF 來改變內部服務的狀態。這方面的一個例子是Jira 中的一個盲SSRF 漏洞，它可以被用於在GitLab基礎設施中任意發出HTTP POST請求。另一個例子是使用盲SSRF 從目標網絡內部執行端口掃描。這方面的一個例子是Jira 中的一個盲SSRF 漏洞，可用於繪製New Relic 基礎設施。

在下圖中，你將看到一個應用程序的源代碼，其行為類似於webhook 服務的行為。用戶提交一個URL，服務嘗試獲取該URL，並將狀態代碼和漏洞消息返回給用戶。

要運行此應用程序，請將下圖中的代碼保存在名為ssrf2.go 的文件中，然後輸入go run ssrf3.go 以運行應用程序並導航到位於http://localhost:8080 的應用程序。

5.1.png

5.2.png

5.3.png

5.4.png

5.5.png

可用於映射內部網絡的應用程序

要了解如何利用盲SSRF，請在你的主機上嘗試一些終端，看看它們是如何響應的。以下是一些探索步驟：

1、嘗試一個沒有服務監聽的端口。

2、試試端口22 看看SSH 是如何響應的。

3、嘗試使用Web 服務器偵聽的端口。

4、響應的時機是否提供了任何有用的信息。

SSRF緩解技術在理想情況下，你的應用程序不需要發出任意請求，或者只需要向一組白名單終端發出請求。在這種情況下，你基本上不必擔心SSRF，因為攻擊者無法控制目標終端。

不幸的是，正如我們在前面的例子中看到的，這通常是不可能的。事實上，你可能正在編寫一個應用程序，你希望在其中授予用戶對終端的控制權，例如webhook。

SSRF 的緩解措施通常可以分為兩大類：你可以在網絡層或應用程序層應用控制。

使用防火牆緩解SSRF對於SSRF，一種常見的緩解措施是實現關於運行應用程序的主機能夠連接到哪些主機的防火牆策略。這通常應用於現有的網絡基礎設施，其中防火牆位於網絡體系結構中的關鍵位置，或者使用網絡設備上的接口ACL 放置在更靠近主機的位置，或者甚至基於主機的防火牆來限制出站連接。

防火牆可能很脆弱，因為任何應用於主機的防火牆都無法區分應用程序建立的連接與節點或同一節點上其他軟件的正常操作規則。防火牆也只能將策略應用於他們看到的流量，因此應用程序可以訪問綁定到本地主機或同一網絡內其他節點的診斷終端。

基於客戶端請求創建出站連接的應用程序也很少見，將來對防火牆策略的更新可能不會考慮到可以創建任意請求的應用程序。

另一個很好的網絡層防禦是使用類似Stripe 開發的Smokescreen 之類的東西。 Smokescreen 是一個HTTP CONNECT 代理，你可以通過它匯集所有流量，並使用它將ACL 放置在允許流量的位置。

“Smokescreen 限制它連接到的URL：它解析請求的每個域名，並確保它是可公開路由的IP，而不是Stripe 內部IP。這可以防止諸如我們自己的webhooks基礎設施被用來掃描Stripe內部網絡之類的攻擊。”

唯一的問題是你的應用程序需要實際支持HTTP CONNECT 代理並願意通過它路由你的流量。好消息是，這通常是默認支持的。例如，Go 中的DefaultTransport 已經做到了這一點，甚至為其他協議添加HTTP CONNECT 代理支持，就像我們對SSH 所做的那樣。

相互認證另一種值得討論的方法是在所有內部服務上使用相互身份驗證。回到webhook 示例，即使攻擊者能夠控制目標，連接也可能無法通過身份驗證與內部資源通信。但是，這種方法不是通用的。如果攻擊者可以控制經過身份驗證的連接，SSRF 就會重新出現。

使用應用程序控制緩解SSRF

如果你無法控製網絡配置或無法運行HTTP CONNECT 代理等其他軟件，則可以通過檢查目標地址是否在阻止範圍內來使用應用層控制來緩解SSRF。

僅僅嘗試解析地址、驗證地址、然後建立連接是不夠的。這很容易受到檢查時間和使用時間漏洞的影響，攻擊者控制DNS 服務器並使用短TTL 在下一次查詢時更改目標地址。如果你正在使用應用層控件，請確保使用較低層的掛鉤。例如，Andrew Ayer 建議使用帶有Go 撥號器的Control 回調來執行此操作。

這樣你就可以創建安全的撥號程序，可以直接替代也可以應用訪問控制的常規撥號程序。看一下下圖中的示例，插入式SafeClient 不僅應用CIDR 檢查，還可以限制HTTP 重定向等內容。

嘗試使用SafeClient ，並再次嘗試利用漏洞。結果還是失敗的。

你也可以從命令行嘗試此程序。以下是一些可以嘗試的示例命令。

7.1.png