Twitter OAuth vulnerability

TwitterのOAuth脆弱性

2013-03-01
Xtone Ltd. ピザ会
Aki / @nekoruri

Transcript

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