Android, Linux, macOS ve iOS'ta Bluetooth tuş vuruşu enjeksiyonu açığı

 (github.com/skysafe)
2 puan yazan GN⁺ 2023-12-17 | 1 yorum | WhatsApp'ta paylaş
  • CVE-2023-45866, birden fazla işletim sisteminin Bluetooth yığınında kullanıcı onayı olmadan sahte bir klavyenin bağlanıp tuş vuruşu enjekte edebilmesini sağlayan bir kimlik doğrulama atlatma açığıdır
  • Yakındaki bir saldırgan, özel ekipman olmadan yalnızca Linux bilgisayar ve sıradan bir Bluetooth adaptörü ile uygulama yükleme, rastgele komut çalıştırma ve mesaj gönderme gibi işlemleri deneyebilir
  • Açığın tetiklenme koşulları platforma göre değişir; Android'de Bluetooth'un açık olması kritik unsurken, Linux/BlueZ'de discoverable/connectable durumu, iOS ve macOS'ta ise Magic Keyboard eşleştirilmiş olup olmaması etkili olur
  • Android 11-14 için 2023-12-05 güvenlik yaması seviyesi ile risk azaltılıyor, ancak Android 4.2.2-10 için düzeltme yok; BlueZ tarafında ise 2020'deki düzeltme varsayılan olarak devre dışı bırakılmıştı
  • Parola veya biyometrik doğrulama gerektiren işlemler yalnızca tuş vuruşu enjeksiyonuyla yapılamasa da, yama almamış cihazlar kısa menzilli Bluetooth saldırılarına açık olabilir

Kimlik doğrulamasız Bluetooth tuş vuruşu enjeksiyonu

  • CVE-2023-45866, Android, Linux, macOS ve iOS'ta kimlik doğrulamasız Bluetooth keystroke injection'a izin veren bir açığı ifade eder
  • Birden fazla Bluetooth yığınında, saldırganın kullanıcı onayı olmadan discoverable host'a bağlanıp tuş vuruşu enjekte etmesine olanak tanıyan bir kimlik doğrulama atlatma mümkündür
  • Yakındaki bir saldırgan, savunmasız cihaza kimliği doğrulanmamış bir Bluetooth bağlantısı kurup aşağıdaki işlemleri tuş vuruşlarıyla gerçekleştirebilir
    • uygulama yükleme
    • rastgele komut çalıştırma
    • mesaj gönderme
  • Saldırı için özel donanım gerekmez; bir Linux bilgisayar ve sıradan bir Bluetooth adaptörü ile gerçekleştirilebilir
  • Tüm exploit ayrıntıları ve PoC betikleri, 12-14 Ocak'taki ShmooCon haftasında yayımlanacaktır

Platformlara göre saldırı koşulları

  • Açık, Bluetooth host durum makinesini kandırarak kullanıcı onayı olmadan sahte bir klavye ile eşleştirme yaptıracak şekilde çalışır
  • Temeldeki kimlik doğrulamasız eşleştirme mekanizması Bluetooth spesifikasyonunda yer alır; uygulamaya özgü hatalar ise bunu saldırı yüzeyine dönüştürür
  • Yama almamış cihazlarda gereken koşullar işletim sistemine göre değişir
    • Android: Bluetooth açıksa savunmasızdır
    • Linux/BlueZ: Bluetooth discoverable/connectable durumda olmalıdır
    • iOS ve macOS: Bluetooth açık olmalı ve Magic Keyboard telefon ya da bilgisayarla eşleştirilmiş olmalıdır
  • Saldırgan hedef telefon veya bilgisayarla eşleştikten sonra, kurbanın yetkileriyle tuş vuruşu enjekte edebilir
  • Parola veya biyometrik doğrulama gerektiren işlemler yalnızca tuş vuruşu enjeksiyonuyla gerçekleştirilemez

MouseJack sonrasında ortaya çıkan eski açıklar

  • 2016'da yayımlanan MouseJack araştırması, Bluetooth'u değil çevre birimlerinin özel kablosuz protokollerini hedef alıyordu
  • Bu araştırma ise Apple Magic Keyboard hedef alınarak Bluetooth ve Apple ekosisteminin incelenmesi sırasında başladı
  • macOS ve iOS'ta kimlik doğrulamasız Bluetooth keystroke injection bulundu ve her iki platformda da Lockdown Mode altında istismar edilebildi
  • Ardından Linux ve Android'de de benzer açıklar doğrulandı; bunun basit bir uygulama hatasından çok protokol kusuruna yakın olduğu görüldü ve Bluetooth HID spesifikasyonu incelendiğinde her ikisinin de payı olduğu anlaşıldı
  • Bazı açıklar MouseJack'ten daha eskiydi ve Android 4.2.2'ye kadar keystroke injection yeniden üretilebildi

