XXE、SSRF、安全でないデシリアライゼーション入門

12K Views

December 12, 19

security php

スライド概要

LINE DEVELOPER DAY 2019における講演資料
#linedevday

徳丸浩

@ockeghem

スライド一覧

徳丸本の中の人 OWASP Japanアドバイザリーボード EGセキュアソリューションズ取締役CTO IPA非常勤職員 YouTubeチャンネル: 徳丸浩のウェブセキュリティ講座 https://j.mp/web-sec-study

埋め込む »CMSなどでJSが使えない場合

関連スライド

SPAセキュリティ超入門

security php javascript

徳丸浩 677.9K

SPAセキュリティ入門～PHP Conference Japan 2021

security

徳丸浩 285.1K

ウェブセキュリティのありがちな誤解を解説する

security php

徳丸浩 52.4K

ウェブセキュリティの知識は普及しているか、徳丸本の著者が憂慮していること

security

徳丸浩 35.7K

Webアプリケーション開発に潜むリスクのケーススタディ

security cookie

徳丸浩 25.9K

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

security aws

徳丸浩 24.1K

各ページのテキスト

XXE、SSRF、安全でないデシリアライゼーション入門 EGセキュアソリューションズ株式会社代表取締役徳丸浩

本日取り上げる脆弱性について • 今日は以下を紹介します – XML外部実体参照（XXE）攻撃 – サーバーサイド・リクエスト・フォージェリ（SSRF） – 安全でないデシリアライゼーション • これらを取り上げる理由 – XXEと安全でないデシリアライゼーションは、 OWASP Top 10 - 2017 で新たにランクインした – SSRFはセキュリティ界隈で非常に熱い – Capital Oneの事件 © 2016-2019 Hiroshi Tokumaru 3

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

https://store.line.me/stickershop/product/9861689 6

https://store.line.me/stickershop/product/9861689

[beta]

外部実体参照とは
XMLの実体（entity）はXMLの文書型定義中で以下のように宣言する。
宣言した実体は、XML文書内で、&greeting; &external-file;という形（実体参
照）で参照できる。
<?xml version="1.0" encoding="utf8"?>
<!DOCTYPE foo [
<!ENTITY greeting "こんにちは">
<!ENTITY externalfile SYSTEM "external.txt">
]>
<foo>
<hello>&greeting;</hello>
<ext>&externalfile;</ext>
</foo>
<foo>
<hello>こんにちは</hello>
<ext>Hello World</ext>
</foo>
© 2016-2019 Hiroshi Tokumaru

8

攻撃手法と影響サンプルスクリプトの説明・XMLデータをアップロードするフォーム: 4e-024.html <body> XMLファイルを指定してください<br> <form action="/4e3/C4e_023a" method="post"> <textarea name="xml" cols="40" rows="5"> </textarea> <input type="submit"/> </form> </body> © 2016-2019 Hiroshi Tokumaru 9

10.

[beta]

