TwitterのOAuth脆弱性

3,150 views
2,871 views

Published on

TwitterのOAuth脆弱性

2013-03-01
Xtone Ltd. ピザ会
Aki / @nekoruri
----
SlideShare側でファイルが破損してしまったようで、
http://www.slideshare.net/nekoruri/20130301-twitter-oauthvulnerability
を再アップロードしました。

Published in: Technology
0 Comments
10 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,150
On SlideShare
0
From Embeds
0
Number of Embeds
72
Actions
Shares
0
Downloads
4
Comments
0
Likes
10
Embeds 0
No embeds

No notes for slide

TwitterのOAuth脆弱性

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

×