ソーシャルサービスのアカウント名を奪取する新手のセキュリティ脅威「Silhouette」とは？

SNSなどソーシャルサービスの「ブロック機能」を悪用する新手のアカウント名奪取の手法「Silhouette（シルエット）」。秘密をばらされなくなければ送金を……なんて事態は避けたいところ。そのための具体的な対策とは？

[土肥正弘，ドキュメント工房]

　「アダルトサイトにアクセスしましたね。秘密にしますから送金してください」と個人名を宛先にしたメールが届く……。NTTの研究チームが、SNSなどソーシャルサービスの「ブロック機能」を悪用する新手のアカウント名奪取方法を発見した。「Silhouette（シルエット）」と名付けられたこの新しい脅威は、SNSで名前が特定されかねないアカウント名を利用しているユーザーは特に注意したいところ。一体どんな攻撃なのだろうか。　

「Silhouette」って何？

　Cookieを使ってログイン認証を行うソーシャルWebサービス（Twitterなど）のユーザーを狙い、通信内容ではなくレスポンスの時間差からアカウント名を特定する新手の攻撃手法。NTTが2018年4月に「IEEE European Symposium on Security and Privacy 2018」（EuroS&P 2018）で発表した（論文はこちら）。

「Silhouette」はどんな被害をもたらすか

　「Silhouette」はNTTセキュアプラットフォーム研究所のチームによって発見された攻撃手法だ。同チームは攻撃者側の視点からシステムの脆弱（ぜいじゃく）性調査などの研究活動を行っており、これまでに数々の脆弱性を発見し、対策に結び付けてきた。

　「Silhouette」発見はその成果の1つ。まだ現実の被害例はないが、攻撃用にしつらえたWebサイトにアクセスした個人のソーシャルサービスのアカウント名が特定されるリスクがあることが分かっている。

　「アカウント名なんて最初からバレバレでしょ？　流出して何か問題あるの？」と甘く考えてはいけない。例えばアダルトサイトに不正スクリプトを仕込むと、あなたがそのサイトにアクセスした数秒後には、SNSなどのアカウント名が攻撃者側に知られることになる。

　「◯月◯日◯時◯分に××サイトにアクセスしましたね？」とSNSにダイレクトメッセージが届き、「SNSであなたの行動をさらしますよ」「さらされたくなければ暗号通貨を振込みなさい」などと要求するかもしれない。

　また、パスワードリスト攻撃が横行していることでも分かる、すでに漏えいしているID／パスワード情報は多数ある。SNSアカウント名およびそれから推定される個人名などと流出した情報を突き合わせれば、あなたが利用している他のサービスへの不正ログインも不可能ではない。

「Silhouette」の攻撃方法は？

　同研究所の渡邉卓弥氏は「Silhouetteは既知の攻撃手法であるCSRFと、タイミング攻撃として知られるサイドチャネル攻撃の一種を組み合わせた手法」だと説明する。どういうことか、まずはCSRFのほうから説明しよう。

CSRFとは？

　CSRFは「クロスサイトリクエストフォージュリ（Cross-Site Request Forgeries）」の略称だ。この攻撃を行う攻撃者は、まず“わなサイト”を用意してユーザーにアクセスを誘う。誘われたユーザーがそのサイトにアクセスすると、サイトに仕組まれる不正なスクリプトにより、ユーザー自身が気付かないうちにユーザー端末のWebブラウザから攻撃対象であるソーシャルサービスに不正なリクエストを送信する。このとき第三者のサイトにログインしていなければ何も起きない。しかし多くのソーシャルサービスでは一度ログインすればCookieを端末側に保存し、それをセッション保持のために使っている。有効なCookieが保存してあれば、ソーシャルサービスへのアクセスはバックグラウンドでも実行できるので、攻撃者はログイン済みのサービスにユーザーに気付かれないように不正リクエストを送り込むことができるのだ。

　この手口を使うと、攻撃者は攻撃用サイトのスクリプトに仕込んだ処理をソーシャルサービスに行わせることができる。例えば正規会員だけに許された送金、商品購入、退会処理、各種設定の変更、掲示板への書き込みなどの処理である。だが、このような目的のCSRF攻撃は現在ではほとんど成功しない。

　なぜなら、この攻撃手法は新しいものではなく、対策が進んでいるからだ。攻撃にはWebサイトの脆弱性が悪用されるが、少なくとも大手のソーシャルサービスならCSRFが成功しないように脆弱性対策を済ましているはずだ。またWebブラウザ側も不正スクリプトなどによる他のサーバへの通信を制限、保護する対策（Same-Origin Policy）をとっている。そのため攻撃者は上記のような目的を果たすのが難しいのだが、実は攻撃用Webページ上のスクリプトにより、そのページにアクセスしてしまったユーザーのWebブラウザから強制的に特定のソーシャルサービスにリクエストを送ることは可能だ（後述するような対策をとっていない場合）。Webブラウザとソーシャルサービス間の通信内容そのものは攻撃者側が知ることはできないが、不正リクエストを送信してから要求したページが返るまでの時間を計測することができる。これに研究チームが着目した。

図1　CSRF対策により応答内容は保護されるが応答時間は計測可能（資料：NTT）

タイミング攻撃、サイドチャネル攻撃とは？