攻撃手法と影響
サンプルスクリプトの説明
・XMLデータを受け取りXML形式を解析して表示するスクリプト:C4e_023.java
public void service(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
request.setCharacterEncoding("UTF-8");
response.setContentType("text/html; charset=UTF-8");
PrintWriter out = response.getWriter();
try {
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
String xml = request.getParameter("xml");
Document doc = builder.parse(new InputSource(new StringReader(xml)));

String name = doc.getElementsByTagName("name").item(0).getTextContent();
String address = doc.getElementsByTagName("address").item(0).getTextContent();
© 2016-2019 Hiroshi Tokumaru

10

11.

12.

[beta]

外部実体参照によるファイルアクセス
/etc /hostsを外部参照で指定したXMLファイルをアップロード
<?xml version="1.0" encoding="utf8"?>
<!DOCTYPE foo [
<!ENTITY host SYSTEM "/etc/hosts">
]>
<user>
<name>安全太郎</name>
<address>&host;</address>
</user>

© 2016-2019 Hiroshi Tokumaru

12

13.

[beta]

URL指定のHTTPアクセスによる攻撃(SSRF攻撃)
内部サーバーのURLを外部参照で指定したXMLファイルをアップロード
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE name [
<!ENTITY schedule SYSTEM "http://internal.example.jp/">
]>
<user><name>安全太郎</name>
<address>&schedule;</address></user>

© 2016-2019 Hiroshi Tokumaru

13

http://internal.example.jp/

14.

脆弱性が生まれる原因と対策原因 XMLの外部実体参照を使うと、XML中に外部のファイルを流し込むことができることはXMLがもともと持つ機能。従って、XXEはXMLの機能を悪用するものであり、プログラムにコーディング上のバグがあるというものではない。各言語共通対策 • XMLの代わりにJSONを用いる外部から与えられる信頼できないXMLを解析しないことが重要。外部とのデータ交換にはXMLではなくJSONを使用する事で脆弱性が発生しないようにできる。ただし、 SOAPのようにプロトコルでXMLを使用している場合はこの対策は使えない。 © 2016-2019 Hiroshi Tokumaru 14

15.

脆弱性が生まれる原因と対策(1) Java言語におけるXXE対策 • DTDあるいは外部実体参照を禁止する Javaの場合は多くのXMLパーサにおいて外部実体参照はデフォルトで有効になっているため、アプリケーション側で対策する必要がある。対策の1つとして、DTD(Document Type Definition)を禁止する事が挙げられる。あるいは、共通対策に挙げたとおり、XMLの代わりにJSONを用いる事で対策が可能である。ただし、XMLとJSON両方に対応したライブラリを使う場合は、受け取ったデータがJSONである事の確認を、ContentTypeのチェック等で行う必要がある。 © 2016-2019 Hiroshi Tokumaru 15

16.

[beta]

JavaによるXXE対策版
public class C4e_023a extends HttpServlet {
public void service(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
request.setCharacterEncoding("UTF-8");
response.setContentType("text/html; charset=UTF-8");
PrintWriter out = response.getWriter();
try {
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl",
true);
// DTDを禁止する設定
DocumentBuilder builder = factory.newDocumentBuilder();
String xml = request.getParameter("xml");
Document doc = builder.parse(new InputSource(new StringReader(xml)));
// 以下略

© 2016-2019 Hiroshi Tokumaru

16

17.

脆弱性が生まれる原因と対策(2) PHPにおけるXXE対策・libxml2のバージョン2.9以降を用いる libxml2のバージョン2.9以降はデフォルトで外部実体参照を停止する設定になっているため、XXE に対して脆弱ではない。ただし、PHP側で外部実体参照を許可する設定にしている場合は例外である。下記にPHP側で外部実体参照を許可するスクリプトを示す。 $doc = new DOMDocument(); $doc->substituteRntities = true; // 外部実体参照を許可…XXE脆弱となる $doc->load($_FILES['user']['tmp_name']); ・libxml_disable_entity_loader(true)を呼び出す PHPバージョン5.2.11以降にはlibxml_disable_entity_loaderという関数が用意されており、下記のように呼び出す事で、libxml2やPHP側の処理内容にかかわらず、外部実体参照を禁止できる。 libxml_disable_entity_loader(true); © 2016-2019 Hiroshi Tokumaru // 外部実体の読み込みを禁止 17

18.

脆弱性が生まれる原因と対策(3) Ruby on RailsにおけるXXE対策 • REXMLを用いてXMLをパースする（詳しくはマニュアル等を参照） • Nokogiriの場合、NOENTオプションを指定しない • ライブラリにより挙動が異なるのでテストしてから使用することを推奨 def xxedo2 xml = params[:xml] doc = REXML::Document.new(xml) @name = doc.elements['//user/name'].text @address = doc.elements['//user/address'].text render 'xxe/xxedo' end © 2016-2019 Hiroshi Tokumaru 18

19.

20.

SSRFのイメージ攻撃者からは、公開サーバー（203.0.113.2）にはアクセスできますが、内部のサーバー（192.168.0.5）はファイアウォールで隔離されているため外部から直接アクセスできない。しかし、公開サーバーから内部のサーバーにはアクセスできる想定。攻撃者は *何らかの方法で* 公開サーバーから内部のサーバーにリクエストを送信することにより、内部のサーバーを攻撃できる場合がある。これがSSRF攻撃。 © 2016-2019 Hiroshi Tokumaru 20

21.

[beta]

プレビュー機能でのSSRF攻撃
これは、はてなブックマークのようなソーシャルブックマークの機能のうち、URLを指定してプレ
ビューを表示するというもの(Ruby on Rails)。

class SsrfController < ApplicationController
def index
url = params[:url]
c = Curl::Easy.new(url) # curb (cURLのRubyラッパー)を使用
c.http_get
s = c.body_str
s.force_encoding("UTF-8"); # curbのバグ対策
render html: Sanitize.clean(s, Sanitize::Config::RELAXED).html_safe
# sanitizeは<script>など攻撃可能なタグを取り除くために使用
end
end
本サンプルはスキームやURLのチェックを一切行っていないため、SSRFに対して脆弱になります。
© 2016-2019 Hiroshi Tokumaru

21

22.

23.

プレビュー機能でのSSRF攻撃次に攻撃例。EC2のインスタンスからhttp://169.254.169.254/ にアクセスすると、そのインスタンスの設定情報が読み込めるという機能がEC2にある。この機能を悪用して、EC2のクレデンシャルを読み込んでみる。まずは、以下のURLにアクセスしてみる。 /ssrf?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ © 2016-2019 Hiroshi Tokumaru 23

24.

25.

SSRF脆弱性(CWE-918)とSSRF攻撃一般的に脆弱性と攻撃手法は1対1の関係になっている。例）SQLインジェクション攻撃が可能なSQLインジェクションの脆弱性しかし、SSRF攻撃とSSRF攻撃の原因となる脆弱性は1対多の関係。例1：SQLインジェクション脆弱性を悪用した任意コマンド実行によるwget、curlを利用したSSRF攻撃例2：ディレクトリトラバーサル脆弱性の混入箇所に、SSRFの脆弱性も含まれていた © 2016-2019 Hiroshi Tokumaru 25

26.

SSRF脆弱性(CWE-918)とは以下は、SSRF脆弱性の分類を定義しているCWE-918の冒頭の引用。 The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination. 参考訳 Webサーバーは、上流のコンポーネントからURLまたは類似のリクエストを受け取り、このURLの内容を取得するが、リクエストが想定される送信先に送られることを十分確実にしていない。要はURLのチェックが不十分なために読まれてはいけないコンテンツを読まれてしまった、ということで、先の例はまさにそのような例になっている。 © 2016-2019 Hiroshi Tokumaru 26

27.

28.

対策 SSRF（CVE-918）以外によるSSRF攻撃が可能な場合 • SSRF攻撃の原因となる脆弱性の対策 SSRF（CVE-918）によるSSRF攻撃が可能な場合 • スキーム（プロトコル）のチェック • parse_urlによって得られたホスト名やパス名からURLを組み立て直す • 仕様的に可能であれば、外部からURLを受け取らないようにするか、許可された URLの一覧表（ホワイトリスト）によるチェック • ネットワーク的な保護 © 2016-2019 Hiroshi Tokumaru 28

29.

30.

対策 • 仕様的に可能であれば、外部からURLを受け取らないようにするか、許可された URLの一覧表（ホワイトリスト）によるチェックホスト名からIPアドレスを求める際にも以下の問題が発生する。＃DNSサーバーが複数のIPアドレスを返す場合の処理の漏れ＃IPアドレスの表記の多様性＃IPアドレスチェックとHTTPリクエストのタイミングの差を悪用した攻撃（TOCTOU脆弱性=DNS Rebinding）＃リクエスト先のWebサーバーが、攻撃対象サーバーにリダイレクトするこれらに注意しつつIPアドレスチェックを実装する必要がある。 © 2016-2019 Hiroshi Tokumaru 30

31.

32.

33.

34.

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

35.

[beta]

参考: cURLの resolve オプションを用いた対策
url = params[:url]
uri = URI.parse(url)
host = uri.host
ip = TCPSocket.gethostbyname(host)[3] # URLからホスト名を取り出し
if ip == '169.254.169.254'
# ブラックリストチェック
render html: 'Invalid Host'
return
end
c = Curl::Easy.new(params[:url])
c.resolve = ["%s:%d:%s" % [uri.host, uri.port, ip]] # resolve によりIPアドレスを指定
c.http_get
s = c.body_str
s.force_encoding("UTF-8");
render html: Sanitize.clean(s, Sanitize::Config::RELAXED).html_safe
検証済みのIPアドレスで接続を行うことから、DNSリバインディング攻撃を防ぐことができる…はず
© 2016-2019 Hiroshi Tokumaru

35

36.

速報: EC2にてSSRF多層防御が実装された What’s new in IMDSv2 With IMDSv2, every request is now protected by session authentication. A session begins and ends a series of requests that software running on an EC2 instance uses to access the locally-stored EC2 instance metadata and credentials. The software starts a session with a simple HTTP PUT request to IMDSv2. IMDSv2 returns a secret token to the software running on the EC2 instance, which will use the token as a password to make requests to IMDSv2 for metadata and credentials. Unlike traditional passwords, you don’t need to worry about getting the token to the software, because the software gets it for itself with the PUT request. The token is never stored by IMDSv2 and can never be retrieved by subsequent calls, so a session and its token are effectively destroyed when the process using the token terminates. There’s no limit on the number of requests within a single session, and there’s no limit on the number of IMDSv2 sessions. Sessions can last up to six hours and, for added security, a session token can only be used directly from the EC2 instance where that session began. https://aws.amazon.com/jp/blogs/security/defense-in-depth-open-firewalls-reverseproxies-ssrf-vulnerabilities-ec2-instance-metadata-service/ 36

https://aws.amazon.com/jp/blogs/security/defense-in-depth-open-firewalls-reverse-

37.

38.

39.

40.

安全でないデシリアライゼーションによる任意コード実行(PHP) Foo Bar class Foo { private $func; public function __destruct() { call_user_func($this->func); } } class Bar { private $func; private $args; public function exec() { call_user_func_array($this->func, $this->args); } } © 2016-2019 Hiroshi Tokumaru 40

41.

[beta]

安全でないデシリアライゼーションによる任意コード実行
:Foo
func:

:配列
0:
1: 'exec'

class Foo {
private $func;
public function __destruct() {
call_user_func($this->func);
}
}

1.
2.
3.
4.
5.

:Bar
func = 'system'
args = ['whoami']
class Bar {
private $func;
private $args;
public function exec() {
call_user_func_array(
$this->func, $this->args);
}
}

Fooオブジェクトのデストラクタが呼ばれる
call_user_func($this->func) が呼ばれる
Barオブジェクトのexecメソッドが呼ばれる
Barオブジェクトのexecメソッド内で、call_user_func_array('system', ['whoami']) が呼ばれる
system('whoami') が呼ばれる
© 2016-2019 Hiroshi Tokumaru

41

42.

43.

Welcart 1.9.4 をリリースしました【脆弱性の修正】 Welcart 1.9.4 をリリースしました。オブジェクトインジェクション脆弱性の修正などを行いました。詳細は以下の通りです。アップグレードを行う場合は、Welcartを停止してからアップグレードを行ってください。【変更点】 • オブジェクトインジェクション脆弱性の修正フロントにて、オブジェクトインジェクションと思われる脆弱性が認められました。過去のすべてのバージョンが対象となります。1.9.4にアップグレードしてください。放置しますと、サイトに任意のファイルの埋め込まれる可能性があります。脆弱性に関する修正の差分はこちら https://www.welcart.com/community/archives/83947より引用 43

https://www.welcart.com/community/archives/83947

44.

Welcart 1.9.3 と 1.9.4の差分典型的な「安全でないデシリアライゼーション」 https://plugins.trac.wordpress.org/changeset?sfp_email=&sfph_mail=&reponame=&new=1728429%40usc-eshop&old=1728428%40usc-e-shop&sfp_email=&sfph_mail= より引用 44

https://plugins.trac.wordpress.org/changeset?sfp_email=&sfph_mail=&reponame=&new=1728429@usc-e-

45.

攻撃に利用できる別プラグインのクラス: All-in-one Event Calendar より class Ai1ec_Shutdown_Controller { protected $_preserve; protected $_restorables; protected $_callbacks; public function __destruct() { // replace globals from our internal store $restore = array(); foreach ( $this->_preserve as $name => $class ) { // 略 } // execute callbacks foreach ( $this->_callbacks as $callback ) { call_user_func( $callback ); } // 後略攻撃に利用可能 } // 後略 } © 2016-2019 Hiroshi Tokumaru 45

46.

[beta]

攻撃に利用できる別プラグインのクラス: ManageWP Worker より
class MWP_WordPress_HookProxy
{
private $callback;
private $args;
// 省略
public function hook()
{
call_user_func_array($this->callback, $this->args);
}
}

攻撃に利用可能

Demo

© 2016-2019 Hiroshi Tokumaru

46

47.

48.

XXE、SSRF、安全でないデシリアライゼーション入門

徳丸 浩

関連スライド

SPAセキュリティ超入門

SPAセキュリティ入門～PHP Conference Japan 2021

ウェブセキュリティのありがちな誤解を解説する

ウェブセキュリティの知識は普及しているか、徳丸本の著者が憂慮していること

Webアプリケーション開発に潜むリスクのケーススタディ

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

各ページのテキスト

徳丸浩