Daniele Antonioli, un cercetător în securitate Bluetooth care a dezvoltat anterior tehnicile de atac BIAS, BLUR și KNOB, a identificat două noi vulnerabilități (CVE-2023-24023) în mecanismul de negociere a sesiunii Bluetooth, care afectează toate implementările Bluetooth care acceptă modurile Secure Connections. ” și „Asociere simplă sigură”, conformă cu specificațiile Bluetooth Core 4.2-5.4. Ca o demonstrație a aplicării practice a vulnerabilităților identificate, au fost dezvoltate 6 opțiuni de atac care ne permit să intrăm în conexiunea dintre dispozitivele Bluetooth asociate anterior. Codul cu implementarea metodelor de atac și utilități pentru verificarea vulnerabilităților sunt publicate pe GitHub.
Vulnerabilitățile au fost identificate în timpul analizei mecanismelor descrise în standardul de realizare a secretului direct (Forward and Future Secrecy), care contracarează compromiterea cheilor de sesiune în cazul determinării unei chei permanente (compromiterea uneia dintre cheile permanente nu trebuie să conducă). la decriptarea sesiunilor interceptate anterior sau viitoare) și reutilizarea cheilor cheilor de sesiune (o cheie dintr-o sesiune nu ar trebui să fie aplicabilă unei alte sesiuni). Vulnerabilitățile găsite fac posibilă ocolirea protecției specificate și reutilizarea unei chei de sesiune nesigure în diferite sesiuni. Vulnerabilitățile sunt cauzate de defecte ale standardului de bază, nu sunt specifice stack-urilor Bluetooth individuale și apar în cipuri de la diferiți producători.
Metodele de atac propuse implementează diferite opțiuni pentru organizarea de falsificare a conexiunilor Bluetooth clasice (LSC, Legacy Secure Connections bazate pe primitive criptografice învechite) și sigure (SC, Secure Connections bazate pe ECDH și AES-CCM) între sistem și un dispozitiv periferic, cum ar fi precum si organizarea conexiunilor MITM.atacuri pentru conexiuni in modurile LSC si SC. Se presupune că toate implementările Bluetooth care respectă standardul sunt susceptibile la vreo variantă a atacului BLUFFS. Metoda a fost demonstrată pe 18 dispozitive de la companii precum Intel, Broadcom, Apple, Google, Microsoft, CSR, Logitech, Infineon, Bose, Dell și Xiaomi.
Esența vulnerabilităților se rezumă la capacitatea, fără a încălca standardul, de a forța o conexiune să folosească vechiul mod LSC și o cheie de sesiune scurtă (SK) nesigură, prin specificarea entropiei minime posibile în timpul procesului de negociere a conexiunii și ignorând conținutul răspunsului cu parametri de autentificare (CR), ceea ce duce la generarea unei chei de sesiune pe baza parametrilor de intrare permanenți (cheia de sesiune SK este calculată ca KDF din cheia permanentă (PK) și parametrii conveniți în timpul sesiunii) . De exemplu, în timpul unui atac MITM, un atacator poate înlocui parametrii 𝐴𝐶 și 𝑆𝐷 cu valori zero în timpul procesului de negociere a sesiunii și poate seta entropia 𝑆𝐸 la 1, ceea ce va duce la formarea unei chei de sesiune 𝑆𝐾 cu o valoare reală. entropie de 1 octet (dimensiunea minimă standard a entropiei este de 7 octeți (56 de biți), care este comparabilă ca fiabilitate cu selecția cheii DES).
Dacă atacatorul a reușit să folosească o cheie mai scurtă în timpul negocierii conexiunii, atunci el poate folosi forța brută pentru a determina cheia permanentă (PK) utilizată pentru criptare și pentru a realiza decriptarea traficului dintre dispozitive. Deoarece un atac MITM poate declanșa utilizarea aceleiași chei de criptare, dacă această cheie este găsită, poate fi folosită pentru a decripta toate sesiunile trecute și viitoare interceptate de atacator.
Pentru a bloca vulnerabilități, cercetătorul a propus să facă modificări la standard care extind protocolul LMP și schimbă logica utilizării KDF (Key Derivation Function) atunci când generează chei în modul LSC. Modificarea nu întrerupe compatibilitatea inversă, dar face ca comanda LMP extinsă să fie activată și să fie trimiși încă 48 de octeți. Bluetooth SIG, care este responsabil pentru dezvoltarea standardelor Bluetooth, a propus respingerea conexiunilor pe un canal de comunicație criptat cu chei de până la 7 octeți ca măsură de securitate. Implementările care utilizează întotdeauna Modul de securitate 4 Nivelul 4 sunt încurajate să respingă conexiunile cu chei de până la 16 octeți.
Sursa: opennet.ru