Compact
true
担当領域:リスクハンティング
デジタルフォレンジック、脆弱性診断などの業務に従事。第10期NEC Cyber Security Analyst(NCSA)を修了。情報処理安全確保支援士(RISS) / CEHを保持。

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

※ 記事の中で、個人の資格情報や問題の答えに直接つながる一部の文字列は***などでマスクしてあります。

flAWSとは

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

図1 flAWSのトップページ画面
図1 flAWSのトップページ画面
100

事前準備

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

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

Level 1

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

This level is *buckets* of fun. See if you can find the first sub-domain.
1
1

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

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

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

s3-website.us-west-2.amazonaws.com.
1
1

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

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

$ aws s3 ls s3://flaws.cloud --region us-west-2

Unable to locate credentials. You can configure credentials by running "aws configure".

1
1

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

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

$ aws s3 ls s3://flaws.cloud –region us-west-2 --no-sign-request
2017-03-14 12:00:38       2575 hint1.html
2017-03-03 13:05:17       1707 hint2.html
2017-03-03 13:05:11       1101 hint3.html
2024-02-22 11:32:41       2861 index.html
2018-07-11 01:47:16      15979 logo.png
2017-02-27 10:59:28         46 robots.txt
2017-02-27 10:59:30       1051 secret-d*****c.html
1
1

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

図2 secret-d*****c.htmlへのアクセス結果
図2 secret-d*****c.htmlへのアクセス結果
100

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

Level 2

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

The next level is fairly similar, with a slight twist. You're going to need your own AWS account for this. You just need the free tier.
1
1

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

$ aws s3 ls s3://level2-c8b*****ae7.flaws.cloud/ --no-sign-request

An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied
1
1

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

$ aws configure --profile hamada
AWS Access Key ID [None]: AKIA****************
AWS Secret Access Key [None]: ********************
Default region name [None]:
Default output format [None]:

$  aws --profile hamada s3 ls s3://level2-c8b*****ae7.flaws.cloud/
…
2017-02-27 11:02:15       1051 secret-e*****c.html
1
1

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

図3 secret-e*****c.htmlへのアクセス結果
図3 secret-e*****c.htmlへのアクセス結果
100

対策手法

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

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

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

図4 脆弱なバケットポリシー設定例
図4 脆弱なバケットポリシー設定例
100
図5 公開/非公開オブジェクトで異なるポリシーを適用する設定例
図5 公開/非公開オブジェクトで異なるポリシーを適用する設定例
100

まとめ

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

参考文献

[1] flAWS
http://flaws.cloud/
[2] AWS CLI の最新バージョンのインストールまたは更新
https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/getting-started-install.html
[3] Docker Hub - amazon/aws-cli
https://hub.docker.com/r/amazon/aws-cli
[4] SynapsInt
https://synapsint.com/
[5] Amazon S3
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/Welcome.html
[6] Using high-level (s3) commands in the AWS CLI - バケットとオブジェクトの一覧表示
https://docs.aws.amazon.com/ja_jp/cli/v1/userguide/cli-services-s3-commands.html#using-s3-commands-listing-buckets
[7] チュートリアル: Route 53 に登録されたカスタムドメインを使用した静的ウェブサイトの設定
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/website-hosting-custom-domain-walkthrough.html
[8] API リクエストに対する AWS Signature Version 4
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_sigv.html
[9] Command line options in the AWS CLI
https://docs.aws.amazon.com/ja_jp/cli/v1/userguide/cli-configure-options.html
[10] Amazon S3 のセキュリティのベストプラクティス
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/security-best-practices.html
[11] Amazon S3 バケットポリシーの例
https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html?icmpid=docs_amazons3_console
[12] flAWS 2
http://flaws2.cloud/

執筆者プロフィール

執筆者
original
50

濱田 元介(はまだ げんすけ)
担当領域:リスクハンティング

デジタルフォレンジック、脆弱性診断などの業務に従事。
第10期NEC Cyber Security Analyst(NCSA)を修了。
情報処理安全確保支援士(RISS) / CEHを保持。