Tweet
Tweet

Slide 1

Slide 1 text

TBD 2016‑11‑14 Shibuya.XSS techtalk #8 ma.la

Slide 2

Slide 2 text

今日のテー マ Flash とCORS の話 URL Parser の話 Chrome 拡張のマルウェア解析の話 せっかくなので全部話しますね。

Slide 3

Slide 3 text

Flash とCORS の話 JS とFlash でcross origin で可能なことのポリシー が異なります 多くの開発者はcross origin で出来て良いことを正確に把握していま せん 外部ドメインの画像をデー タとして取得出来る問題が「 裏技」 のよ うに扱われ、 脆弱性として認識されないことがありました CORS によって仕様が整理されているので、 仕様か脆弱性かは明確 になりつつあります

Slide 4

Slide 4 text

続きはWeb で Flash の微妙な仕様を脆弱性として報告しています(1 年直ってない) cross origin でサイズ取得、 リダイレクト有無の判別 https://gist.github.com/mala/8e822f2e292d8db68e288ac9350 25c71

Slide 5

Slide 5 text

Chrome のマルウェア解析の話 Chrome 拡張機能がマルウェアになったと騒いでる人がいたので調 査しました。 特定の拡張機能について騒ぐのはナンセンスなので、5000 件ほど ダウンロー ドして調査しました TOP5000 のうち、 既に削除されているものも含めると 0.7% 程度難 読化された外部script の読み込みがありました

Slide 6

Slide 6 text

続きはWeb で 興味深い挙動として、 いくつかは webRequestBlocking permission によってCSP を破壊していました。 https://gist.github.com/mala/e87973df5029d96c9269d9431fc ef5cb

Slide 7

Slide 7 text

URL Parser に起因する脆弱性 ma.la

Slide 8

Slide 8 text

概要 URL パー サに起因する脆弱性について いくつかはまだ未修正

Slide 9

Slide 9 text

1. URL Parser とは My URL isn't your URL cURL の作者によるURL の仕様と実装についての苦言 https://daniel.haxx.se/blog/2016/05/11/my‑url‑isnt‑your‑url/

Slide 10

Slide 10 text

URL の解釈に関する話 ブラウザやライブラリによって異なるURL と認識される RFC 通りに実装されているとは限らないし、RFC が正しいとは限ら ない 互換性のため、 相互運用性のためにinvalid なURL を許容することが ある

Slide 11

Slide 11 text

例えば http://example.com/#hash#in#hash # in location.hash valid or invalid?

Slide 12

Slide 12 text

厳格なparser ではerror Java: new URI Ruby: URI.parse

Slide 13

Slide 13 text

2. URL 誤認による脆弱性 URL Parser 自体にバグが有るもの チェックするタイミングによって問題が起きるもの

Slide 14

Slide 14 text

SOP bypass Android でのUXSS \u0000javascript:xxx でUXSS が可能だった問題

Slide 15

Slide 15 text

問題の箇所 https://android.googlesource.com/platform/external/webkit/+/7e 4405a7a12750ee27325f065b9825c25b40598c^!/ URL をcheck する箇所でprotocol を確認している 正規化前のURL で、javascript: かどうかの確認が行われる 実際には正規化されたURL で処理される → \u0000 が無視される

Slide 16

Slide 16 text

Open Redirect http://homakov.blogspot.jp/2014/01/evolution‑of‑open‑redirect‑ vulnerability.html //example.com /\example.com http:example.com

Slide 17

Slide 17 text

WordPress の事例 CVE‑2016‑2221 https://core.trac.wordpress.org/changeset/36444 Open redirect vulnerability in the wp_validate_redirect

Slide 18

Slide 18 text

Bypass A: http:example.com host が取れないけど相対パスじゃない ブラウザでは http://example.com と解釈

Slide 19

Slide 19 text

ホスト名の一致を確認する必要がある parse_url(url).host == “example.com”

Slide 20

Slide 20 text

Bypass B: otherprotocol:example.com javascript://example.com%0A alert(1); XSS with href, iframe, js refresh, etc.

Slide 21

Slide 21 text

Oops! じゃあ、protocol もチェックしましょう url.protocol == “http” || url.protocol == “https”

Slide 22

Slide 22 text

Bypass C: http://evil.example.com#@example.com/ host of this url is Browser: evil.example.com PHP 5.6: example.com

Slide 23

Slide 23 text

非常に深刻な問題 origin = scheme + host + port 正しい方法でのsame origin 判定が失敗する！！ SOP bypass on server‑side

Slide 24

Slide 24 text

host 名を誤認するURL いくつかのライブラリ、 言語の標準実装で問題あり PHP, ■■■■, ■■■■■■■ (reported by mala) PHP 5.6.28 / 7.0.13 で直っています cURL ( 自分の報告ではない)

Slide 25

Slide 25 text

