TwitterのOAuth脆弱性
2K Views
March 01, 13
スライド概要
TwitterのOAuth脆弱性
2013-03-01
Xtone Ltd. ピザ会
Aki / @nekoruri
秋葉原生まれ大手町育ちの歌って踊れる江戸っ子インフラエンジニア。 0と1が紡ぐ「ゆるやかなつながり」に魅せられ早20年、 SNSとCGMの力で世界を幸福にするのがライフワーク。 市民、幸福は義務です。 あなたは幸福ですか？
関連スライド
各ページのテキスト
TwitterのOAuth脆弱性 2013-03-01 Xtone Ltd. ピザ会 Aki / @nekoruri
なにがおきたの？ ( ^o^) なんか友達からURL送られてきたお
なにがおきたの？ ( ˘⊖˘) 。o(ID/Pass入力しなきゃ安全だよな ……)
なにがおきたの？ |URL| ┗(☋｀ )┓三
なにがおきたの？ ( ◠‿◠ )☛ アクセストークンは頂いた、抵抗は無意 味だ
なにがおきたの？ ▂▅▇█▓▒░(’ω’)░▒▓█▇▅▂うわあああああああ
なにがおきたの？ ( ^o^)なんか友達からURL送られてきたお ( ˘⊖˘) 。O(ID/Pass入力しなきゃ安全だよな ……) |URL| ┗(☋｀ )┓三 ( ◠‿◠ )☛アクセストークンは頂いた、抵抗は無意 味だ ▂▅▇█▓▒░(’ω’)░▒▓█▇▅▂うわあああああああ ＿人人人人人人人人＿ ＞ 大量のDM送信 ＜ ￣Y^Y^Y^Y^Y^Y^Y￣
おさらい • URLを開くだけでアクセストークンが取られ る – 連携済みアプリの権限を悪者が丸ごと奪取 – デスクトップアプリ系なので、ほとんどDM込み 全許可 – CSRF脆弱性の一種 • 現時点（2013/03/01 13時）で少しだけ改善 – 当初使われていた手法は無効化（未確認） • その後（2013/03/01 15時）に対応 – クライアントアプリ提供者の設定変更が必要 – まだ脆弱なシナリオは残る（後述）
おきたこと 1. URLを開く 2. IFRAMEでTwitterの認証ページにリダイレ クト 3. ログイン中かつ連携済みアプリがあれば、 ダイアログ無しでCallback URLにリダイレ クト 4. Callback URLでアクセストークン取得完了
おきたこと 1. URLを開く 2. IFRAMEでTwitterの認証ページにリダイレ クト 3. ログイン中かつ連携済みアプリがあれば、 ダイアログ無しでCallback URLにリダイレ クト IFRAME内である以外は、 4. Callback URLでアクセストークン取得完了 通常のソーシャルログインそのものじゃね？ !?
取られていたはずの対策 PINコード入力(OOB)モード • 必ずPINコードが表示 • Callback URLは指定不可 X-Frame-Optionsヘッダ • フレーム内では表示されない
問題点1 アプリ設定のCallback URL • アプリ設定で入れたCallback URLは？ – 仕様変更により、実質空欄かどうかしか見ていな い • 空欄 – PINコード入力モードが必須になる • なにかいれる – 入力内容と無関係にrequest_token取得時に Callback URLを指定できる – request_token取得時にCallback URLを省略するとこ れになるらしい（未確認）
問題点2 PINコードなんて使わねーよ馬鹿 • 操作上の不利益 – 表示された8桁の数字をコピペさせる？はぁ？ • 技術的難しさ – 表示された内容からスクレーピング？ – できない場合もある（標準ブラウザ等） – 他の手段があるなら面倒だしそっちで……
問題点2 PINコードなんて使わねーよ馬鹿 • PINコードは嫌だ派の回避策 – PINコードなんて使わない （アプリ設定にはダミーURLを設定） – どこかにリダイレクトさせてアプリで受け取 る • リダイレクト先ウェブサーバをlocalhostで起動 • 独自スキーマでインテント（Android）
問題点2 PINコードなんて使わねーよ馬鹿 • PINコードは嫌だ派の回避策 – PINコードなんて使わない （アプリ設定にはダミーURLを設定） – どこかにリダイレクトさせてアプリで受け取 る • リダイレクト先ウェブサーバをlocalhostで起動 • 独自スキーマでインテント（Android） 認証開始時に任意のURLを Callback URLに指定可能
問題点3 X-Frame-Options • そもそもなにそれ – フレーム内での表示を「拒否」できる – 対応するかはブラウザ次第 （サーバ側はフレーム内かどうかはわからな い） – 最近のブラウザではそれなりに実装 IE 8+, Firefox 3.6.9+, Safari 4+, Chrome 4.1+ – TwitterではSAMEORIGINが設定 → 同じドメイン上のサイトからのみ許可
問題点3 X-Frame-Options • そもそもなにそれ – フレーム内での表示を「拒否」できる – 対応するかはブラウザ次第 （サーバ側はフレーム内かどうかはわからな い） – 最近のブラウザではそれなりに実装 IE 8+, Firefox 3.6.9+, Safari 4+, Chrome 4.1+ – TwitterではSAMEORIGINが設定 → 同じドメイン上のサイトからのみ許可 ……だったはずなのに……
問題点3 X-Frame-Options • Locationのリダイレクトは受け付けちゃう – Firefox、Chromeで確認 – 意味ないじゃん！！！！ ＜2013-03-01 13時頃での対策＞ リダイレクトの方法を Locationヘッダ→HTML refreshに変更 • ちなみに – 一般的な設定では既に持ってるCookieも送信 – 3rd party Cookieの送信ポリシー次第 参考：http://d.hatena.ne.jp/mala/20111125/1322210819
問題点3 X-Frame-Options • Locationのリダイレクトは受け付けちゃう この時点で、今回の大量のIFRAME – Firefox、Chromeで確認 – 意味ないじゃん！！！！ による総当たり攻撃には対応 ＜2013-03-01 13時頃での対策＞ リダイレクトの方法を Locationヘッダ→HTML refreshに変更 • ちなみに – 一般的な設定では既に持ってるCookieも送信 – 3rd party Cookieの送信ポリシー次第 参考：http://d.hatena.ne.jp/mala/20111125/1322210819
問題点4 「ソーシャルログイン」機能 • OAuth 1.0aの仕様外のTwitter独自機能 – GET oauth/authenticate https://dev.twitter.com/docs/api/1/get/oauth/aut henticate – ログイン時かつ許可済みのアプリならば、 ダイアログ無しでリダイレクト – （おそらく）ユーザの利便性のために提供 – この機能の存在自体が脆弱性……？
本質的な問題では無いもの consumer_secretの「流出」 • デスクトップアプリにおける consumer_secret – OAuthで認証する時に使う – アプリ毎に1つ – 配布ファイル内に含めないといけない – メモリ上で必ず一時的には平文で存在 設計上は「公開情報」とみなすべき クライアントが本物かは信用できな い どう せ 漏れ る
OAuth 1.0aのおさらい（超ざっくり） ブラウザ （ユーザー） クライアント Twitter request_token request_token request_token + Cookie ログインしてクライアントに権限を渡す許可 を出す Callback URL + request_token + verifierにリダイレクトしろ 同上 Callback URLを保存 Callback URL request_token + verifier access_token ※ 主要な情報の動きだけを書いたものです。
OAuth 1.0aのおさらい（超ざっくり） クライアント 一度許可をしていると、 2度目以降は画面無しで request_token Callback URLにリダイレクト Twitter Callback URL request_token request_token + Cookie Callback URL + request_token + verifierにリダイレクトしろ 同上 Callback URLを保存 ブラウザ （ユーザー） request_token + verifier access_token ※ 主要な情報の動きだけを書いたものです。
OAuth 1.0aのおさらい（超ざっくり） ブラウザ （ユーザー） クライアント Twitter request_token Callback URLにいるクライアント が request_token アクセストークンを取得できる request_token Callback URL + request_token + verifierにリダイレクトしろ 同上 Callback URLを保存 Callback URL request_token + verifier access_token ※ 主要な情報の動きだけを書いたものです。
OAuth 1.0aのおさらい（超ざっくり） ブラウザ （ユーザー） クライアント Twitter Callback URLを誰が渡すかが重要 request_token Callback URLにいるクライアント が request_token アクセストークンを取得できる request_token Callback URL + request_token + verifierにリダイレクトしろ 同上 Callback URLを保存 Callback URL request_token + verifier access_token ※ 主要な情報の動きだけを書いたものです。
問題点4 「ソーシャルログイン」機能 • ウェブアプリの場合 – consumer_secretを知っている → 正しいクライアントと言い切れる（普通 は） – 正しいクライアントの主張するCallback URLは 信用できる – そのままリダイレクトしてCallback URLの先の ページにアクセストークンを渡しても良い
問題点4 「ソーシャルログイン」機能 • デスクトップアプリの場合 – consumer_secretを知っている → 正しいクライアントとは限らない – そのクライアントが主張しているCallback URL は信用できない – 登録されたアプリ情報を見せて、ユーザーの 判断を仰がなくてはいけない。 （2013-03-01 15時頃?） アプリ設定でダイアログ強制表示を選べるように変更
（参考）PINコードを入力する 場合 ブラウザ （ユーザー） クライアント Twitter PINで認証したい request_token request_token Twitterサイト上に 表示されたPINコードは request_token + Cookie 自動では取得できない ログインしてクライアントに権限を渡す許可 を出す PINコード PINコード コピペ PINコード request_token + verifier access_token ※ 主要な情報の動きだけを書いたものです。
アプリ側の対策案 1. PIN入力モードだけを使う（確実） アプリ設定のCallback URLは空欄にする – 2. PIN入力の手間を減らす（非推奨） ブラウザに表示されたPINを自動取得 スマホ系での対策案 – – • • Androidのブラウザでスクレイピング http://www.slideshare.net/maimuzo/android-3170284 iPhoneでOAuth認証するぜの巻 http://hidden.vis.ne.jp/blog/?p=570 ただし：本来は標準ブラウザに飛ばすべき – • OAuthの認証にWebViewを使うのはやめよう http://shogo82148.github.com/blog/2012/11/24/no-morewebview/
アプリ側の対策案 3. デスクトップアプリはダイアログを強制表示（確 実） – – – – – アプリ設定の「Sign in with Twitter」を無効化 oauth/authenticateでもリダイレクトしない （必ず確認ダイアログが表示される） これがTwitter側からの最終的な対策と思われる 作者が気付かず「Sign in with Twitter」が有効なままのデ スクトップアプリは対策されない → 窓から投げ捨てろ、アプリへの許可を取り消せ 悪意のあるアプリが他のアプリのconsumer_{token,secret} を利用する場合 → 必ずダイアログ出るので無意味 アプリの名前も確認せず[許可]押した奴が悪い
主な情報源 1. 2. 3. 4. 5. 6. [Twitter公式] Changes to the 'Sign in with Twitter' flow https://dev.twitter.com/blog/changes-to-sign-in-with-twitter TwitterのOAuthの問題まとめ https://gist.github.com/mala/5062931 怪しいクライアントを許可していないのに勝手に twitter で DM が送信されていた http://vividcode.hatenablog.com/entry/twitter-oauthvulnerability DM踏んだだけでアレな件はTwitterのOAuth実装がク○だと思 う https://gist.github.com/ritou/5053810 【拡散希望】twitterの新型ウイルスがヤバい URL踏んだだけ でアウト http://uinyan.com/twitter_oauth_vulnerability/ フィッシング？ - Togetter http://togetter.com/li/463503
今回の名言 （malaさんのgist:5062931より） ユーザーの自衛策として「怪しいリンク をクリックするな」というのは無茶なの で、そういった対策が必要なものはバグ です、セキュリティホールです。怪しい リンクをクリックできない世界のほうが 間違っている。
Twitterさん迅速な対応おつかれさまでした。