http://こいつの:話@shibuya.xss.moe
TRANSCRIPT
!Date -> 2016/03/28 Event -> Shibuya.XSS techtalk #7 !
http://こいつの:話@shibuya.xss.moe/ !Speaker -> やぎはしゅ Twitter -> @yagihashoo Web -> https://xss.moe/
console.log(やぎはしゅ)
• 八木橋 優(やぎはし ゆう) • 就職しました(約1年前)
今日の話題これ、知ってますか？
3
こういう機能
4
仕様上は…。
• URIはRFC2396で定義、RFC3986で改定されている • RFC2396「基本的にイマイチだよね」 • RFC3986「":"より後ろの文字列をそのまま平文で表示すんなよ！見えちゃうから！」
• RFC1738を見ると当初はFTPやTelnetでの使用を想定していた形跡もあるが、全体的にもやっとした仕様になっている
1.ざっくりとした仕様はちゃんと定義されている 2.その取扱いについてはブラウザ側に任されている部分が多い 3.稀によくある話だけど、ブラウザ間で実装に差異がありそう
5
実装上は…。
• もう死んでると思っている人も実は多そう
6
各ブラウザ毎の対応状況
Windows OS X iOS Android
IE ✕ ― ― ―
Edge ✕ ― ― ―
Chrome ◯ ◯ ✕ ◯
Firefox ◯ ◯ ◯ ◯
Safari ― ◯ ◯ ―
Opera ◯ ◯ ― ◯
7
各ブラウザ毎の対応状況
Windows OS X iOS Android
IE ✕ ― ― ―
Edge ✕ ― ― ―
Chrome 確認なし 確認なし ✕ 確認なし
Firefox 確認あり 確認あり 確認なし 確認あり
Safari ― 警告あり 警告あり ―
Opera 確認なし 確認なし ― PWマスクあり
8
ユーザ確認が入るパターン
9
ユーザ確認が入るパターン
10
PWがマスクされるパターン
11
Firefoxの挙動履歴表示時にユーザ名、パスワードも併せて表示されてしまう。
12
Chrome/Operaの挙動
ブラウザ終了後も認証情報が保持されている。
13
URLに認証情報を含めない場合 URLに認証情報を含めた場合
ID/PWの入力ダイアログなし
Cmd+Q Cmd+Q
Safariの挙動
画面上に認証情報がそのまま表示されてしまう。
14
攻撃への悪用可能性
• ここまでだけなら割としょーもない仕様の話 • たぶんそのうち勝手に死に絶える • ふと思いついたシナリオの話 • 割とシンプルかつ被弾する範囲も多くなりそう
15
各種ルータの管理画面ハック
• 管理画面のXSSやらCSRFやらは割とよく見かける • 運良く修正までこぎつけるとJVNに載る • 修正まで漕ぎ着けなかった場合は…
16
管理画面攻略まで
• 一般にルータの管理画面は内側にしか公開されない • 内部ネットワークの脆弱性は割と軽視されがち • ルータの管理画面の脆弱性を突くとき前提となる条件は以下 1. ユーザが管理画面にログイン済である 2. XSSが発現するURLが既知である 3. ユーザが罠ページを踏む
• 最もキツい条件が「ユーザが管理画面にログイン済である」であると思われる
17
ユーザが管理画面にログイン済である
• 多くのルータの管理画面の認証方式がBasic認証 • ユーザ名とパスワードがわかればXSSが発現するページのURLにそれらを含めるだけで強制的に標的をログインさせることが可能
• ユーザ名とパスワードはググれば出てくる！！⇒ 条件1、突破
18
XSSが発現するURLが既知である
• あるルータでXSSが発現する条件を知っている場合例えば反射型ならlocation.pathname以降は既知
• 残るはlocation.hostname部分だけ • 多くのルータのIPアドレスはググれば出てくる！！⇒ 条件2、突破
19
ユーザが罠ページを踏む
• 何らかの方法で踏ませる⇒ 条件3、突破
20
まとめ
• ネットワーク機器(特に家庭用のルータ)のXSSは攻撃成立の難易度が普通のXSSに比べて難しいわけではない！
• URL中の認証情報、ちょっと掘るだけで怪しげな挙動が非常に多くて、バグハンター諸氏が楽しめそうな気配がある
22
window.close()