flaws.cloud Level6 Write up
Level6の問題です。問題文は次のとおり。
問題
For this final challenge, you're getting a user access key that has the SecurityAudit policy attached to it. See what else it can do and what else you might find in this AWS account. Access key ID: Secret:
(認証情報はマスクしてます……)
SecurityAuditポリシーがアタッチされたユーザアクセスキーを入手したので、何ができるのか調査してみようという問題です。
解答
AWSのドキュメントによればSecurityAuditポリシーは職務機能の AWS 管理ポリシーの一つです。職務機能の AWS 管理ポリシーは特定の業務に関連するタスクの実行に必要な権限を簡単に付与できるポリシーで、多くのサービスの権限が1つのポリシーにまとめられています。SecurityAuditポリシーはその名称から、セキュリティ監査に関連する権限を一括して付与できるポリシーだと推測できます。
入手したアカウントに紐付けられているポリシーはiam list-attached-user-policies
で確認できますが、アカウントのユーザ名が必要です。作業中のアカウント情報はsts get-caller-identify
で確認できます。
入手した認証情報を設定し、問題文で与えられたアカウントの情報を確認すると、ユーザ名がLevel 6であることがわかりました。
入手したユーザ名を用いてiam list-attached-user-policies
を実行しアカウントに紐づくポリシーを確認すると、list_apigateways
とMySecurityAudit
という2つのポリシーがアタッチされていることがわかりました。MySecurityAuditは問題文でSecurityAuditポリシーとして挙げられていたものと思われます。list_apigatewaysは詳細不明ですが、名称からAmzon API Gatewayとの関連が考えられます。
ポリシーのARNがわかったので、iam get-policy
でポリシーの中身を確認します。
- list_apigatewaysの内容
- MySecurityAuditの内容
list_apigatewaysについてさらに調査します。既にVersionIdが判明しているので、iam get-policy-version
を使ってポリシーが記述されたJSONファイルを参照できます。
Resourceに"apigateway"という文字列が存在しており、推測通りAmazon API Gateway関連のポリシーでした。ドキュメントで記述形式を確認すると、このポリシーはGETメソッドでarn:aws:apigateway:us-west-2::/restapis/*というリソースにアクセスする権限が与えられていると読み取れます。
何らかの手段で実装されているコードがAmazon API Gatewayから実行されているのではないかと考えられます。APIから呼び出されるコードはEC2やLambdaで作成できるようですが、どちらかといえばLambdaのほうが一般的ではないでしょうか。
先ほど見つけたもう一つのポリシー MySecurityAudit の内容を確認すると、Lambda関連で複数次の権限が割り当てられていることがわかります。
- GetAccountSettings
- GetPolicy
- List*
$ aws --profile level6 iam get-policy-version --policy-arn arn:aws:iam::975426262029:policy/MySecurityAudit --version-id v1 { "PolicyVersion": { "Document": { "Version": "2012-10-17", "Statement": [ { "Action": [ 中略 "lambda:GetAccountSettings", "lambda:GetPolicy", "lambda:List*","acm:Describe*", ], "Resource": "*", "Effect": "Allow" } ] }, "VersionId": "v1", "IsDefaultVersion": true, "CreateDate": "2019-03-03T16:42:45+00:00" } }
List* が許可されていたのでlambda list-functions
で作成されているLambda関数を確認してみると、Level6という関数の存在がわかりました。
名前からしてLevel6関数は怪しいため、この関数を実行する方法を考えます。この関数がAmazon API Gatewayで呼び出されると推測すると、適切なエンドポイントにリクエストを投げれば実行できるはずです。ドキュメントによればAmazon API Gatewayで作成されたRest APIは以下の形式のURLにリクエストを送信することで実行できます。
https://{restapi_id}.execute-api.{region}.amazonaws.com/{stage_name}/
APIを実行するためにはAPI IDとリージョン、ステージ名を特定する必要があります。API IDとリージョンはlambda get-policy
で調査できます。
改行が上手くいっておらず見づらいですが、APIに関するポリシーの記述形式を参考にするとなんとか意味がわかります。ポイントになるのは操作対象のAPIを指定するResourceの箇所で、出力結果のarn:aws:lambda:us-west-2:975426262029:function:Level6
は以下のように指定されていることがわかります。
- リージョン : us-west-2
- アカウントID : 975426262029
- API ID : s33ppypa75
これで必要な情報はステージ名を残すだけとなりました。apigateway get-stages
でステージ名を調査すると、Prodだとわかりました。
得られた情報を整理すると以下のとおりです。
- 関数名 : level6
- リージョン : us-west-2
- API ID : s33ppypa75
- ステージ名 : Prod
この情報をもとにRest APIでLambda関数level6を実行するURLにアクセスすると、別のURLへ誘導する応答が得られました。
誘導先のURLにブラウザでアクセスすると、最後のページに辿り着きました。
以上
flaws.cloud Level5 write up
Level5の問題です。問題文は次のとおり。
問題
This EC2 has a simple HTTP only proxy on it. Here are some examples of it's usage: http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/flaws.cloud/ http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/summitroute.com/blog/feed.xml http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/neverssl.com/ See if you can use this proxy to figure out how to list the contents of the level6 bucket at level6-cc4c404a8a8b876167f5e70a7d8c9880.flaws.cloud that has a hidden directory in it.
http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud
のプロキシ機能を利用して秘匿されたディレクトリ上に保管されているLevel6の問題コンテンツを探す問題です。
解答
何も取っ掛かりがわからなかったのでHint1を開けると次のように記載されていました。IPアドレス 169.254.169.254
でメタデータサービスと呼ばれるものが利用できるということです。
On cloud services, including AWS, the IP 169.254.169.254 is magical. It's the metadata service. There is an RFC on it (RFC-3927), but you should read the AWS specific docs on it here.
Need another hint? Go to Hint 2
調べてみると、実行中のインスタンスからhttp://169.254.169.254/latest/meta-data/ にアクセスすることでインスタンスメタデータというインスタンスに関するデータを表示できることがわかりました。
ここで思い出したのが先日参加したSEC-JAWS勉強会で紹介されたSSRFの攻撃テクニック。URLの一部をインスタンスメタデータを返す値に変更することでメタデータを取得できるというものです。
問題の例で与えられているURL例を見ると、http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/<URL>/
という形式になっています。このURLの部分にインスタンスメタデータを返すURLを設定してアクセスしてみると、メタデータの項目を取得できました。
インスタンスにアタッチされているIAMロールの認証情報を取得できると都合が良いので、http://169.254.169.254/latest/meta-data/iam/security-credentials
の情報を表示させると、flawsというロールが存在しており、インスタンスメタデータを通じて認証情報を取得することができました。
入手したIAMロールをAWS CLIに設定してS3の情報を確認すると ddcc78ff というディレクトリを確認できます。
ブラウザでアクセスすることでLevel 6の問題を表示できました。
Level 6に続く
flaws.cloudをやってみた
AWSのセキュリティについて学習するflaws.cloudを解いてみたというやつです。年明けから手をつけ始めて1月中旬には完答してましたがWriteupの清書をめっちゃサボってました。
ダラダラと進めていたAWSのCTFことhttps://t.co/wp4Gsc1FAc 完答です。調べながらダラダラ進めても1週間くらいのボリュームなのでAWS初心者にはちょうど良い感じでした pic.twitter.com/t85wwJlcPj
— もってぃ (@mot_skmt) 2021年1月17日
さらにコンテンツのリリースから時間も経っていて既に日本語の解説記事も多数あるためわざわざ記事化する必要性を悩みましたが、せっかく清書したので供養+自分用備忘録として記事に残します。
長くなるので、問題ごとに解答記事を分けています。
各記事へのリンク
- flaws.cloud Level1 Write up
- flaws.cloud Level2 Write up
- flaws.cloud Level3 Write up
- flaws.cloud Level4 Write up
- flaws.cloud Level5 Write up
- flaws.cloud Level6 Write up
flaws.cloudについて
flaws.cloudは有志が作成した常設のAWSのセキュリティ学習用コンテンツです。全部で6つの問題が用意されており、1つ問題を解くごとに新しい問題にアクセスできるようになります。また特徴として各問題に丁寧なヒントが用意されており、AWSの知識があまり無い状態でもヒントを頼りにすればスムーズに正解にたどり着けます。
問題もAWSを対象にしたフォレンジックやログ解析というよりは、設定のミスを理解していくことに主眼が置かれています。
中にはクラウドサービス特有の機能を用いて調査するなど、知らないと思いつかない手順も中にはありましたが、多くの場合は「こういうことがやりたいな~」という感じで調べれば方法が出てくるものばかりでした。 そのような意味では、AWSへの入門としてもぴったりかもしれません。
個人的にはAWS特有の設定、そしてその設定ミスがどのような攻撃につながってしまうのかという観点を得る上で多くの学びを得られるものでした。
このflaws.cloudですが実は続編としてflAWS 2というものもあるそうです。こちらにもいずれ取り組めればと思います。
flaws.cloud Level4 Write up
Level4の問題です。問題文は次のとおり。
問題
For the next level, you need to get access to the web page running on an EC2 at 4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud
It' ll be useful to know a snapshot was made of that EC2 shortly after nginx was setup on it.
https://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud
にアクセスすることができれば正解という問題です。URLにアクセスしたところ認証を求められてしまいページを開けません。
It'll be useful to know that a snapshot was made of that EC2 shortly after nginx was setup on it.
という文言のとおりnginxのセットアップ直後にスナップショットを作成したというのがカギになりそうです。
解答
Amazon EC2のディスクはAmazon Elastic Block Store (Amazon EBS)という仮想ストレージサービスで提供されています。EC2のスナップショットを取得する際に最もシンプル手法は、Amazon EBSのスナップショットを取得(対象EC2インスタンスのディスクをコピー)することらしいです。保存されている(と思われる)EBSに何らかの手段でアクセスできると良さそう。
EBSを操作するには discribe-snapshots
を用います。しかし、何もオプションを付けないと操作しているアカウントに関連しない情報まで表示されてしまいます。--owner self
を付けて以下のようにコマンドを実行するとアカウントに関連するスナップショットの情報のみを表示できました。
aws ec2 discribe-snapshots --owner self --profile <IAMユーザ> --output json
続いてスナップショットにアクセスする方法を調査します。スナップショットをローカルにダウンロードすることはできないため、AWS上でデータを閲覧する必要があります。AWSでのフォレンジック手法を調べてみると、SANSが参考になりそうな資料(PDFファイル)を公開していました。
この資料ではAWS環境上でインシデントレスポンスなどセキュリティの調査を行う手法が紹介されており、AWS上でフォレンジックを行う手順も説明されていました。
- Create a security group that does not allow outbound traffic
- Attach to compromised Amazon EC2 instance
- Take snapshot of Amazon EC2 instance
- Perform memory acquisition, if possible
- Share snapshot with Security Account (if using one)
- Create volume from snapshot
- Attach volume to SIFT EC2 instance
- Conduct forensics
スナップショットが作成されていることは確認済みなので、手順3. までは実施できていると考えられます。手順4. はメモリイメージの取得なので今回は無視して、手順5. の Share snapshot with Security Account を実施する方法を調べます。
スナップショットはデフォルトでは作成したユーザしかアクセスできないですが、権限を変更することで他者からのアクセスを許可できます。
また、作成されたスナップショットに対するアクセス許可はdescribe-snapshot-attribute
で表示できます。
以上を踏まえてスナップショットのアクセス許可を確認するとcreateVolumePermission属性がallとなっており、誰でもスナップショットからボリュームを作成できることがわかりました。
続いて手順6. の Create volume from snapshot の実施手順を調べます。AWSのドキュメントによれば、AWS CLIでcreate-volume
コマンドを用いるとスナップショットからEBS ボリュームを作成できるようです。なお、事前に操作するIAMユーザに対してEC2へのアクセス許可を設定する必要があるため、今回は操作中のユーザにEC2へのフルアクセス権限を付与しました。
以下のコマンドでスナップショットからEBSボリュームを作成します。
Falseと表示されていて怪しさはありましたが、操作したIAMユーザでAWSにログインし確認すると無事にボリュームが作成できていました。
最後に手順7. の Attach volume to SIFT EC2 instance を行いますが、SIFTを用意するのは面倒なのでとりあえずUbuntuのインスタンスを作成し、AWSのドキュメントの手順に従ってスナップショットから作成したボリュームをアタッチします。この際、ボリュームを作成したAZとインスタンスを作成したAZが異なるとアタッチできないのでインスタンス作成時に注意が必要です(当初us-west-2bにインスタンスを作成したせいでボリュームをアタッチできず悩みました)。
インスタンスにボリュームをアタッチ後、システムにマウントします。手順はAWSのドキュメントを参考にしました。
Linux で Amazon EBS ボリュームを使用できるようにする docs.aws.amazon.com
mount /dev/xvdf1 /data
でマウントし、中身を見れることを確認します。
ファイルを漁ったところ/home/ubuntu/
にsetupNginx.sh
というファイルが存在しており、内容を確認するとユーザ認証用ファイルを生成するシェルスクリプトでした。
入手したユーザ名とパスワードでWebサイトのユーザ認証を行うと、次の問題ページのURLを入手できます。
Level 5に続く
flaws.cloud Level3 Write up
Level3の問題です。問題文は次のとおり。
問題
The next level is fairly similar, with a slight twist. Time to find your first AWS key! I bet you'll find something that will let you list what other buckets are.
他のs3バケットを確認できるAWS key(= AWS アクセスキー?)を見つける問題です。
解答
AWS CLIでLevel 3のS3バケットにアクセスしてみると、ファイル一覧を取得できます。.gitが存在しているので、この内容を確認するとコミット時の情報から何かしらヒントが得られるかもしれません。
S3バケットからダウンロードする方法を調べると、AWS CLIでs3 cp
コマンドを使えばいいことがわかりました。以下のようにしてバケットをローカルにダウンロードします。
.git/logs/HEAD からコミットログを確認すると "Oops, accidentally added something I shouldn't have" という気になる文字列が記述されていました。
git log
で整形して表示します。コメントの内容からは最初に誤った情報を含んだままコミットし、修正後に再度コミットしたと推測できます。そのため、f52ec03b227ea6094b04e43f475fb0126edb5a61 でコミットした内容を復元すると良さそうです。
特定のコミットに切り替えるにはgit checkout
を用いるらしいのでやってみると、access_keys.txtというファイルが生成されていました。
access_keys.txtにはアクセスキーIDとシークレットアクセスキーが記述されていました。入手した情報をaws configure
で設定し、割り当てられているS3リソースをs3 ls
で確認するとLevel 4~Level 6の問題と思われるバケットを確認できました。Level4~のコンテンツにアクセスすることで、次の問題に進めます。
Level4に続く
flaws.cloud Level2 Write up
Level2の問題です。問題文は次のとおり。
問題
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.
Level1同様にサブドメインを見つける問題ですが、少し捻った内容になっているとのことです。また、問題を解くにはAWSのアカウントが必要です。
解答
AWSのアカウントはクレジットカード情報の登録が必要なものの、作成自体は無料でできます。
さて、アカウントは作成したものの完全に手詰まりで何をすればいいのかわかりません。おとなしくヒント1を見るとAWS CLIによる操作の例が記載されていました。--profile
はAWS CLIを利用するユーザ情報を指定するものです。
ユーザ情報を設定するためにはIAMユーザを作成する必要があります。AWSのドキュメントを参考にアクセスキーIDとシークレットアクセスキーが有効なユーザを作成し、s3を利用するためのロールとしてs3-full-access
を割り当てました(無闇にフルアクセスのロールを適用するのは良くないんだろうなぁ…)。ユーザ作成後にキーペアが記載されたCSVファイルをダウンロードしておきます。
AWS CLIにIAMユーザの情報を設定するためにaws configure --profile [ユーザ名]
を実行するとアクセスキーIDとシークレットアクセスキー、リージョン、出力方式が聞かれるのでキーペア情報を参照しながら設定します。
設定完了後にヒント1で示された以下のコマンドを実行するとS3バケット内のオブジェクト一覧が表示されました。
secret-e443fc.html というファイルが怪しそうなのでブラウザでhttp://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud/secret-e4443fc.html
にアクセスすると正解でした。
Level 3に続く
flaws.cloud Level1 Write up
Level1の問題です。問題文は次のとおり。
問題
This level is buckets of fun. See if you can find the first sub-domain.
問題ページ flaws.cloud のサブドメインを探す問題です。
解答
flaws.cloudをnslookupにかけるとIPアドレスが 52.218.245.163
であることがわかります。さらにこのIPアドレスで逆引きするとAmazon S3にコンテンツが置かれていることがわかります。
ホスト名先頭の"s3-content~"で調べてみると、Amazon S3でWebサイトをホスティングする際に用いられるドメインだということがわかりました。また特定のドメインと同一名称のバケットを作成すると、S3にホスティングされたWebサイトをCNAMEに指定できるようです。つまり、flaws.cloud.s3-website-us-west-2.amazonaws.com
はflaws.cloudのCNAME ということがわかります。
上記の http://bucket-name.s3-website-Region.amazonaws.com
というURLの形式を当てはめると、flaws.cloudがホスティングされているS3の情報を次のように特定できます。
- バケット名 : flaws.cloud
- リージョン:us-west-2
またAmazon S3のバケットはそれぞれ一意のURLを持っていて、以下の形式を用いてアクセスが可能できます。
- 仮想ホスティング形式のアクセス:
https://bucket-name.s3.Region.amazonaws.com/key name
- パス形式のアクセス:
https://s3.Region.amazonaws.com/bucket-name/key name
つまり、flaws.cloudのS3バケットのURLは https://flaws.cloud.s3.us-west-2.amazonaws.com
になると推測できます。ブラウザでアクセスしたところ、バケット内のファイル一覧のようなXML形式の情報が確認できました(恐らく外部から見えるのは望ましくない)。内容を見ると、一番下に"secret-dd02c7c.html"という怪しいファイルが記載されています。
ブラウザでこのファイルを示すURL https://flaws.cloud.s3.us-west-2.amazonaws.com/secret-dd02c7c.html
にアクセスすると、Level 2の問題へのURLを入手できました。
Level 2に続く