Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Twitter OAuth vulnerability

Twitter OAuth vulnerability

TwitterのOAuth脆弱性

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

@nekoruri

March 01, 2013
Tweet

More Decks by @nekoruri

Other Decks in Programming

Transcript

  1. TwitterのOAuth脆弱性
    2013-03-01
    Xtone Ltd. ピザ会
    Aki / @nekoruri

    View full-size slide

  2. なにがおきたの?
    ( ^o^) なんか友達からURL送られてきたお

    View full-size slide

  3. なにがおきたの?
    ( ˘⊖˘) 。o(ID/Pass入力しなきゃ安全だよな……)

    View full-size slide

  4. なにがおきたの?
    |URL| ┗(☋` )┓三

    View full-size slide

  5. なにがおきたの?
    ( ◠‿◠ )☛ アクセストークンは頂いた、抵抗は無意味だ

    View full-size slide

  6. なにがおきたの?
    ▂▅▇█▓▒░(’ω’)░▒▓█▇▅▂うわあああああああ

    View full-size slide

  7. なにがおきたの?
    ( ^o^)なんか友達からURL送られてきたお
    ( ˘⊖˘) 。O(ID/Pass入力しなきゃ安全だよな……)
    |URL| ┗(☋` )┓三
    ( ◠‿◠ )☛アクセストークンは頂いた、抵抗は無意味だ
    ▂▅▇█▓▒░(’ω’)░▒▓█▇▅▂うわあああああああ
    _人人人人人人人人_
    > 大量のDM送信 <
     ̄Y^Y^Y^Y^Y^Y^Y ̄

    View full-size slide

  8. おさらい
    • URLを開くだけでアクセストークンが取られる
    – 連携済みアプリの権限を悪者が丸ごと奪取
    – デスクトップアプリ系なので、ほとんどDM込み全許可
    – CSRF脆弱性の一種
    • 現時点(2013/03/01 13時)で少しだけ改善
    – 当初使われていた手法は無効化(未確認)
    • その後(2013/03/01 15時)に対応
    – クライアントアプリ提供者の設定変更が必要
    – まだ脆弱なシナリオは残る(後述)

    View full-size slide

  9. おきたこと
    1. URLを開く
    2. IFRAMEでTwitterの認証ページにリダイレクト
    3. ログイン中かつ連携済みアプリがあれば、
    ダイアログ無しでCallback URLにリダイレクト
    4. Callback URLでアクセストークン取得完了

    View full-size slide

  10. おきたこと
    1. URLを開く
    2. IFRAMEでTwitterの認証ページにリダイレクト
    3. ログイン中かつ連携済みアプリがあれば、
    ダイアログ無しでCallback URLにリダイレクト
    4. Callback URLでアクセストークン取得完了
    !? IFRAME内である以外は、
    通常のソーシャルログインそのものじゃね?

    View full-size slide

  11. 取られていたはずの対策
    • 必ずPINコードが表示
    • Callback URLは指定不可
    PINコード入力(OOB)モード
    • フレーム内では表示されない
    X-Frame-Optionsヘッダ

    View full-size slide

  12. 問題点1
    アプリ設定のCallback URL
    • アプリ設定で入れたCallback URLは?
    – 仕様変更により、実質空欄かどうかしか見ていない
    • 空欄
    – PINコード入力モードが必須になる
    • なにかいれる
    – 入力内容と無関係にrequest_token取得時にCallback
    URLを指定できる
    – request_token取得時にCallback URLを省略するとこ
    れになるらしい(未確認)

    View full-size slide

  13. 問題点2
    PINコードなんて使わねーよ馬鹿
    • 操作上の不利益
    – 表示された8桁の数字をコピペさせる?はぁ?
    • 技術的難しさ
    – 表示された内容からスクレーピング?
    – できない場合もある(標準ブラウザ等)
    – 他の手段があるなら面倒だしそっちで……

    View full-size slide

  14. 問題点2
    PINコードなんて使わねーよ馬鹿
    • PINコードは嫌だ派の回避策
    – PINコードなんて使わない
    (アプリ設定にはダミーURLを設定)
    – どこかにリダイレクトさせてアプリで受け取る
    • リダイレクト先ウェブサーバをlocalhostで起動
    • 独自スキーマでインテント(Android)

    View full-size slide

  15. 問題点2
    PINコードなんて使わねーよ馬鹿
    • PINコードは嫌だ派の回避策
    – PINコードなんて使わない
    (アプリ設定にはダミーURLを設定)
    – どこかにリダイレクトさせてアプリで受け取る
    • リダイレクト先ウェブサーバをlocalhostで起動
    • 独自スキーマでインテント(Android)
    認証開始時に任意のURLを
    Callback URLに指定可能

    View full-size slide

  16. 問題点3
    X-Frame-Options
    • そもそもなにそれ
    – フレーム内での表示を「拒否」できる
    – 対応するかはブラウザ次第
    (サーバ側はフレーム内かどうかはわからない)
    – 最近のブラウザではそれなりに実装
    IE 8+, Firefox 3.6.9+, Safari 4+, Chrome 4.1+
    – TwitterではSAMEORIGINが設定
    → 同じドメイン上のサイトからのみ許可

    View full-size slide

  17. 問題点3
    X-Frame-Options
    • そもそもなにそれ
    – フレーム内での表示を「拒否」できる
    – 対応するかはブラウザ次第
    (サーバ側はフレーム内かどうかはわからない)
    – 最近のブラウザではそれなりに実装
    IE 8+, Firefox 3.6.9+, Safari 4+, Chrome 4.1+
    – TwitterではSAMEORIGINが設定
    → 同じドメイン上のサイトからのみ許可
    ……だったはずなのに……

    View full-size slide

  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に変更

    View full-size slide

  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
    による総当たり攻撃には対応

    View full-size slide

  20. 問題点4
    「ソーシャルログイン」機能
    • OAuth 1.0aの仕様外のTwitter独自機能
    – GET oauth/authenticate
    https://dev.twitter.com/docs/api/1/get/oauth/aut
    henticate
    – ログイン時かつ許可済みのアプリならば、
    ダイアログ無しでリダイレクト
    – (おそらく)ユーザの利便性のために提供
    – この機能の存在自体が脆弱性……?

    View full-size slide

  21. 本質的な問題では無いもの
    consumer_secretの「流出」
    • デスクトップアプリにおけるconsumer_secret
    – OAuthで認証する時に使う
    – アプリ毎に1つ
    – 配布ファイル内に含めないといけない
    – メモリ上で必ず一時的には平文で存在
    設計上は「公開情報」とみなすべき
    クライアントが本物かは信用できない
    どうせ
    漏れる

    View full-size slide

  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
    ※ 主要な情報の動きだけを書いたものです。

    View full-size slide

  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にリダイレクト

    View full-size slide

  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にいるクライアントが
    アクセストークンを取得できる

    View full-size slide

  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にいるクライアントが
    アクセストークンを取得できる

    View full-size slide

  26. 問題点4
    「ソーシャルログイン」機能
    • ウェブアプリの場合
    – consumer_secretを知っている
    → 正しいクライアントと言い切れる(普通は)
    – 正しいクライアントの主張するCallback URLは信
    用できる
    – そのままリダイレクトしてCallback URLの先のペー
    ジにアクセストークンを渡しても良い

    View full-size slide

  27. 問題点4
    「ソーシャルログイン」機能
    • デスクトップアプリの場合
    – consumer_secretを知っている
    → 正しいクライアントとは限らない
    – そのクライアントが主張しているCallback URLは信
    用できない
    – 登録されたアプリ情報を見せて、ユーザーの判断
    を仰がなくてはいけない。
    (2013-03-01 15時頃?)
    アプリ設定でダイアログ強制表示を選べるように変更

    View full-size slide

  28. (参考)PINコードを入力する場合
    クライアント Twitter
    PINコード
    ブラウザ
    (ユーザー)
    request_token + Cookie
    request_token
    ログインしてクライアントに権限を渡す許可を出す
    request_token
    PINコード
    PINで認証したい
    request_token + verifier
    access_token
    ※ 主要な情報の動きだけを書いたものです。
    Twitterサイト上に
    表示されたPINコードは
    自動では取得できない
    PINコード
    コピペ

    View full-size slide

  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/

    View full-size slide

  30. アプリ側の対策案
    3. デスクトップアプリはダイアログを強制表示(確実)
    – アプリ設定の「Sign in with Twitter」を無効化
    – oauth/authenticateでもリダイレクトしない
    (必ず確認ダイアログが表示される)
    – これがTwitter側からの最終的な対策と思われる
    – 作者が気付かず「Sign in with Twitter」が有効なままのデスク
    トップアプリは対策されない
    → 窓から投げ捨てろ、アプリへの許可を取り消せ
    – 悪意のあるアプリが他のアプリのconsumer_{token,secret}を
    利用する場合
    → 必ずダイアログ出るので無意味
    アプリの名前も確認せず[許可]押した奴が悪い

    View full-size slide

  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

    View full-size slide

  32. 今回の名言
    (malaさんのgist:5062931より)
    ユーザーの自衛策として「怪しいリンクをク
    リックするな」というのは無茶なので、そういっ
    た対策が必要なものはバグです、セキュリ
    ティホールです。怪しいリンクをクリックできな
    い世界のほうが間違っている。

    View full-size slide

  33. Twitterさん迅速な対応おつかれさまでした。

    View full-size slide