Android、Linux、macOS、iOSのBluetoothキー入力注入の脆弱性

 (github.com/skysafe)
2 ポイント 投稿者 GN⁺ 2023-12-17 | 1件のコメント | WhatsAppで共有
  • CVE-2023-45866は、複数のOSのBluetoothスタックにおいて、ユーザー確認なしに偽のキーボードを接続し、キー入力を注入できる認証バイパス脆弱性
  • 近くにいる攻撃者は、特殊な機器なしにLinuxコンピューターと一般的なBluetoothアダプターだけで、アプリのインストール、任意コマンドの実行、メッセージ送信といった操作を試みられる
  • 脆弱となる条件はプラットフォームごとに異なり、AndroidではBluetoothが有効かどうかが鍵で、Linux/BlueZではdiscoverable/connectable状態、iOSとmacOSではMagic Keyboardのペアリング有無が影響する
  • Android 11〜14は2023-12-05セキュリティパッチレベルで緩和されるが、Android 4.2.2〜10には修正がなく、BlueZでは2020年の修正がデフォルトで無効化されていた
  • パスワードや生体認証が必要な操作はキー入力注入だけでは実行できないが、未パッチのデバイスは近距離Bluetooth攻撃にさらされる可能性がある

認証なしのBluetoothキー入力注入

  • CVE-2023-45866は、Android、Linux、macOS、iOSで認証なしのBluetoothキーストロークインジェクションを許す脆弱性
  • 複数のBluetoothスタックで、攻撃者がユーザー確認なしにdiscoverable hostへ接続し、キー入力を注入できる認証バイパスが可能
  • 近くにいる攻撃者は、脆弱なデバイスに未認証のBluetooth接続を確立し、次の操作をキー入力として実行できる
    • アプリのインストール
    • 任意コマンドの実行
    • メッセージ送信
  • 攻撃に特殊なハードウェアは不要で、Linuxコンピューターと一般的なBluetoothアダプターで実行可能
  • エクスプロイトの詳細全体とPoCスクリプトは、ShmooConの週である1月12〜14日に公開予定

プラットフォーム別の攻撃条件

  • 脆弱性は、Bluetoothホストのステートマシンを欺き、ユーザー確認なしに偽のキーボードとペアリングさせる仕組みで動作する
  • 基盤となる認証なしのペアリングメカニズムはBluetooth仕様に存在し、実装ごとのバグがこれを攻撃面として露出させている
  • 未パッチのデバイスで必要となる条件はOSごとに異なる
    • Android: Bluetoothが有効なら脆弱
    • Linux/BlueZ: Bluetoothがdiscoverable/connectable状態である必要がある
    • iOSおよびmacOS: Bluetoothが有効で、Magic Keyboardがスマートフォンまたはコンピューターにペアリングされている場合に脆弱
  • 攻撃者が対象のスマートフォンやコンピューターとペアリングした後は、被害者の権限でキー入力を注入できる
  • パスワードや生体認証が必要な操作は、キー入力注入だけでは実行できない

MouseJack以後に明らかになった古い脆弱性

  • 2016年に公開されたMouseJack研究は、Bluetoothではなく周辺機器のカスタム無線プロトコルを対象にしていた
  • 今回の研究は、Apple Magic Keyboardを対象にBluetoothとApple環境を調査する過程で始まった
  • macOSとiOSでは、認証なしのBluetoothキーストロークインジェクションが見つかり、両プラットフォームともLockdown Modeでも悪用可能だった
  • その後LinuxとAndroidでも類似の脆弱性が確認され、単なる実装バグというよりプロトコルの欠陥に近いように見え、Bluetooth HID仕様を確認した結果、その両方に当てはまるものだった
  • 一部の脆弱性はMouseJackより古く、Android 4.2.2までキーストロークインジェクションを再現できた

Androidへの影響とパッチ状況

  • テストで脆弱と確認されたAndroidデバイスとバージョンは以下の通り
    • Pixel 7, Android 14
    • Pixel 6, Android 13
    • Pixel 4a (5G), Android 13
    • Pixel 2, Android 11
    • Pixel 2, Android 10
    • Nexus 5, Android 6.0.1
    • BLU DASH 3.5, Android 4.2.2
  • 2023-12-05セキュリティパッチレベルはAndroid 11〜14の脆弱性を緩和する
  • Android 4.2.2〜10には利用可能な修正がない
  • 公開スケジュールは以下の通り
    • 2023-08-05: Googleに脆弱性を報告
    • 2023-12-06: 公開
  • Googleは、Android 11〜14に影響する問題の修正が影響を受けるOEMに提供され、現在サポートされているすべてのPixelデバイスが12月のOTAアップデートで修正を受けると述べている

