Daniele Antonioli, badacz bezpieczeństwa Bluetooth, który wcześniej opracował techniki ataków BIAS, BLUR i KNOB, zidentyfikował dwie nowe podatności (CVE-2023-24023) w mechanizmie negocjacji sesji Bluetooth, które dotyczą wszystkich implementacji Bluetooth wspierających tryby bezpiecznego parowania „Secure Connections” i „Secure Simple Pairing”, zgodne ze specyfikacjami Bluetooth Core 4.2-5.4. W ramach demonstracji zastosowania wykrytych podatności opracowano 6 wariantów ataków, które umożliwiają wniknięcie w połączenie między wcześniej sparowanymi urządzeniami Bluetooth. Kod z implementacją metod ataku oraz narzędzia do sprawdzania występowania podatności zostały opublikowane na GitHubie.
Podatności zostały wykryte podczas analizy mechanizmów osiągania bezpośredniej tajności opisanych w standardzie (Forward and Future Secrecy), które mają zapobiegać kompromitacji kluczy sesyjnych w przypadku zdefiniowania stałego klucza (kompromitacja jednego z stałych kluczy nie powinna prowadzić do odszyfrowania wcześniej przechwyconych lub przyszłych sesji) oraz ponownemu używaniu kluczy sesyjnych (klucz z jednej sesji nie powinien być stosowany w innej sesji). Zidentyfikowane podatności pozwalają na obejście tej ochrony i ponowne wykorzystanie niepewnego klucza sesyjnego w różnych sesjach. Podatności te są wynikiem niedoróbek w podstawowym standardzie, nie są specyficzne dla poszczególnych stosów Bluetooth, i przejawiają się w chipach różnych producentów.
Proponowane metody ataków realizują różne warianty organizacji spoofingu klasycznych (LSC, Legacy Secure Connections oparte na przestarzałych prymitywach kryptograficznych) oraz chronionych (SC, Secure Connections oparte na ECDH i AES-CCM) połączeń Bluetooth między systemem a urządzeniem peryferyjnym, jak również organizacji ataków MITM dla połączeń w trybach LSC i SC. Zakłada się, że wszystkie implementacje Bluetooth zgodne ze standardem są podatne na różne warianty ataku BLUFFS. Działanie metody zostało zademonstrowane na 18 urządzeniach od takich firm jak Intel, Broadcom, Apple, Google, Microsoft, CSR, Logitech, Infineon, Bose, Dell i Xiaomi.
Istota luk w zabezpieczeniach sprowadza się do możliwości wymuszenia powrotu do starszego trybu LSC i niebezpiecznego krótkiego klucza sesyjnego (SK) bez naruszenia standardu, poprzez określenie minimalnej możliwej entropii w trakcie negocjacji połączenia i zignorowanie treści odpowiedzi z parametrami uwierzytelniania (CR), co prowadzi do generacji klucza sesyjnego na podstawie stałych parametrów wejściowych (klucz sesyjny SK oblicza się jako KDF ze stałego klucza (PK) i uzgodnionych w trakcie sesji parametrów). Na przykład, atakujący podczas ataku MITM może zastąpić w trakcie negocjacji sesji parametry 𝐴𝐶 i 𝑆𝐷 zerowymi wartościami, a entropię 𝑆𝐸 ustawić na 1, co doprowadzi do utworzenia klucza sesyjnego 𝑆𝐾 z faktyczną entropią wynoszącą 1 bajt (standardowy minimalny rozmiar entropii wynosi 7 bajtów (56 bitów), co w kategoriach bezpieczeństwa jest porównywalne z próbami łamania kluczy DES).
Jeśli atakującemu udało się w trakcie negocjacji połączenia wymusić użycie krótszego klucza, może on następnie przy pomocy ataku brute force zidentyfikować stały klucz (PK) używany do szyfrowania i osiągnąć odszyfrowanie ruchu między urządzeniami. Ponieważ podczas ataku MITM można zainicjować użycie tego samego klucza szyfrowania, jeśli klucz zostanie odgadnięty, można go użyć również do odszyfrowania wszystkich wcześniejszych i przyszłych sesji przechwyconych przez atakującego.
Aby zablokować luki w zabezpieczeniach, badacze zaproponowali wprowadzenie zmian do standardu, które rozszerzą protokół LMP i zmienią logikę wykorzystania KDF (Key Derivation Function) przy tworzeniu kluczy w trybie LSC. Zmiana nie narusza kompatybilności wstecznej, ale prowadzi do włączenia rozszerzonej komendy LMP i konieczności wysłania dodatkowych 48 bajtów. Organizacja Bluetooth SIG, odpowiedzialna za rozwój standardów Bluetooth, w ramach środków ochrony zaproponowała odrzucanie połączeń z zaszyfrowanymi kanałami komunikacyjnymi z kluczami o rozmiarze do 7 bajtów. Realizacjom, które zawsze stosują poziom Security Mode 4 Level 4, zaleca się odrzucanie połączeń z kluczami o rozmiarze do 16 bajtów.
Źródło: opennet.ru
