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

この記事は下記のブログの続きですので、まだ読んでいなければ先にLevel 1の記事をご覧ください。
そちらの記事にSSRFの説明も記載してありますので、
SSRFとはなんぞや?って方は読んでいただければふわっと理解できるかと思います!

chikoblog.hatenablog.jp

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

Level 2

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

一番下に問題が記載されてます。
The next level is fairly similar, with a slight twist. You're going to need your own AWS account for this. You just need the free tier.
Level 1と似ているが少しひねりを入れているみたいなことが書いてありますね。
また、Level 2からは個人のAWSアカウントが必要になるようです。

とりあえず進めてみる

似ているということだからLevel 1と同様に
Level 2のドメインlevel2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloudに対してdig anyを実行してみる。

$ dig any level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud +short
52.218.218.98

Level 1とは違いNSレコードの情報は抜けないみたいです。
Aレコードは抜けましたので、手に入れたAレコードでnslookupを実行する。

$ nslookup 52.218.193.211
211.193.218.52.in-addr.arpa     name = s3-website-us-west-2.amazonaws.com.

Authoritative answers can be found from:

S3バケットのPTRレコードがわかりましたね、ここまではLevel 1と大差ないです。

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

f:id:Chiko_gorilla:20200110194121p:plain

これもLevel 1 と同様にLevel 2のドメインがS3バケット名になっていました。
Level 1同様にaws s3 lsコマンドを実行する。

$ aws s3 ls s3://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud

An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied

やっとLevel 1との違いが出てきました。
どうやら、アクセス拒否されてます。ここまでガバガバだったのに…

AWS ListObjectsV2の公式サイトを見ると
ListObjectsV2を使用するには、s3:ListBucketアクションを実行するアクセス許可が必要なようです。
アクセス許可が必要ってことはaws s3 lsコマンドに--profileオプションをつけて、
アカウントを指定して実行したらエラーは出ないというなのか?

とりあえず、問題の最初に個人のAWSアカウントが必要と書いていあったので、
aws s3 lsコマンドに--profileオプションをつけて実行してみました。

>aws s3 ls s3://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud/ --profile アカウント名
2017-02-27 02:02:15      80751 everyone.png
2017-03-03 03:47:17       1433 hint1.html
2017-02-27 02:04:39       1035 hint2.html
2017-02-27 02:02:14       2786 index.html
2017-02-27 02:02:14         26 robots.txt
2017-02-27 02:02:15       1051 secret-e4443fc.html

情報が抜き取れました。
あとは明らかに怪しいsecret-e4443fc.htmlを開いてみます。

以下のURLをブラウザでアクセスする。
http://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud.s3-website-us-west-2.amazonaws.com/secret-e4443fc.html

f:id:Chiko_gorilla:20200110201908p:plain

Level 2クリアしました。
Level 1をクリアした後だと何か物足りなさはあります。

やってみた感想

Level 2はLevel 1の問題を代用されています。
Level 1をクリアした人だと比較的簡単に突破ができますね。

なので、ここではLevel 1とLevel 2をやって学んだこと、
僕なりの対策をまとめていきます。

学んだ教訓

AWS環境では、静的ファイルのホストに使用するなど、
あらゆる種類のアクセス許可と機能を備えたS3バケットを設定できます。

S3バケットの権限をあまりにもゆるい設定をおこなってしまうと、
この問題のように意図しないを情報を外部に渡してしまうケースが出てきてしまいます。
Webサーバのディレクトリ一覧を許可しないように設定をしばければいけないですね。

調べてみると、S3バケットEveryoneへのアクセス許可を設定するのと同様に、
誤ってAny Authenticated AWS Userへのアクセス許可を設定してしまっているケースが多いようです。
実際にこの設定はAWSアカウントを持っている人を意味するのに、
これは自分のAWSアカウントのユーザ」だけだと誤解して設定しまうことがあるようです。

S3バケットの設定は注意して設定した方が良いですね。

設定の間違いを避ける為に

デフォルトでは、S3バケットは作成時はプライベートで安全な設定になっています。

Level 1とLevel 2の問題はWebページとしてアクセスできるようにするため、
Static Website Hostingをオンにして、
バケットポリシーをすべてのs3:GetObject権限を許可されているようです。

これは、Webページとしてバケットを公開する場合は問題はない設定です。
しかし、この問題はあえてバケットポリシーへEveryoneを追加してList権限を持つように変更しているようです。

以下製作者の参考画像 f:id:Chiko_gorilla:20200112131402p:plain

Everyoneはインターネット上の全員を意味していて、Listのアクセス許可があるため、
http://flaws.cloud.s3.amazonaws.com/にアクセスするだけでファイルをListすることもできるようになってしまいます。

設定するときは上記した内容をしなければファイルをListされることはなさそうです。

S3バケットバケットポリシーがAny Authenticated AWS Userを設定するのもあまり良くないです。
上記した通り、「これは自分のAWSアカウントのユーザ」のみだと勘違いしていると
Level 2の問題のようにaws s3 lsコマンドに--profileオプションで情報が取られてしまうケースがあります。 f:id:Chiko_gorilla:20200112132015p:plain

終わりに

やはりセキュリティ意識は持っていないと大切な情報が抜かれてしまうのは怖いですね。
こういった問題を1度解いてみるとそういえばこの設定情報が抜かれる可能性があると
気づけるようになるのでおすすめです。

皆様も是非チャレンジしてみては如何でしょうか?

Level 3は以下の記事へ chikoblog.hatenablog.jp