Transcript Cookie forcing

Cross-domain leakiness
Divulging sensitive information & attacking SSL sessions
Chris Evans - Google
Billy Rios - Microsoft
自己紹介
• Chris Evans
o
o
o
トラブルメーカー、エンジニア、技術リーダー、Googleセキュ
リティチーム
http://scary.beasts.org/
http://scarybeastsecurity.blogspot.com/
• Billy Rios
o
o
モデル、セキュリティエンジニア、Microsoft
http://xs-sniper.com/
謝辞
クレジット
•
•
•
•
Filipe Almeida, Google
Michal Zalewski, Google
Drew Hintz, Google
Kanatoko
Cross-domain leakiness
概要
•
•
•
•
•
•
はじめに
背景知識
クロスドメインなバグ
設計におけるクロスドメイン問題
ブラウザのSSLセッションを攻撃
デモ
Cross-domain leakiness
はじめに
• そのウェブアプリケーションはクロスドメインセーフ?
• ユーザのブラウザは?
背景知識
中間者攻撃 (MITM)
• 何者かがネットワークトラフィックを傍受
o 特にワイヤレスネットワークで
• MITMなし
o 悪意のあるURLを踏ませて攻撃
• 受動的なMITM
o 通信内容を傍受するだけ
o 例: ISPに設置された政府機関のブラックボックス
• 積極的なMITM
o レスポンスやリクエストを偽装可能
o 例: 無料のワイヤレスネットワーク
背景知識
単一のセッションに限定したブラウジン
グ
• 偏執的なユーザのウェブ利用方法
• 疑心暗鬼がベース
o 同一オリジンポリシー
o ブラウザのセキュリティ
o データの隔離
o ウェブアプリケーション
背景知識
クロスサイトスクリプトインクルー
ジョン
• XSSIとも呼ばれる
• Sometimes bucketed under XSRF / CSRF
• リモートの認証済みリソースを読み込む
o <script src="http://remote.com/sensitive"/>
背景知識
Cookieのセキュリティモデル
• 元々のCookieモデル:
o ドメインとパスが一致した場合に送信
• DOMに対するアクセスに同一オリジンポリシーが追加
:
o プロトコル、ドメイン、ポートが一致した場合に許
可
• CookieのモデルではHTTPでHTTPSのCookieが漏洩
o Cookieに「セキュア」属性が追加
クロスドメインなバグ
Firefox #1: 画像を盗む
• 認証済みの画像を盗む
• canvasのgetImageData()で
o もしくはtoDataUrl()
• 以前は画像のピクセルが読めなかった
• ドメインはチェックされるが302によるリダイレクト
で回避
• WebKitのナイトリービルドにも同じバグが
• 302によるリダイレクトは過去にも実績あり
• 簡単なデモ
クロスドメインなバグ
Firefox #2: 16進数文字列を盗む
• 認証済みの１６進数文字列を盗める
• FireFox 3.0.3に影響するが、おそらくこのカンファレ
ンスまでに修正されていないはずなので、詳細は非公
開
• 簡単なデモ
クロスドメインなバグ
Safari #1: ファイルを盗む
• まだ修正されていないため、詳細は非公開
• ややこしいクロスドメインでオリジンチェックを怠る
• 簡単なデモ
クロスドメインなバグ
Safari #3: ファイルを盗む
•
•
•
•
CVE-2008-3638で修正
リモートとローカルの境界を区別するのを怠る
Java関連
デモ
クロスドメインなバグ
WebKit: ピクセルを盗む
• Nice combination of features came together in WebKit
nightly
• 予期せぬIllustrates danger of unexpected interactions
• 機能をコラボ:
o SVGサポート
o <img>のターゲットとしてのSVG
o getImageData()
o SVGに含まれた<image>
• <html:iframe>と組み合わせればさらに凶悪
クロスドメインなバグ
まだまだある
• ブラウザの新機能は常に新しいクロスドメインなエリ
アとの相互作用をもたらす
o しばしばわかりにくい
• ブラウザがクロスドメインデータを扱う詳細なリスト
が必要
• クロスドメインのエリアとテスト結果をまとめたスプ
レッドシート
o https://spreadsheets.google.com/ccc?key=pEFQCm
3fodP3jM-lyIwjwSw
What’s in a Name?
ケーススタディ: Flash DNSリバインディン
グ
• DNSリバインディングとピンニング問題を簡単に復習
• 攻撃者はFoo.comのDNSをコントロール
• Foo.comのリクエストを送信、foo.comは
111.111.111.111
• 攻撃者はFoo.comのDNSエントリを10.1.1.1に変更
• 攻撃者はすでにロードされたコンテンツを10.1.1.1の情
報を盗むのに使う
What’s in a Name?
ケーススタディ: Flash DNSリバインディ
ング
• CVE-2008-1655で修正
• 同一ドメインでも異なる形式を区別
• 発見したのはJumperz (金床氏)!
o オリジナルをベースにしているが、すこし工夫した
What’s in a Name?
ケーススタディ: Flash DNSリバインディ
ング
•
•
•
•
「.」で終わるドメイン名を扱う
さて、XS-Sniper.comとXS-Sniper.com.は同じか?
Flashのソケットでおもしろいことに ☺
修正済なのに、なぜ今これを取り上げるのか?
設計の問題
CSSのプロパティを盗む
• ブラウザが クロスドメインのCSSをロード
o <link rel="stylesheet" href="http://remote/blah"/>
• ブラウザが自動判定し、インライン<style>をHTMLか
ら抽出
• JavaScriptからプロパティの値を読める
• クロスアプリケーションにログイン状態を判定するす
ごい方法
• プロパティにはまだセンシティブなデータは含まれて
いない
設計の問題
XSSI - リモートスクリプトインジェク
ション
• この問題はさらに悪化!
o バリッドなテキスト構造は増加傾向
• リモートドメインのJavaScriptは実行可能
• ソースは読めないが、ソースを実行することで副作用
を観察できる
クロスサイトスクリプトインクルージ
XSSI: stealable constructs
ョン
• 関数のコールバック
o 例 "callback_func(1, 'data');"
• 変数をセット
o 例 "var result = 100;"
• 関数の定義
o 例 "function blah() { var a = 1; }"
• JavaScriptの配列データ (FireFox 2)
o 例 "[1, 2, 3, 4]"
XSSI
今後
• XMLを盗む
o XHTMLと一部のHTMLはXMLとしてパースできる
o XMLはE4Xをサポートする正しいJavaScript
 FireFox2, FireFox3
