在瞭解調查結果之前，先來了解一下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介紹
CORS-anywhere是一個開源工具，為開發人員提供了一種處理跨域請求的方法。該專案儲存庫在Github上有3千多顆星，這足以證明它的受歡迎程度。
“CORS -Anywhere是一個NodeJS代理 ，它將CORS標頭新增到代理請求中”。
在著手研究這一工具時，Github（Github issue）上有一個關於CORS-anywhere的潛在安全風險的提問。就此問題，作者（Rob--W）給出了他的觀點。
簡而言之，他的回答列出了3個要點：
a. 拒絕服務(Denial of Service)
b. IP地址欺騙
c. SSRF（伺服器端請求偽造）
在對於Web應用程式滲透測試中，最有趣的是最後一個要點——伺服器端請求偽造。
伺服器端請求偽造（也稱為SSRF）是一個網路安全漏洞，攻擊者可以利用該漏洞誘使伺服器端應用程式向攻擊者選擇的任意域發出HTTP請求。在典型的SSRF示例中，攻擊者的操作可能導致伺服器建立自身連線，或者在組織基礎結構中構建其他基於Web服務或外部第三方系統的連線。
如果想要了解更多關於SSRF的資訊，可訪問參考文獻8。
· 利用SSRF漏洞的常見方法
a. 在內部網路中執行埠掃描和網路偵察
b. 將請求傳送到內部伺服器的API
c. 訪問內部網路中的敏感資源
有了執行SSRF的方法，那麼使用SSRF可以獲得什麼呢？
提示：區塊鏈瀏覽器使用的CORS-wheres託管在AWS EC2雲伺服器上。
AWS EC2 metadata
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-metadata-token-ttl-seconds”。在SSRF攻擊中，攻擊者通常無法在請求中插入其他HTTP標頭。
更多有關IMDSv1和IMDSv2區別的資訊，可訪問AWS security blog（參考文獻3）。
利用SSRF漏洞
如上所述，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"案例
由於“CORS-wherewhere”的流行和AWS雲的大量使用。究竟有多少EC2雲伺服器遭受“CORS-wherewhere”造成的SSRF漏洞？
預設的CORS-anywhere頁面自動生成頁面內容，使潛在的駭客更容易找到它們，包括這句第一行就非常引人注目:“This API enables cross-origin requests to anywhere”。所以CertiK技術團隊使用Shodan.io和Zoomeye這兩個搜尋引擎尋找連線到網際網路的裝置，並在搜尋中尋找可利用的例項。
“Shodan”返回6個結果，“Zoomeye”返回447個結果。
為了消除誤報並進一步驗證來自搜尋引擎的結果，CertiK技術團隊編寫了指令碼用來確認主機線上，並且可以在“CORS-anywhere”的幫助下訪問後設資料服務。最終發現網際網路上總共有100個AWS EC2雲伺服器因為部署了CORS-anywhere，而會受到SSRF攻擊。但因為沒有被授權，所以沒有繼續嘗試獲取檢索AWS role credentials。
總結
在滲透測試期間，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/152
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/
https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/iam-instanceprofile.html
https://cosmos.network/rpc/v0.37.9
https://www.shodan.io/
https://www.zoomeye.org/
https://portswigger.net/web-security/ssrf
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html
https://github.com/Azure/WALinuxAgent/wiki/VMs-without-WALinuxAgent
https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity
