Hi，朋友。我最近挖到一個有趣的漏洞，正迫不及待地想寫出來。這個洞是利用一系列漏洞來繞過不同層的防禦，最終拿到全印度最大的股票經紀公司的AWS憑據。下面我來介紹如何繞過Web應用防火牆（WAF）和Web緩存機制，並利用SSRF漏洞獲取AWS賬戶憑據。
（以上操作均在有關公司的明確許可範圍內）
一開始測試時，我發現了一個與文件系統交互的端點。於是我直接測試有沒有LFI（本地文件包含）漏洞，卻發現請求被Cloudflare防火牆擋在了外面——
（Cloudflare WAF）
現在爲了繞過防火牆，我必須把請求直接發給原始服務器，希望它們的服務器或負載均衡器沒有使用IP白名單策略——
（常見請求調用的場景）
爲了找到原始服務器的IP，直接敲命令"dig www.xxx.com"，並得到了原始服務器IP——
然後我在本地host文件中添加了這條DNS條目，並使用LFI讀取/etc/passwd，以下是得到的響應——
（打過碼的示例圖片）
我成功繞過防火牆並執行了LFI漏洞。在whois上搜索了此IP的相關信息後，我發現它屬於AWS。我覺得它同時也是個SSRF漏洞因爲存在一個“頁面/URL”的轉換特性，那接下來就是利用SSRF漏洞來讀取AWS賬戶憑據。於是我繼續調用API來讀取AWS實例的元數據（http://169.254.169.254/latest/meta-data/）——
（讀取AWS實例元數據的HTTP請求）
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 06 Apr 2019 14:32:48 GMT
Content-Type: text/css;charset=UTF-8
Connection: close
Vary: Accept-Encoding
Strict-Transport-Security: max-age=15552000
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Proxy-Cache: HIT
Content-Length: 0
響應碼是200 OK但沒有響應體，這意味着它確實與API進行了交互但最終返回了空響應。但爲什麼是空的？如果你仔細看一下上圖，會發現服務器是一臺"Nginx"而且響應頭中含有"X-Proxy-Cache"。該響應頭是由Nginx緩存層設置的，其值爲"HIT"也就意味着在客戶端訪問AWS元數據API時，服務器首先命中了Nginx緩存並用了緩存中的結果，而這個結果是空的。
現在爲了從服務器獲得響應，我不得不繞過緩存層。首先，我需要了解nginx緩存系統中的URL緩存分頁規則。
一些參考文章——
https://www.digitalocean.com/community/tutorials/how-to-implement-browser-caching-with-nginx-s-header-module-on-centos-7
https://www.howtoforge.com/make-browsers-cache-static-files-on-nginx
我的理解是，一般緩存是基於URL路由路徑的。如果URL是https://somewebsite.com/a.html，並且它與路由路徑匹配（根據緩存規則它會匹配），那麼請求會指向緩存；如果網址是https://somewebsite.com/a.html?那麼URL路由路徑不會匹配任何緩存規則，因此它將略過緩存並從服務器得到響應。於是我繼續調用API並以?或其他特殊字符結尾，來請求AWS實例元數據。這（http://169.254.169.254/latest/meta-data?）與緩存規則中設置的URL路徑路徑不匹配，以下是返回的響應——
（繞過Web緩存的Http請求訪問AWS實例元數據）
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 06 Apr 2019 14:32:48 GMT
Content-Type: text/css;charset=UTF-8
Connection: close
Vary: Accept-Encoding
Strict-Transport-Security: max-age=15552000
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Proxy-Cache: MISS
Content-Length: 315
ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
events/
hostname
identity-credentials/
instance-action
instance-id
instance-type
local-hostname
local-ipv4
mac
metrics/
network/
placement/
product-codes
profile
public-hostname
public-ipv4
public-keys/
reservation-id
security-groups
services/
可以看到"X-Proxy-Cache"緩存頭現在被設置爲"MISS"，意味着API調用沒有進入緩存層，而是直接從服務器獲取了響應。
我最終成功繞過了緩存層並利用起了SSRF漏洞。現在來讀取AWS賬戶憑證，直接調用AWS實例元數據安全憑證的API（http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance?）如我所料，現在能獲取到了——
我拿到了AWS的訪問ID，訪問密鑰和令牌，現在能登錄他們的AWS賬戶並訪問大量重要內容。
總結一下，首先繞過Cloudflare防火牆使我可以利用LFI，然後繞過Web緩存機制將其升級爲SSRF，最後我利用SSRF漏洞獲得了AWS賬戶憑據。
怎麼樣，這是個有趣的漏洞吧！😃