KNOB – atak na Bluetooth Classic. Można bezprzewodowo wymusić klucz kryptograficzny o długości 8 bitów (!). Następnie podsłuchiwać / wpływać na transmisję.

Jak wiecie, Bluetooth uznawany jest za znacznie bezpieczniejszy protokół niż wiele autorskich rozwiązań, które często nie używają  żadnego szyfrowania podczas transmisji radiowej (patrz np. możliwość wstrzykiwania dowolnej sekwencji klawiszy poprzez atak na klawiatury bezprzewodowe / myszy / inne urządzenia + oczywiście możliwość ich podsłuchiwania). Niektórzy używają też Bluetootha do tworzenia hotspotu z dostępem do Internetu…

Tymczasem odkryto właśnie spory problem w specyfikacji Bluetooth (od 1.0 do 5.1), sprowadza się on do możliwości zmniejszenia rozmiaru klucza kryptograficznego używanego przez urządzenia komunikujące się Bluetoothem do 8 bitów (!). Jest to w pełni zgodne ze specyfikacją, która mówi:

For the encryption algorithm, the key size may vary between 1 and 16 octets (8 – 128 bits)

Atak polega na przezroczystym dla użytkowników wpłynięciu na proces negocjacji kluczy – realizowany protokołem Bluetooth BR/EDR (Basic Rate/Enhanced Data Rate). Przy okazji warto pamiętać, że BR/EDR to tzw. „Bluetooth Classic” (Bluetooth LE to coś innego i nie jest podatny, choć uwaga na chipy obsługujące jednocześnie oba standardy).

(…) attack capable of making two (or more) victims using a Bluetooth encryption key with 1 byte of entropy without noticing it. The attacker then can easily brute force the encryption key, eavesdrop and decrypt the ciphertext and inject valid ciphertext without affecting the status of the target Bluetooth piconet.

Sam protokół BR/EDR nie jest szyfrowany ani nie jest sprawdzane uwierzytelnienie stron, co więcej umożliwia on negocjację długości ustalanego pomiędzy stronami połączenia klucza (wg specyfikacji minimalna długość to 8 bitów (!)). Badacze pokazali też konkretny atak brute-force na ten klucz (mamy tu zaledwie 256 możliwości…).

W tym miejscu warto również wspomnieć, że protokół zazwyczaj jest implementowany na poziomie firmware-u (system operacyjny często nic nie wie o szczegółach tej negocjacji, więc i nie widzi ataku, ani faktu że właśnie wynegocjowano mały klucz).

Po przeczytaniu tego wszystkiego można myśleć – no dobra, ale wygląda na to, że problem występuje w procesie parowania urządzeń. Otóż nie – badacze przedstawiają PoC-a na już sparowanych ofiarach – zob. sekcję w rozdziale 4.2 cytowanej pracy, która rozpoczyna się tak:

assuming that the victims are already paired, we test if two victims are vulnerable to the KNOB attack as follows (…)

Tutaj wyniki dla popularnych chipów:

KNOB – co jest podatne?

W odpowiedzi, organizacja standaryzująca Bluetooth zaktualizowała specyfikację, wymagając teraz klucz długości co najmniej 7 oktetów. Na obecną chwilę trudno stwierdzić ile urządzeń da się zaktualizować aby było zgodnymi z nową specyfikacją – choć np. Microsoft już wypuścił odpowiednią łatę.

Jakie są wymagania odnośnie ataku? Oczywiście atakujący musi znajdować się fizycznie niewielkiej odległości od ofiar i obie muszą być podatne na KNOB (czyli w skrócie korzystać z nieprawidłowo zaimplementowanego protokołu BR/EDR – a raczej prawidłowo, tyle że vs. niedawno jeszcze obowiązująca wersja specyfikacji Bluetooth). Ważną rolę grają odpowiednio niskie czasy transmisji / reakcji w trakcie realnego ataku, choć w oryginalnej pracy badacze wskazują, że nie jest to duży problemem:

We expect that a remote attacker with commercial-off-the-shelf devices such as a software defined radio, GNU Radio and a laptop can conduct the attack.

Dodatkowo, atak powiedzie się na sparowane wcześniej urządzenia, choć najprawdopodobniej nie powiedzie się na już zestawione połączenie (np. mamy podłączone słuchawki; atakujący musi poczekać np. na ich wyłączenie i włączenie).

–Michał Sajdak