flaws.cloudに挑戦してみた

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

#事前準備
 今回はawsに関する問題なのでawscliを使用します。そのため[こちら](https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-chap-install.html)でawscliのインストールと初期設定をしてください。
※regionはすべてのクレデンシャルで'us-west-2'で設定してください。

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

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

なのでまず`nslookup`でドメインの調査してみます。
そうするとipアドレスが出てきます。これをまた`nslookup`で逆引きします。
![スクリーンショット (2).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/546906/27f33c3d-eb66-f872-ed23-6438b3a86c20.png)

するとs3-website-us-west-2.amazonaws.comと出てくるのでawsのs3というサービスで動いていることがわかります。次に"aws s3 サブドメイン"で検索するとドメインの命名規則が見つかります。そこから上記のURLのwebsiteの部分を消せばバケット内のファイル一覧が見られます。
![スクリーンショット (3).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/546906/9ea4d1d5-7f81-1279-6e24-a5c603e53fbf.png)

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

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

#level2
　次はURLが載ってますがアクセスできません。なのでawscliでアクセスしてみます。
![スクリーンショット (4).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/546906/c6d20472-e2a5-b36b-17ae-357855c700c6.png)

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

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

#level3
　先ほど同じようにバケットの中身を見てます。
![スクリーンショット (6).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/546906/6ef5013d-c629-412d-1154-b35ecd94b94c.png)

　`.git/`があるので`aws s3 cp s3://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud . --recursive`でダウンロードします。これを解析していきます。
![スクリーンショット (10).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/546906/af93e8ce-b369-9146-d0bb-e7290cea7430.png)

間違えてあげてしまったaccess_key.txtが復元できたので、このアクセスキーで`aws configure --profile profile_name`で設定します。その上でバケット内を見てみるとここからはlevel2と一緒です。
![スクリーンショット (11).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/546906/e7c34f32-3837-71c7-c94e-3dc03b996977.png)


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

#level4
ここからレベルが跳ね上がります。
![スクリーンショット (30).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/546906/8c860acd-ead5-7efb-91b0-b51906aba5ff.png)

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

そうするとawsのアカウントidが取得できるので、それを使ってフィルタします。`aws ec2 describe-snapshots --owner-id 975426262029 --profile level3`によって欲しいsnapshotに関する情報だけを取得できます。
![スクリーンショット (35).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/546906/69bb3c83-f6aa-e703-7d10-bffd4229c0d8.png)

このsnapshotが欲しいので`aws ec2 describe-snapshot-attribute --snapshot-id snap-0b49342abd1bdcb89 --attribute createVolumePermission --profile level3`でpermissionを確認します。
![スクリーンショット (36).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/546906/d1ab28ff-0530-c2b1-cdad-aac235b66410.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においてクレデンシャル情報はとても大事なことがよくわかります。
　今回は大和セキュリティさんに初めて参加させていただいて、とても勉強になったので記事に書かせていただきました。使用された[スライド](https://www.slideshare.net/zaki4649/flawscloud)は上がっているので是非そちらを見てください。ありがとうございました。