Security-JAWS Days CTF 作問者解説

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

Transcript

1. Security-JAWS Days CTF
   作問者解説
   @tigerszk
   

   View Slide

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)
   

   View Slide

3. AWSに特化したCTFを開催
   2023/8/27にSecurity-JAWSさんとコラボして、
   AWSサービスに特化したCTFイベントを開催してみました！
   Security-JAWS DAYS DAY2
   https://s-jaws.doorkeeper.jp/events/155025
   

   View Slide

4. ざっくりしたイベントの概要
   • 出題する全問題が、AWSサービスに特化した内容のものと
   なっている
   • 現実世界でありがちなAWSにおけるセキュリティ問題を盛り
   込んで作問し、参加いただいた方にAWSセキュリティに興味
   を持っていただくことを目的として開催
   • AWS初心者やCTFが初めての方向けの比較的優しめな問題も
   出題
   • 競技時間は5時間で、競技者はオンサイト＆リモートで参加
   • 出題した全問題についてイベント内で解説を実施
   

   View Slide

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
   監視して通知
   

   View Slide

6. 出題した問題
   • 問題数は計30問を出題
   • 出題した問題カテゴリ
   ✓ Trivia
   ✓ Warmup
   ✓ Easy
   ✓ Medium
   ✓ Hard
   AWS初心者・CTF初参加の方向け
   腕に自信がある方向け
   今回私は、Warmup＆Easyの比較的簡単な問題を複数問と、Hard
   の問題を1問作問しています。
   なお、Triviaの問題については、S-JAWS運営の方に問題内容を検
   討していただきました。
   

   View Slide

7. 以降は、私が出題した問題の解説を
   記載します。
   

   View Slide

8. Trivia
   

   View Slide

9. Triviaの問題について
   • S-JAWS運営の方が考えてくださった全13問のAWSサービス＆AWS
   セキュリティにまつわるクイズでした。
   • AWSをあまり触ったことがない人でも、検索すれば答えにたどり着
   ける内容の問題を出題しています。
   • Triviaの各問題についてはもれなく大体8割以上の人が正答されてい
   る状況でした。
   ※イベント中に配布した解説資料のTriviaの部分に一部記載ミスがあり
   内容を修正しています。すいません…。
   

   View Slide

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
    

    View Slide

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
    

    View Slide

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": []
    ※配布したログの一部を抜粋
    

    View Slide

13. Warmup
    

    View Slide

14. • コンセプトとしては、CTF初心者の方でも解けるような内容の問題の出題
    を意識しました。
    • AWSセキュティというよりかは、AWS CLIの操作など基礎的な知識を要求
    するような問題を出題しています。
    • AWS CLIに不慣れな方もいらっしゃると思いましたので、マネジメントコ
    ンソールを操作するような問題も出題しています。
    • 「Show IAM policy」や「Run Function」は想定していたよりも正答率が
    悪かったので、もっと早くヒントをだしたり、カテゴリをEasyにしてもよ
    かったかなと振り返って思いました。
    Warmupの問題について
    

    View Slide

15. 回答者数：92
    

    View Slide

16. AWS CLI practice
    アクセスキーからAWSアカウントを答えさせるだけの超簡単問題。
    アクセスキーを設定
    aws configure --profile practice
    AWSアカウントを出力
    aws sts get-caller-identity --profile practice
    

    View Slide

17. 回答者数：83
    

    View Slide

18. パスワードを安全に管理したいサービスとはズバリ「AWS Secrets Manager」です。
    マネジメントコンソールで、アクセスしに行くとFLAGを取得できます。
    Where is the password?
    

    View Slide

19. 回答者数：85
    

    View Slide

20. Find data 1
    バケツ＝S3 bucketの中にFLAGが置いてあるよという意味でした。
    マネジメントコンソールで、アクセスしに行くとFLAGを取得できます。
    

    View Slide

21. 回答者数：72
    

    View Slide

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と
    いうファイルが存在することが分かります。
    この中から当たりの画像を探せという内容となっています。
    

    View Slide

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を利用して以下のようにファイルサイズを
    比較すると一つだけ大きさが違うファイルが存在することが分かります。
    ちなみに当たりのディレクトリの数字は〇物語のサメから来ていますｗ
    

    View Slide

24. 回答者数：48
    

    View Slide

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ユーザーには直接アタッチされておらず、グループにアタッチされています。
    

    View Slide

26. Sidの値にBase64の値が確認できるので、デコードすればFALGを獲得できます。
    ちなみに、ここまで到達していても意外とこの文字列に気づいてくれなかった方が結構い
    らっしゃったのでもうちょい工夫すべきだったなあというのが反省点ですね。
    Show IAM policy
    

    View Slide

27. 回答者数：52
    

    View Slide

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関
    数に対する実行権限を有していることがわかります。
    

    View Slide

