flaws.cloudのwriteup (Level1~Level2)
flAWS challengeはAWSを利用して実際にページが公開されており、AWS特定のセキュリティ学習が行えるサイトである。
海外の記事は結構見つかるが日本語のものが見当たらなかったので前編・中編・後編の３つの記事に分けてwriteupしていきたいと思う。また各コマンド実行の出力内容は載せていないので、できれば実際に手を動かしながら読んでいただけると嬉しい。
環境：Kali
Level 1
http://flaws.cloudを開くと簡単な説明があり、下の方に「最初にサブドメインを見つけなさい。」とある。
まず私はOSSのOSINTツールのSublist3rを使用してみたところ、この先の問題で使用するサブドメインを全て発見してしまった。手順は以下。
# git clone https://github.com/aboul3la/Sublist3r
# cd Sublist3r
# python sublist3r.py -d flaws.cloud -v
が、これでは作成者の意図に反する上に学習にならないので、なかったことにする。
ちなみに、こちらのサイトでも私と同じことやっちゃってる人いて、ちょっと笑ってしまった。
とりあえずDNS情報を探ってみる。
# dig any flaws.cloud
するとNSレコード情報からネームサーバーとしてマネージドサービスRoute53を使用していることが分かる。
そしてAレコード情報から得られたドメインと紐づくサーバーのIPを逆引きすると
# dig -x <得られたIP>
PTRレコード情報の「s3-website-us-west-2.amazonaws.com」からflaws.cloudのサーバーはS3を使用していることがわかる。ブラウザを通しても確認できる。
# firefox s3-website-us-west-2.amazonaws.com
S3をStatic web hostingとして利用する場合、エンドポイントが付与される。つまりflaws.cloudがS3を利用していることから、そのエンドポイントは「http://flaws.cloud.s3-website-us-west-2.amazonaws.com」であることが分かる。
# firefox flaws.cloud.s3-website-us-west-2.amazonaws.com
次にこのS3バケットにAWS CLIを用いてバケットへアクセスしてみる。
# pip install awscli
# aws s3 ls s3://flaws.cloud/ --no-sign-request
するとバケットに直接アクセスできてしまい、アップロードされているファイルの一覧が取得でき、secret-dd02c7c.htmlという怪しいファイルが見つかる。これはS3管理画面の[アクセス制限]における[アクセスコントロールリスト]の[パブリックアクセス]の[Everyone]グループの[オブジェクトの一覧]が「はい」になっているため、もしくは、S3管理画面の[アクセス制限]における[バケットポリシー]のJSON内のResourceキーのValueが「arn:aws:s3:::flaws.cloud」になってしまっているためと思われる。
これらの設定をしてしまうとバケット内のオブジェクトではなく、バケットそのものへのアクセス許可し、オブジェクトをリスト表示できることになってしまう。
以下でファイルの情報がXML形式で確認できる。
# firefox http://flaws.cloud.s3.amazonaws.com
あとはブラウザでsecret-dd02c7c.htmlを確認。
# firefox http://flaws.cloud.s3.amazonaws.com/secret-dd02c7c.html
http://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud/
というURLの存在が確認できるのでLevel2へ進む。
Level 2
ブラウザでhttp://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloudを開くとLevel1の解説があり、
下の方に「Level2はLevel1とほぼ同じ。ただAWSアカウント必要だ。」とある。
AWSアカウントを所有していない方は用意して、とりあえずLevel1と同じような手順でサブドメlevel2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloudのDNS情報を探っていく。
今回はLevel1と同じように下のコマンドを叩いても拒否されてしまう。
# aws s3 ls s3://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud --no-sign-request
ヒントを見るとAWSへのアクセスキーがキモとわかる文章があるため、AWSの[IAM]の画面から使用しているユーザーの[認証情報]タブで開ける画面内で[アクセスキーの作成]を行い、
aws cliにアクセスキーとシークレットキーを設定してもう一度実行してみる。
# aws configure
AWS Access Key ID [None]: <ここにアクセスキー>
AWS Secret Access Key [None]: <ここにシークレットキー>
あとは全部Enter連打。
# aws s3 ls s3://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud
すると今度はバケットに直接アクセスできることが判明し、secret-e4443fc.htmlが見つかるのでブラウザで確認。
# firefox http://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud.s3.amazonaws.com/secret-e4443fc.html
これが実現してしまう理由は、Level1と同じくS3のアクセス制限にある。
Level1では[アクセスコントロールリスト]の[Everyone]の設定で[オブジェクト一覧]が[はい]になっている、
もしくは[バケットポリシー]のJSON内のResourceキーのValueに問題があり、バケット内のオブジェクトの一覧表示が可能になっていた。
Level2ではAWSアカウントを持っているユーザーであれば誰でもバケットそのものへのアクセスができてしまう設定になっていることが判明する。
これは[アクセスコントロールリスト]を設定してパブリックな状態にしていなくても、[バケットポリシー]を使用してバケットがパブリックな状態になっていることが原因で、[バケットポリシー]のJSON内のResourceキーのValueが「arn:aws:s3:::flaws.cloud/*」になっているからと思われる。
下のコマンドで認証なしにバケットにアクセスしようすると失敗することがわかり、
# aws s3 ls s3://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud --no-sign-request
下を実行すると成功できてしまうことが分かる。
# aws s3 ls s3://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud
secret-e4443fc.htmlを見るとhttp://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/というURLの存在が確認できるのでLevel3へ進む。
ちなみに現在のS3の管理画面のUIはhttp://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud/にある解説で使用されているものから更新されているので注意。以前は[アクセスコントロールリスト]内の[Everyone]と同じように「Any Authenticated AWS User」などが設定できていたようだが、私自身その頃のAWSの管理画面をいじったことがないのでわからない。