francozappa/blurBLURtooth: Bluetooth ClassicおよびBluetooth Low Energyにおけるクロストランスポートキー導出の悪用 [CVE-2020-15802] [CVE-2022-20361]
AsiaCCS'22で発表されたBLUR攻撃に関するリポジトリです。論文タイトル: BLURtooth: Bluetooth ClassicおよびBluetooth Low Energyにおけるクロストランスポート鍵導出の悪用
便利なリンク: pdf, video, slides, website.
BibTexエントリ:
@inproceedings{antonioli22blur,
author={Antonioli, Daniele and Tippenhauer, Nils Ole and Rasmussen, Kasper
and Payer, Mathias},
title={{BLURtooth: Exploiting Cross-Transport Key Derivation in
Bluetooth Classic and Bluetooth Low Energy}},
booktitle={Proceedings of the Asia conference on computer and
communications security (ASIACCS)},
month={May},
year={2022}
}
BLUR攻撃には CVE-2020-15802 と CVE-2022-20361 が割り当てられています。
このREADMEの残りの部分では、Bluetooth Classic (別名 BR/EDR) を BT、Bluetooth Low Energy を BLE、Cross-Transport Key Derivation を CTKD と表記します。また、攻撃デバイスと被害者はBT、BLE、CTKDをサポートしていると仮定します。これは、デバイスがBluetooth 4.2+とBT/BLE Secure Connectionsをサポートしていることを意味します。
攻撃を実行する最も簡単な方法は、1台のデバイスを被害者と攻撃デバイスの両方として使用することです。例えば、LinuxノートPCを被害者/攻撃デバイスとして使用し、他の任意のデバイスをもう一方の被害者として使用することをお勧めします。
私たちはbluezとbluez toolsを実行しているLinuxマシンを使用しています。btmgmtツールに依存しており、そのソースコードをざっと読むと役立つかもしれません。特に、pairサブコマンドを使用します。これは、任意の入出力機能を宣言しながら、BT/BLE経由で任意のペアリング要求を送信できるようにするものです。
Usage: pair [-c cap] [-t type] <remote address>
論文で提示された正確な攻撃シナリオを再現したい場合は、追加の作業が必要です。具体的には、BIAS攻撃で提示されたセットアップを再現する必要があります。セットアップが完了したら、開発ボードをBT/BLEコントローラとして、LinuxノートPCをホストとして使用できるようになります。さらに、ホストからのリンク層パケット（例：BT LMPトラフィック）を傍受し、internalblueを使用して開発ボードのファームウェアを実行時に動的にパッチできるようになります。
この手順はオプションであり、独自のLinuxカーネルにパッチを当てる必要があります。
btmgmt -c 3を使用すると、bluezは自動的にMitM保護フラグを解除します。例えば、AuthReqバイトを0x03ではなく0x02に設定します。しかし、BLUR攻撃ではこのフラグを解除する必要はなく、リモートデバイスが入出力機能をサポートしている場合にNoInputNoOutput機能を宣言するだけで済みます。このトリックにより、MitMフラグを解除せずにペアリング手順がJust Worksにダウングレードされます。
このセットアップを実装するには、Linuxカーネルを最小限に変更する必要があります。具体的には、/net/bluetooth/hci_event.cで以下のように変更します:
cp.authentication = conn->auth_type;
to:
cp.authentication = 0x03;
これにより、宣言する入出力機能に関係なく、AuthReqフラグを0x03にハードコードします。
通常通り被害者デバイスをペアリングします。例えば、スマートフォンを標的にする場合は、ラップトップ（被害者と攻撃デバイスの両方として機能）とペアリングします。ペアリングの一部として、ユーザー操作が必要になる場合があります（例：Numeric Comparison）。
REMOTE-BTADDと表記）をメモしますhciconfigを実行し、hciインデックス（例：0）をメモしますsudo btmgmt -i 0を実行します[hci0] #を含む青色のターミナルプロンプトが表示されるはずですここでは、被害者がパブリックBLEアドレスを使用していると仮定しています。ランダムアドレスを使用している場合は、-tオプションを2に変更してください。
btmgmt CLIから以下を実行:
pair -t 1 REMOTE-BTADD
アソシエーションをJust Worksにダウングレードする必要がある場合は、以下を実行:
pair -c 3 -t 1 REMOTE-BTADD
-cフラグは攻撃者の入出力機能を設定し、値0x3はNoInputNoOutputに対応します。一方、ラップトップ/スマートフォンのデフォルト値は0x1でDisplay Yes/Noに対応します。
この場合、BLEペリフェラルをなりすましても、セントラルとしてBT経由でペアリングします。
btmgmt CLIから以下を実行:
pair -t 0 REMOTE-BTADD
アソシエーションをJust Worksにダウングレードする必要がある場合は、以下を実行:
pair -c 3 -t 0 REMOTE-BTADD
被害者にとって現在未知の（つまり、ペアリングされていない）デバイスをなりすましながら、上記の攻撃を繰り返します。
bluetoothctl CLIからは、discoverableをonまたはoffに設定し、pairableを設定できます。btmgmt CLIからは、connectableフラグも設定できます。
bluetoothctlでは、discoverable-timeoutを使用して発見可能タイムアウトを制御できます。例えば、0に設定するとデバイスは常に発見可能になります。
BTの場合、セントラルまたはペリフェラルとしてリモートデバイスとペアリング中に、次のLMPパケットを受信します: LMP not accepted ext (opcode: 0x02) with pairing not allowed (error code: 0x18)
BLEの場合、セントラルまたはペリフェラルとしてリモートデバイスとペアリング中に、次のSMPパケットを受信します: SMP Pairing Failed Command (opcode 0x05) with Pairing Not Supported (reason 0x05)。
BTの場合、リモートデバイスとペアリング中に、LMPフィーチャーパッケージ内のホストとコントローラのSecure Connectionsサポートを確認します。例: 次のWireshark表示フィルタを使用: btbrlmp.efeat.scc or btbrlmp.efeat.sch。
BLEの場合、リモートデバイスとペアリング中に、SMP Pairing RequestまたはResponse内のSecure Connectionフラグを含むAuthReqバイトを確認します。例: 次のWireshark表示フィルタを使用: btsmp.sc_flag == 1。
BTの場合、リモートデバイスとペアリング中に、BLE SMPトラフィックはL2CAP上でトンネリングされます。したがって、btl2cap.payload Wiresharkフィルタを使用すると、ペイロードが0x01で始まる（SMP Pairing Request）セントラルからペリフェラルへの1つのパケットと、ペイロードが0x02で始まる（SMP Pairing Response）逆方向の別のパケットが表示されるはずです。さらに、SMP鍵配布フェーズをエンコードする他の生のL2CAPパケットも表示されるはずです。
BLEの場合、リモートデバイスとペアリング中に、SMP Pairing RequestまたはResponseで、セントラルとペリフェラルの両方がSMP鍵配布中にリンクキーを送受信する意思があるかどうかを確認します。例: 次のWiresharkフィルタを使用: btsmp.key_dist_linkkey or btsmp.key_dist_linkkey。