原文作者 | CertiK滲透測試團隊
編輯及出品 | CertiK（ID：certikchina）
在最近一次進行的Web應用程式滲透測試中，CertiK技術團隊發現了一個預料之外的嚴重漏洞。在獲得客戶的許可後，我們將此發現寫入本文以做分享，幫助相關開發人員未來規避同樣的錯誤。
目標Web應用程式是一個區塊鏈瀏覽器，它具備區塊信息查找、交易歷史記錄查找、部署的智能合約等功能。
該應用程式的前端是用React編寫的，React是一個Web框架，可以很好地預防XSS（跨站點腳本）和HTML注入等攻擊。
在實現方面，前端JavaScript定期從區塊鏈RPC API中獲取新的塊數據。因為區塊鏈是一個簡單的應用程式，沒有「傳統的」後端伺服器，不涉及身份驗證和授權，也不需要處理大量的用戶輸入。因此一般來說，很難在區塊鏈瀏覽器應用程式中找到嚴重漏洞。
然而，在滲透測試期間，CertiK團隊發現了一些關於用於獲取塊數據的請求URL有些異常。該URL看起來像這樣：
https://cors.x.y/http://load-balancer.us-east-1.elb.amazonaws.com/blocks/270865
如果仔細觀察，就能發現這個完整的URL由兩個前後連接的URL組成。
「第二個」URL看起來像一個AWS負載均衡器的DNS名稱，那第一個指向的又是什麼？
單獨訪問第一個URL」https://cors.x.y」後，它進入一個名為「CORS-anywhere」的開源工具的默認頁面。CertiK技術團隊發現該工具配置錯誤，從而能夠訪問敏感信息。
下文將進一步解釋背景，並敘述CertiK技術團隊的發現及進行的其他研究。
在了解調查結果之前，先來了解一下CORS（跨源資源共享）。如果你有Web開發的經驗，應該無數次遇到這種bug:
當一個Web應用從與該資源本身所在的伺服器不同的域、協議或埠請求一個資源時，Web應用會發起一個跨域 HTTP 請求。如果響應中沒有正確的「access-control-allow-origin」標頭（引用），瀏覽器將阻止發起跨域請求的網頁，讀取跨域請求返回的內容。
在本文中，將不會太過深入地討論SOP（同源政策）和CORS（跨源資源共享）機制。簡而言之，SOP會阻止JavaScript讀取跨源請求中的響應，而CORS則是一種繞開由同源策略施加的限制的方法。
區塊鏈瀏覽器中的跨域請求來自何處？為什麼我們需要處理它？在這種情況下，上面提到的區塊鏈瀏覽器的後臺是Cosmos鏈。在Cosmos中，與節點進行交互的方式是利用JSON RPC API（https://cosmos.network/rpc) 。節點的主機名通常是由開發人員分配的，或者是AWS應用程式負載平衡器的DNS名稱。
如果區塊鏈瀏覽器的主機名是「explorer.mychain.com」，而RPC API的主機名是「api.mychain.com」。
那麼當瀏覽器「explorer.mychain.com」向「api.mychain.com」發出請求時，它就會成為一個跨域請求。如果其中沒有正確的CORS標頭，瀏覽器就會阻止應用網站讀取RPC API的HTTP響應。
目前有很多可以解決跨源請求問題的方法，文章末尾處會給出解釋。
對於此區塊鏈瀏覽器，CertiK技術團隊發現它使用名為「CORS-anywhere」的類似代理工具作為處理CORS標頭的解決方案。因此團隊就此對「CORS-anywhere」展開研究。
CORS-anywhere是一個開源工具，為開發人員提供了一種處理跨域請求的方法。該項目存儲庫在Github上有3千多顆星，這足以證明它的受歡迎程度。
「CORS -Anywhere是一個NodeJS代理 ，它將CORS標頭添加到代理請求中」。
在著手研究這一工具時，Github（Github issue）上有一個關於CORS-anywhere的潛在安全風險的提問。就此問題，作者（Rob--W）給出了他的觀點。
簡而言之，他的回答列出了3個要點：
拒絕服務(Denial of Service)IP位址欺騙SSRF（伺服器端請求偽造）在對於Web應用程式滲透測試中，最有趣的是最後一個要點——伺服器端請求偽造。
伺服器端請求偽造（也稱為SSRF）是一個網絡安全漏洞，攻擊者可以利用該漏洞誘使伺服器端應用程式向攻擊者選擇的任意域發出HTTP請求。在典型的SSRF示例中，攻擊者的操作可能導致伺服器建立自身連接，或者在組織基礎結構中構建其他基於Web服務或外部第三方系統的連接。
如果想要了解更多關於SSRF的信息，可訪問參考文獻8。
利用SSRF漏洞的常見方法在內部網絡中執行埠掃描和網絡偵察將請求發送到內部伺服器的API訪問內部網絡中的敏感資源有了執行SSRF的方法，那麼使用SSRF可以獲得什麼呢？
提示：區塊鏈瀏覽器使用的CORS-wheres託管在AWS EC2雲伺服器上。
AWSEC2雲伺服器有一個特殊端點：
http://169.254.169.254/latest/meta-data/
此端點只能在伺服器內部訪問。這個端點包含AWS實例元數據，例如實例ID、主機名、公共/私有IP和AWS角色憑據。
用Google檢索時，http://169.254.169.254被Y Combinator定義為「EC2最危險的功能」。
如果EC2雲伺服器被分配了IAM（身份和訪問管理）角色，則對應的credentials將出現在元數據中。有了role credentials，就有了附加到EC2雲伺服器的IAM角色特權。
例如，IAM角色具有一個名為「aws-elasticbeanstalk-ec2-role」的角色。這是在使用Elastic Beanstalk服務啟動環境時創建的角色。根據AWS文檔，此角色具有對s3存儲庫的完全訪問權限。如果能從元數據端點獲取憑據，就可以訪問組織中的s3存儲庫。
EC2雲伺服器metadata服務有兩種版本：IMDSv1（Instance Metadata Service Version 1）；IMDSv2（Instance Metadata Service Version 1）。
對於IMDSv1，檢索實例元數據僅需要GET請求：
對於IMDSv2，在查詢任何元數據之前，必須創建定義會話持續時間的會話通證。
通過將PUT請求發送到「http://169.254.169.254/latest/api/token」來創建會話。然後就可以使用PUT請求返回的通證請求元數據。
針對於保護Web應用程式中的SSRF漏洞的保護，與在IMDSv1相比，IMDSv2提供了額外的安全措施。簡而言之，有幾個優點：
a. 必須通過PUT請求獲取通證，而大多數SSRF攻擊僅支持GET和POST方法。
b. PUT請求包含一個HTTP標頭「X-aws-ec2-meta>更多有關IMDSv1和IMDSv2區別的信息，可訪問AWS security blog（參考文獻3）。
如上所述，CORS-anywhere可被用於執行SSRF攻擊，並且被部署在EC2雲伺服器上，是時候對此進行利用了。
CertiK技術團隊使用Elastic Beanstalk啟動一個EC2雲伺服器。為了方便演示假設訪問EC2雲伺服器上部署的cors-anywhere的URL是http://cors.x.y：
針對IMDSv1的利用：針對IMDSv1的十分簡單直接。CertiK技術團隊向部署CORS-anywhere的伺服器發出GET請求，去獲取附加了IAM角色的AWS憑證。
針對IMDSv2的利用：儘管IMDSv2比v1更安全，但仍然可以通過在CORS-anywhere中的SSRF漏洞來訪問metadata，獲取role credentials。這是因為CORS-anywhere支持HTTP PUT方法，能將所有標頭轉發到元數據服務。
要利用IMDSv2中的此漏洞，需要發送兩個請求。首先，發送一個包含「X-aws-ec2-metadata-token-ttl-seconds」HTTP標頭的PUT請求以獲取會話通證。然後，發送一個包含「X-aws-ec2-元數據通證」HTTP標頭的GET請求，該標頭的值是從上一個請求中獲取的。
可以使用這些證書來獲得對S3儲存庫和Cloudwatch日誌的完全(讀+寫)訪問權限。
由於「CORS-wherewhere」的流行和AWS雲的大量使用。究竟有多少EC2雲伺服器遭受「CORS-wherewhere」造成的SSRF漏洞？
默認的CORS-anywhere頁面自動生成頁面內容，使潛在的黑客更容易找到它們，包括這句第一行就非常引人注目:「This API enables cross-origin requests to anywhere」。所以CertiK技術團隊使用Shodan.io和Zoomeye這兩個搜尋引擎尋找連接到網際網路的設備，並在搜索中尋找可利用的實例。
CORS-anywhere的默認頁面
「Shodan」返回6個結果，「Zoomeye」返回447個結果。
為了消除誤報並進一步驗證來自搜尋引擎的結果，CertiK技術團隊編寫了腳本用來確認主機在線，並且可以在「CORS-anywhere」的幫助下訪問元數據服務。最終發現網際網路上總共有100個AWS EC2雲伺服器因為部署了CORS-anywhere，而會受到SSRF攻擊。但因為沒有被授權，所以沒有繼續嘗試獲取檢索AWS role credentials。
ZoomEye
在滲透測試期間，CertiK技術團隊利用區塊鏈瀏覽器使用的CORS-anywhere中的SSRF漏洞，獲取EC2 role credentials，從而獲得對公司S3存儲庫和CloudWatch Logs的完全（讀取和寫入）訪問權限。但沒有在AWS雲中執行進一步的滲透，因為這不在滲透測試的範圍之內。
重點：
1. Web應用程式中的漏洞不僅可以在系統的前端和後端找到，而且可以在基礎設施中找到。
2. 在系統上部署第三方工具之前，請謹慎操作並了解潛在的安全風險。
3. 無論是由內部安全團隊還是第三方公司執行安全審計和滲透測試，對於確保系統的安全都至關重要。安全專業人員將嘗試從惡意黑客的角度破壞系統，在黑客真的利用漏洞之前提前幫助識別和修復。
4. 了解AWS共享責任模型。客戶應對其系統上運行的軟體負責。不要讓配置錯誤的軟體成為破壞雲基礎架構的關鍵。
5. 可以關閉AWS EC2 雲伺服器中的matadata服務：
在AWS中，可以通過禁用對元數據服務的HTTP端點的訪問來關閉對元數據服務的訪問。這可以通過在AWS CLI中執行以下命令來完成：
6. 與Cosmos RPC API通信時，有更安全的方法來處理跨域請求：
在config / config.toml配置文件中為「 cors_allowed_origins」指定允許的值。在相同的主機名下配置應用程式和RPC API。將Nginx反向代理放置在節點（鏈）伺服器的前面，以將CORS標頭插入HTTP響應中使用WebSocket而不是HTTP與RPC API進行通信。這個滲透測試故事的寓意是，當你受益於第三方代碼的價值和功能時，你也需要承擔其中可能存在的風險和安全漏洞。
在此次滲透測試服務中，CertiK技術團隊能夠在惡意黑客利用SSRF漏洞之前就將漏洞捕獲。但並不是每次都能這麼幸運。因此無論是接使用內部還是外部安全團隊的審計，對於識別並降低風險因素，以及確保代碼和用戶安全都是至關重要的。
CertiK團隊在區塊鏈的各方面，諸如Solidity，RUST和Go等不同語言；以太坊，Cosmos和Substrate等多種平臺方面，都擁有豐富的經驗和專業知識。此外，在涵蓋非區塊鏈特定的應用程式，包括前端、後端和基礎設施滲透測試等方面，CertiK的技術團隊也十分專業。
如果你希望對區塊鏈生態系統（包括智能合約，底層區塊鏈協議的實現以及網絡應用程式等）進行徹底的安全審計，CertiK都可以為你提供幫助。
我們絕不僅僅是尋找漏洞，而是要消除哪怕只有0.00000001%被攻擊的可能性。
參考文獻
https://github.com/Rob--W/cors-anywhere/issues/152https://developer.mozilla.org/en-US/docs/Web/HTTP/CORShttps://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-meta>https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/iam-instanceprofile.htmlhttps://cosmos.network/rpc/v0.37.9https://www.shodan.io/https://www.zoomeye.org/https://portswigger.net/web-security/ssrfhttps://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-meta>https://github.com/Azure/WALinuxAgent/wiki/VMs-without-WALinuxAgenthttps://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity
了解更多
General Information: info@certik.org
Audit & Partnerships: bd@certik.org
Website: certik.org
Twitter: @certik.org
Telegram: t.me/certik.org
Medium:medium.com/certik
幣乎：bihu.com/people/1093109
本文來源： 金色財經 / 作者：CertiK中文社區