UPDATE 2017‑02 Java/Android それぞれ修正された CVE‑2016‑5552 Java : 2017‑01 http://www.oracle.com/technetwork/security‑ advisory/cpujan2017‑2881727.html Android : 2017‑02 https://source.android.com/security/bulletin/2017‑02‑01.html http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/cd0585378c46 https://android.googlesource.com/platform/libcore/+/4b3f2c6c5 b84f80fae8eeeb46727811e055715ea^!/

Slide 26

Slide 26 text

この問題は知られている？ 未修正の事例はまだ公開できないが、 問題自体はcURL のケー スで 公知 https://curl.haxx.se/docs/adv_20161102J.html CVE‑2016‑8624 複数の実装で同様の問題がある、 インター ネットのバグ！

Slide 27

Slide 27 text

WordPress の事例のテストケー スにあり PHP のバグなので上流に報告しましょう

Slide 28

Slide 28 text

正しい実装は？ https://tools.ietf.org/html/rfc3986#section‑3.2 T h e a u t h o r i t y c o m p o n e n t i s p r e c e d e d b y a d o u b l e s l a s h ( t e r m i n a t e d b y t h e n e x t s l a s h ( " / " ) , q u e s t i o n m a r k ( " ? " ) , s i g n ( " # " ) c h a r a c t e r , o r b y t h e e n d o f t h e U R I .

Slide 29

Slide 29 text

Authority component user:pass@example.com の部分 / or ? or # で問答無用で終わるのが正しい

Slide 30

Slide 30 text

バグが起こりやすい原因 絶対URL と相対パスの両方を同じライブラリで処理 http url とそれ以外のprotocol も同列に処理 歴史的経緯、 相互運用性、 互換性のための寛容な処理 user:pass には本来、 予約文字が使えない a u t h o r i t y = [ u s e r i n f o " @ " ] h o s t [ " : " p o r t ] u s e r i n f o = * ( u n r e s e r v e d / p c t - e n c o d e d / s u b - d e l i m s /

Slide 31

Slide 31 text

3. 実世界での問題 URL Parser のバグがどのように脆弱性になるか XSS, Open Redirector, SSRF ...

Slide 32

Slide 32 text

A: DOM based XSS(client side) CVE‑2012‑3695 userinfo 部分を使って誤認識させる http://masatokinugawa.l0.cm/2012/08/safari‑location.href.html http://siteA.example.com%2F@siteB.example.com/ location.href of WebKit based browser ホスト名部分がdecode されて返ってくる → location.href が異なる host の値を返す。 same origin の判定に失敗して外部ドメインのリソー スを読み込み

Slide 33

Slide 33 text

B: Open Redirector → XSS client side + server side jQuery mobile + open redirector http://jqm‑site.example.com/#!/path/to/redirect_other_website 外部HTML をオー プンリダイレクタで読み込ませるもの2011 年に発 見 最近報告したものがある

Slide 34

Slide 34 text

C: Open Redirector → Auth bypass server side. URL parser バグ起因のものは実際の事例は見つけていない 危なっかしい状態だったものはあり

Slide 35

Slide 35 text

validation of callback url OAuth, OpenID などのredirect url domain のみ一致でcheck していると危険 URL parser がバグっていると。。。 そもそも「 ドメイン」 丸ごと安全とは限らない

Slide 36

Slide 36 text

Why? ホスト名誤認を使って別ドメインに認証コー ドを送る オー プンリダイレクタとの組み合わせ referrer で外部に認証コー ドが漏洩するPath を指定する

Slide 37

Slide 37 text

Provider 実装側 Path は先頭一致にしないで「 完全一致」 にすべき redirect_uri=http://example.com/auth/callback/../../../ これが通ってしまうと別Path に認証コー ドを送ることが可能 そもそもuser:pass が入ってるのとおかしいので、 正規化して完全 一致にしましょう。 query string 部分のみ除去して登録済みURL と比較

Slide 38

Slide 38 text

D: SSRF / TOCTOU attack イントラネットのURL にHTTP request を送る 管理画面に攻撃コー ド送る 変換系処理のAPI で内容を取得する

Slide 39

Slide 39 text

SSRF with URL Parser's bug URL がintranet のhost ではないか確認 → hostname 誤認問題があるparser を使っていると。。。 解釈の違いによって問題が起きる場合がある

Slide 40

Slide 40 text

そもそも check と use は異なる実装で行ってはいけない Time‑of‑check Time‑of‑use problem URL をcheck するタイミング、fetch するタイミング DNS が変更されている可能性がある

Slide 41

Slide 41 text

バグをなくすための考え方 check / use で可能であれば同じ実装を使いましょう。 check / use は同じデー タを使いましょう。 "Normalize strings before validating them"

Slide 42

Slide 42 text

HTML parser の問題 以前発表した https://speakerdeck.com/owaspjapan/xss‑with‑ html‑parsing‑confusion‑number‑appsecapac2014 < ! - - > - - > の解釈の違いを使ったXSS ブラウザの実装と、js やサー バー サイドで解釈が違う TinyMCE, etc.

Slide 43

Slide 43 text

URL Parser の場合 client / server / language 複数の実装が混在するのは必然 need more test case.

Slide 44

Slide 44 text

終わり