Grupurile de cercetare Forescout Research Labs și JSOF Research au publicat rezultatele unui studiu comun al securității diferitelor implementări ale schemei de compresie utilizate pentru a împacheta nume duplicate în mesajele DNS, mDNS, DHCP și IPv6 RA (ambalarea părților duplicate ale domeniului în mesaje). care includ mai multe nume). În timpul lucrărilor au fost identificate 9 vulnerabilități, care sunt rezumate sub numele de cod NAME:WRECK.
Au fost identificate probleme în FreeBSD, precum și în subsistemele de rețea IPnet, Nucleus NET și NetX, care au devenit larg răspândite în sistemele de operare în timp real VxWorks, Nucleus și ThreadX utilizate în dispozitive de automatizare, stocare, dispozitive medicale, avionică, imprimante. și electronice de larg consum. Se estimează că cel puțin 100 de milioane de dispozitive sunt afectate de vulnerabilități.
- O vulnerabilitate din FreeBSD (CVE-2020-7461) a făcut posibilă organizarea execuției codului său prin trimiterea unui pachet DHCP special conceput către atacatorii aflați în aceeași rețea locală ca și victima, a cărui procesare de către un client DHCP vulnerabil a condus la o depășire a tamponului. Problema a fost atenuată de faptul că procesul dhclient în care era prezentă vulnerabilitatea rula cu privilegii de resetare într-un mediu Capsicum izolat, ceea ce necesita identificarea unei alte vulnerabilități pentru a ieși.
Esența erorii constă în verificarea incorectă a parametrilor, în pachetul returnat de serverul DHCP cu opțiunea DHCP 119, care vă permite să transferați lista „căutare domeniului” către resolver. Calculul incorect al dimensiunii buffer-ului necesar pentru a găzdui numele de domenii dezambalate a dus la scrierea informațiilor controlate de atacator dincolo de buffer-ul alocat. În FreeBSD, problema a fost rezolvată în septembrie anul trecut. Problema poate fi exploatată doar dacă aveți acces la rețeaua locală.
- O vulnerabilitate în stiva de rețea IPnet încorporată utilizată în RTOS VxWorks permite execuția potențială a codului pe partea clientului DNS din cauza manipulării necorespunzătoare a compresiei mesajelor DNS. După cum s-a dovedit, această vulnerabilitate a fost identificată pentru prima dată de Exodus în 2016, dar nu a fost niciodată remediată. O nouă solicitare către Wind River a rămas fără răspuns, iar dispozitivele IPnet rămân vulnerabile.
- Au fost identificate șase vulnerabilități în stiva Nucleus NET TCP/IP, susținută de Siemens, dintre care două ar putea duce la execuția de cod de la distanță, iar patru ar putea duce la refuzul serviciului. Prima problemă periculoasă este legată de o eroare la decomprimarea mesajelor DNS comprimate, iar a doua este legată de analizarea incorectă a etichetelor numelor de domeniu. Ambele probleme duc la o depășire a memoriei tampon la procesarea răspunsurilor DNS special formatate.
Pentru a exploata vulnerabilitățile, un atacator trebuie pur și simplu să trimită un răspuns special conceput la orice cerere legitimă trimisă de pe un dispozitiv vulnerabil, de exemplu, efectuând un atac MTIM și interferând cu traficul dintre serverul DNS și victimă. Dacă atacatorul are acces la rețeaua locală, atunci el poate lansa un server DNS care încearcă să atace dispozitivele problematice trimițând cereri mDNS în modul de difuzare.
- Vulnerabilitatea din stiva de rețea NetX (Azure RTOS NetX), dezvoltată pentru ThreadX RTOS și deschisă în 2019 după ce a fost preluată de Microsoft, a fost limitată la refuzul serviciului. Problema este cauzată de o eroare la analizarea mesajelor DNS comprimate în implementarea rezolutorului.
Dintre stivele de rețea testate în care nu s-au găsit vulnerabilități legate de comprimarea datelor repetate în mesajele DNS, au fost denumite următoarele proiecte: lwIP, Nut/Net, Zephyr, uC/TCP-IP, uC/TCP-IP, FreeRTOS+TCP , OpenThread și FNET. Mai mult, primele două (Nut/Net și lwIP) nu acceptă deloc compresia în mesajele DNS, în timp ce celelalte implementează această operațiune fără erori. În plus, se observă că anterior aceiași cercetători identificaseră deja vulnerabilități similare în stivele Treck, uIP și PicoTCP.
Sursa: opennet.ru