Bluetooth to jedna z najbardziej rozpowszechnionych technologii bezprzewodowej komunikacji krótkiego zasięgu, stosowana zarówno w urządzeniach konsumenckich, jak i przemysłowych. Od klawiatur, smartfonów i słuchawek po medyczne sensory i rozwiązania IoT – niemal każdy z nas ma z nią styczność na co dzień. Jednakże złożoność stosów protokołów Bluetooth powoduje, że są one podatne na różnorodne błędy implementacyjne. Jednym z najnowszych odkryć w tej dziedzinie jest podatność znana jako Bleak Pairing, zidentyfikowana w SDK Realtek, wykorzystywanym w milionach układów BLE. Choć wydaje się niepozorna, może prowadzić do zdalnego i trwałego uniemożliwienia łączenia urządzeń – czyli ataku DoS (Denial of Service).
Geneza problemu – luka w BLE od Realtek
Podatność zidentyfikowano w stosie Bluetooth Low Energy w wersji 1.4.0 SDK Realtek RTL8762E – popularnym rozwiązaniu dla tanich urządzeń konsumenckich i IoT. Podatny kod znajduje się w warstwie zarządzania bezpieczeństwem BLE – Security Manager Protocol (SMP). Problem polega na niewłaściwej walidacji kolejności pakietów w czasie procedury Secure Connections Pairing – etapu, w którym dwa urządzenia ustalają klucze szyfrowania komunikacji. Jeśli atakujący wyśle pakiet Pairing Random wcześniej, niż przewiduje to specyfikacja, stos BLE przyjmie go, mimo że nie doszło jeszcze do wymiany kluczy publicznych. Prowadzi to do przerwania sesji i braku możliwości zestawienia bezpiecznego połączenia.
Szczegóły techniczne
Bluetooth działa na zasadzie tzw. maszyny stanów, w której każde urządzenie BLE przechodzi przez ściśle określone etapy – od zapytania o urządzenie, przez wymianę informacji identyfikacyjnych, po ustanowienie szyfrowanego kanału. W BLE Secure Connections kolejne kroki to: generowanie klucza publicznego (PK), wymiana PK, generowanie losowych wartości (Nonce) i dopiero wtedy przesłanie Pairing Random. Realtek SDK nie sprawdza poprawnie, czy poprzedni etap został zakończony, co pozwala na ominięcie całego procesu. Z punktu widzenia inżynierii protokołów jest to błąd logiki sekwencyjnej – klasyczny problem FSM (Finite State Machine) bez kontroli integralności stanu.
Jak działa atak?
Eksperci opracowali dowód koncepcji (PoC) – skrypt w Pythonie z wykorzystaniem odpowiednio zmodyfikowanego sniffera BLE, który w sztuczny sposób inicjuje parowanie, a następnie natychmiast wysyła pakiet Pairing Random. Gdy stos Realteka go odbierze, błędnie zakłada, że wcześniejsze etapy zostały już przeprowadzone. Ponieważ struktura danych staje się niespójna, stos BLE przechodzi w stan błędu i przerywa dalsze operacje. Co gorsza, często nie próbuje nawet wznowić parowania – użytkownik musi ręcznie zresetować urządzenie.
Potencjalne skutki – więcej niż tylko rozłączenie
Na pierwszy rzut oka mogłoby się wydawać, że atak tego typu jest mało groźny – w końcu „tylko” przerywa parowanie. Jednak w rzeczywistości konsekwencje są znacznie poważniejsze. W środowiskach medycznych czy przemysłowych, gdzie urządzenia BLE odpowiadają za monitoring parametrów życiowych lub kontrolę automatyki, chwilowa utrata łączności może prowadzić do niebezpiecznych sytuacji. Ponadto atakujący może automatycznie i cyklicznie powtarzać wysyłanie pakietów Pairing Random, uniemożliwiając użytkownikowi przywrócenie funkcjonalności urządzenia bez fizycznej interwencji.
Dziesiątki milionów urządzeń narażone na atak
Chipset RTL8762E Realtek znajduje się w setkach modeli opasek fitness, smart-zamków, świateł BLE, słuchawek i kontrolerów gier. Wiele z nich to tzw. OEM-y, czyli urządzenia bez logo znanej marki, lecz używane w produktach końcowych przez inne firmy. Z powodu braku centralnej aktualizacji firmware większość użytkowników nawet nie będzie świadoma istnienia podatności – tym samym atak staje się niezwykle groźny w skali globalnej.
Inne podobne przypadki – MediaTek, Airoha, BlueZ
Nie tylko Realtek ma problem. W przeszłości wykryto krytyczne luki w innych popularnych implementacjach Bluetooth:
- MediaTek – podatności we współdzieleniu bufora Bluetooth/WLAN (ang. coexistence) w chipach Helio SoC, umożliwiające dostęp do systemu operacyjnego.
- Airoha (MT7921) – używana w słuchawkach Sony i Bose – umożliwiała dostęp do danych firmware i pamięci RAM przez BLE.
- BlueZ (Linux) – luka BleedingTooth (CVE-2020-12351) pozwalała na RCE na poziomie jądra przez L2CAP.
Problemy projektowe – dlaczego protokoły BLE są tak podatne?
Bluetooth to skomplikowany protokół warstwowy z dziesiątkami profili i trybów transmisji. BLE został zaprojektowany jako energooszczędna wersja klasycznego Bluetooth, ale jego struktura wymaga implementacji logiki stanów na poziomie sprzętowym lub firmware. Wiele firm używa uproszczonych stosów protokołów dostarczanych przez producenta chipów, co oznacza, że błąd w SDK trafia do setek modeli urządzeń. Dodatkowo brak pełnej walidacji specyfikacji Bluetooth Core przez twórców sprzętu sprawia, że błędy logiczne – takie jak ten w Realtek – są trudne do wykrycia bez dokładnej inspekcji lub fuzzowania.
Możliwość wykorzystania w atakach trwałych
Ze względu na to, że BLE działa w sposób pasywny i cały czas „nasłuchuje”, atakujący może przeprowadzać ataki bez wiedzy użytkownika – np. z użyciem stacjonarnego laptopa, raspberry Pi z anteną BLE lub specjalistycznych narzędzi, takich jak Ubertooth One. Możliwość cyklicznego restartowania procesu parowania skutecznie blokuje łączność, nawet gdy urządzenie zostanie fizycznie ponownie uruchomione.
Co można zrobić? – zalecenia dla producentów
Producentom zaleca się natychmiastową aktualizację SDK Realtek oraz weryfikację logiki stanów SMP. W szczególności polecane są:
- Blokada przyjmowania pakietów Pairing Random przed Pairing Public Key.
- Weryfikacja zgodności z Bluetooth Core 5.x – użycie stateful validation.
- Dodanie systemów monitorujących anomalie protokołowe – np. alertów przy błędnym SMP sequence.
Środki zaradcze dla użytkowników
Jeśli jesteś użytkownikiem sprzętu opartego na chipie Realtek RTL8762E (lub pokrewnym), wykonaj następujące kroki:
- Sprawdź, czy producent oferuje aktualizację firmware.
- Jeśli to możliwe – wyłącz funkcję BLE w momentach bez aktywnego użycia.
- Unikaj publicznych przestrzeni BLE (np. targów elektroniki, lotnisk), gdzie ktoś mógłby prowadzić atak pasywny.
- Monitoruj nieoczekiwane rozłączenia – mogą być sygnałem ataku.
BLE w krytycznych systemach – ryzyko dla sektora medycznego i przemysłowego
W systemach klasy SCADA, medycznych implantach, urządzeniach noszonych przez pacjentów, BLE stanowi podstawowy kanał transmisji. Utrata jego stabilności może oznaczać poważne zagrożenie – od błędów diagnostycznych po fizyczne uszkodzenie urządzeń. Standardy takie jak IEC 62304 lub ISO 14971 powinny uwzględniać aktualne zagrożenia BLE jako istotne ryzyko w analizach bezpieczeństwa funkcjonalnego.
Podsumowanie
Luka Bleak Pairing to nie tylko błąd kodu – to sygnał, że protokoły komunikacji bezprzewodowej wymagają stałej kontroli, testów bezpieczeństwa i odpowiedzialnego wdrażania. Producentów obowiązuje nie tylko zgodność ze specyfikacją, ale też zapewnienie odporności implementacyjnej. Dla użytkowników oznacza to jedno: aktualizujmy, monitorujmy i nie traktujmy BLE jako „niewidzialnej, bezpiecznej magii”.