29. Run Function
    

    View Slide

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を獲得できます。
    

    View Slide

31. Easy
    

    View Slide

32. 回答者数：20
    

    View Slide

33. Webページにアクセスして、HTMLソースを確認してみるとこのWebサイトはなん
    らかのAWSサービスを利用していると書いてあります。
    CTFに慣れてない方はHTMLソースを見てみるという所になかなか気づかない方が多
    かったのでこれももっと早めにヒント出せばよかったなと思っています。
    Recon the website
    

    View Slide

34. S3を利用していることが分かる
    ドメインに紐づくIPアドレスを調べるとS3を利用していることが分かります。
    

    View Slide

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
    

    View Slide

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の形式となります。パス形式は将来的には廃止が検討
    されているようです。
    

    View Slide

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/
    

    View Slide

38. FLAGを獲得
    アクセスするとS3バケットのファイルの一覧を確認できます。
    FLAGのprefixがわかるため、アクセスすればFLAGを獲得できます。
    

    View Slide

39. この問題のコンセプト
    • 現実世界でも度々問題になっている、S3バケットの設定不備によって情報
    が漏洩してしまうケースをモチーフにした問題でした。
    • Ｓ3の仕様からエンドポイントを推測され情報漏洩へとつながってしまう
    ケースがあることをお分かりいただければ幸いです。
    

    View Slide

40. 回答者数：63
    

    View Slide

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.
    

    View Slide

42. S3のバージョニングについて
    • S3のバージョニング機能とは、S3バケット内でファイルを更新した場合な
    どに、異なるオブジェクトの状態をバージョンとして保持してくれる機能
    です。
    • S3 のバージョニング機能を使用すると、バケットに保存されたすべてのオ
    ブジェクトのすべてのバージョンを、保存、取得、復元することができま
    す。
    • バージョン数の上限については特に定められていないようです。
    • デフォルトでは無効化されているので、利用するには有効化する必要があ
    ります。
    【参考】Amazon Simple Storage Service S3 バケットでのバージョニングの使用
    https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/Versioning.html
    

    View Slide

43. 削除前のデータの情報を確認
    S3バケットにおけるオブジェクトバージョンの一覧を取得
    aws s3api list-object-versions --bucket himituno-bucket3 --profile finddata3
    調査をするとSECRET_DATAというファイルのデータが論理的な削除として扱われている
    だけで元々のファイルがバケット上に存在していることが確認できます。
    

    View Slide

44. FALGを獲得
    指定したバージョンのファイルを取得
    aws s3api get-object --bucket himituno-bucket3 --key SECRET_DATA SECRET_DATA ¥
    --version-id MO4Xz6sB8DONDjCid6ideiRgfdyywcSv --profile finddata3
    削除前のSECRET_DATAのファイルを取得して、中身を確認するとFLAGを取得できます。
    

    View Slide

45. この問題のコンセプト
    • S3のバージョンニング機能の知識を問う問題でした。
    • また、セキュリティ的な観点からだと、このように見た目上は削除さ
    れていても、情報が完全に消去できていないケースはよくあります。
    そのため、機密性の高い情報などを取り扱う場合にはご注意ください。
    

    View Slide

46. Hard
    

    View Slide

47. 回答者数：2
    

    View Slide

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_pass http://$proxy_host/$proxy_path;
    proxy_set_header Host $proxy_host;
    }
    }
    }
    

    View Slide

49. 設定ファイルよりわかること
    配布されているnginx.confの内容より、このWebサーバには二つの設定不備
    が存在することが分かります。
    1. location /assetsの設定に不備があり、パストラバーサルの脆弱性が存
    在する。
    2. location ~^/admin/proxy/については特に値が制限されていないため
    SSRF攻撃に利用できそう(※)
    ※正し、location /admin/の設定をみると分かる通り、Basic認証が設定
    されているため、すぐにはアクセスできなさそう。
    

    View Slide

50. パストラバーサルの脆弱性
    location /assets {
    alias /usr/share/static/;
    }
    【参考】 nginxの設定ミスで起こるパス トラバーサル
    https://qiita.com/no1zy_sec/items/e541f1c838874ff400bb
    /で終端していないため..を利用してディレクトリを
    遡れる
    

    View Slide

