Kerentanan injeksi input Bluetooth pada Android, Linux, macOS, dan iOS

 (github.com/skysafe)
2 poin oleh GN⁺ 2023-12-17 | 1 komentar | Bagikan ke WhatsApp
  • CVE-2023-45866 adalah kerentanan bypass autentikasi pada stack Bluetooth di beberapa sistem operasi yang memungkinkan penyambungan keyboard palsu dan penyuntikan input tombol tanpa konfirmasi pengguna
  • Penyerang di dekat target dapat mencoba tindakan seperti memasang aplikasi, menjalankan perintah arbitrer, dan mengirim pesan hanya dengan komputer Linux dan adaptor Bluetooth biasa, tanpa perangkat khusus
  • Syarat kerentanannya berbeda di tiap platform: pada Android faktor utamanya adalah apakah Bluetooth aktif, pada Linux/BlueZ adalah status discoverable/connectable, sedangkan pada iOS dan macOS dipengaruhi oleh apakah Magic Keyboard dipasangkan
  • Android 11-14 dimitigasi oleh security patch level 2023-12-05, tetapi Android 4.2.2-10 tidak memiliki perbaikan, dan pada BlueZ perbaikan tahun 2020 dinonaktifkan secara default
  • Tindakan yang memerlukan kata sandi atau autentikasi biometrik tidak bisa diselesaikan hanya dengan injeksi input tombol, tetapi perangkat yang belum ditambal tetap dapat terekspos pada serangan Bluetooth jarak dekat

Injeksi input Bluetooth tanpa autentikasi

  • CVE-2023-45866 adalah kerentanan yang memungkinkan injeksi keystroke Bluetooth tanpa autentikasi pada Android, Linux, macOS, dan iOS
  • Pada beberapa stack Bluetooth, dimungkinkan bypass autentikasi yang memungkinkan penyerang terhubung ke host yang discoverable dan menyuntikkan input tombol tanpa konfirmasi pengguna
  • Penyerang di dekat target dapat membuat koneksi Bluetooth yang tidak diautentikasi ke perangkat rentan dan melakukan tindakan berikut melalui input tombol
    • memasang aplikasi
    • menjalankan perintah arbitrer
    • mengirim pesan
  • Serangan ini tidak memerlukan perangkat keras khusus dan dapat dilakukan dengan komputer Linux serta adaptor Bluetooth biasa
  • Detail eksploit lengkap dan skrip PoC dijadwalkan akan dipublikasikan pada 12-14 Januari selama pekan ShmooCon

Kondisi serangan per platform

  • Kerentanan ini bekerja dengan menipu state machine host Bluetooth agar melakukan pairing dengan keyboard palsu tanpa konfirmasi pengguna
  • Mekanisme pairing tanpa autentikasi yang mendasarinya ada di spesifikasi Bluetooth, dan bug implementasi mengeksposnya sebagai permukaan serangan
  • Kondisi yang diperlukan pada perangkat yang belum ditambal berbeda menurut sistem operasi
    • Android: rentan jika Bluetooth aktif
    • Linux/BlueZ: Bluetooth harus dalam status discoverable/connectable
    • iOS dan macOS: rentan jika Bluetooth aktif dan Magic Keyboard dipasangkan ke ponsel atau komputer
  • Setelah penyerang berhasil melakukan pairing dengan ponsel atau komputer target, mereka dapat menyuntikkan input tombol dengan hak akses korban
  • Tindakan yang memerlukan kata sandi atau autentikasi biometrik tidak dapat dilakukan hanya dengan injeksi input tombol

Kerentanan lama yang terungkap setelah MouseJack

  • Riset MouseJack yang dipublikasikan pada 2016 menargetkan protokol nirkabel kustom periferal, bukan Bluetooth
  • Riset kali ini bermula saat menelaah Bluetooth dan ekosistem Apple dengan fokus pada Apple Magic Keyboard
  • Pada macOS dan iOS ditemukan injeksi keystroke Bluetooth tanpa autentikasi, dan keduanya dapat dieksploitasi bahkan dalam Lockdown Mode
  • Setelah itu ditemukan kerentanan serupa pada Linux dan Android, sehingga masalah ini tampak lebih dekat ke cacat protokol daripada sekadar bug implementasi, dan hasil pengecekan spesifikasi Bluetooth HID menunjukkan bahwa keduanya memang berperan
  • Beberapa kerentanan ini lebih tua daripada MouseJack, dan injeksi keystroke dapat direproduksi hingga Android 4.2.2