Linux/BlueZへの影響とパッチ

  • テストで脆弱と確認されたUbuntuバージョンは18.04、20.04、22.04、23.10
  • GoogleによるとChromeOSは脆弱ではなく、直接テストはしていないがBlueZ設定が脆弱性を緩和しているように見える
  • Linuxの脆弱性は2020年にCVE-2020-0556として修正されたが、その修正はデフォルトでは無効化されていた
  • ChromeOSは、この修正を有効化していることが知られている唯一のLinuxベースOS
  • CVE-2023-45866に対するBlueZパッチは、2020年の修正をデフォルトで有効化する
  • 関連するBlueZパッチ:
  • Ubuntu関連情報:
  • Debian関連情報:
  • Fedora関連情報:
  • 公開スケジュールは以下の通り
    • 2023-08-10: Canonicalに脆弱性を報告
    • 2023-09-25: Bluetooth SIGに脆弱性を報告
    • 2023-10-02: CERT/CCにケースを開設
    • 2023-12-06: 公開

macOSとiOSへの影響

  • macOSでテストされ、脆弱と確認されたデバイスは以下の通り
    • 2022 MacBook Pro, macOS 13.3.3, M2
    • 2017 MacBook Air, macOS 12.6.7, Intel
  • macOSのLockdown Modeは攻撃を防げない
  • macOS Sonoma 14.2は脆弱性を修正する
  • macOSの公開スケジュールは以下の通り
    • 2023-08-01: Appleに脆弱性を報告
    • 2023-12-06: 公開
  • iOSでテストされ、脆弱と確認されたデバイスはiOS 16.6を実行するiPhone SE
  • iOSのLockdown Modeも攻撃を防げない
  • iOSの公開スケジュールは以下の通り
    • 2023-08-04: Appleに脆弱性を報告
    • 2023-12-06: 公開

関連記事

