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 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%[email protected]/
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
終わり