Dampak pada Android dan status patch

  • Perangkat dan versi Android yang dikonfirmasi rentan dalam pengujian adalah sebagai berikut
    • 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
  • Security patch level 2023-12-05 memitigasi kerentanan pada Android 11-14
  • Android 4.2.2-10 tidak memiliki perbaikan yang tersedia
  • Jadwal pengungkapan adalah sebagai berikut
    • 2023-08-05: kerentanan dilaporkan ke Google
    • 2023-12-06: dipublikasikan
  • Google menyatakan bahwa perbaikan untuk masalah yang memengaruhi Android 11-14 telah diberikan kepada OEM yang terdampak, dan semua perangkat Pixel yang saat ini masih didukung akan menerima perbaikan melalui pembaruan OTA bulan Desember

Dampak pada Linux/BlueZ dan patch

  • Versi Ubuntu yang dikonfirmasi rentan dalam pengujian adalah 18.04, 20.04, 22.04, 23.10
  • Menurut Google, ChromeOS tidak rentan, dan meskipun tidak diuji secara langsung, konfigurasi BlueZ tampaknya memitigasi kerentanan ini
  • Kerentanan Linux telah diperbaiki pada 2020 sebagai CVE-2020-0556, tetapi perbaikan tersebut dinonaktifkan secara default
  • ChromeOS dikenal sebagai satu-satunya OS berbasis Linux yang mengaktifkan perbaikan ini
  • Patch BlueZ untuk CVE-2023-45866 mengaktifkan perbaikan tahun 2020 tersebut secara default
  • Patch BlueZ terkait:
  • Informasi terkait Ubuntu:
  • Informasi terkait Debian:
  • Informasi terkait Fedora:
  • Jadwal pengungkapan adalah sebagai berikut
    • 2023-08-10: kerentanan dilaporkan ke Canonical
    • 2023-09-25: kerentanan dilaporkan ke Bluetooth SIG
    • 2023-10-02: kasus dibuka di CERT/CC
    • 2023-12-06: dipublikasikan

Dampak pada macOS dan iOS

  • Perangkat yang diuji pada macOS dan dikonfirmasi rentan adalah sebagai berikut
    • 2022 MacBook Pro, macOS 13.3.3, M2
    • 2017 MacBook Air, macOS 12.6.7, Intel
  • Lockdown Mode pada macOS tidak dapat menghentikan serangan
  • macOS Sonoma 14.2 memperbaiki kerentanan ini
  • Jadwal pengungkapan macOS adalah sebagai berikut
    • 2023-08-01: kerentanan dilaporkan ke Apple
    • 2023-12-06: dipublikasikan
  • Perangkat yang diuji pada iOS dan dikonfirmasi rentan adalah iPhone SE yang menjalankan iOS 16.6
  • Lockdown Mode pada iOS juga tidak dapat menghentikan serangan
  • Jadwal pengungkapan iOS adalah sebagai berikut
    • 2023-08-04: kerentanan dilaporkan ke Apple
    • 2023-12-06: dipublikasikan

Bacaan terkait