1件のコメント

 
GN⁺ 2023-12-17
Hacker Newsのコメント

  • これを確認するために少し調べる必要がありましたが、安全に過ごすには、Androidでは使わないときにBluetoothをオフにしておくことをお勧めします。ただし、使っている間は脆弱です
    私のPixelは2023-12-05のセキュリティアップデートを受け取り、この問題は修正されましたが、Pixel以外の端末についてはよく分かりません
    Linuxでは、/etc/bluetooth/input.confを開いてClassicBondedOnly=trueに設定すればよいです。私の場合は新しく追加する必要はなく、コメントアウトを解除するだけで済みました。次のbluetoothdバージョンではデフォルト値がtrueになる予定ですが、今すぐ自分で設定でき、その後Bluetoothサービスを再起動する必要があります
    macOSやiOSは該当する端末を持っていないので分かりません

    • iOSのアップデート後にはBluetoothがいつも再びオンになるのがずっと嫌でした。実際には使ってもいないのに、なぜそうなるのか長い間不思議でした
      Wi-Fiもコントロールセンターから完全にはオフにできない、穴だらけのチーズのような状態です
    • Fedora 38のbluez v5.70-4では、12月7日からデフォルト値がtrueのようです
      $ rpm -q --changelog bluez | grep CVE-2023-45866 -C1
      * Thu Dec 07 2023 Peter Robinson - 5.70-4
      - Add mitigation for CVE-2023-45866
    • iOSはBluetoothをオフにするのがあまりに面倒で残念です。Androidならスワイプしてクリックで済むのに、iOSではスワイプ、長押し2回、クリック2回が必要です
      Androidから乗り換えた後しばらくは頑張りましたが、結局諦めました
    • 該当ページを見ると、パスワードや生体認証が不要なものにだけ動作すると書かれています
      スマートフォンを使わないときは積極的にロックし、使っている最中にキー入力が送信されれば画面で見えるはずなので、Bluetoothをオンにしておくことがそこまでひどいことには見えません
    • GrapheneOSがsunfish(4a)ブランチでこれを修正したか確認する方法があるのか気になります。Pixel 4aなのでAndroid 13に縛られており、車のドアを開けるにはBluetoothが必要です
      GrapheneOSで修正されているなら、ついに移行するきっかけになるのですが、今のスマートフォンが問題なく動いているので、新しいスマートフォンを買う正当化が難しいです

  • Windowsがまったく言及されていないのが気になります。表面的には良いニュースに聞こえますが、なぜWindowsが実際に影響を受けないのかを知らないとリスクを判断できません
    例えばWindowsのBluetoothスタックにBlueZのClassicBondedOnly=falseに相当する構造があるのか分かれば、強化したい環境でその値がtrueかどうか注視すべきだ、といった判断ができます
    あるいはスタックがまったく異なる動作をしていて、考慮すべき点もまったく違うかもしれません
    PoCとデモが多い動画に期待していますが、Windowsはシェアも高く、戸惑うシステム管理者も多いでしょうから、情報があると助かります。「まだWindowsは攻撃していない」というのも有用な情報です

    • この特定の攻撃については、Windowsは脆弱ではないのかもしれません
      ただし、Flipper ZeroでBluetoothデバイスを作ると、Windowsクライアントが接続した瞬間にキーボードとして認識し、任意のPowerShellコマンドを実行させることができます。自分ではYouTubeを開いてRickRollするのにしか使ったことがなく、違法なことは試していません
      今ではすべてのBluetoothをオフにしていますが、Linuxを壊さずにbluezを削除する方法は分かりません
    • WindowsではBluetoothが普段からまともに動作することがまれなので、そのせいかもしれません
    • WindowsのBluetoothスタックがBlueZのClassicBondedOnly=falseに相当すると言っていましたが、もしかして**ClassicBondedOnly=true**のことですか？
    • まだWindowsではこれを試していないからだと思います

  • 業界がスマートフォンから物理オーディオ接続をなくし、無線へ押し進めた今、こういうニュースが出てきて本当に良かったです。よくやりました

    • USB-C DACは安く、広く入手できます
    • この脆弱性は、接続された無線キーボードとマウスにキー入力を注入する問題です。[1] スマートフォン業界がUSB-Cを採用したことで、有線接続はこれまで以上に簡単になりました
      [1] https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/pr...

  • この脆弱性は、Bluetoothホストのステートマシンをだまして、ユーザー確認なしに偽のキーボードとペアリングさせる仕組みで動作します。基盤となる認証なしペアリングのメカニズムはBluetooth仕様で定義されており、実装ごとのバグがこれを攻撃者に露出させます
    ところで、なぜ黙ってペアリングできるようにしたかったのでしょうか。問題になったメカニズムの本来の目的をもっと詳しく知りたいです

    • Bluetooth仕様上は、さまざまな非コンピューター機器のためです。例えば最初のコントローラーをPlayStationにペアリングするとき、USBマウスを挿して「ペアリングを許可」をクリックしなくても済むようにする用途です
      実際に影響を受けた機器でなぜそうしていたのかは分かりません
    • より無邪気だった時代の古い設計にすぎません。最新仕様では許可されていませんが、互換性を最大化しようとしてBluetoothスタック側が新しい動作をオフにした状態でした

  • この問題はmacOS 14.2とiOS 17.2で修正されました
    https://support.apple.com/en-us/HT214036
    https://support.apple.com/en-us/HT214035

  • Arch Linuxではbluez 5.70-2から修正されています [1]
    [1]: https://gitlab.archlinux.org/archlinux/packaging/packages/bl...

  • 「当時は Bluetooth が intimidating で、ただ安全だと仮定していた」というくだりが刺さる。複雑な技術スタックの上のほうのどこかにはちゃんと分かっている人たちがいて、砂上の城を棒で支えているわけではないはず、という神話は、そうした威圧感から生まれるように思う

  • 携帯電話やコンピューターを相手に実用的かは疑わしいが、キオスク端末を誰にもいじられないよう管理しなければならない立場なら、日々が少し面白くなったと言える

    • 10年ほど前、パスワードなしの VNC が開いた Linux マシンを誤ってインターネットに公開してしまったことがある。数分で誰かが接続し、自動キー入力で何かを実行しようとしたが、明らかに Windows を狙った挙動だった
      バックドアを1つでもうまく仕込めれば、その後は作業できる
      標的型攻撃なら、画面ロックがかからないよう1分ごとに Shift キー入力を送り、後で自分でその機械の前に行って何かをするだけでも十分かもしれない
    • コンピューターでは、毒入りの sudo や su をどこかに隠して $PATH に追加することも可能そうに見える

  • USB も似ている。「充電専用」ポートにキーボードをつなぐと動作する。Android で実際に試したところ、ここでは実質的に悪用可能ではないとたしなめられた

    • Android のポートを充電だけに使うのか？ HDMI にも非常に便利だし、周辺機器にも使える
      それでもこれは脆弱性とは見なさない。単に便利な機能だ。ここでの問題は、誰かがユーザーに気づかれないまま、機密性の高い作業中でもこれを実行できることだ
      昨日投稿された素晴らしいプロジェクト https://mitxela.com/projects/smsc も、この方法で携帯電話から使えた
    • 物理的に「充電専用」ポートを備えた Android デバイスが何なのか気になる

  • Linux の脆弱性は2020年に修正されたが（CVE-2020-0556）、その修正はデフォルトでは無効のまま残っていた。ChromeOS だけがその修正を有効にしたとされており、Ubuntu、Debian、Fedora、Gentoo、Arch、Alpine が告知していたにもかかわらずそうだった

    • NixOS に入っているか確認するのに30秒で十分だった[1]。さらに30秒かけて見たところ、記事が出た翌日の 2023-12-08 08:23 GMT+13 にパッチされていた
      ただ、ディストリビューションの告知で単にアップグレードすれば直ると書かれているなら[2]、「修正がデフォルトでオフだった」とはどういう意味なのか分からない。アップグレード後も手動で設定変更が必要という意味なのか？ NixOS の修正はデフォルト値を反転させるものに見える
      明示的に ClassicBondedOnly=false を設定していたユーザーは変更する必要がある、という意味なら、もっとずっと明確に書けたはずだ
      [1] https://github.com/NixOS/nixpkgs/blob/3dda6d5ed56af34534dd4c...
      [2] https://ubuntu.com/security/notices/USN-4311-1