INT 4: HACKER

Web security research

Spoofing Twitter official application / 偽のTwitter公式アプリが作成可能だった問題

f:id:reinforchu:20190923152212p:plain

 dev.twitter.com(現在のdeveloper.twitter.com)とapi.twitter.com(Sign in with Twitter)において、Twitter公式アプリケーションと瓜二つの偽物が作成可能で、詐称できた問題について書き起こします。

 

概要

 この問題には現在対策され、少なくとも私が知りうる限りでは、新規に作成できなくなっています。対策されたことを踏まえ、ここでは過去の手法について軽く触れておきます。

 

問題点

 Twitterのサーバーサイドの文字列処理の検証に不備がありました。それは、Unicodeの不可視文字コードです。悪意のあるUnicode文字を、先頭または後方に挿入することで、アプリケーション上のアプリケーション名の重複チェックを回避しつつ、不可視文字が挿入された悪意のあるTwitterサードパーティーアプリケーションが作成可能でした。

 もちろんこの記事ではPoCや、具体的な文字コードを言及することはありません。

 

実際の Sign in with Twitter

f:id:reinforchu:20201219083631j:plain

これは当時、巧妙に作成したもので、うっかり認証させてしまいそうになったかもしれません。

 

Twitterの対策

 Twitterはサーバーサイド側の実装においても、入力値のチェックを厳格に行うように修正されました。後述しますが結果的には対策されましたが、問題点が残っています。

 

残された問題点

・既存作成済みのアプリケーションが凍結(SUSPEND)されていない

 これはセキュリティリサーチにおいて面白いことですが、不正と思われるアプリケーションは凍結や削除するのが筋でしょう。

f:id:reinforchu:20201219084444p:plain

 中には凍結(SUSPEND)された、まあ珍しいアプリケーションが私のアカウントに残っています。

f:id:reinforchu:20201219084659p:plain

 残念なことに、未だ凍結されていないアプリケーションに中には、Sign in with Twitter が有効(審査済み)されているものが残っています。

f:id:reinforchu:20201219084916p:plain

 もし私が悪い人だった場合、これは想像したくはありません。

 

被害に遭わないために

 ここまで巧妙なアプリケーションの作成が可能であった場合、サードパーティーアプリケーションの認証にはよく注意することを推奨します。少なくとも、公式Twitterが権限を求めてくることは、今現在は仕組み上撤廃されていると思われます。また、名指しをしてしまうと、○○診断系のアプリケーションは収集した情報や、取得した権限で何をしでかすか分かったものではありません。ただ、個々人が信用して注意して認証したとしても、サードパーティーアプリケーションのTokenが漏れるなど、どうしようもないことも多分にあります。必要性のある時だけ認証し、不要になったらRevokeするという運用手段も一つの手であるのかな、と考えます。

 今一度、自身が認証しているアプリケーションを見直してみましょう。