1 komentar

 
GN⁺ 2023-12-17
Pendapat di Hacker News

  • Saya sempat mencari-cari untuk memastikan ini, dan agar tetap aman, di Android sebaiknya matikan Bluetooth saat tidak digunakan. Namun, saat sedang digunakan tetap rentan
    Pixel saya sudah menerima pembaruan keamanan 2023-12-05 dan masalah ini sudah diperbaiki, tetapi saya tidak begitu tahu untuk perangkat non-Pixel
    Di Linux, buka /etc/bluetooth/input.conf lalu setel ClassicBondedOnly=true. Dalam kasus saya, tidak perlu menambahkan baris baru, cukup menghapus tanda komentar. Pada versi bluetoothd berikutnya nilai default akan menjadi true, tetapi sekarang Anda bisa menyetelnya sendiri, lalu setelah itu harus memulai ulang layanan Bluetooth
    Untuk macOS atau iOS saya tidak tahu karena tidak punya perangkatnya

    • Saya selalu tidak suka Bluetooth selalu menyala lagi setelah pembaruan iOS. Sudah lama saya heran kenapa begitu, padahal sebenarnya tidak saya pakai
      Wi-Fi juga seperti keju berlubang karena tidak bisa dimatikan sepenuhnya dari Control Center
    • Di bluez v5.70-4 pada Fedora 38, tampaknya nilai default sudah true sejak 7 Desember
      $ rpm -q --changelog bluez | grep CVE-2023-45866 -C1
      * Thu Dec 07 2023 Peter Robinson - 5.70-4
      - Add mitigation for CVE-2023-45866
    • Sayang sekali mematikan Bluetooth di iOS terlalu merepotkan. Di Android cukup swipe lalu klik, sedangkan di iOS perlu swipe, tekan lama dua kali, lalu klik dua kali
      Setelah pindah dari Android, saya sempat berusaha beberapa waktu, tetapi akhirnya menyerah
    • Kalau melihat halaman tersebut, tertulis bahwa ini hanya bekerja pada hal-hal yang tidak memerlukan kata sandi atau autentikasi biometrik
      Saat tidak memakai ponsel, kunci saja secara aktif; dan kalau input tombol dikirim saat sedang dipakai, itu akan terlihat di layar, jadi menyalakan Bluetooth tidak tampak seburuk itu
    • Saya penasaran apakah ada cara untuk memastikan GrapheneOS sudah memperbaiki ini di branch sunfish(4a). Karena Pixel 4a, saya terjebak di Android 13, dan untuk membuka pintu mobil saya perlu Bluetooth
      Kalau GrapheneOS sudah memperbaikinya, akhirnya itu bisa jadi alasan untuk pindah, tetapi ponsel saya sekarang masih berfungsi dengan baik sehingga sulit membenarkan pembelian ponsel baru

  • Saya penasaran kenapa Windows sama sekali tidak disebut. Di permukaan terdengar seperti kabar baik, tetapi untuk menilai risikonya, kita perlu tahu kenapa Windows memang tidak terdampak
    Misalnya, jika tahu apakah stack Bluetooth Windows punya struktur yang setara dengan ClassicBondedOnly=false di BlueZ, di lingkungan yang ingin diperkeras kita bisa menilai bahwa nilai itu perlu dipantau apakah true
    Atau mungkin stack-nya bekerja sama sekali berbeda sehingga hal-hal yang perlu dipertimbangkan juga benar-benar berbeda
    Saya menantikan video dengan banyak PoC dan demo, tetapi Windows punya pangsa pasar besar dan banyak admin sistem yang bisa panik, jadi akan bagus kalau ada informasi. “Windows belum kami coba serang” juga informasi yang berguna

    • Windows mungkin tidak rentan terhadap serangan khusus ini
      Namun jika membuat perangkat Bluetooth dengan Flipper Zero, begitu klien Windows tersambung, perangkat itu dikenali sebagai keyboard dan bisa membuatnya menjalankan perintah PowerShell yang diinginkan. Saya sendiri hanya pernah memakainya untuk membuka YouTube dan melakukan RickRoll, tidak mencoba hal ilegal
      Sekarang saya sudah mematikan semua Bluetooth, tetapi tidak tahu cara menghapus bluez tanpa merusak Linux
    • Mungkin karena di Windows, Bluetooth memang jarang berfungsi dengan benar bahkan dalam kondisi biasa
    • Anda mengatakan stack Bluetooth Windows setara dengan ClassicBondedOnly=false di BlueZ, apakah maksudnya ClassicBondedOnly=true?
    • Saya rasa karena ini belum dicoba di Windows

  • Sekarang industri sudah menghilangkan koneksi audio fisik dari ponsel dan mendorong semuanya ke nirkabel, berita seperti ini benar-benar menyenangkan. Bagus sekali

  • Kerentanan ini bekerja dengan menipu state machine host Bluetooth agar melakukan pairing dengan keyboard palsu tanpa konfirmasi pengguna. Mekanisme dasar pairing tanpa autentikasi didefinisikan dalam spesifikasi Bluetooth, dan bug pada masing-masing implementasi mengeksposnya kepada penyerang
    Tapi kenapa mereka ingin membuat pairing bisa terjadi diam-diam? Saya ingin tahu lebih rinci tujuan yang dimaksudkan dari mekanisme yang bermasalah ini

    • Menurut spesifikasi Bluetooth, ini karena banyak perangkat non-komputer. Misalnya agar saat memasangkan controller pertama ke PlayStation, Anda tidak perlu mencolokkan mouse USB untuk mengklik “izinkan pairing”
      Saya tidak tahu kenapa pada perangkat-perangkat yang benar-benar terdampak dibiarkan seperti itu
    • Ini hanya desain lama dari masa yang lebih polos. Spesifikasi terbaru tidak mengizinkannya, tetapi demi memaksimalkan kompatibilitas, stack Bluetooth menonaktifkan perilaku baru itu

  • Masalah ini sudah diperbaiki di macOS 14.2 dan iOS 17.2
    https://support.apple.com/en-us/HT214036
    https://support.apple.com/en-us/HT214035

  • Di Arch Linux, ini sudah diperbaiki mulai bluez 5.70-2 [1]
    [1]: https://gitlab.archlinux.org/archlinux/packaging/packages/bl...

  • Bagian “saat itu Bluetooth terasa intimidating, jadi saya menganggapnya aman saja” terasa mengena. Sepertinya mitos bahwa di suatu tempat di lapisan atas stack teknologi yang rumit ada orang-orang yang benar-benar paham, dan bahwa kita tidak sedang menyangga istana di atas pasir dengan sebatang tongkat, lahir dari rasa gentar seperti itu

  • Saya ragu apakah ini praktis untuk menyerang ponsel atau komputer, tetapi jika Anda berada di posisi harus mengelola kios agar tidak bisa disentuh sembarang orang, hidup jadi sedikit lebih menarik

    • Sekitar 10 tahun lalu, saya pernah tanpa sengaja mengekspos mesin Linux dengan VNC tanpa kata sandi ke internet. Dalam beberapa menit seseorang masuk dan mencoba menjalankan sesuatu dengan input tombol otomatis, tetapi jelas aksinya menargetkan Windows
      Kalau berhasil menanam satu backdoor saja, setelah itu mereka bisa mulai bekerja
      Untuk serangan tertarget, mengirim input tombol Shift setiap 1 menit agar layar tidak terkunci, lalu nanti datang langsung ke depan mesin dan melakukan sesuatu, bisa saja sudah cukup
    • Di komputer, tampaknya juga mungkin menyembunyikan sudo atau su beracun di suatu tempat lalu menambahkannya ke $PATH

  • USB juga mirip. Jika Anda menyambungkan keyboard ke port “hanya untuk pengisian daya”, itu berfungsi. Saya sudah mencobanya langsung di Android, dan di sini saya dimarahi karena katanya ini tidak praktis untuk dieksploitasi

    • Apakah port Android hanya dipakai untuk mengisi daya? Port itu juga sangat berguna untuk HDMI, dan bisa dipakai untuk periferal
      Meski begitu, saya tidak menganggap ini sebagai kerentanan. Ini hanya fitur yang berguna. Masalahnya di sini adalah seseorang bisa melakukannya tanpa disadari pengguna, bahkan saat pengguna sedang melakukan pekerjaan sensitif
      Proyek keren yang diunggah kemarin, https://mitxela.com/projects/smsc, juga bisa digunakan di ponsel dengan cara seperti ini
    • Saya penasaran perangkat Android apa yang secara fisik punya port “hanya untuk pengisian daya”

  • Kerentanan Linux sudah diperbaiki pada 2020 (CVE-2020-0556), tetapi perbaikan itu tetap dinonaktifkan secara default. Kabarnya hanya ChromeOS yang mengaktifkan perbaikan tersebut, meskipun Ubuntu, Debian, Fedora, Gentoo, Arch, dan Alpine sudah menerbitkan pemberitahuan

    • Cukup 30 detik untuk mengecek apakah ini masuk ke NixOS[1]. Saya luangkan 30 detik lagi, dan ternyata sudah dipatch pada 2023-12-08 08:23 GMT+13, sehari setelah tulisan itu naik
      Namun jika pemberitahuan distro mengatakan bahwa cukup melakukan upgrade untuk memperbaikinya[2], saya tidak mengerti apa maksud “perbaikannya dinonaktifkan secara default”. Apakah artinya setelah upgrade masih perlu mengubah konfigurasi secara manual? Perbaikan di NixOS tampaknya membalik nilai default
      Jika maksudnya pengguna yang secara eksplisit menyetel ClassicBondedOnly=false harus mengubahnya, itu bisa ditulis dengan jauh lebih jelas
      [1] https://github.com/NixOS/nixpkgs/blob/3dda6d5ed56af34534dd4c...
      [2] https://ubuntu.com/security/notices/USN-4311-1