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 imballare nomi ripetitivi nei messaggi DNS, mDNS, DHCP e IPv6 RA (imballaggio di parti duplicate dei domini in messaggi contenenti più nomi). Nel corso del lavoro svolto sono state rilevate 9 vulnerabilità, riassunte con il nome in codice NAME:WRECK.
I problemi sono stati rilevati in FreeBSD, nonché nei sottosistemi di rete IPnet, Nucleus NET e NetX, diffusi nei sistemi operativi in tempo reale VxWorks, Nucleus e ThreadX, utilizzati in dispositivi di automazione, archiviazione, dispositivi medici, avionica, 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 maligno tramite l'invio da parte di un attaccante, situato nella stessa rete locale della vittima, di un pacchetto DHCP appositamente formattato, la cui elaborazione da parte del client DHCP vulnerabile poteva portare a un overflow del buffer. La problematica era mitigata dal fatto che il processo dhclient, in cui si trovava la vulnerabilità, veniva eseguito con privilegi ridotti in un ambiente isolato Capsicum, dal quale era necessario identificare un'altra vulnerabilità per uscire.
Il problema risiedeva nella verifica errata dei parametri nel pacchetto restituito dal server DHCP con l'opzione 119 DHCP, che consente di trasmettere un elenco di "domain search" per il resolver. Un calcolo errato della dimensione del buffer necessario per contenere le informazioni decompresse nomi di dominio, portava alla scrittura di informazioni controllabili dall'attaccante al di fuori del buffer allocato. In FreeBSD il problema è stato risolto già nel settembre dello scorso anno. La vulnerabilità può essere sfruttata solo in presenza di accesso alla rete locale.
- Una vulnerabilità nello stack di rete integrato IPnet, utilizzato in RTOS VxWorks, consente di eseguire potenzialmente codice dal lato del client DNS a causa di un'elaborazione errata della compressione dei messaggi DNS. A quanto pare, questa vulnerabilità era stata individuata per la prima volta dalla società Exodus nel 2016, ma non è mai stata corretta. Anche la nuova richiesta a Wind River è rimasta senza risposta e i dispositivi con IPnet rimangono vulnerabili.
- Nel stack TCP/IP Nucleus NET, supportato da Siemens, sono state identificate 6 vulnerabilità, di cui due potrebbero portare all'esecuzione remota di codice e quattro all'avvio di un attacco di negazione di servizio. Il primo problema critico è legato a un errore nel decompresso dei messaggi DNS compressi, mentre il secondo riguarda l'analisi errata delle etichette dei nomi di dominio. Entrambi i problemi portano a un overflow del buffer durante l'elaborazione di risposte DNS appositamente formulate.
Per sfruttare le vulnerabilità, un attaccante deve semplicemente inviare una risposta appositamente formattata a qualsiasi richiesta legittima inviata da un dispositivo vulnerabile, ad esempio, conducendo un attacco MITM e infiltrandosi 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 problematizzati tramite l'invio di richieste mDNS in modalità broadcast.
- La vulnerabilità nel stack di rete NetX (Azure RTOS NetX), sviluppato per ThreadX RTOS e reso pubblico nel 2019 dopo il passaggio a Microsoft, ha comportato un attacco di negazione di servizio. 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à relative alla compressione di dati ripetuti nei messaggi DNS, si segnalano i progetti lwIP, Nut/Net, Zephyr, 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 implementano questa operazione senza errori. Inoltre, si fa notare che in precedenza gli stessi ricercatori avevano già identificato vulnerabilità simili negli stack Treck, uIP e PicoTCP.
Fonte: opennet.ru
