PillolHacking.Net

Oggi le applicazioni web dominano il panorama di Internet. Webmail, multimedia, produttività sono probabilmente le aree più interessate da questo fenomeno. Di conseguenza le applicazioni web diventano centrali nelle strategie d’attacco di hackers ed ethical-hackers.

Ma c’è un aspetto che di solito sfugge. Anche i pannelli di controllo e di amministrazione di dispositivi/sistemi sono web centrici. Probabilmente anche chi legge ha a casa un router comodamente configurabile tramite interfaccia web. E anche questi software sono vulnerabili.

In genere si pensa che i software e i computer nascosti dietro un rassicurante firewall o proxy siano al sicuro e si tende a sottovalutare i pericoli. Ma i pericoli ci sono.

I pericoli ci sono soprattutto se si sottovaluta l’impatto che possono avere certi campi-dati considerati ininfluenti ai fini della sicurezza. O non considerati affatto.

Rafael Dominguez Vega ha identificato alcuni di questi campi, ha studiato come poterli sfruttare, ha verificato la percentuale di applicazioni vulnerabili a questo tipo di attacco, e infine ha pubblicato le sue scoperte in un interessante paper intitolato “Behind enemy lines”.

Questo tipo di attacco funziona perché chi scrive i programmi non pensa che un input non generato dall’interazione di un utente sia dannoso, o meglio non pensa che un input generato automaticamente sia pericoloso (che poi è la stessa cosa però più leggibile), dimenticando quel che dice Alex Mayfield:

“Ogni volta che un ingegnere del software dice ‘nessuno si prenderà la briga di fare quella cosa’, c’è un ragazzino in Finlandia che si prenderà la briga di farla”

L’idea di base è la seguente: un hacker invia un pacchetto dati contraffatto, avvelenando un campo dal contenuto trascurabile o di cui si sottovaluta l’impatto sulla sicurezza, con un codice di attacco e lo lancia contro il bersaglio. Il dato verrà catturato dai log del pannello di controllo e scatterà non appena l’amministratore visualizzerà quelli che dovrebbero essere innocui file di registro. Condizione fondamentale per il funzionamento è che il campo deve essere visualizzato nel pannello della web application vulnerabile.

L’autore di questo studio parla di attacchi tramite SSID e DHCP, ma voglio aggiungere una mia esperienza personale con il campo HTTP referer.

• HTTP Referer Il campo HTTP referer contiene l’URL di provenienza. Se su PillolHacking.Net c’è un link a un articolo pubblicato su Repubblica.it e l’utente lo clicca, sui log di Repubblica apparirà come referer l’URL di provenienza, ovvero il riferimento a PillolHacking.Net. Creando un header HTTP con un qualche tipo di codice di attacco è possibile avvelenare i log del nemico. Qualche anno fa scoprii un bug in un CMS che permetteva di sfruttare questo bug per lanciare comandi da remoto.

• SSID Stessa cosa per il SSID. Questo è il campo di un pacchetto dati wireless (frame) che identifica il nome di una LAN wifi. Questo campo si presta ad essere manipolato con l’iniezione di codice che verrà eseguito al momento della visualizzazione nell’interfaccia di amministrazione.

• DHCP E’ il protocollo che gestisce la configurazione automatica degli host, attribuisce indirizzi IP e altri parametri (DNS, maschere di sottorete) rendendo elementare la configurazione di una LAN. Manipolando un particolare tipo di pacchetto DHCP, ovvero DHCPREQUEST, introducendo codice nel campo Hostname, è possibile ottenere lo stesso risultato dei precedenti attacchi, ovvero l’esecuzione del codice d’attacco al momento della visualizzazione nell’interfaccia web.

Naturalmente c’è in giro un exploit che mostra uno di questi bug in azione; per la precisione un attacco DHCP contro i Sagem Routers F@ST (1200/1240/1400/1400W/1500/1500-WG/2404).

Agli hacker (ethical o non ethical) ricordo quindi di non tralasciare nessun particolare che potrebbe condurre al cuore del sistema da attaccare, dietro le linee nemiche.

Segnala presso: