TwitterのOAuth脆弱性
Upcoming SlideShare
Loading in...5
×
 

TwitterのOAuth脆弱性

on

  • 1,974 views

TwitterのOAuth脆弱性 ...

TwitterのOAuth脆弱性

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

Statistics

Views

Total Views
1,974
Views on SlideShare
1,918
Embed Views
56

Actions

Likes
9
Downloads
2
Comments
0

2 Embeds 56

https://twitter.com 51
http://www.slideee.com 5

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

TwitterのOAuth脆弱性 TwitterのOAuth脆弱性 Presentation Transcript

  • 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にリダイレクト 4. Callback URLでアクセストークン取得完了 !? IFRAME内である以外は、 通常のソーシャルログインそのものじゃね?
  • 取られていたはずの対策 • 必ずPINコードが表示 • Callback URLは指定不可 PINコード入力(OOB)モード • フレーム内では表示されない 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で確認 – 意味ないじゃん!!!! • ちなみに – 一般的な設定では既に持ってるCookieも送信 – 3rd party Cookieの送信ポリシー次第 参考:http://d.hatena.ne.jp/mala/20111125/1322210819 <2013-03-01 13時頃での対策> リダイレクトの方法を Locationヘッダ→HTML refreshに変更
  • 問題点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 による総当たり攻撃には対応
  • 問題点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 Callback URL + request_token + verifierにリダイレクトしろ ブラウザ (ユーザー) request_token + Cookie request_token ログインしてクライアントに権限を渡す許可を出す request_token 同上 Callback URL CallbackURLを保存 request_token + verifier access_token ※ 主要な情報の動きだけを書いたものです。
  • 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にリダイレクト
  • 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にいるクライアントが アクセストークンを取得できる
  • 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にいるクライアントが アクセストークンを取得できる
  • 問題点4 「ソーシャルログイン」機能 • ウェブアプリの場合 – consumer_secretを知っている → 正しいクライアントと言い切れる(普通は) – 正しいクライアントの主張するCallback URLは信 用できる – そのままリダイレクトしてCallback URLの先のペー ジにアクセストークンを渡しても良い
  • 問題点4 「ソーシャルログイン」機能 • デスクトップアプリの場合 – consumer_secretを知っている → 正しいクライアントとは限らない – そのクライアントが主張しているCallback URLは信 用できない – 登録されたアプリ情報を見せて、ユーザーの判断 を仰がなくてはいけない。 (2013-03-01 15時頃?) アプリ設定でダイアログ強制表示を選べるように変更
  • (参考)PINコードを入力する場合 クライアント Twitter PINコード ブラウザ (ユーザー) request_token + Cookie request_token ログインしてクライアントに権限を渡す許可を出す request_token PINコード PINで認証したい request_token + verifier access_token ※ 主要な情報の動きだけを書いたものです。 Twitterサイト上に 表示されたPINコードは 自動では取得できない PINコード コピペ
  • アプリ側の対策案 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/
  • アプリ側の対策案 3. デスクトップアプリはダイアログを強制表示(確実) – アプリ設定の「Sign in with Twitter」を無効化 – oauth/authenticateでもリダイレクトしない (必ず確認ダイアログが表示される) – これがTwitter側からの最終的な対策と思われる – 作者が気付かず「Sign in with Twitter」が有効なままのデスク トップアプリは対策されない → 窓から投げ捨てろ、アプリへの許可を取り消せ – 悪意のあるアプリが他のアプリのconsumer_{token,secret}を 利用する場合 → 必ずダイアログ出るので無意味 アプリの名前も確認せず[許可]押した奴が悪い
  • 主な情報源 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
  • 今回の名言 (malaさんのgist:5062931より) ユーザーの自衛策として「怪しいリンクをク リックするな」というのは無茶なので、そういっ た対策が必要なものはバグです、セキュリ ティホールです。怪しいリンクをクリックできな い世界のほうが間違っている。
  • Twitterさん迅速な対応おつかれさまでした。