LoginSignup
2

More than 3 years have passed since last update.

flaws.cloudに挑戦してみた

Last updated at Posted at 2020-01-23

はじめに

 先日、大和セキュリティ勉強会に参加してきまして、とても勉強になったので備忘録程度に記事を書こうと思います。今回やったのは、flaws.cloudというサイトです。ctf形式でAWSにおけるハッキングトピックを学べるサイトになっています。level1からlevel6までの計6問で構成されています。詳しいwrite upはもっと偉大な方々が書かれているので適度な感じに書いていこうと思います。解き方もそこで教えてもらった解き方で書かせてもらいます。

事前準備

今回はawsに関する問題なのでawscliを使用します。そのためこちらでawscliのインストールと初期設定をしてください。
※regionはすべてのクレデンシャルで'us-west-2'で設定してください。

level1

 flaws.cloudにアクセスすると説明が書かれていて、一番下に次の問題のページのサブドメインを見つけてねっていう問題文が書かれています。

 1 現状わかっているのはflaws.cloudというドメインだけです。

なのでまずnslookupでドメインの調査してみます。
そうするとipアドレスが出てきます。これをまたnslookupで逆引きします。
スクリーンショット (2).png

するとs3-website-us-west-2.amazonaws.comと出てくるのでawsのs3というサービスで動いていることがわかります。次に"aws s3 サブドメイン"で検索するとドメインの命名規則が見つかります。そこから上記のURLのwebsiteの部分を消せばバケット内のファイル一覧が見られます。
スクリーンショット (3).png

見るからに怪しいhtmlファイルが存在するのでアクセスするとlevel2のURLが張られています。

解説

これはpermissionの設定不備のため誰でもバケットの中身見れてしまうことから生まれます。みなさんは間違ってもpermisssionをEveryoneにはしないように。level3まで似たような問題が続きます。

level2

 次はURLが載ってますがアクセスできません。なのでawscliでアクセスしてみます。
スクリーンショット (4).png

 また怪しいhtmlファイルがあったのでアクセスするとlevel3のURLの書かれたページでした.

解説

これはpermissionの設定を"Any Authenticated AWS User"にしてあるためです。これはawsのアカウントからなら誰でもアクセスできるという設定です。

level3

 先ほど同じようにバケットの中身を見てます。
スクリーンショット (6).png

 .git/があるのでaws s3 cp s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud . --recursiveでダウンロードします。これを解析していきます。
スクリーンショット (10).png

間違えてあげてしまったaccess_key.txtが復元できたので、このアクセスキーでaws configure --profile profile_nameで設定します。その上でバケット内を見てみるとここからはlevel2と一緒です。
スクリーンショット (11).png

解説

よくあるgitに誤ってpushしてしまったverです。pushを取り消さなければこのように復元できてしまいます。ほかにもソースコードの中にパスワードなどをハードコーディングしているのを誤ってpushしてしまうと同じことが起きます。

level4

ここからレベルが跳ね上がります。
スクリーンショット (30).png

次はBASIC認証を求められます。いつもならSQLiやwebアプリケーションの脆弱性を探って攻撃してみますが、今回は違います。そして問題文にも書いてありますが、今回はs3は関係なくEC2が題材です。そして問題文にsnapshotが関係しているのがわかるのでsnapshotを取得するところから始まります。
aws ec2 describe-snapshot --profile profile_nameでスナップショットに関する情報を取得できますが、そのままでは不必要な情報まで取得できてしまうのでフィルタをかける必要があります。aws sts get-caller-identity -–profile level3でクレデンシャルに関する情報を取得します。
スクリーンショット (33).png

そうするとawsのアカウントidが取得できるので、それを使ってフィルタします。aws ec2 describe-snapshots --owner-id 975426262029 --profile level3によって欲しいsnapshotに関する情報だけを取得できます。
スクリーンショット (35).png

このsnapshotが欲しいのでaws ec2 describe-snapshot-attribute --snapshot-id snap-0b49342abd1bdcb89 --attribute createVolumePermission --profile level3でpermissionを確認します。
スクリーンショット (36).png

allなので誰でも作成することが可能なことがわかります。なので自分のアカウントにコピーします。aws ec2 create-volume --availability-zone us-west-2b --region us-west2 --snapshot-id snap-0b49342abd1bdcb89ここでリージョンとアヴェラビリティゾーンを指定する必要があります。
次は、自分でEC2のUbuntuを作成して、先ほど作成したボリュームをアタッチします。その後EC2にSSHでアクセスします。EC2の/snap/に先ほどアタッチしたボリュームがあるのでマウントします。ここから2種類BASIC認証の認証情報を取得する方法があります。
1つはマウントしたボリュームのホームディレクトリに.passwdを生成するシェルスクリプトを見る方法です。
もう1つは~/.bash_historyをさかのぼると最初に設定したときのログが見ることができます。
これでBASIC認証を突破することができ、level5に進むことができます。

解説

 これはスナップショットの作成のpermissionがallになっているのが元凶です。デフォルトでは権限は与えられてないので誤って設定しなければ問題はないです。

level5, level6

誠に遺憾ですが自分の技術力ではlevel5以上は理解が追い付かず歯が立ちませんでした。なんとなく空気としてはわかるのでまとめときます。
・level5 SSRFを用いたクレデンシャルの奪取
・level6 aws特有の機能を複合された問題で、lambda関数がキーだそう

まとめ

今回はlevel5以外は脆弱性などを突いた攻撃は行っておらず、すべて設定のミスを突いた問題です。やはり基本ですが"permissionは必要最低限"がとても重要ですね。そしてawsにおいてクレデンシャル情報はとても大事なことがよくわかります。
 今回は大和セキュリティさんに初めて参加させていただいて、とても勉強になったので記事に書かせていただきました。使用されたスライドは上がっているので是非そちらを見てください。ありがとうございました。

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2