TBD/Shibuya.XSS techtalk #8

Flash & CORS https://gist.github.com/mala/8e822f2e292d8db68e288ac935025c71
malicious chrome extension https://gist.github.com/mala/e87973df5029d96c9269d9431fcef5cb
URL Parser / English ver https://gist.github.com/mala/f86a849d15b2d60d7119e05f33b4b885

Transcript

1. TBD 2016‑11‑14 Shibuya.XSS techtalk #8 ma.la
2. 今日のテー マ Flash とCORS の話 URL Parser の話 Chrome 拡張のマルウェア解析の話 せっかくなので全部話しますね。
3. Flash とCORS の話 JS とFlash でcross origin で可能なことのポリシー が異なります 多くの開発者はcross origin で出来て良いことを正確に把握していま せん 外部ドメインの画像をデー タとして取得出来る問題が「 裏技」 のよ うに扱われ、 脆弱性として認識されないことがありました CORS によって仕様が整理されているので、 仕様か脆弱性かは明確 になりつつあります
4. 続きはWeb で Flash の微妙な仕様を脆弱性として報告しています(1 年直ってない) cross origin でサイズ取得、 リダイレクト有無の判別 https://gist.github.com/mala/8e822f2e292d8db68e288ac9350 25c71
5. Chrome のマルウェア解析の話 Chrome 拡張機能がマルウェアになったと騒いでる人がいたので調 査しました。 特定の拡張機能について騒ぐのはナンセンスなので、5000 件ほど ダウンロー ドして調査しました TOP5000 のうち、 既に削除されているものも含めると 0.7% 程度難 読化された外部script の読み込みがありました
6. 続きはWeb で 興味深い挙動として、 いくつかは webRequestBlocking permission によってCSP を破壊していました。 https://gist.github.com/mala/e87973df5029d96c9269d9431fc ef5cb
7. URL Parser に起因する脆弱性 ma.la
8. 概要 URL パー サに起因する脆弱性について いくつかはまだ未修正
9. 1. URL Parser とは My URL isn't your URL cURL の作者によるURL の仕様と実装についての苦言 https://daniel.haxx.se/blog/2016/05/11/my‑url‑isnt‑your‑url/
10. URL の解釈に関する話 ブラウザやライブラリによって異なるURL と認識される RFC 通りに実装されているとは限らないし、RFC が正しいとは限ら ない 互換性のため、 相互運用性のためにinvalid なURL を許容することが ある
11. 例えば http://example.com/#hash#in#hash # in location.hash valid or invalid?
12. 厳格なparser ではerror Java: new URI Ruby: URI.parse
13. 2. URL 誤認による脆弱性 URL Parser 自体にバグが有るもの チェックするタイミングによって問題が起きるもの
14. SOP bypass Android でのUXSS \u0000javascript:xxx でUXSS が可能だった問題
15. 問題の箇所 https://android.googlesource.com/platform/external/webkit/+/7e 4405a7a12750ee27325f065b9825c25b40598c^!/ URL をcheck する箇所でprotocol を確認している 正規化前のURL で、javascript: かどうかの確認が行われる 実際には正規化されたURL で処理される → \u0000 が無視される
16. Open Redirect http://homakov.blogspot.jp/2014/01/evolution‑of‑open‑redirect‑ vulnerability.html //example.com /\example.com http:example.com
17. WordPress の事例 CVE‑2016‑2221 https://core.trac.wordpress.org/changeset/36444 Open redirect vulnerability in the wp_validate_redirect
18. Bypass A: http:example.com host が取れないけど相対パスじゃない ブラウザでは http://example.com と解釈
19. ホスト名の一致を確認する必要がある parse_url(url).host == “example.com”
20. Bypass B: otherprotocol:example.com javascript://example.com%0A alert(1); XSS with href, iframe, js refresh, etc.
21. Oops! じゃあ、protocol もチェックしましょう url.protocol == “http” || url.protocol == “https”
22. Bypass C: http://evil.example.com#@example.com/ host of this url is Browser: evil.example.com PHP 5.6: example.com
23. 非常に深刻な問題 origin = scheme + host + port 正しい方法でのsame origin 判定が失敗する！！ SOP bypass on server‑side
24. host 名を誤認するURL いくつかのライブラリ、 言語の標準実装で問題あり PHP, ▪▪▪▪, ▪▪▪▪▪▪▪ (reported by mala) PHP 5.6.28 / 7.0.13 で直っています cURL ( 自分の報告ではない)
25. 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^!/
26. この問題は知られている？ 未修正の事例はまだ公開できないが、 問題自体はcURL のケー スで 公知 https://curl.haxx.se/docs/adv_20161102J.html CVE‑2016‑8624 複数の実装で同様の問題がある、 インター ネットのバグ！
27. WordPress の事例のテストケー スにあり PHP のバグなので上流に報告しましょう
28. 正しい実装は？ 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 .
29. Authority component user:pass@example.com の部分 / or ? or # で問答無用で終わるのが正しい
30. バグが起こりやすい原因 絶対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 /
31. 3. 実世界での問題 URL Parser のバグがどのように脆弱性になるか XSS, Open Redirector, SSRF ...
32. 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 の判定に失敗して外部ドメインのリソー スを読み込み
33. B: Open Redirector → XSS client side + server side jQuery mobile + open redirector http://jqm‑site.example.com/#!/path/to/redirect_other_website 外部HTML をオー プンリダイレクタで読み込ませるもの2011 年に発 見 最近報告したものがある
34. C: Open Redirector → Auth bypass server side. URL parser バグ起因のものは実際の事例は見つけていない 危なっかしい状態だったものはあり
35. validation of callback url OAuth, OpenID などのredirect url domain のみ一致でcheck していると危険 URL parser がバグっていると。。。 そもそも「 ドメイン」 丸ごと安全とは限らない
36. Why? ホスト名誤認を使って別ドメインに認証コー ドを送る オー プンリダイレクタとの組み合わせ referrer で外部に認証コー ドが漏洩するPath を指定する
37. Provider 実装側 Path は先頭一致にしないで「 完全一致」 にすべき redirect_uri=http://example.com/auth/callback/../../../ これが通ってしまうと別Path に認証コー ドを送ることが可能 そもそもuser:pass が入ってるのとおかしいので、 正規化して完全 一致にしましょう。 query string 部分のみ除去して登録済みURL と比較
38. D: SSRF / TOCTOU attack イントラネットのURL にHTTP request を送る 管理画面に攻撃コー ド送る 変換系処理のAPI で内容を取得する
39. SSRF with URL Parser's bug URL がintranet のhost ではないか確認 → hostname 誤認問題があるparser を使っていると。。。 解釈の違いによって問題が起きる場合がある
40. そもそも check と use は異なる実装で行ってはいけない Time‑of‑check Time‑of‑use problem URL をcheck するタイミング、fetch するタイミング DNS が変更されている可能性がある
41. バグをなくすための考え方 check / use で可能であれば同じ実装を使いましょう。 check / use は同じデー タを使いましょう。 "Normalize strings before validating them"
42. HTML parser の問題 以前発表した https://speakerdeck.com/owaspjapan/xss‑with‑ html‑parsing‑confusion‑number‑appsecapac2014 < ! - - > - - > の解釈の違いを使ったXSS ブラウザの実装と、js やサー バー サイドで解釈が違う TinyMCE, etc.
43. URL Parser の場合 client / server / language 複数の実装が混在するのは必然 need more test case.
44. 終わり