NECサイバーセキュリティ戦略本部セキュリティ技術センターの中島です。
2021年９月、OWASP TOP 10:2021のドラフト[1]が公開されました。その中で、新たにSSRF（Server Side Request Forgery）がランクインしました。SSRFは、サーバーサイドに対する攻撃手法のひとつです。近年、SSRFを用いた攻撃がクラウド環境に対してもよく見られるようになり、注目されています。本日は脆弱なAWS環境を構築することができるツール「CloudGoat」[2]の攻撃シナリオ「SSRF-EC2」を使って、クラウド環境におけるSSRFを使用した攻撃について紹介します。
SSRF とは
SSRF（Server Side Request Forgery）とは、サーバー側のアプリケーションを操り、そのサーバーから攻撃者が指定した任意の別のサーバ―（ドメイン）へHTTP要求を行わせる攻撃手法・脆弱性です。[3]
よく見られるSSRFの攻撃例として、以下の図のようにインターネットに公開されているサーバーから本来インターネットから到達できない内部のサーバーに対してHTTP要求を行わせることでアクセスを行う攻撃があります。
クラウド環境下では、SSRFを利用してメタデータサービスに対して不正にアクセスする事例があります。メタデータサービスは、クラウド環境の内部のインスタンスからHTTPリクエストを送付することでクラウド上のインスタンスに関する資格情報などのメタデータを取得できるサービスです。最近では、SSRFの脆弱性を利用してメタデータサービスにクラウドシステムの外部からアクセスし、認証情報窃取して悪用する事例が見られます。
有名な事例として、2019年には米国の金融大手 Capital One がWAFの設定ミスを悪用したSSRF攻撃の被害にあっています。詳細については、SSRF攻撃によるCapital Oneの個人情報流出についてまとめてみた[4]に詳しくまとめられています。
CloudGoat とは
本記事では、CloudGoatを使ってSSRFを用いた攻撃について紹介しますので、CloudGoatについて少しふれておきます。
CloudGoat とは、脆弱性が作りこまれたAWS環境を構築することができるツールです。
Rhino Security Labs社が提供しており、設定されたシナリオに沿ってAWS環境に対する攻撃について学ぶことができます。
本記事の執筆時点では以下の9つのシナリオが用意されています。
- iam_privesc_by_rollback
- lambda_privesc
- cloud_breach_s3
- iam_privesc_by_attachment
- ec2_ssrf ★本記事で紹介
- ecs_takeover
- rce_web_app
- codebuild_secrets
- ecs_efs_attack
本記事ではCloudGoatの環境構築方法については割愛いたします。ご自身で実際に動かしてみたい方は、 CloudGoatのGithubに記載されているRequirementsとQuickStartを参考に構築してください。
なお、CloudGoatは脆弱な環境をAWS上に作成するツールですので、ご自身のお手元で試される際には接続元IPアドレスの制限やCloudGoat用のIAMユーザーを作成して作業するなど、十分なセキュリティ対策を実施してください。（※CloudGoatのgithubに記載されている設定手順に従うことで、最低限のセキュリティ設定ができるようになっています。）
SSRF-EC2 の紹介
本記事では、CloudGoatのシナリオの中でも、Amazon EC2におけるSSRFの脆弱性を扱う「SSRF-EC2」を紹介します。
シナリオの概要は以下の通りです。
- はじめに「Solus」というIAMユーザーのクレデンシャル情報が与えられます。
- 「Solus」のもつ権限を使用してLambda関数にハードコーディングされた認証情報発見します。
- 認証情報を使用して脆弱なwebアプリケーションを実行しているEC2インスタンスにアクセスし、SSRFの脆弱性をついてEC2のメタデータサービスから鍵を取得します。
- 鍵を用いてs3バケットにアクセスします。
それではまずは、シナリオを開始するために問題環境をセットアップします。
下記のコマンドを実行すると、AWSアカウント内にシナリオ用のリソースが作成されます。
リソースの作成が終わると、start.txtというファイルが作成された旨が表示されます。
ファイルの中身を確認します。
本シナリオで使用する 「solus」 という IAM ユーザーが作成され、その認証情報が入っていることがわかります。
「aws config」コマンドを使用して「solus」というprofile を作成します。
まずは与えられたsolusユーザーに関するポリシーを確認します。
ユーザーのポリシーを確認する権限は与えられていませんでした。
シナリオを確認するとLambda関数の情報にシークレットが隠されていると書いてあるので、関数の情報を確認し、実行してみます。
Lambda関数を実行することはできませんでしたが、環境変数に EC2_ACCESS_KEY_ID と EC2_SECRET_KEY_ID の情報が設定されていることがわかりました。
このように関数の環境変数にシークレットを保存すると漏洩する可能性があります。AWS Key Management Service (KMS) などを使用して、関数の環境変数にシークレットを保存しないようにすることを推奨します。
それでは、入手した認証情報を用いて「solus_lambda」というプロファイルを作成します。
「solus_lambda」に関するポリシーを確認しようとしますが、権限が与えられていないためアクセスできないことを確認しました。
作成したプロファイルを用いてEC2インスタンスの情報を確認します。
EC2 インスタンスのパブリックIPアドレスがわかりました。
このIPアドレスにアクセスしてみます。
「url」というパラメーターがあることがわかるので、パラメーターをセットしてリクエストを送信します。
SSRFのデモページであることがわかりました。
ここで、メタデータサービス（http[:]//169.254.169.254/latest/meta-data/iam/security-credentials/）にアクセスすることで、インスタンスで使用される情報と認証情報を取得します。次に、取得した認証情報を用いて他のサービスを侵害していくことを考えます。
EC2インスタンスにアタッチされたIAMロール名を取得しました。
つづいて、このIAMロールの認証情報を取得します。
IAMロールの一時的な認証情報（AccessKeyId, SecretAccessKey, Token）の情報を取得しました。取得したIAMロールの認証情報を用いて「solus_ec2」というプロファイルを作成します。
取得した認証情報を使用して、s3バケットの一覧を表示します。
「cg-secret-s3-bucket-cgid08ld8mqgxr」というバケットがあることがわかりました。
このバケットの内容を表示します。
「admin-user.txt」というファイルがあることがわかりました。
ダウンロードして中身を確認します。
認証情報が入っていることを確認しました。
入手した認証情報を用いて 「ssrf_admin」というプロファイルを作成します。
作成したプロファイルを用いて権限の確認をします。
アタッチされているポリシーを確認します。
ポリシーの中身を確認するため、まずはポリシーのバージョンを確認します。
ポリシーの中身を確認します。
管理者権限をもっていることがわかりました。
一番はじめに確認したLambda関数をもう一度確認します。
関数を実行します。
実行結果を確認します。
「You Win!」が返ってきていることがわかります。
以上で本シナリオは終了です。
最後に後片付けとしてこのシナリオで使用しているリソースをAWS環境から削除します。
まとめ
本記事では、脆弱なAWS環境を構築することができるツール「CloudGoat」のシナリオを通じて、クラウド環境におけるSSRFについて紹介しました。このツールには、SSRF以外にもクラウド環境における脆弱性が組み込まれたシナリオが用意されていますので、ぜひ活用してみてください。
参考資料
[2] https://github.com/RhinoSecurityLabs/cloudgoat
[3] https://portswigger.net/web-security/ssrf
[4] https://piyolog.hatenadiary.jp/entry/2019/08/06/062154
執筆者プロフィール
中島 春香（なかしま はるか）
セキュリティ技術センター リスクハンティングチーム
ペネトレーションテストを通じて安全なシステムの構築支援の業務に従事。
CTF for GIRLS副代表として主にWeb分野の問題作成やワークショップ企画設計を担当。
CISSP Associate 保持 SANS SEC504 メダル保持
「Hardening II SU」にてMVV(Most Valuable vendor)賞受賞
趣味は美味しいものやワクワクすることを探し歩くこと。