Ecco un altro BWAIN, l’acronimo che usiamo per “Bug With An Impressive Name” (Bug con un nome impressionante).
Questa è l’abbreviazione che utilizziamo per tutti quei bug che si ritrovano con nomi, loghi e persino siti Web dedicati che sono accattivanti, interessanti, fantasiosi, importanti o drammatici, e talvolta anche tutto questo contemporaneamente.
Esempi classici del genere includono:
- Heartbleed. Il famigerato bug di perdita di dati lato server in OpenSSL, la libreria di cifratura utilizzata da milioni di server Web in tutto il mondo.
- Orpheus’ Lyre. Una falla nel sistema di autenticazione Kerberos utilizzato da Microsoft Windows e in vari programmi open source tra cui Samba. Questo è l’unico BWAIN che non aveva solo un logo ma anche una melodia a tema. (In realtà, nel caso in cui ve lo stiate chiedendo, si tratta di un ukulele, non di una vera lira.)
- BootHole, il bootloader Linux più popolare il cui logo mostra uno stivale con un verme che sporge da un buco sulla punta.
Questa volta stiamo parlando di NAME: WRECK, una serie di bug in qualche modo correlati nel software DNS principale utilizzato da diversi sistemi operativi.
Questo “cluster di bug” compare in uno studio pubblicato recentemente dai ricercatori di Forescout e JSOF.
Il soprannome deriva dalla parola “nome” nel DNS, combinata con il fatto che tutti i bug potrebbero teoricamente consentire a un aggressore di mandare in crash un dispositivo interessato, se non peggio.
DNS, come probabilmente sapete, è l’abbreviazione di Domain Name System, che converte nomi come nakedsecurity.sophos.com in numeri IP come 192.0.66.200 [corretto al 2021-04-13T16: 20Z].
Tecnicamente, si può eseguire uno stack di rete TCP / IP senza DNS, semplicemente facendo riferimento a ciascun dispositivo solo tramite il suo numero di rete.
Ma anche le reti di test più limitate e autonome finiscono rapidamente per richiedere un DNS e, se mai volessi collegare il tuo dispositivo o dispositivi a Internet, dovresti considerare il supporto DNS un must.
Ecco perché qualsiasi dispositivo TCP / IP e qualsiasi sistema operativo includono il codice per la cosiddetta risoluzione DNS o ricerca DNS.
Quel codice deve sapere come formulare le richieste DNS, che sono pacchetti di rete binari codificati in modo compatto specificati nell’RFC 1035 e pubblicati nel lontano 1987, quando ogni byte contava davvero.
Il codice di ricerca DNS deve anche sapere come analizzare le risposte DNS di ritorno formattate in modo simile, anche se quel codice non ha creato quei pacchetti fin dall’inizio e non sa se può fidarsi della persona che lo ha fatto.
Come probabilmente saprai già, il processo di dare un senso ai dati binari, noto anche come parsing, spesso può essere eseguito male.
Il fatto che un programma possa analizzare in modo affidabile miliardi di pacchetti ben formati senza intoppi non significa che non si comporterà male di fronte a pacchetti deliberatamente malformati che normalmente non si incontrerebbe mai.
Come recita la vecchia barzelletta: “Un penetration tester entra in un bar e dice:” 4.294.967.297 birre, per favore “, solo per vedere quanto è bravo il barista.”
Il diavolo è nei dettagli
Il report su NAME: WRECK riguarda più vulnerabilità che risalgono tutte all’anno scorso tranne una.
Fortunatamente, sono state tutte risolte (una ha già un aggiornamento da quasi un anno) ma insieme costituiscono un utile promemoria del fatto che anche nell’età moderna, i programmatori continuano a commettere errori di codifica della vecchia scuola.
Le vulnerabilità raggruppate sotto il “brand” NAME: WRECK sono state trovate in tre diversi sistemi operativi.
Due erano sistemi operativi di basso livello, spesso noti come RTOS (abbreviazione di sistemi operativi in tempo reale) dedicati ai dispositivi Internet of Things (IoT), ovvero Nucleus NET di Siemens e NetX di Microsoft.
Il terzo era FreeBSD, ampiamente utilizzato sia come sistema operativo per server mainstream che come sistema operativo per dispositivi embedded. (Come suggerisce il nome, FreeBSD è disponibile gratuitamente, come Linux, ma utilizza una licenza open source molto più semplice e liberale.)
Errori di parsing e problemi di casualità
Sei dei bug riguardavano errori di parsing, in cui i dati restituiti nelle risposte DNS venivano elaborati con noncuranza, portando all’overflow del buffer.
Alcuni di questi potrebbero essere sfruttati per far sì che il codice di ricerca DNS legga i dati dove non dovrebbe, causando un arresto anomalo o un Denial of Service) (DoS).
Altri potrebbero essere sfruttati non solo per leggere dal posto sbagliato ma anche per scrivere nel posto sbagliato, portando all’esecuzione di un codice remoto (RCE).
RCE generalmente significa che un utente malintenzionato può inserire silenziosamente malware nel tuo computer semplicemente inviando pacchetti non autorizzati, senza dover prima accedere o conoscere alcun tipo di password.
Una falla riguardava un bug del limite di loop, in cui il codice non aggiungeva byte a una stringa di testo, decideva che la stringa non era ancora piena e tornava indietro aggiungendo inutilmente zero byte più e più volte all’infinito, nella speranza che la stringa alla fine si allungasse.
L’ultimo bug era relativo a una scarsa casualità, in cui i numeri casuali una tantum aggiunti come identificatori di transazione nelle risposte DNS non erano abbastanza casuali.
Come risultato gli attaccanti possono creare delle false risposte DNS e fare DNS poisoning (avvelenamento del DNS) sulla lista delle risposte DNS conosciute conservate sul dispositivo.
Fornendo a un dispositivo Internet un elenco di nomi di server e numeri IP falsi, i criminali avrebbero potuto indurre quel device a visitare siti di impostori, sostituendo i numeri IP reali di server noti con numeri IP controllati da criminali.
I bug erano:
Come correre ai ripari?
Come spesso accade, in questo caso la cura è la patch.
Gli utenti regolari di FreeBSD avranno quasi sicuramente aggiornato i loro laptop e server ormai, e quasi certamente non c’è bisogno di preoccuparsi.
Tuttavia, se hai un dispositivo embedded basato su FreeBSD, potresti contattare il produttore del device per confermare che la patch è stata inclusa nel firmware del dispositivo attuale.
Dato l’interesse dei media per questo studio, gli sviluppatori che utilizzano Nucleus NET o NetX nei loro prodotti dovrebbero prendere in considerazione la pubblicazione di una nota per i loro clienti per comunicare loro se i loro dispositivi sono vulnerabili o meno.
I programmatori interessati al tipo di errori di codifica di basso livello che hanno portato a questi bug potrebbero voler dare un’occhiata al rapporto Forescout / JSOF, che fornisce sei esempi pratici degli errori di codifica da cercare!
Lascia un commento