Twitterの脆弱性 2013

Twitterは2010年から、年ごとにTwitterのサービスのセキュリティ問題の報告者のリストを掲載しています。以下がそのページです。

https://twitter.com/about/security

幸運にも、僕は毎年載ることができているので、2013年も早速載ってやろうじゃないかということで頑張って脆弱性を探しました。結果はページを見てもらえばわかると思いますが、なんとかみつけることができました。今回みつけた問題がどんな問題だったかを書きたいと思います。2つあります。

1. analytics.twitter.com のXSS

analytics.twitter.comは、Twitterが提供するサイトオーナーのための解析ツール、だそうです。こんな具合に、ログインページのパラメータでエンコーディング処理に起因するXSSがありました。

XSSベクタに関して特に面白いことはないので、このXSSの影響について考察します。

https://analytics.twitter.com と https://twitter.com の認証は区別されており、https://twitter.comでログインしても https://analytics.twitter.com でログイン状態になることはありません。認証用のCookieの値には適切にHttpOnly属性がついており、XSSがあったとしてもJavaScriptでは取得できないようになっています。
よって、これらから考えられる通常の主な影響は、

・ analytics.twitter.comの解析ツールを利用するログイン中のサイトオーナーがanalytics.twitter.com上で不正な操作をされたり、情報を第三者に取得される
・ *.twitter.comという知名度のあるドメインを使って偽のページを表示することによる効果的なフィッシングをされる

などだと思います。

が、実はそれだけではありませんでした。Twitterは同一生成元ポリシーの制限を緩める設定をhttps://twitter.com 上でしているため、もう少し影響は大きくなります。
その設定とは、 https://twitter.com で読み込まれるJavaScriptの次の一行です。

document.domain="twitter.com";

明示的にdocument.domainを設定したページは、明示的に同じdocument.domainを設定したもう一方の*.twitter.com上のページと相互にアクセスできるようになります。

これはつまり、https://analytics.twitter.com のdocument.domainを、XSSを利用して"twitter.com"に設定すれば、https://analytics.twitter.com から https://twitter.com の内容を読み出すことができることを意味します。https://twitter.com には、ログイン状態で、Twitter上の操作を外部から制限するためのtokenも埋め込まれているので、これを取得し、任意のツイートをつぶやかせるリクエストを発行させることも可能でした。よって、解析ツールを利用するユーザーだけでなく、一般Twitterユーザーも罠ページへのアクセスだけで不正な操作や情報の取得をされる恐れのある問題だったと思います。

2. askobama.twitter.com の https/httpリソースの混在

こちらの画像をご覧ください：

httpsのページ「https://askobama.twitter.com」で、「http://platform.twitter.com/widgets.js」と、"httpで"JavaScriptを読み込んでいます。
もしこのHTTPリソースを中間者が改ざんした場合、考えられる影響はなんでしょうか。

これも先ほどのXSSと同じように、document.domainを"twitter.com"に設定する内容にしてしまえば、https://twitter.com の内容にアクセスすることも可能になります。こんな特設のページでさえも、https://twitter.com のセキュリティに穴をあける問題に直結してしまうというのはちょっと面白いですね。document.domainでアクセスする方法は、ポートとプロトコルは一致している必要があるので、そもそも askobama.twitter.com にhttpsでアクセスできるようにしなければ、https://twitter.com まで影響を受けることはなかったというのもまた面白い点です。

TwitterのSecurity Teamはこの問題に対し、慎重に「http」と「://」の間に「s」を入力することで解決しようとし、無事入力が成功したようです。


以上です！
twitter.comでdocument.domainを設定しているのには理由があるのでしょうが、結果的にサブドメインに脆弱性があった場合の影響範囲が広くなってしまっていますね。

2010年頃なんかのTwitterは、少し風変わりな文字列をツイートに入力すれば、すぐに文字化けが発生したり、XSSが生まれたりしていたものですが、あの頃とは随分変わったなと思います。僕の報告がこの数年間のTwitterのセキュリティの改善の一助になったのであれば、僕はとても嬉しいです。

Google Translator Toolkitに存在したGoogleアカウントのメールアドレスを知られる問題

今月まだ一度もブログを更新してないので、とりあえず小ネタを。

GoogleのTranslator Toolkitという、オンラインで共同でドキュメントの翻訳作業ができるツールに存在した、Googleにログイン中のユーザーのメールアドレスを攻撃者に知らせてしまう問題について書きます。

Translator Toolkitは、共同で翻訳作業をしたい人のメールアドレスを指定し、招待することで、アクセス可能な人を制限しながら翻訳作業をすることができるツールです。
アクセスを許可していない人から翻訳ドキュメントのURLにアクセスされても、以下のように、アクセス許可が与えられていないというメッセージが現れ、適切に閲覧制限できているのがわかります。

ところが一方、 victim.masatokinugawa がこのエラーメッセージを見ているとき、翻訳ドキュメントのオーナーの画面には以下のように表示されていたのです。 

なぜか、victim.masatokinugawaが閲覧者として表示されています。
ページのソースを見ると、完全なメールアドレスも確認できます。

これは明らかに、閲覧者を表示する機能に問題があります。本来は、閲覧を許可されたユーザーが翻訳ドキュメントを開いている場合だけ、閲覧者として表示するようにすべきです。
この不適切な表示により、Googleアカウントへログイン中のユーザーに、攻撃者の翻訳ドキュメントにアクセスさせることで、攻撃者はアクセス者のメールアドレスを不正に知ることが可能でした。

招待していない側からのアクセスは適切に制限できているのに、招待されていない側が漏洩の被害者になるという、面白いバグだと思います。

この問題は2012年4月2日に報告し、しばらくして修正されました。
またGoogleの脆弱性報酬プログラムにより、$500を頂きました。

GoogleからNexus 10をもらった

日頃の行いがいいので、もらいました！！
ホリデーギフトという名目で、去年はChromebookを貰った(※受け取ったのは2012年なんだけど、話をもらったのは2011年)んですが、今年はNexus 10を頂きました。

タブレット、僕は1個も持ってなくて、ちょうどほしいと思ってたところだったので、嬉しいです！

今年はどちらかというとブラウザの脆弱性を探す方に力を入れていたので、前年よりはGoogleサービスの脆弱性報告はしていなかったのですが、気が向いた時に探したり、ブラウザの問題絡みでGoogleのサービスに影響を与える問題などを報告したりして、まぁそこそこは報告していました。

最近はこんな、上位報告者のリストみたいなのも掲載されてるみたいで、

The "0x0A List" – Application Security – Google
http://www.google.com/about/appsecurity/hall-of-fame/

僕は0x02位らしいです。 結構上位ですね！
来年もまた、何かあげたくなるような貢献ができるよう頑張りたいと思います。

Thank you Google Security Team!!