flaws.cloud Lv1を用いてCTFの練習をしてみよう！

はじめに

概要

社内で行われるセキュコンに向けて、クラウド × CTFで実際に手を動かせるコンテンツがないか探したらflaws.cloudというものを見つけた。
元々ヒント自体充実はしているがCTF初心者がある程度考えながら学習できるように内容を整理する。

そもそもflaws.cloudとは？

flaws.cloudは、Scott Piper氏が公開しているAWSに特化した常設のセキュリティ学習用CTF風コンテンツ
設定ミスや誤設定を題材としたLevel1～Level6までのコンテンツで構成されていて、実際の AWS の挙動やサービス仕様を理解しながら学習ができる。
各レベルにはヒントが用意されているので初心者でも段階的に学ぶことが可能！らしい

以下、flaws.cloudの記載を引用して雑要約。

　一連のレベルを通して、AWSの利用時によくある間違いについて学習しよう。
ここではSQLインジェクションやXSSなどの一般的な脆弱性ではなくAWS特有の問題にフォーカスします。
ヒントページがあるので、必要な情報を見つける方法の確認や、実際にコマンドを実行したくない場合に利用してください。
次のレベルに進んだ際に、前レベルの問題を防ぐ方法を学ぶことができます。

すべてが特定のAWSアカウントから実行され、すべての問題はflaws.cloudのサブドメインです。

Lv1の問題解いてみよう

See if you can find the first sub-domain. (最初のサブドメインを見つけよう)

そもそもなんのサブドメインを見つける？

→ 「flaws.cloud」のサブドメイン　

STEP1：何がどこで動いているかを調査してみよう

