AWS S3 對象存儲攻防

文章轉載自火線Zone社區

0x00 前言

對象存儲（Object-Based Storage），也可以叫做面向對象的存儲，現在也有不少廠商直接把它叫做云存儲。

說到對象存儲就不得不提 Amazon，Amazon S3 (Simple Storage Service) 簡單存儲服務，是 Amazon 的公開云存儲服務，與之對應的協議被稱為 S3 協議，目前 S3 協議已經被視為公認的行業標準協議，因此目前國內主流的對象存儲廠商基本上都會支持 S3 協議。

在 Amazon S3 標準下中，對象存儲中可以有多個桶（Bucket），然后把對象（Object）放在桶里，對象又包含了三個部分：Key、Data 和 Metadata

Key 是指存儲桶中的唯一標識符，例如一個 URL 為：https://teamssix.s3.ap-northeast-2.amazonaws.com/flag，這里的 teamssix 是存儲桶 Bucket 的名稱，/flag 就是 Key

Data 就很容易理解，就是存儲的數據本體

Metadata 即元數據，可以簡單的理解成數據的標簽、描述之類的信息，這點不同于傳統的文件存儲，在傳統的文件存儲中這類信息是直接封裝在文件里的，有了元數據的存在，可以大大的加快對象的排序、分類和查找。

操作使用 Amazon S3 的方式也有很多，主要有以下幾種：

AWS 控制臺操作

AWS 命令行工具操作

AWS SDK 操作

REST API 操作，通過 REST API，可以使用 HTTP 請求創建、提取和刪除存儲桶和對象。

關于對象存儲就介紹到這里，下面來看看在對象存儲下的一些攻防手法。

0x01 Bucket 公開訪問

在 Bucket 的 ACL 處，可以選擇允許那些人訪問

如果設置為所有人可列出對象，那么只要知道 URL 鏈接就能訪問，對于設置為私有的情況下，則需要有簽名信息才能訪問，例如 https://teamssix.s3.ap-northeast-2.amazonaws.com/flag?response-content-disposition=xxx&X-Amz-Security-Token=xxx&X-Amz-Algorithm=xxx&X-Amz-Date=xxx&X-Amz-SignedHeaders=xxx&X-Amz-Expires=xxx&X-Amz-Credential=xxx&X-Amz-Signature=xxx

對于敏感文件，建議權限設置為私有，并培養保護簽名信息的安全意識。

理論上，如果公開權限文件的名稱設置的很復雜，也能在一定程度上保證安全，但不建議這樣做，對于敏感文件，設置為私有權限的安全性要更高。

0x02 Bucket 爆破

當不知道 Bucket 名稱的時候，可以通過爆破獲得 Bucket 名稱，這有些類似于目錄爆破，只不過目錄爆破一般通過狀態碼判斷，而這個通過頁面的內容判斷。

當 Bucket 不存在有兩種返回情況，分別是 InvalidBucketName 和 NoSuchBucket

當 Bucket 存在時也會有兩種情況，一種是列出 Object

另一種是返回 AccessDenied

這樣通過返回內容的不同，就可以進行 Bucket 名稱爆破了，知道 Bucket 名稱后，Key 的爆破也就很容易了。

0x03 Bucket Object 遍歷

在 s3 中如果在 Bucket 策略處，設置了 s3:ListBucket 的策略，就會導致 Bucket Object 遍歷

在使用 MinIO 的時候，如果 Bucket 設置為公開，那么打開目標站點默認就會列出 Bucket 里所有的 Key

將 Key 里的值拼接到目標站點后，就能訪問該 Bucket 里相應的對象了

0x04 任意文件上傳與覆蓋

如果對象存儲配置不當，比如公共讀寫，那么可能就會造成任意文件上傳與文件覆蓋。

如果目標的對象存儲支持 html 解析，那就可以利用任意文件上傳進行 XSS 釣魚、掛暗鏈、掛黑頁、供應鏈投毒等操作。

0x05 AccessKeyId、SecretAccessKey 泄露

如果目標的 AccessKeyId、SecretAccessKey 泄露，那么就能獲取到目標對象存儲的所有權限，一般可以通過以下幾種方法進行收集：

Github 敏感信息搜索

反編譯目標 APK

目標網站源代碼泄露

0x06 Bucket 接管

假如在進行滲透時，發現目標的一個子域顯示如下內容

通過頁面特征，可以判斷出這是一個 Amazon 的 S3，而且頁面顯示 NoSuchBucket，說明這個 Bucket 可以接管的，同時 Bucket 的名稱在頁面中也告訴了我們，為 test.teamssix.com

那么我們就直接在 AWS 控制臺里創建一個名稱為 test.teamssix.com 的 Bucket 就可以接管了

創建完 Bucket 后，再次訪問發現就顯示 AccessDenied 了，說明該 Bucket 已經被我們接管了。

將該 Bucket 設置為公開，并上傳個文件試試

在該子域名下訪問這個 test.txt 文件

可以看到通過接管 Bucket 成功接管了這個子域名的權限

