近年個人データの「商品化」が進み、人に関するあらゆる生活関連データの収集・カタログ化・関連付けのスキルがある人にとっては非常に大きなチャンスが到来しています。ここ数年、ユーザ個人の識別とウェブサイト上の動きの追跡方法を探したい広告主と阻止したいブラウザベンダーとの間で闘いが繰り広げられてきました。例えばMozillaはFirefox内でのブラウザー・フィンガープリントへの数々の保護対策を行ってきましたし、EFFの Privacy Badger のアンチトラッキングブラウザプラグインは、FirefoxとChromeから100万回以上インストールされています。
望ましくないオンライントラッキングの阻止のための様々な努力にも関わらず、ネットにつながるガジェットは個人を識別するだけでなく、正確な位置情報まで明らかにしてしまう場合があることが判明しました。この記事では、Google HomeとChromecastデバイス に対するその種の新手の攻撃についてご紹介しようと思います。
これらの問題は、IoTデバイスではよく見られる2つの基本的な設計上の選択に起因しています。
- ローカルネットワーク上への接続時に認証を要求されることは滅多にない。
- 組み込みシステムの設定や制御にHTTPが頻繁に使用される。
これらの特性が重なることで、ウェブブラウザ、さらにはウェブサイトとネットワークデバイスがやり取りすることもあるということです。このことについては私が以前、コード実行を達成するためのクロスサイトリクエストフォージェリ（CSRF）やDNSリバインディングの使用についての記事でも述べました。
Google Castデバイスを分析する
このリサーチは、 ウェブサイトがどのようにローカルネットワーク上のスクリーンやスピーカーを識別して乗っ取るのかを実演するブラックハットトレーニングを実施しようという単純な目標から始まりました。するとすぐに私が教えてきたIoT分析技術が利用できる別のはるかに興味深い攻撃対象範囲に気が付いたのです。
ユーザがGoogle HomeとChromecastを設定できるホームアプリは、ほとんどの操作をGoogleのクラウドを使用して実行しますが、一部のタスクはローカルHTTPサーバを使用することが分かりました。デバイス名やWiFi接続の設定といった操作を行うコマンドは、何の認証もなしでデバイスに直接送信されます。
この機能を使用するGoogleのアプリは、対象デバイスのGoogleアカウントにログインしなければならないとしていますが、実際のところプロトコルレベルに組み込まれた認証メカニズムはありません。私のホームネットワークでは、DNSリバインディングサーバを活用してChromecastの画面をハイジャックできただけでなく、実際にデバイスから抽出したデータを利用して、デバイスの地理的な位置を驚くほど正確に突き止めることができました。
これはHTML5 のロケーションAPIを調べたことがあれば驚くに値しないことです。もしご覧になったことがなければChromeのシークレットモードでGoogleマップを開き、マイロケーションアイコンをクリックし、位置情報のトラッキングを有効にするようにいわれたらそうしてみてください。（シークレットモードを使用するのは、念のためGoogleが携帯電話から取得した位置情報の履歴データを使用できないようにするためです）。GPSレシーバーがなくても、Googleマップは通常10メートル範囲内でデバイスの位置を見つけ出せます。
マジックのトリックのようですが、周囲のWiFiネットワークの信号強度を分析し、さらにGoogleの拡張ロケーションサービスを使用している数百万の携帯電話から収集されたWiFiアクセスポイントマップを使用して位置を三角測量することで可能になります。
不正利用と影響
私は自分が開催しているIoTトレーニングで使っているDNSリバインディングソフトウェアを使用することで、ChromeまたはFirefoxを使用しているLinux、Windows、macOSで有効に動作する簡単なエンドツーエンド攻撃を作ることが出来ました。一般的なURLを手始めとしてまずローカルサブネットを識別し、スキャンを行ってGoogleデバイスを探し、サブドメインIDを登録すると標的に対してDNSリバインディングを開始しました。そしてページが読み込まれてから約1分後、Googleマップ上に私の自宅が表示されていたのです。
これはいろいろと悪用される恐れがあり、例えば脅迫やゆすりの効果を高めるために利用することも可能です。米連邦捜査局（FBI）や米国国税庁（IRS） のなりすまし、また人に見られたくない写真を公開すると脅すあるいは友人や家族に秘密を公開すると脅す際にこの情報を使えば、詐欺の信ぴょう性を高めたり、成功率を高めたりすることができます。しかしDNSのリバインディングが唯一の不正入手手段というわけではありません。
ブラウザの拡張機能とモバイルアプリは、無制限のネットワークアクセスを使用して、DNSキャッシュの更新に頼ることも待つこともなく、デバイスに直接クエリーできます。こうして広告主はエンドユーザに警告を出すことなく位置情報データを得るための直接的なパスを入手できます。位置情報データは、他の追跡されたウェブアクティビティと関連付けられ、おそらく現実世界の特定のアイデンティティーに結びつけることも可能でしょう。
こういった問題はGoogleデバイスだけのものではありません。何年もの間、私は組み込みデバイスを検査してきましたが、WiFi調査データやシリアルナンバーなどの各デバイスに固有の詳細を公開しているデバイスは珍しくありません。例えば、スマートTVは大抵キャストなどの機能をサポートするために使用されるDIALプロトコルの一部として、個別に識別可能なスクリーンIDがあります。
個人情報を護るために
自分自身のデバイスによって追跡されるリスクを完全に無くす唯一の方法は、切断することです。しかし、もしNetflixの最新シリーズのイッキ見を続けて、照明を落とすのにスマートスピーカーを使っているならば、いささか決定打に欠けるものの、極力晒されないようにするために出来ることがあります。
オプション#1 専門家級のネットワークセグメンテーションを行う
私の家には常に別個のネットワークが少なくとも3つあります。1つ目のネットワークはメインのホームネットワークとしてファイルの転送や一般的なウェブブラウジングに使用しており、それとは別にデバイス接続用ネットワークがあり、さらにセキュリティ監査のため時折デバイスを設定するため専用の「ワイルドウェスト」ネットワークがあります。このようにすることで、私がメインのネットワーク上でネットサーフィンしていても、不正なウェブサイトやアプリは、私のデバイスを見つけたり接続したりすることができません。Chromecastを使用するときは、ネットワークを一時的に切り替えるか、あまり使い勝手のよくない「ゲストモード」にする必要があります。
オプション#2 より簡易なネットワークセグメンテーション
過去10年間をネットワークセキュリティ製品の開発に費やしてきた私にとってVLANとファイアウォールのルールは有用ですが、ほとんどのユーザには向いていません。比較的簡単にこれを可能にする消費者向けルータもいくつかありますが、意図したとおりに動作するよう設定したり、検証したりするのは、必ずしも容易ではありません。はるかに簡単な解決策は、コネクテッドデバイス専用のネットワーク上に別のルータを追加することです。新しいルータのWANポートを既存のルータの空いてるLANポートに接続することにより、メインネットワーク上で実行している攻撃者コードは、接続されたデバイスを悪用するパスがみつけられません。これはデフォルトでIoTデバイスからメインネットワークへの攻撃を防止するものではありませんが、ほとんどの他愛ない攻撃は、攻撃対象となる別のネットワークがあることを認識することさえできません。
オプション#3 DNSリバインド保護
DNSリバインディング攻撃は、一般的に使用されているネームサーバの脆弱なデフォルト構成に乗じて行われます。DNSサーバはリバインディング攻撃を阻止するように設定できますが、大抵の場合、正当な動作に干渉する可能性があるためそのような保護を有効にしていないのです。しかし、コンシューマルータで一般的に使用されているDNSソフトウェアは実際にDNSリバインド保護機能を備えているということです。たとえほとんどのルータがデフォルトでは有効にしていない場合でも、手動で有効にできるオプションがあります。 OpenWRTとDD-WRT のユーザはこの保護を有効にすることが可能であり、そうするべきです。上級ユーザーなら、リバインディング保護を有効にして、独自のローカルDNSサーバ（Raspberry Piなど）の展開も検討できます。
まとめ
長年にわたって、デバイスメーカーは抵抗の少ないユーザエクスペリエンスに大きな焦点を当ててきましたが、その結果悪用されやすくなってしまいました。DNSのリバインディングやモバイルアプリがあるとはいえ、ローカルネットワーク上（特にHTTPサービス）で実行されているすべてのサービスは、インターネットに直接晒されるような設計になってしまいます。ローカルネットワーク上にある認証情報無しでアクセス可能なデータは、悪意のある敵にもアクセス可能であると想定しなければなりません。つまり、本来はすべての要求は認証を必要とするようにし、認証されていない応答は可能な限り一般的なものに留める必要があります。
しかしそれが実現されるまでは消費者は可能な限りデバイスを分離し、接続されているガジェットと同じネットワーク上にあるときには、どのウェブサイトやアプリが読み込まれているか気をつけていなくてはなりません。