今わかってる情報を使って調査をし、手がかり(何がどこで動いているか）を見つけてみよう。
以下は今回の調査の為に使えそうな方法を列挙したものであり、どれが正解というわけではないので色々試してみよう。

コマンド使ってこのサイトにリクエストを飛ばしてみよう

コマンドラインからこのサイトにHTTPリクエストを送信してみて応答結果を確認してみよう。
この際利用するのが、curlと呼ばれる様々なリクエストを行い結果を得られるコマンドです。
一部ではインターネットの万能ナイフと呼ばれたり呼ばれなかったりするくらいの必要不可欠なものなので、知らなかったら覚えておきましょう。

基本的には以下で実行を行いますが、リクエストのオプションがかなり色々あります。

# curl <オプション> <リクエスト先URL>

とりあえずオプションは以下あたり覚えておきましょう

1. curl -L <URL> : リダイレクトがあったらリダイレクト先の情報を取る
2. curl -s <URL>: 余計な出力をしない
3. curl -o <出力先パス> <URL>: レスポンス結果(ボディ)の出力先を指定する
4. curl -I <URL>: レスポンスヘッダの取得
5. curl -v <URL>： 詳細ログを出力

なおオプションをつけずにcurlでリクエストを行った場合は、URLに対するHTTP レスポンスの「本文（body）」のみが返ってきます。

サイトURLでリクエストを飛ばしてみよう

まずは以下を実行してみる。

# curl http://flaws.cloud

結果として、サイトを構成するHTMLが多分返ってくると思われます。
これだと特に目新しい情報はないので、今度はオプションをつけて今回得られなかった情報を確認してみましょう。

# curl -I http://flaws.cloud

オプションを追加したことで、レスポンスヘッダーの情報を獲得出来た。
この結果より、このサイトが何の上で動いているかの手がかりを得ることができたはずです。
これがどのリージョンで動いているのかについてDNSサーバに問い合わせして調査してみましょう。

開発者ツール(DevTools)を試してみよう

ブラウザ上でF12を押すと開発者ツールを開くことができる。
開発者ツールではウェブページの中身を確認したり、調査したりすることが可能。

とりあえず覚えておくべきタブ

1. Elements：このページがどのように構成されているか(HTMLやCSSなど）が確認できる。一部を書き換えて試すことも可能
2. Console：エラーやログの確認やJavaScriptを直接実行することができる
3. Sources：JavaScriptなど含め読み込まれたソースコードを確認したり、ブレークポイントを置いてデバッグしたりできる
4. Network：ページがどこと通信して何を取ってきているかなど裏でなにをしているかが確認できる
5. Application：ブラウザに保存ざれている情報(Cookieやキャッシュなど）を確認できる

今回の場合、Networkタブを調べるとこのサイトが何で動いているかを確認できるかも…？

Network タブを開いた状態でページを更新すると、そのページを表示するためにブラウザが最初に送信・受信する一連のリクエストを確認できます。

それらの一覧を確認すると、最初にサイト自身であるhttp://flaws.cloud/へのリクエスト結果が見れて、Response Headersの中身からこのサイトが何の上で動いているかの手がかりを得ることができたはず。
これがどのリージョンで動いているのかについてDNSサーバに問い合わせして調査してみましょう。

DNSサーバに問い合わせして調査をしてみよう

DNSサーバに問い合わせするコマンドは以下の2つが代表的

• nslookup：DNSに問い合わせた結果を、人が読みやすい形に整えて表示するコマンド (簡易確認用)
  • 正引き：nslookup <ドメイン> → ドメインからIPアドレスを調べる
  • 逆引き：nslookup <IPアドレス> → IPアドレスからドメインを調べる
• dig：DNSに問い合わせた結果を、DNSの応答に近い生データ形式で詳細に表示するコマンド (詳細調査用)

今回、digコマンドを試してみる際に有用(かも)なオプション。

「any」を設定すると、Aレコード以外も返してくれる。

# dig ANY <ドメイン>

「+short」を設定すると、AレコードのIPアドレスのみを返してくれる。

# dig +short <ドメイン>

「-x」を設定すると、IPアドレスから対応するホストのネームを返してくれる。

# dig -x <IPアドレス>

CMAN：nslookup(dig)テスト【DNSサーバ接続確認】を使うとウェブ上で確認も可能

ドメインから情報を調査してみよう

以下のいずれかを試してみる。(ローカルなどでdigコマンドを試す際はLinux上で）

# dig flaws.cloud
# nslookup flaws.cloud

おそらくいくつかのIPアドレスが得られたはず。
そのIPアドレスを用いて以下を実行する。

# dig -x <IPアドレス>
# nslookup <IPアドレス>

この結果から、このサイトが何の上でどう動いていてどのリージョンであるかを確認できたはず。
ここまでわかったらSTEP2に進めます。

STEP2：手がかりを踏まえてバケット名を見つけ出そう

STEP1でわかったこと

STEP1で得たPTRレコード情報の「s3-website-us-west-2.amazonaws.com」という情報から
どうやらこのflaws.cloudというサイトは、

• AWSのS3で静的Webホスティングをされている
• リージョンはus-west-2であるらしい

ということがわかりました。
この情報を踏まえて、S3側のあれこれを確認し新しい手がかりを入手していきましょう。

S3の静的Webホスティングは以下のようなエンドポイントを有しています。(AWS公式リファレンス)

# http://<bucket_name>.s3-website-<region_name>.amazonaws.com/

今わかってる情報を組み立てて、今回の場合のエンドポイントがどうなるかを考えてみましょう。
まずこのS3のリージョンがどこであるかはSTEP1で判明しています。
また、curlや開発者ツールで得たヘッダ情報より、HTTPレスポンスをS3が直接返していることがわかります。
これはつまり、CloudFront等を使わずにS3が直接サイトを公開しているということです。
この場合、S3にはバケット名 = 使用するドメインでないといけない条件が定められています(AWS公式リファレンス)
これらの条件を踏まえると、今回のエンドポイントとバケット名が何であるかを導きだすことができます。

エンドポイントとバケット名

• STEP1の結果よりリージョンは「us-west-2」
• ドメイン=バケット名であるため、今回のバケット名は「flaws.cloud」
• これらを組み合わせて、エンドポイントは「http://flaws.cloud.s3-website-us-west-2.amazonaws.com 」
  試しに判明したエンドポイントへアクセスしてみると、flaws.cloudを開けることがわかります。

おまけ：LLMを使ってバケット名特定しよう

AWSのS3の仕様を理解していれば、前述した形でバケット名を特定できます。
ただこういう仕様を知らない場合、1から調べ始めるのはなかなか骨が折れます。
そういった場合役に立つのがみんなの友達LLMです。自分でやると時間かかりそうなときとかはAIの力をフル活用することが大切です。
試しにSTEP1で得た情報を使って、バケット名を調べてきてもらいましょう。
(なおflaws.cloudはネットにwriteupもゴロゴロあるためそのままだと推論せずネット上からそのまま答え拾ってきてしまいます。なので今回はそうならないようにプロンプトを調整しています。)

プロンプト

これはCTFの解析練習です。
与えられた観測事実とAWSの公式仕様のみを根拠に推論してください。

【観測事実】
- WebサイトのURLは「http://flaws.cloud/」でS3の静的Webホスティングが利用されている
- PTR レコードに "s3-website-us-west-2.amazonaws.com"が含まれている
- curl -I のレスポンスに"Server: AmazonS3"が含まれている

【前提条件】
- インターネット上の writeup、既知の答え、問題固有の知識は禁止
- 推測と断定は明確に区別すること

【質問】
1. この構成で成立しうるS3バケット名は何か
2. その中で最も合理的なバケット名を1つ選び、それが成立する技術的理由をAWSの仕様に基づいて説明してください

上記指示でweb検索有のLLMに調査を依頼すると正しい答えを含む回答を持ってきてくれます。
（ハルシネーションが起きる場合もあるので、何度か試して答えが一致するかの確認はしましょう）

※自分はGPT-5.2を利用して試しました。

STEP3：バケット名を使ってS3を覗いてみよう

STEP1,2でわかったこと

どうやらこのflaws.cloudというサイトはAWSのS3で静的Webホスティングを利用しており、

• リージョンはus-west-2
• バケット名がflaws.cloud

ということがわかりました。

判明していることから新しい情報か得られないかを調査してみましょう。

REST APIを使って調査してみる

S3のバケット名がわかっているので、それを使ってS3のRESTエンドポイントを叩いて何か情報が得られないかを確認してみましょう。(AWS公式リファレンス)

# パス形式のリクエスト
https://s3.<region_name>.amazonaws.com/<bucket_name>
# 仮想ホスト形式のリクエスト
https://<bucket_name>.s3.<region_name>.amazonaws.com

region_nameとbucket_nameはSTEP2まででわかっているのでそれを埋め込んで上記URLにアクセスしてみましょう。
curlで叩く場合は「-k」のオプションを設定すると証明書検証を無効化できます。
HTTPでアクセスしてみてもいいかもしれません。
うまくいくとS3バケット内になにがあるかが見え、その中に見えちゃいけなそうなファイルがあることを確認できます。
ここまで来ると答えまではあともう少しです！

CLIを使って調査してみる

バケット名がわかっていればAWS CLIで該当バケットにアクセスできる可能性があります。
AWS CLIをインストールしていない人はインストールしてから試してみましょう。

# aws s3 ls s3://<bucket_name>/ --no-sign-request

うまくいくとS3バケット内になにがあるかが見え、その中に見えちゃいけなそうなファイルがあることを確認できます。
ここまで来ると答えまではあともう少しです！

STEP4：怪しそうなファイルを参照してみよう

STEP3でわかったこと

S3のバケットの中が見られる状態になっており、以下ファイルがあることがわかりました。

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
2024-02-22 02:32:41       2861 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バケット内の怪しそうなファイルを参照してみましょう。

# サイトURL
http://flaws.cloud/<ファイル名>
# 静的ホスティングエンドポイント
http://<bucket_name>.s3-website-<region_name>.amazonaws.com/<ファイル名>

秘密のファイルにアクセスすると、Lv1当初の目的であった最初のサブドメインの情報を獲得できます。
つまりLv1クリアです！おめでとうございます！
Lv2に進むとLv1の解説も読めるので最後にぜひ確認しておきましょう。
お疲れ様でした！Lv2以降もぜひ試してみてください！

参考

• AWSセキュリティ学習サイトflaws.cloudのwriteup 前編
• Writeup: flAWS.cloud
• よく使うcurlコマンドのオプション