51. SSRFに利用できそう
    location /admin/ {
    auth_basic "Restricted";
    auth_basic_user_file /usr/share/secret/.htpasswd;
    location ~^/admin/proxy/(?.*?)/(?.*)$ {
    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
    

    View Slide

52. .htpasswdを入手
    パストラバーサルの設定不備を利用して以下のURLにアクセスすることで、
    Basic認証の認証情報が記載されている.htpasswdファイルを入手すること
    が可能です。
    http://apjweb.scjdaysctf2023.net/assets../secret/.htpasswd
    

    View Slide

53. パスワードをクラックする
    John the ripperなどを利用すれば.htpasswdファイルからBasic認証のパス
    ワードを割り出すことが可能です。
    

    View Slide

54. /adminにアクセスすると
    以下のようなメッセージがあり、phpMyAdminのログインページにアクセスす
    ることができます。
    

    View Slide

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値に変更して送信
    

    View Slide

56. クラウド環境での悪用
    • AWSなどのパブリッククラウドサービスではメタデータサービスと呼ばれる機能
    が存在します。
    • この機能は、メタデータと呼ばれるインスタンス固有のデータ(インスタンスID、
    OSデータ、一時的に付与される認証情報など)を内部WebAPIを通じて取得すると
    いった仕組みとなっています。
    • クラウド環境のサーバにSSRFの脆弱性が存在する場合には、この機能を悪用され
    このメタデータを不正に取得されてしまう可能性があります。
    【参考】インスタンスメタデータとユーザーデータ
    https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instance-metadata.html
    

    View Slide

57. 一時的な認証情報の取得
    • IAMロールという仕組みでAWSのサービスに対して、権限を付与すること
    ができることは既に説明した通りです。
    • EC2にIAMロールアタッチされている場合には、このメタデータAPIより
    IAMロールの権限を一時的な認証情報として取得して、自由に利用するこ
    とができます。
    AWS側のメタデータAPI
    EC２インスタンス
    一時的な認証情報を返す
    http://169.254.169.254/latest/meta-data/…
    IAMロールがアタッチ
    IAMロールの権限を利用するために、EC2からAWSのメタデータAPIに対して、通
    信が行われIAMロールの権限に紐づく一時的な認証情報の取得している。
    

    View Slide

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ロールがアタッチ
    

    View Slide

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のエンドポ
    イントにアクセスを行います。
    

    View Slide

60. 一時的な認証情報を奪取
    ※一部を黒塗りにしています。
    

    View Slide

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ファイルとアクセスキーが配
    置されていることがわかります。
    

    View Slide

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ポリシーの調査を行います。
    

    View Slide

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関数に対して実行権限と
    読み取りの権限があることがわかる。
    

    View Slide

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…。恥ずかしいｗ
    基本的に深夜に作問していたのでご勘弁くださいｗ
    

    View Slide

65. どうでもいい情報ですが
    バックアップとしてダンプしていたSQLファイルのテーブルには、
    「水星の魔女」のキャラクターの名前をネタとして記載していました。
    気づいてくれていた方がいなさそうなのでちょっと残念…。
    

    View Slide

66. Lambda関数の内容を調査
    lambda関数のバージョンを全て列挙。
    aws lambda list-versions-by-function --function-name db-buckup ¥
    --profile dboperator
    対象のlambda関数を調査すると、複数のバージョンが存在し、Descriptionの記載
    内容から、最新のバージョンでパスワードの暗号化が実装されたことがわかります。
    Version 1 Version 2
    

    View Slide

67. DBユーザーの認証情報を入手
    古いバージョンのLambda関数をダウンロードし、コードを確認すると、変数
    内に認証情報がハードコードされていることが確認できます。
    古いバージョンを指定して、lambda関数(バージョンを指定して)のコードをダウンロード。
    aws lambda get-function --function-name db-buckup ¥
    --qualifier 1 --profile dboperator
    

    View Slide

68. ちょっとした補足
    • ちなみに最新バージョンの修正済みのコードでは、環境変数に設定した暗
    号化された値を、KMSを利用して復号するようなコードが実装されていま
    す。
    • コード中に認証情報をハードコードしていなかったとしても、環境変数に
    そのまま認証情報を設定しているような実装の場合には、このように
    lambda関数の読み取り権限を有していれば、簡単に値を取得することが可
    能なので注意が必要です。
    • 実際のペネトレーションテストの現場でも環境変数から認証情報を取得で
    きるケースはしばしばあります。
    

    View Slide

69. FLAGを獲得
    認証情報を利用してphpMyAdminにアクセスすればFLAGを獲得できます。
    

    View Slide

70. この問題のコンセプト
    • 今までご覧いただいた通り、比較的難易度の低い問題を量産していた
    感じなので、ちょっと重めの問題を作問しようと頑張ってみました。
    • タイトル通り、AWS環境におけるペネトレーションテストを体験して
    もらうような内容をイメージして作問してみました。
    • Nginxの設定不備は現実世界でもあり得る設定不備だと思うので注意
    が必要です。
    • lambda関数に関わらず古いコードが残っていて、セキュリティ的な
    問題に発展することも良くあるケースなので注意が必要です。
    • こういった複数の問題が重なり、侵害につながってしまうケースがあ
    りえるということをご認識いただければ幸いです。
    

    View Slide

71. イベントに参加いただいた方に圧倒的感謝！
    ありがとうございました！
    

    View Slide