• XMLに対するJavaScriptインジェクションで盗む
• ランダムなFireFoxのバグ: XMLに対するXMLインジェク
ション
XSSI
今後
• 言語のコアな部分をオーバーロード
o XMLのコンストラクタをオーバーロード
o 数値のコンストラクタをオーバーロード
o エラータイプをオーバーロード
o 基本的なオブジェクトをオーバーロード
XSSI
対策
• XSRFに対する保護を適用
o 認証済みのGETリクエストには難しい
• JavaScriptの実行や文法を破壊
o while(1);はよく使われる
 「1」がNumber()を発動させたら?
o 文法を思いっきり破壊するか、もしくはオーバーラ
イドができなさそうなものを使う
o 例 "for (;;);" or ")]}"
• 常にXMLプロローグとDTDを含める
SSLサイトに対する積極的なMITM
• コンテンツを混在させるべきではない!
• 安全でないスクリプトの参照を見つけ出す (画像でもう
まくいくことが)
• 安全でないスクリプトの参照はHTTPSによるロードを強
制
• 攻撃者は警告を表示させることなくSSLで保護されたサ
イトのMIMTが可能!
• 実際の例を…
設計の問題
Cookie forcing
• この名称はGoogleの検索結果から
o "Cookie forcing"の検索結果 123件
• ちょwww、名前に「jacking」が入ってないwww
o 気に入らなければ「cookie force-jacking」とでも
Cookie forcing
それって何? おいしいの?
• Cookieのモデルはセキュア属性が付いてもまだ危険
• 「読み取り」は固定されているが「書き込み」はされ
ていない
• ゆえに、http://bank.com/ は、https://bank.com/の
セキュア属性Cookieを上書き可能
• これ自体はよく知られており、目新しくはない
o 目新しいのは攻撃の詳細とデリバリーメカニズム
Cookie forcing
悪意のあるCookieには何が可能か?
• アプリケーションはCookieを完全に信用してしまうこ
とがある
o アプリケーションで作成したのだから信用できる
o HTTPSを使用しているから整合性もあるはず
• 悪意のあるCookie forcingは is sidejacking to the max
- (現時点の)ベストプラクティスに従っているにも関わ
らず、HTTPSアプリケーションを破る
Cookie forcing
Cookieの埋め込みでXSS
• アプリケーションが、書き込み時にCookieをエスケー
プする...
• ... で、読み取り時には注意しなくてもいい、はず?
• HTMLの生成やDOMアクセスでXSS
• JSONのeval()でXSS
Cookie forcing
Cookieの埋め込みでXSRF
• よくあるXSRF対策のひとつでは、URLパラメータと
nouce(一度だけ使われるランダムな文字列)を比較する
• 大規模なアプリケーションではCookieにnonceを入れ
る
• ということは、攻撃者はnonce CookieとURLパラメー
タも手に入れられる!
Cookie forcing
アプリケーションロジックの
Cookie
• Cookieによってはアプリケーションのロジックに影響
する
• 嫌がらせ
o 表示言語
o 永続的にアプリケーションを破壊
• もうちょっとまじめに
o センシティブな設定
o デバッグモード
Cookie forcing
ログイン/ログアウトXSRF
• 認証クッキーの保護にできることはすくない
o (緩和策はのちほど)
• すでに発行されたCookieに対する攻撃も同様
• 「痕跡を残さない」攻撃も可能
• XSRF対策でPOSTのデータはXSRF保護で回避
o XSRFトークンが不一致の場合、アプリケーション
はどう振る舞うだろう?
Cookie forcing
対策
• Cookieのデータは悪意あるものとして扱う
o パースしてエスケープすること、eval()してはいけ
ない
• センシティブなCookieは署名する
o ユーザと関連付けるのを忘れないこと
o 現在のセッションに関連付けるのがベスト
• ログイン/ログアウトXSRF対策は困難
o ランダムなCookie名は可能
o しかし、今度は攻撃者による同名Cookieに対策が必
要
 どちらが本物?!