Android etkisi ve yama durumu

  • Testlerde savunmasız olduğu doğrulanan Android cihaz ve sürümleri şunlardır
    • 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 güvenlik yaması seviyesi, Android 11-14'teki açığı hafifletir
  • Android 4.2.2-10 için kullanılabilir bir düzeltme yoktur
  • Açıklanma takvimi şöyledir
    • 2023-08-05: Açık Google'a bildirildi
    • 2023-12-06: Kamuya açıklandı
  • Google, Android 11-14'ü etkileyen sorunun düzeltmesinin etkilenen OEM'lere sağlandığını ve halen desteklenen tüm Pixel cihazlarının Aralık OTA güncellemesiyle düzeltme aldığını belirtti

Linux/BlueZ etkisi ve yamalar

  • Testlerde savunmasız olduğu doğrulanan Ubuntu sürümleri 18.04, 20.04, 22.04, 23.10'dur
  • Google'a göre ChromeOS savunmasız değildir; doğrudan test edilmemiş olsa da BlueZ yapılandırmasının açığı hafiflettiği görülmektedir
  • Linux açığı 2020'de CVE-2020-0556 olarak düzeltilmişti, ancak ilgili düzeltme varsayılan olarak devre dışıydı
  • ChromeOS, bu düzeltmeyi etkinleştirdiği bilinen tek Linux tabanlı işletim sistemi olarak belirtiliyor
  • CVE-2023-45866 için BlueZ yaması, 2020 düzeltmesini varsayılan olarak etkinleştirir
  • İlgili BlueZ yamaları:
  • Ubuntu ile ilgili bilgiler:
  • Debian ile ilgili bilgiler:
  • Fedora ile ilgili bilgiler:
  • Açıklanma takvimi şöyledir
    • 2023-08-10: Açık Canonical'a bildirildi
    • 2023-09-25: Açık Bluetooth SIG'e bildirildi
    • 2023-10-02: CERT/CC nezdinde vaka açıldı
    • 2023-12-06: Kamuya açıklandı

macOS ve iOS etkisi

  • macOS'ta test edilip savunmasız olduğu doğrulanan cihazlar şunlardır
    • 2022 MacBook Pro, macOS 13.3.3, M2
    • 2017 MacBook Air, macOS 12.6.7, Intel
  • macOS'taki Lockdown Mode, saldırıyı engelleyemez
  • macOS Sonoma 14.2 açığı düzeltir
  • macOS için açıklanma takvimi şöyledir
    • 2023-08-01: Açık Apple'a bildirildi
    • 2023-12-06: Kamuya açıklandı
  • iOS'ta test edilip savunmasız olduğu doğrulanan cihaz, iOS 16.6 çalıştıran iPhone SE'dir
  • iOS'taki Lockdown Mode da saldırıyı engelleyemez
  • iOS için açıklanma takvimi şöyledir
    • 2023-08-04: Açık Apple'a bildirildi
    • 2023-12-06: Kamuya açıklandı

İlgili okumalar

