Daniele Antonioli, a Bluetooth biztonsági kutatója, aki korábban kifejlesztette a BIAS, BLUR és KNOB támadási technikákat, két új sebezhetőséget (CVE-2023-24023) azonosított a Bluetooth munkamenet egyeztetési mechanizmusában, amelyek minden olyan Bluetooth-megvalósítást érintenek, amelyek támogatják a Secure Connections módokat. "Biztonságos egyszerű párosítás", amely megfelel a Bluetooth Core 4.2-5.4 specifikációinak. Az azonosított sérülékenységek gyakorlati alkalmazásának demonstrációjaként 6 támadási lehetőséget fejlesztettek ki, amelyek segítségével beékelődhetünk a korábban párosított Bluetooth-eszközök közötti kapcsolatba. A támadási módszereket és a sebezhetőségek ellenőrzésére szolgáló segédprogramokat tartalmazó kódot közzétették a GitHubon.
A sérülékenységeket a továbbított titkosság elérését szolgáló szabványban leírt mechanizmusok (Forward and Future Secrecy) elemzése során azonosították, amelyek állandó kulcs meghatározása esetén ellensúlyozzák a munkamenetkulcsok kompromittálását (az állandó kulcsok egyikének kompromittálása nem vezethet a korábban elfogott vagy jövőbeli munkamenetek visszafejtésére) és a munkamenetkulcsok kulcsainak újrafelhasználására (az egyik munkamenetből származó kulcs nem alkalmazható egy másik munkamenetre). A talált sebezhetőségek lehetővé teszik a megadott védelem megkerülését, és a megbízhatatlan munkamenetkulcsok újrafelhasználását különböző munkamenetekben. A sérülékenységeket az alapszabvány hibái okozzák, nem az egyes Bluetooth-veremekre vonatkoznak, és különböző gyártók chipjeiben jelennek meg.
A javasolt támadási módszerek különböző lehetőségeket valósítanak meg a klasszikus (LSC, Elavult kriptográfiai primitíveken alapuló Legacy Secure Connections) és biztonságos (SC, Secure Connections ECDH és AES-CCM alapú) Bluetooth-kapcsolatok hamisításának megszervezésére a rendszer és a periféria között, mint pl. valamint MITM kapcsolatok szervezése, támadások LSC és SC módú kapcsolatokra. Feltételezhető, hogy a szabványnak megfelelő összes Bluetooth-megvalósítás érzékeny a BLUFFS-támadás valamely változatára. A módszert olyan cégek 18 készülékén mutatták be, mint az Intel, a Broadcom, az Apple, a Google, a Microsoft, a CSR, a Logitech, az Infineon, a Bose, a Dell és a Xiaomi.
A sérülékenységek lényege abban rejlik, hogy a szabvány megsértése nélkül egy kapcsolatot a régi LSC mód és egy megbízhatatlan rövid munkamenet kulcs (SK) használatára kényszeríthetünk úgy, hogy a kapcsolat egyeztetési folyamata során megadjuk a minimális entrópiát, és figyelmen kívül hagyjuk a a válasz tartalma hitelesítési paraméterekkel (CR), amely állandó bemeneti paraméterek alapján munkamenetkulcs generálásához vezet (az SK munkamenetkulcs az állandó kulcsból (PK) és a munkamenet során egyeztetett paraméterekből KDF-ként kerül kiszámításra) . Például egy MITM támadás során a támadó lecserélheti a 𝐴𝐶 és 𝑆𝐷 paramétereket nulla értékre a munkamenet egyeztetési folyamata során, és a 𝑆𝐸 entrópiát 1-re állíthatja, ami egy tényleges munkamenetkulcs 𝑆𝐾 képzéséhez vezet. 1 bájtos entrópia (a szabványos minimális entrópiaméret 7 bájt (56 bit), ami megbízhatóságban összemérhető a DES kulcs kiválasztásával).
Ha a támadónak sikerült elérnie egy rövidebb kulcs használatát a kapcsolódási egyeztetés során, akkor nyers erőt alkalmazhat a titkosításhoz használt állandó kulcs (PK) meghatározására és az eszközök közötti forgalom visszafejtésére. Mivel egy MITM támadás kiválthatja ugyanazon titkosítási kulcs használatát, ha ez a kulcs megtalálható, akkor a támadó által elfogott összes múltbeli és jövőbeli munkamenet visszafejtésére használható.
A sebezhetőségek blokkolása érdekében a kutató olyan változtatásokat javasolt a szabványon, amelyek kiterjesztik az LMP protokollt, és megváltoztatják a KDF (Key Derivation Function) használatának logikáját a kulcsok LSC módban történő generálásakor. A változás nem töri meg a visszafelé kompatibilitást, de engedélyezi a kiterjesztett LMP parancsot, és további 48 bájtot küld. A Bluetooth-szabványok fejlesztéséért felelős Bluetooth SIG biztonsági intézkedésként javasolta a titkosított kommunikációs csatornán keresztüli kapcsolatok elutasítását legfeljebb 7 bájt méretű kulcsokkal. A mindig a 4. szintű 4-es biztonsági módot használó megvalósításokat javasoljuk, hogy utasítsák el a legfeljebb 16 bájt méretű kulcsokkal rendelkező kapcsolatokat.
Forrás: opennet.ru