偏執狂を攻撃
銀行にアクセスするとか?
• ウインドウ1枚、タブ1つのモデル
• HTTPSのブックマークだけを開く
• すると、もう攻撃は成功している
o 何が起きたのか?
偏執狂を攻撃
ブラウザが更新するものって?
•
•
•
•
フィッシング対策/マルウェアリストの更新
HTTPSの証明書をHTTPで読み込む
更新告知ping
RSSフィードの更新
偏執狂を攻撃
えーと、ただのHTTP
• 攻撃者は302リダイレクトを返す
o 任意のドメインに対して
• ブラウザが新しいリクエストを投げる
• 攻撃者がCookieを付けて返す
• あらゆるドメインの任意のCookieをセットもしくは削
除
o セキュア属性のCookieも含む
o もしくは、すでに発行されたCookieを上書き
• 痕跡を残さないからこの攻撃はすごい
o バックグラウンドでリクエストされるリダイレクト
は、
URLバーにも現れない
偏執狂を攻撃
他にも可能性が
• 未来のセッションのためにキャッシュに毒入れ
o HTTPのみ
• 未来のセッションのためにCookieに毒入れ
偏執狂を攻撃
対策
• 信頼できないネットワークでは、ブラウザのHTTPSに
よる整合性に依存しない
• より信頼できるネットワークにはVPNを使う
• HTTPリクエストにつながるブラウザの機能を無効にす
る(でも、ひとつでも抜けていたら?)
• HTTPプロトコルのプロキシはlocalhost:1に設定
デモ
cookie forcingのデモ
Q&A