chikoblog

やってみたことの掃溜め

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

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

EC2インスタンスメタデータサービスv2のリリースでも上がっている
flaws.cloudを使ってSSRF攻撃について個人的に調査してまとめてみました!

以下参考記事
クラメソ様のEC2インスタンスメタデータサービスv2のリリースの記事 dev.classmethod.jp

SSRF攻撃についてpiyokango様がまとめている記事 piyolog.hatenadiary.jp

そもそもSSRF攻撃って?

SSRF攻撃をすごく簡単に説明すると

通常のWEBサイトとかのイメージだとWEBにアクセスしてくるユーザは WEBサーバやその他外部公開用のサーバにアクセスしてWEBのページを見ることが可能です。 f:id:Chiko_gorilla:20191218194704p:plain

SSRFの脆弱性がある場合、
攻撃者は公開サーバ(WEBとか)など踏み台に利用して FW(Firewall)などで隔離されている内部サーバ(DBとか)へ攻撃をおこなうことができたりします。 f:id:Chiko_gorilla:20191218194501p:plain

画像はあくまで例で最終的な攻撃目標はいろいろあり、 最近問題になっているのがクラウドサービスのインスタンスメタデータを取得できるAPIのエンドポイントを狙ってきたりします。

AWS環境で簡単なSSRF攻撃を実践してみた!

調べてもいまいちわからん!

一先ず、AWSのセキュリティ学習ができるflaws.cloudでSSRFについて出題されているみたいなので実際にやってみた

トップページはこんな感じ f:id:Chiko_gorilla:20191219162830j:plain

※ヒント無しで右往左往しながらやってみました!

Level 1

This level is buckets of fun. See if you can find the first sub-domain.

最初のサブドメイン…?を見つければよさそうですね

最初の説明に「範囲はすべてが単一のAWSアカウントで実行され、すべての課題はflaws.cloudのサブドメインです。」と
記載があったので「flaws.cloud」に対してdigコマンド(もちろんオプションはany)を実行してみる

$ dig any flaws.cloud +short
ns-1890.awsdns-44.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
ns-966.awsdns-56.net.
ns-1061.awsdns-04.org.
ns-1890.awsdns-44.co.uk.
ns-448.awsdns-56.com.
52.218.225.10

Aレコード情報とNSレコード情報を入手!NSを見る限りRoute53を利用していることがわかる digで手に入れたAレコードのIPをnslookupで引いてみる
(ちなみに52.218.225.10をブラウザアクセスするとS3の公式ページに飛びます。おしゃれ)

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

Authoritative answers can be found from:

お、S3のPTRレコードがわかりましたね
ダメもとでブラウザアクセス! f:id:Chiko_gorilla:20191219175129p:plain

でさーね…
この「flaws.cloud」はおそらくs3で静的ウェブサイト公開をおこなっているんじゃないか?

AWS S3の公式サイト を見ると、S3バケットをWEBサイトホスティングように設定する際のWEBサイトエンドポイントの一般的な 2 つの形式は次のとおりになるようだ

bucket-name.s3-website-region.amazonaws.com
bucket-name.s3-website.region.amazonaws.com

まさかとは思うが、バケットの名前「flaws.cloud」じゃないよね?
http://flaws.cloud.s3-website-us-west-2.amazonaws.com」をブラウザアクセス f:id:Chiko_gorilla:20191219183755p:plain

S3バケットが外部からアクセス可能であれば、
S3バケットの中身を確認できるのではないか?

AWSコンソールに接続しなくてもS3バケットの中身を確認する方法...
S3のバケット名がわかっているのであれば、すぐに思いついたのはAWS CLIでS3 lsなのでとりあえず実行してみる。

$ aws s3 ls  s3://flaws.cloud/ 
2017-03-14 03:00:38       2575 hint1.html
2017-03-03 04:05:17       1707 hint2.html
2017-03-03 04:05:11       1101 hint3.html
2018-07-10 16:47:16       3082 index.html
2018-07-10 16:47:16      15979 logo.png
2017-02-27 01:59:28         46 robots.txt
2017-02-27 01:59:30       1051 secret-dd02c7c.html

お、情報抜き取れますね!
正しくない公開範囲だとこうなるのか…と思いつつS3バケットの中身を確認し怪しげな「secret-dd02c7c.html」を見てみた URLはこんな感じに「http://flaws.cloud.s3-website-us-west-2.amazonaws.com/secret-dd02c7c.htmlf:id:Chiko_gorilla:20191220122056p:plain

Congrats! You found the secret file!
どうやらLevel1クリアしたようです!

やってみた感想

長くなりそうでしたので今回の記事はLevel1だけにしましたが、 セキュリティをしっかり考えておかなければ「flaws.cloud」のようにWEBサイトページから様々な情報が抜き取られることがわかりました!

Level1を例にすると「flaws.cloud」(公開されている場所)からS3バケットの情報(本来は非公開?)が抜き取られてしまっています。

SSRFはおっかないですね

AWSの環境設計の際もセキュリティ意識はしっかり持っておかなければ予想外のところから攻撃されてしまいますね…
EC2インスタンスメタデータサービスv2はしっかり学習しておかなければ!

Level2は以下の記事へ chikoblog.hatenablog.jp