0x07 Bucket ACL 可寫

列出目標 Bucket 提示被拒絕

查看目標 Bucket ACL 策略發現是可讀的，且策略如下

aws s3api get-bucket-acl --bucket teamssix

查詢官方文檔，內容如下：

通過官方文檔，可以分析出這個策略表示任何人都可以訪問、寫入當前 Bucket 的 ACL

那么也就是說如果我們把權限修改為 FULL_CONTROL 后，就可以控制這個 Bucket 了，最后修改后的策略如下：

{ "Owner": { "ID": "d24***5" }, "Grants": [ { "Grantee": { "Type": "Group", "URI": "http://acs.amazonaws.com/groups/global/AllUsers" }, "Permission": "FULL_CONTROL" } ] }

將該策略寫入

aws s3api put-bucket-acl --bucket teamssix --access-control-policy file://acl.json

再次嘗試，發現就可以列出對象了

0x08 Object ACL 可寫

讀取 Object 時提示被禁止

查看目標 Object 策略發現是可讀的，且內容如下：

aws s3api get-object-acl --bucket teamssix --key flag

這個策略和上面的 Bucket ACL 策略一樣，表示任何人都可以訪問、寫入當前 ACL，但是不能讀取、寫入對象

將權限修改為 FULL_CONTROL 后，Object ACL 策略如下：

{ "Owner": { "ID": "d24***5" }, "Grants": [ { "Grantee": { "Type": "Group", "URI": "http://acs.amazonaws.com/groups/global/AllUsers" }, "Permission": "FULL_CONTROL" } ] }

將該策略寫入后，就可以讀取對象了

aws s3api put-object-acl --bucket teamssix --key flag --access-control-policy file://acl.json

0x09 特定的 Bucket 策略配置

有些 Bucket 會將策略配置成只允許某些特定條件才允許訪問，當我們知道這個策略后，就可以訪問該 Bucket 的相關對象了。

例如下面這個策略：

{ "Version": "2012-10-17", "Statement": [ { "Sid": "TeamsSixFlagPolicy", "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::teamssix/flag", "Condition": { "StringLike": { "aws:UserAgent": "TeamsSix" } } } ] }

當直接訪問 teamssix/flag 的時候會提示 AccessDenied

而加上對應的 User-Agent 時，就可以正常訪問了

在實戰中，可以去嘗試讀取對方的策略，如果對方策略沒做讀取的限制，也許就能讀到。

其次在進行信息收集的時候，可以留意一下對方可能會使用什么策略，然后再去嘗試訪問看看那些原本是 AccessDenied 的對象是否能夠正常訪問。

0x10 Bucket 策略可寫

修改策略獲得敏感文件

現有以下 Bucket 策略

可以看到根據當前配置，我們可以對 Bucket 策略進行讀寫，但如果想讀取 s3://teamssix/flag 是被禁止的

因為當前策略允許我們寫入 Bucket 策略，因此可以將策略里原來的 Deny 改為 Allow，這樣就能訪問到原來無法訪問的內容了。

修改后的策略如下：

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "*" ] }, "Action": [ "s3:GetBucketPolicy", "s3:PutBucketPolicy" ], "Resource": [ "arn:aws:s3:::teamssix" ] }, { "Effect": "Allow", "Principal": { "AWS": [ "*" ] }, "Action": [ "s3:GetObject" ], "Resource": [ "arn:aws:s3:::teamssix/flag" ] } ] }

這里將第 20 行由原來的 Deny 改成了 Allow

當策略寫入后，可以看到成功獲取到了原本 Deny 的內容

修改網站引用的 s3 資源進行釣魚

當策略可寫的時候，除了上面的將可原本不可訪問的數據設置為可訪問從而獲得敏感數據外，如果目標網站引用了某個 s3 上的資源文件，而且我們可以對該策略進行讀寫的話，也可以將原本可訪問的資源權限設置為不可訪問，這樣就會導致網站癱瘓了。

例如這樣的一個頁面

查看源代碼可以看到引用了 s3 上的資源

查看 Bucket 策略，發現該 s3 的 Bucket 策略是可讀可寫的

這時我們可以修改 Bucket 的靜態文件，使用戶輸入賬號密碼的時候，將賬號密碼傳到我們的服務器上

當用戶輸入賬號密碼時，我們的服務器就會收到請求了

修改 Bucket 策略為 Deny 使業務癱瘓

除了上面的利用手法外，也可以將策略設置為 Deny

當策略 PUT 上去后，網站業務就無法正常使用了

參考文章：

https://www.ithome.com/0/501/133.htm

https://mp.weixin.qq.com/s/eZ8OAO5ELgUNvVricIStGA

https://mp.weixin.qq.com/s/r0DuASP6gH_48b5sJ1DCTw

https://blog.csdn.net/bandaoyu/article/details/117469496

https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/userguide/Welcome.html

https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/userguide/acl-overview.html

https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/userguide/access-policy-language-overview.html

對象存儲服務 OBS

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。