2021年10月1日

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つのシナリオが用意されています。

本記事ではCloudGoatの環境構築方法については割愛いたします。ご自身で実際に動かしてみたい方は、 CloudGoatのGithubに記載されているRequirementsとQuickStartを参考に構築してください。

なお、CloudGoatは脆弱な環境をAWS上に作成するツールですので、ご自身のお手元で試される際には接続元IPアドレスの制限やCloudGoat用のIAMユーザーを作成して作業するなど、十分なセキュリティ対策を実施してください。（※CloudGoatのgithubに記載されている設定手順に従うことで、最低限のセキュリティ設定ができるようになっています。）

SSRF-EC2 の紹介

本記事では、CloudGoatのシナリオの中でも、Amazon EC2におけるSSRFの脆弱性を扱う「SSRF-EC2」を紹介します。

シナリオの概要は以下の通りです。

それではまずは、シナリオを開始するために問題環境をセットアップします。
下記のコマンドを実行すると、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以外にもクラウド環境における脆弱性が組み込まれたシナリオが用意されていますので、ぜひ活用してみてください。

参考資料

執筆者の他の記事を読む