2026年2月13日

本記事では、AWSのセキュリティトレーニングコンテンツであるflAWS[1]の中からLevel 1, 2の問題の解法解説と、セキュリティ対策手法について紹介します。

目次

flAWSとは

flAWSは米国のScott Piper氏が有志で作成したCTF形式の常設サイトで、AWS特有の問題(よくある設定ミスやそれに起因する脆弱性)を題材として取り扱っています。
サイト名の「flAWS」は、欠陥を意味する英単語「flaw」とAWSをかけたものだと思われます。
問題はLevel 1からLevel 6まであり、各レベルの問題を解くと次のレベルのリンクが出現するという仕組みになっています。また各問題にはヒントが複数用意されているため、わからなかった部分を答え合わせしながら次に進めることができます。

事前準備

問題を解くにあたり、以下の2つを用意する必要があります。

AWS CLIの実行環境は各オペレーティングシステムでawsコマンドをネイティブインストールする方法[2]もありますが、AWS CLIだけを使いたいのであればDockerイメージ[3]を利用することもできます。

Level 1

問題サイトにアクセスすると、早速Level 1の問題文が表示されています。

問題文の誘導に従い、SynapsInt[4]等のサービスを利用してflaws.cloudのサブドメインを調査すれば簡単に次のレベルの問題のリンクが表示されてしまいます。しかしこれはAWSにかかわる問題であるという出題の意図から外れてしまいますので、今回は別の方法で解いていきます。

問題文の前半で不自然に強調されている”buckets”という単語に着目します。
Buckets(バケット)とは、AWSのストレージサービスであるAmazon S3[5]における、オブジェクト(メタデータ)を保存するコンテナの名称です。この問題サイトのコンテンツがAmazon S3のバケット上に保管されている可能性が考えられるので、そのバケット情報を調査する方針で進めます。

始めにこのコンテンツがどこでどのように管理されているのかを調べるため、DNS情報を調査します。
flaws.cloudのAレコードを調べると、いくつかのIPアドレスが取得できます。取得したIPアドレスのPTRレコードを調査すると、以下の出力が取得できます。

これはこのサイトがAmazon S3上の静的サイトとして、AWSのus-west-2リージョン(米国・オレゴン)でホスティングされていることを示しています。

次にこのバケットに保管されているコンテンツ情報を取得するため、AWS CLIを利用します。
Amazon S3に関して、バケットとオブジェクトの一覧表示[6]コマンドがあるので、それを実行します。ここでターゲットとなるバケット名はドメイン名と一致するという規則[7]があります。

コマンドを実行したところ、資格情報がないというエラーが出力されました。
AWS CLIはAPIリクエストを送信する際にデフォルトでアクセスキーを用いた署名が付与される[8]のですが、資格情報をまだ入力していない状態でコマンドを実行したために署名が付与されなかったということを示しています。

“aws configure”を実行して資格情報を入力し、プロファイルを指定することでこのエラーを回避できますが、今回私はAWS CLIのコマンドオプションの一つである”--no-sign-request”[9]を使用しました。これは匿名アカウントであることを明示してリクエストに対する署名付与プロセスをスキップするオプションです。

これで対象のバケットのオブジェクト一覧を取得できました。
最終行にある”secret-d*****c.html”がいかにも機密情報をもっていそうなので、
http[:]//flaws.cloud/secret-d*****c.htmlにアクセスしてみます。

アクセス結果は図2のとおり。秘密ファイルにたどり着き、Level 1の問題が解けました。

Level 2

Level 2の問題文は以下のとおりです。

Level 1では匿名アカウントでCLIの実行ができましたが、Level 2では個人のAWSアカウントを使用するよう誘導されています。
試しに匿名アカウントでオブジェクト一覧の取得を試みますが、アクセス拒否されます。

誘導に従い、AWS CLIでアカウントの資格情報を入力してからコマンドを実行すると、Level 1と同様に怪しげなオブジェクトが表示されます。

アクセスしてみると、Level 2の秘密ファイルでした。

対策手法

ここまではいかにして機密情報を取得するかという視点で解説をしました。
しかしAWSを用いてWebサイトを公開する立場では、逆にこのようなことが起こらないようにセキュリティ対策をする必要があります。

今回の問題サイトで機密情報が漏洩してしまった原因は、図4のようなバケットポリシーの設定を行っていたことであるといえます。具体的には、GetObjectとListObjectの2つのアクションをバケット内のすべてのオブジェクトに対して有効化してしまった点です。これにより第三者(Level 2においては任意のAWSアカウント)がオブジェクトの一覧を取得し、機密情報へのアクセスができるような公開設定になってしまいました。

問題サイトのように同一バケット内で公開/非公開オブジェクトが混在する場合は、オブジェクトごとに異なるポリシーを適用することで非公開オブジェクトへのアクセスを遮断できます。
図5では先に第三者がアクセス可能なオブジェクトを明示的に列挙したうえで、内部ユーザだけに非公開オブジェクトへのアクセスおよびオブジェクトの一覧取得のアクションを許可するよう、Principalでロールを指定したポリシーを適用する例を示しています。
ほかにもAmazon公式ドキュメントで紹介されている設定例[10][11]を見ると、フォルダごとにアクセス管理をする方法や、オブジェクトに特定のタグを設定する方法などもあるようです。

まとめ

本記事ではflAWSを紹介し、Level 1, 2の解法と対策手法を解説しました。
flAWSにはこのあとにもLevel 6まで問題が続いていますし、さらに後継のflAWS 2[12]なども公開されています。CTFの一種としてチャレンジするのもいいですし、ヒントと解答を読んで仕組みを理解するだけでも勉強になりますので、一度気軽に触れてみることをお勧めします。

参考文献

執筆者の他の記事を読む