1 yorum

 
GN⁺ 2023-12-17
Hacker News yorumları

  • Bunu doğrulamak için biraz araştırmam gerekti; güvende kalmak için Android’de kullanmadığınız zamanlarda Bluetooth’u kapalı tutmak iyi olur. Yine de kullandığınız sırada savunmasız kalıyorsunuz.
    Benim Pixel’im 2023-12-05 güvenlik güncellemesini aldı ve bu sorun düzeltildi, ancak Pixel olmayan cihazlar konusunda emin değilim.
    Linux’ta /etc/bluetooth/input.conf dosyasını açıp ClassicBondedOnly=true olarak ayarlayabilirsiniz. Benim durumumda yeni bir şey eklemeye gerek kalmadan yalnızca yorumu kaldırmak yeterli oldu. Bir sonraki bluetoothd sürümünde varsayılan değer true olacak, ancak şimdiden kendiniz ayarlayabilirsiniz; ardından Bluetooth servisini yeniden başlatmanız gerekir.
    macOS veya iOS için bilmiyorum, çünkü o cihazlara sahip değilim.

    • iOS güncellemesinden sonra Bluetooth’un her zaman tekrar açılmasından oldum olası hoşlanmamışımdır. Aslında hiç kullanmadığım hâlde neden böyle olduğunu uzun süre merak ettim.
      Wi-Fi da Denetim Merkezi’nden tamamen kapatılamayan, delikli peynir gibi bir durumda.
    • Fedora 38’de bluez v5.70-4 ile 7 Aralık’tan beri varsayılan değer true gibi görünüyor.
      $ 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’ta Bluetooth’u kapatmak fazla zahmetli olduğu için üzücü. Android’de kaydırıp tıklamak yeterli; iOS’ta ise kaydırma, iki kez uzun basma ve iki kez tıklama gerekiyor.
      Android’den geçtikten sonra bir süre uğraştım ama sonunda vazgeçtim.
    • İlgili sayfaya bakınca bunun yalnızca parola veya biyometrik doğrulama gerektirmeyen şeylerde çalıştığı söyleniyor.
      Telefonu kullanmadığınızda etkin biçimde kilitlerseniz, kullanırken de tuş girişleri gönderilirse ekranda görünecektir; bu yüzden Bluetooth’u açık bırakmak o kadar korkunç görünmüyor.
    • GrapheneOS’un bunu sunfish(4a) dalında düzeltip düzeltmediğini kontrol etmenin bir yolu var mı merak ediyorum. Pixel 4a olduğu için Android 13’e bağlıyım ve araba kapısını açmak için Bluetooth’a ihtiyacım var.
      GrapheneOS’ta düzeltildiyse sonunda geçmek için bir sebep olurdu; ama mevcut telefonum gayet iyi çalıştığı için yeni telefon almayı gerekçelendirmek zor.

  • Windows’tan hiç bahsedilmemiş olması merak uyandırıyor. Dışarıdan iyi haber gibi geliyor, ama riski değerlendirebilmek için Windows’un neden gerçekten etkilenmediğini bilmek gerekir.
    Örneğin Windows Bluetooth yığınında BlueZ’deki ClassicBondedOnly=false karşılığı bir yapı olup olmadığını bilsek, sertleştirmek istediğimiz ortamlarda bu değerin true olup olmadığını takip etmemiz gerektiği sonucuna varabiliriz.
    Ya da yığın tamamen farklı çalışıyor olabilir ve dikkate alınması gereken şeyler de tamamen farklı olabilir.
    Çok sayıda PoC ve demo içeren videoyu bekliyorum; ama Windows’un pazar payı yüksek ve telaşlanacak çok sayıda sistem yöneticisi olacağından, bilgi olması iyi olurdu. “Windows’ta henüz denemedik” bile faydalı bir bilgi.

    • Bu belirli saldırı Windows için geçerli bir zafiyet olmayabilir.
      Ancak Flipper Zero ile bir Bluetooth cihazı oluşturursanız, Windows istemcisi bağlandığı anda onu klavye olarak algılatıp istediğiniz PowerShell komutlarını çalıştırmasını sağlayabilirsiniz. Ben şahsen yalnızca YouTube açıp RickRoll yapmak için kullandım; yasa dışı bir şey denemedim.
      Artık tüm Bluetooth’u kapalı tutuyorum, ama Linux’u bozmadan bluez’yi nasıl kaldıracağımı bilmiyorum.
    • Belki de Windows’ta Bluetooth normalde de düzgün çalıştığı nadiren görüldüğü içindir.
    • Windows Bluetooth yığınının BlueZ’deki ClassicBondedOnly=false karşılığı olduğunu söylemişsin; acaba ClassicBondedOnly=true demek istemiş olabilir misin?
    • Bence sebep, bunu Windows’ta henüz denememiş olmaları.

  • Sektör telefonlardaki fiziksel ses bağlantılarını kaldırıp herkesi kablosuza ittiği şu dönemde böyle haberler görmek gerçekten harika. Aferin.

    • USB-C DAC’ler ucuz ve yaygın biçimde bulunabiliyor.
    • Bu zafiyet, bağlı kablosuz klavye ve farelere tuş girişi enjekte etme sorunu.[1] Telefon sektörü USB-C’yi benimsediğinden beri kablolu bağlantı hiç olmadığı kadar kolaylaştı.
      [1] https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/pr...

  • Bu zafiyet, Bluetooth ana makine durum makinesini kandırarak kullanıcı onayı olmadan sahte bir klavyeyle eşleşmesini sağlama şeklinde çalışıyor. Altta yatan kimlik doğrulamasız eşleşme mekanizması Bluetooth şartnamesinde tanımlı ve uygulamaya özgü hatalar bunu saldırganlara açık hâle getiriyor.
    Peki neden sessizce eşleşmeye izin vermek istemişler? Sorunlu mekanizmanın amaçlanan kullanımını daha ayrıntılı öğrenmek isterdim.

    • Bluetooth şartnamesi açısından bunun nedeni çeşitli bilgisayar dışı cihazlar. Örneğin ilk kontrolcüyü PlayStation’a eşleştirirken USB fare takıp “eşleşmeye izin ver”e tıklamak zorunda kalmamanız için.
      Gerçekte etkilenen cihazlarda neden böyle bıraktıklarını bilmiyorum.
    • Daha saf bir döneme ait eski bir tasarımdan ibaret. Güncel şartname buna izin vermiyor, ancak uyumluluğu en üst düzeye çıkarmak için Bluetooth yığınları yeni davranışı kapalı tutmuştu.

  • Bu sorun macOS 14.2 ve iOS 17.2’de düzeltildi.
    https://support.apple.com/en-us/HT214036
    https://support.apple.com/en-us/HT214035

  • Arch Linux’ta bluez 5.70-2 sürümünden itibaren düzeltildi [1]
    [1]: https://gitlab.archlinux.org/archlinux/packaging/packages/bl...

  • “O sırada Bluetooth gözümü korkuttuğu için güvenli olduğunu varsaymıştım” kısmı etkileyici. Karmaşık bir teknoloji yığınının üst katmanlarında bir yerlerde işi gerçekten bilen insanlar olduğu ve kum üstüne inşa edilmiş bir kaleyi sopalarla ayakta tutmadıkları yönündeki mit sanki bu göz korkutuculuktan doğuyor.

  • Telefonlara veya bilgisayarlara karşı pratik olup olmayacağından şüpheliyim; ama kiosklara kimsenin dokunamamasını sağlamakla görevliyseniz hayat biraz daha ilginç hâle gelmiş demektir.

    • Yaklaşık 10 yıl önce, parolasız VNC’si açık bir Linux makineyi yanlışlıkla internete açmıştım. Birkaç dakika içinde biri bağlanıp otomatik tuş girişleriyle bir şey çalıştırmaya çalıştı; davranış açıkça Windows’u hedefliyordu.
      Tek bir arka kapıyı başarıyla yerleştirebilirse ondan sonra çalışmaya devam edebilir.
      Hedefli bir saldırıysa, ekranın kilitlenmemesi için dakikada bir Shift tuşu girdisi göndermek ve daha sonra bizzat makinenin başına gidip bir şey yapmak bile yeterli olabilir.
    • Bilgisayarlarda zehirlenmiş bir sudo ya da su komutunu bir yere saklayıp $PATH’e eklemek de mümkün görünüyor.

  • USB de benzer. “Yalnızca şarj” portuna klavye bağlarsanız çalışır. Android’de bizzat denedim ve burada bunun pratikte kötüye kullanılabilir olmadığı konusunda azar işittim.

    • Android portu sadece şarj için mi kullanılıyor? HDMI için de çok kullanışlı, çevre birimleri için de kullanılabiliyor.
      Yine de bunu bir güvenlik açığı olarak görmüyorum. Sadece kullanışlı bir özellik. Buradaki sorun, birinin bunu kullanıcı fark etmeden, hassas işlemler sırasında bile yapabiliyor olması.
      Dün yayımlanan harika proje https://mitxela.com/projects/smsc de bu yöntemle telefonda kullanılabiliyordu.
    • Fiziksel olarak “yalnızca şarj” portu olan Android cihazın ne olduğunu merak ediyorum.

  • Linux açığı 2020’de düzeltilmişti (CVE-2020-0556), ancak bu düzeltme varsayılan olarak devre dışı kalmıştı. Yalnızca ChromeOS’un bu düzeltmeyi etkinleştirdiği biliniyor; Ubuntu, Debian, Fedora, Gentoo, Arch ve Alpine duyuru yapmış olmasına rağmen durum böyleydi.

    • NixOS’a girip girmediğini kontrol etmek 30 saniye sürdü[1]. Bir 30 saniye daha ayırınca, yazının yayımlanmasından bir gün sonra, 2023-12-08 08:23 GMT+13’te yamalandığını gördüm.
      Ancak dağıtım duyurusu yalnızca yükseltme yapınca düzeleceğini söylüyorsa[2], “düzeltme varsayılan olarak kapalıydı” ifadesinin ne anlama geldiğini anlamıyorum. Yükseltmeden sonra da elle yapılandırma değişikliği gerektiği anlamına mı geliyor? NixOS düzeltmesi varsayılanı tersine çeviriyor gibi görünüyor.
      Kastedilen, açıkça ClassicBondedOnly=false ayarlamış kullanıcıların bunu değiştirmesi gerektiğiyse, bu çok daha net yazılabilirdi.
      [1] https://github.com/NixOS/nixpkgs/blob/3dda6d5ed56af34534dd4c...
      [2] https://ubuntu.com/security/notices/USN-4311-1