こんにちは、技術統括部の手島と申します。
今回は、PCなどのUSBホストに対し、USBホストが利用可能と判断したUSBデバイスクラスを列挙するツール CDI USB MAPPER を開発したので紹介します。
何ができるの？
例えばこんなことができます。
- USBホストが利用可能と判断したUSBデバイスクラスを一覧にできる
- 禁止したはずのUSBデバイスクラスが本当に使えないことを検証できる
- 意図せず有効になっているUSBデバイスクラスを発見できる
以下は、PC側で USBメモリ（Mass Storage）を利用できないよう設定したPCで再確認した例です。
この CDI USB MAPPER は、様々なUSBデバイスのデスクリプタを返すことでUSBホストに対して各種USBデバイスとして振る舞い、その際のUSBホストの応答を観察する仕組みで動いています。
何で CDI USB MAPPER を作ったの？
弊社のお客様や技術者仲間との会話から、USBについて以下のような課題を聞いたことから開発を始めました。
- USBメモリの利用を禁止してみたが、第三者に確認してほしい
- 業務PCへキーボードやマウスのみを許可したが、いろんなUSBデバイスを接続して試すのが大変
- 特定の型番のキーボードだけを接続許可したが、同種・別型番のデバイスが接続できないことを確認したい
今回作成した CDI USB MAPPER を使ってみる前に、まずはUSBデバイスがどのようにPCなどのUSBホストから認識されるのか、ざっと話していきます。
USBデバイスが認識される仕組み
まず、USBデバイスがUSBホストから認識される仕組みに軽く触れます。 PCなどのUSBホストへUSBデバイスが接続された際、USBホストは、接続されたUSBデバイスに関する情報であるUSBデスクリプタ（Descriptor）を取得してUSBデバイスを認識します。
USBポートへUSBデバイスが接続されると、USBホストは Device Descriptor, Configuration Descriptor, String Descriptor 等のデスクリプタをUSBデバイスへ要求して取得します。 その後、USBホストは各デバイスクラス固有のデスクリプタを要求し、USBデバイスとして認識する準備を進めます。 例えばマウスなどのHuman Interface Device(HID) が接続された場合は HID Report Descriptor を要求し、接続されたHIDがどのようなデバイスで、どんなフォーマットでデータをやりとりするのかを認識します。
これらのデスクリプタには、接続されたUSBデバイスの名前、製造事業者名、デバイスのシリアル番号、ミリアンペア単位の要求電流、等が含まれています。 皆さんのPC上でUSBデバイスの名前などが表示される際には、これらのデスクリプタから取得した情報を元にしています。
これ以外にも USB Low|Full|High Speed の認識などが行われますが、USBの規格書は全部で1000ページを軽く超えるため、これ以上の内容は省略します。
どのように特定のUSBデバイスクラスが利用できないと判断するのか？
デスクリプタを取得した後に、PCなどのUSBホストは SET_CONFIGURATION リクエストを USBデバイスに対して送信して、初めて利用可能な状態になります。 これを利用し、USBデバイスが利用できる/できないを判断しているので解説していきます。
以下の図は USB2.0 の規格書、 Universal Serial Bus Specification の 9章から引用したものです。
この図はUSBデバイスが利用できるようになるまでの状態遷移を示しており、このダイアグラムの最下部まで遷移することで利用できるようになります。 まず電源が投入され、バスリセットが行われ、アドレスが設定され、Configuredの状態になって、初めてUSBデバイスが利用できるようになります。 デスクリプタの取得は、Default, Address の状態時、いつでも行えます。（Configured の状態でも行えますが、今回は対象外にしています） USBホストは取得したデスクリプタやシステムのポリシー等を基に利用可否を判断し、USBデバイスに対し SET_CONFIGURATION というリクエストを送信します。
こちらは、USBメモリを接続した際のUSB上の通信を、私がロジック・アナライザで取得した際の記録です。 今回作成した弊社製のデバイスは、このリクエストの有無を判断基準にしています。
USBデバイスが利用できない場合の挙動差はどんな感じ？
CDI USB MAPPER では、デスクリプタ要求後に SET_CONFIGURATION が行われるかどうかの挙動差を、利用可否を判断する基準としています。
一般的には、USBデバイスの認識は可能な限り早く終わらせ、すぐに利用し始めたいものです。 そのため、市販されているマウス、キーボードやUSBメモリは、接続後から SET_CONFIGURATION リクエストに至るまでの間、 USBデバイスからの IN 方向でデスクリプタの取得、USBデバイスへの OUT 方向でCapsLock状態を伝えてキーボードのインジケーターLEDを点灯させるなど、 時間を持て余すことなく様々なリクエストが行われています。 開発中にいろんな USBデバイスの通信を眺めてみたところ、USBデバイス側の処理能力不足でデスクリプタの返送に時間がかかる場合はあるものの、 USB上で通信がぱったり行われなくなるケースは、USBホストが利用可能と判断しなかったUSBデバイスが接続された場合、例えば特別なドライバが必要なのにPCへ未インストールだった計測機器や、あえてOS上で利用できないようにしたデバイスの接続時などでした。 （補足: USBデバイスの処理が追いつかない場合を考慮して、USBホストは一定時間 NAK の返答を許容しながら再試行を続けます。USB 2.0仕様では1つの Control Transfer 全体のタイムアウトは最大500msとされています。）
そのため、USBホストからリクエストがあるたびにタイムアウトまでの時間を新規に数え直し、10秒間以上USBホストからリクエストがされなくなった場合には、このデバイスはUSBホストから利用できないと判断されて放置されているのだろう、と検証マシン側で判断し、記録しています。 この10秒間という数字はUSBの規格で規定されているものではなく、様々なUSBデバイスを調査した結果、最も長い通信停止時間でも1秒以内であったため、安全側に倒して10秒を採用しました。 近年のPCのプロセッサやチップセットは処理能力が高いですが、USBホスト機能をもつ組込機器を対象とした場合、処理能力によっては延長や判断基準の変更を要する可能性のあるパラメータとなります。
ここまで、USBデバイスが認識される仕組みについて解説しました。
USBメモリが使えないことを確認してみよう
ここからは今回作成した CDI USB MAPPER を使ってみた様子を載せています。
CDI USB MAPPER を用いると、対象のUSBホスト側で利用可能と判断されたUSBデバイスクラスを一覧にして確認することができます。 利用するデスクリプタは、テスト用PCに予め様々なUSBデバイスのものをデータベースにしてあります。 これを、Windows PC 上で USBメモリを使えない設定がきちんと動作しているか？という確認に用いてみたので、その様子を紹介します。
今回使用する CDI USB MAPPER の基板はこちらです。 設計は自社で行っています。
今回のテストはこのような構成で実施します。
左側の大きな四角は CDI USB MAPPER 全体を示し、私の作業用PCと CDI USB MAPPER の基板をUSBケーブルで接続した組み合わせです。 右側にターゲット役がいます、今回は Windows PCを用いました。こちらもUSBケーブルで接続します。
作業風景です。自宅の作業机が飼い猫に占拠されたため、段ボールの上で作業しました。
写真下部の銀色のPCはホスト側で、私の作業用PCです。 写真上部の水色のPCはターゲット側で、私が「やられ役」として使用しているPCです。 ターゲットの OS では Windows 11 Home が動作しています。 真ん中に今回のサービスを提供する CDI USB MAPPER の基板が鎮座しています。
ホストPCは、この CDI USB MAPPER を操作してターゲットへデスクリプタを返答させ、様々なUSBデバイスを模倣します。 なりすましたUSBデバイスはターゲット側へ接続され、USBホストが各デバイスを利用しようとした SET_CONFIGURATION リクエストの有無をホストPC側で検証する仕組みになっています。
USBメモリを利用できる Windows PC での結果
こちらは、USBメモリの動作については特に何も変更していない状態の Windows PC の結果です。 今回候補にした全てのUSBデバイスクラスについて、USBホストは利用可能と判断しました。 これはおかしな挙動ではありません。
USBメモリを利用できなくした Windows PC での結果
レジストリエディタで以下のレジストリを変更し、USBメモリ（Mass Storage）を利用しないよう設定して Windows PC を再起動しました。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\USBSTOR
結果はこちらです。
ご覧の通り、Mass Storage について、USBホストが利用可能と判断しなかったという結果になりました。 より詳しい内容に言及すると、ターゲットからデスクリプタを要求されたので返答したものの、USBホストである PC からのリクエストが止まり、 SET_CONFIGURATION が規定時間内に行われなかったため、このUSBデバイスクラスはターゲット側で利用可能と判断されなかった、と記録しています。
他社・既存ツールとの比較
USB のテストツールといえば Facedancer や Cynthion が有名で強力なツールです。 特に Cynthion は FPGA を活用した高速なUSB解析やMITM機能を備えており、この分野では非常に優れたツールです。
一方で CDI USB MAPPER は、USBホストの挙動観察、USBデバイスが行う各種デスクリプタの返答の模倣、この二つに特化して、以下を目標に作成しました。
- 自社でハードウェアからソフトウェアまで全てを開発して外部依存を減らす
- 動作の仕組みや判断基準を全て説明できる状態にする
- テスト内容をカスタマイズできる状態にする
また、 CDI USB MAPPER は USBホストとしても動作でき、USBデバイスに対する調査を行うことも可能です。 通常ではUSBホストが行わないようなリクエストを行い、USBデバイス側のテストに利用しています。 脆弱性には該当しないものの、いくつかUSBデバイスの面白い挙動を見つけたので、改めて記事にしていきます。
おわりに
弊社では、今回のような USBを使用したシステムや組込機器のセキュリティテストもサポートしております。 テスト用の基板設計からテストスクリプトの作成まで、全てを自社で行っているため、テスト内容を全て説明可能なことが強みです。
企業において
- Mass Storage禁止
- CDC禁止
- RNDIS禁止
- MTPのみ許可
などの設定をしたときに、本当にその通り動いているかを機械的に確認でき、人力でUSBメモリやLANアダプタを差し替えるより遥かに効率的です。
USBホストが利用可能と判断するUSBデバイスクラスの調査についての相談は、弊社のお問い合わせフォームからご連絡ください。
※本記事に記載されている製品名、会社名、システム名等は、各社の商標または登録商標です。本記事では ™、® 等の表示を省略しています。