I gruppi di ricerca Forescout Research Labs e JSOF Research hanno pubblicato i risultati di uno studio congiunto sulla sicurezza di diverse implementazioni dello schema di compressione utilizzato per l'imballaggio di nomi ripetitivi nei messaggi DNS, mDNS, DHCP e IPv6 RA (imballaggio di parti duplicate di domini in messaggi contenenti più nomi). Durante il lavoro condotto, sono state identificate 9 vulnerabilità, riunite sotto il nome in codice NAME:WRECK.
I problemi sono stati riscontrati in FreeBSD, così come nelle sottosistemi di rete IPnet, Nucleus NET e NetX, diffusi nei sistemi operativi in tempo reale VxWorks, Nucleus e ThreadX, utilizzati in dispositivi di automazione, sistemi di archiviazione, apparecchiature mediche, avionic, stampanti ed elettronica di consumo. Si stima che almeno 100 milioni di dispositivi siano vulnerabili.
- Una vulnerabilità in FreeBSD (CVE-2020-7461) consentiva l'esecuzione di codice malevolo tramite l'invio di un pacchetto DHCP appositamente formattato da un attaccante che si trovava nella stessa rete locale della vittima, il cui trattamento da parte del client DHCP vulnerabile portava a un overflow del buffer. Un fattore mitigante era che il processo dhclient, che presenta la vulnerabilità, veniva eseguito con privilegi ridotti in un ambiente isolato Capsicum, da cui era necessario identificare un'ulteriore vulnerabilità per evadere.
Il problema risiede in un controllo errato dei parametri, nel pacchetto restituito dal server DHCP con l'opzione 119-DHCP, che consente di trasmettere l'elenco "domain search" per il risolutore. Calcolo errato della dimensione del buffer necessario per contenere i dati decompresso. di nomi di dominio, portava alla scrittura di informazioni controllate dall'attaccante al di fuori del buffer assegnato. In FreeBSD, il problema è stato risolto già a settembre dello scorso anno. La questione può essere sfruttata solo in presenza di accesso alla rete locale.
- Una vulnerabilità nel stack di rete incorporato IPnet, utilizzato in RTOS VxWorks, consente potenzialmente l'esecuzione di codice lato DNS client a causa di un'elaborazione errata della compressione dei messaggi DNS. In effetti, questa vulnerabilità è stata identificata per la prima volta da Exodus nel 2016, ma non è mai stata corretta. Anche una nuova richiesta a Wind River è rimasta senza risposta, lasciando i dispositivi con IPnet vulnerabili.
- Nel stack TCP/IP Nucleus NET, supportato da Siemens, sono state identificate 6 vulnerabilità, delle quali due potrebbero portare all'esecuzione remota di codice, e quattro all'inizio di un attacco di denial of service. Il primo problema critico è legato a un errore nell'elaborazione di messaggi DNS compressi, mentre il secondo riguarda un'analisi errata delle etichette dei nomi di dominio. Entrambi i problemi portano a un overflow del buffer durante l'elaborazione di risposte DNS appositamente formattate.
Per sfruttare le vulnerabilità, basta che l'attaccante invii una risposta appositamente formattata a qualsiasi richiesta legittima inviata dal dispositivo vulnerabile, ad esempio attraverso un attacco MITM e l'inserimento nel traffico tra il server DNS e la vittima. Se l'attaccante ha accesso alla rete locale, può avviare un server DNS che tenta di attaccare i dispositivi vulnerabili inviando richieste mDNS in modalità broadcast.
- Una vulnerabilità nello stack di rete NetX (Azure RTOS NetX), progettato per ThreadX RTOS e aperto nel 2019 dopo il trasferimento a Microsoft, si limita a causare un denial of service. Il problema è causato da un errore nell'analisi dei messaggi DNS compressi nell'implementazione del resolver.
Tra gli stack di rete verificati, nei quali non sono state trovate vulnerabilità legate alla compressione dei dati ripetitivi nei messaggi DNS, sono stati nominati i progetti lwIP, Nut/Net, Zephyr, uC/TCP-IP, uC/TCP-IP, FreeRTOS+TCP, OpenThread e FNET. I primi due (Nut/Net e lwIP) non supportano affatto la compressione nei messaggi DNS, mentre gli altri eseguono questa operazione senza errori. Inoltre, si osserva che precedentemente gli stessi ricercatori avevano già identificato vulnerabilità simili negli stack Treck, uIP e PicoTCP.
Fonte: opennet.ru