　セキュリティを破るのに正攻法ではなく、からめ手から攻める攻撃をサイドチャネル攻撃という。例えば暗号解読のために暗号装置の処理時間や、電磁波、熱量などの物理的な特徴を計測してヒントを得ようとする攻撃手法のことだ。処理時間を観測するケースがタイミング攻撃である。

　研究チームは、リクエストをソーシャルWebサービスに送り、そのレスポンスが返ってくるまでの時間を利用した。例えばTwitterの場合なら、仮に鈴木さんが山田さんのプロフィールページを見せてくれとリクエストしたとしよう。Twitter側のサーバはそのリクエストを受け取ったら山田さんのページを用意して鈴木さんに送る。これが普通の処理だ。一方、多くのソーシャルサービスには相手を「ブロック」して自分の情報を閲覧できないようにする機能がある。もし山田さんが鈴木さんをブロックしていた場合には、鈴木さんには空のページが返される。ブロックされていない場合にはページに内容があるので読み込み時間は比較的長くかかり、ブロックされている場合は内容がないのでページ読み込み時間は短い。実際にSNSを提供するTwitterが実施したテストでは、プロフィールページの読み込み時間が約500msから約200msまで低下したそうだ。

　攻撃者側はこの時間差を利用するのだが、その前に攻撃の前準備が要る。まずSNSに入会して、多数の自分のアカウント（シグナルアカウント）を作成しておく。同時に攻撃対象となる特定、または不特定のソーシャルWebサービスユーザーのアカウント名を収集する（ターゲットアカウント）。そして自分のアカウントの1つ1つで、集めたユーザーアカウントをルールのもとにブロックしていく。例えば図1のように、Aliceはブロックなし、BobはS3アカウントのみブロック、CarolはS2アカウントだけでブロック、という具合だ。こうすると、図1のマトリックスが出来上がり、ブロック／非ブロックのパターンと、ターゲットアカウントのひも付けができる。

図2　攻撃の前準備：ターゲットアカウントとブロック／非ブロックのパターンをひも付ける（資料：NTT）　図ではシグナルアカウントを3つのみ例示しているが、これはもっとたくさん用意することができ、ターゲットアカウントは何千、何万件と対象にできる

　この準備ができたら、攻撃を始める。わなサイトに例えばCarolが訪問すると、不正スクリプトによりCarolのブラウザがS1、S2、S3のシグナルアカウントにリクエストを送る。それぞれのシグナルアカウントとの応答時間が計測され、S1、S3では長くかかり、S2では短いということが、攻撃者側に分かる。攻撃者は、S2だけがブロックされているのだから、図1のマトリックスに照らして、わなサイトに訪問したのはCarolだと特定できる。

　なお、ネットワークの状況により応答時間は一定しないが、ごく短い時間で数回リクエストを繰り返せば、シグナルアカウントの応答時間の差の計測には影響しない。

図3　攻撃：不正サイトのスクリプトでターゲットユーザーにシグナルアカウントへのリクエストを強制、応答時間を計測する（資料：NTT）

　研究チームは攻撃の実証テストを著名なSNSやアダルトサイトなどを利用して行ったが、少なくとも12件がこの攻撃に対して脆弱なことがわかったという。

「Silhouette」攻撃への対策は？

　では、この攻撃にどう対策すればよいだろうか。

　ソーシャルWebサービスの提供者の立場では、まずCSRFへの脆弱性をなくす一般的な対策をとることが大事だ。つまりページアクセスをPOSTメソッドにしてhiddenパラメータに秘密情報を含めたセッション管理を行うことや、Refererを確認して正しいページ遷移をしてのリクエストかを判断することなどである。IPAの「安全なウェブサイトの作り方」の参照をお薦めする。

　その上で、ログイン状態を管理するCookieのヘッダに「SameSite」属性を追加すればいい。そうすればサイト間でCookieを送ることを制限できるため、異なるサイトからの不正なリクエスト送信を防ぐのに役立つ。ただしソーシャルWebサービスのHTTPヘッダでSameSiteの利用の宣言が必要であり、Webブラウザ側にはSameSiteへの対応が必要だ。

図4　HTTPのSet-Cookieレスポンスヘッダの構文

　NTTは「Silhouette」の脅威を発見した時から世界のソーシャルWebサービスやWebブラウザベンダーに情報共有を行い、対策実装を呼びかけてきた。Twitterはすでに対策済みであり、他のソーシャルWebサービスは非公表だが対策は広がっているものと思われる。ブラウザの対応状況は表1の通りだ。だいたい問題なく対応可能と思われるが、非対応バージョンを利用している場合はバージョンアップをお薦めする。

表1 SameSite対応ブラウザのバージョン。IE Mobile 10／11、UC Browser for Android 11.8、QQ Browser 1.2は未対応（https://caniuse.com/#feat=same-site-cookie-attributeより引用）（注）リリース当初は未対応、2017年秋のWindows 10 RS3 Creators Update以降で2018年1月のセキュリティアップデート以降のIE 11が対応

　またユーザー側にも注意が必要だ。怪しいサイトには近づかない、不審なURLリンクはクリックしない、という基本的な慎重さをもったうえで、安全性が不明なWebサイトにはブラウザのプライベートブラウジング機能を使ってアクセスし、その時限りのCookie利用にとどめるようにしたい。またソーシャルWebサービス利用後は必ずログアウトする習慣をつけるのもよいだろう。攻撃者に悪用されるログイン状態を必要以上に継続させないことをお薦めする。