~/docs/stop_DNS-hijacking

Con questo articolo vorrei portare in cattedra qualche piccola tecnica di hardening che personalmente implemento sempre su tutte le infrastrutture che gestisco. Lo scopo è quello di monitorare, gestire, bloccare (o mitigare) tutto il traffico DNS che circola sulla nostra infrastruttura per eliminare (o ridurre) il fenomeno del DNS hijacking.

One step backward

Ponendo ad esempio una classica infrastruttura di rete aziendale (che questa sia piccola o grande non fa differenza), normalmente avremmo dei server DNS all’interno del nostro perimetro i quali sono preposti a risolvere sia i nomi interni all’organizzazione sia gli indirizzi esterni.

Tipicamente, in un’infrastruttura Microsoft Active Directory, abbiamo uno (o meglio più) domain controller i quali espongono il servizio DNS: i client hanno come DNS gli IP dei DC e le query avvengono seguendo lo schema sotto riportato.

Hardening tip #1

Lato server, il primo consiglio tecnico – o per meglio dire la prima regola aurea che personalmente implemento sempre – è quella di bloccare sul firewall qualsiasi traffico verso internet che non sia esplicitamente necessario. Nel caso dei server DNS (riprendendo il nostro esempio), questi fanno relay unicamente verso 8.8.8.8 e 1.1.1.1 quindi dovrò creare delle regole ad hoc che permettano il traffico unicamente verso questi indirizzi per il protocollo DNS.

Lo so cosa state pensando: è un lavoro abnorme!
Si, lo so, credetemi, me ne rendo conto perché è un lavoro che ho fatto su di un’infrastruttura composta da 3 data center con oltre 100 server distribuiti, 40 sedi e quasi 1100 PDL. Mappare tutti i servizi presenti sui server e creare per ciascuno una regola di firewall che tenga conto di sorgente, destinazione e protocollo è lungo e complesso, sopratutto se su questi server abbiamo dei servizi terzi sviluppati da software house che spesso non tengono traccia nella loro documentazione dei traffici e dei protocolli di rete che utilizzano.
In più è da manutenere. Quindi si, è un lavoro abnorme: però è da fare. Fa parte del lavoro. Prima si fa pace con la questione, prima lo si accetta e prima si finisce!
Torniamo a noi

Digressione personale

Scenario 2 – Local hijack

Questo è uno scenario reale (e anche abbastanza comune) che mi capita di vedere.

In questo caso abbiamo una macchina (o un servizio) che interroga direttamente un DNS non appartenente alla nostra infrastruttura: probabilmente nel codice applicativo queste interrogazioni sono hardcoded.

In questo caso la query è lecita, o per meglio dire, è innocua: la stampante chiede direttamente al DNS esterno (con una certa insistenza, btw) di risolvere l’indirizzo www.zebra.com

e il DNS di Google di concerto risponde

Ma cosa accadrebbe se, ipoteticamente, un’applicazione malevola atterrata su di un client bypassasse i DNS configurati sulla scheda di rete e dirottasse tutte le query verso un DNS malevolo?

Come è facile intuire la vittima atterrerebbe sulla landing page dell’attaccante, magari con le stesse fattezze grafiche di mail.google.com, con l’unico scopo di sottrarci le credenziali di accesso.

Hardening tip #2

Il secondo consiglio che mi permetto di lasciare è quello di bloccare tutto il traffico DNS, non solo dei server ma anche dei client, se non esplicitamente indirizzato ai soli server della nostra infrastruttura.

Questa operazione è tutto sommato semplice da implementare tuttavia potrebbe essere fonte di interruzione dei servizi laddove chi implementa il codice dovesse imporre dei controlli sulla risoluzione e/o sulla raggiungibilità dei servizi, faccio un esempio reale che mi è capitato.

In passato mi sono trovato di fronte ad un PLC il quale tentava di interrogare, mediante i suoi DNS hardcoded, un host “sospetto” (qualcosa del tipo 101a.b8-d6-07.sitostrano.xyz). Andando ad analizzare il traffico mi sono reso conto che, interrogando manualmente quel DNS per quell’host, la risposta inoculata nel pacchetto di ritorno era “OK”. Bloccando le query DNS il PLC smetteva di funzionare dopo qualche minuto, proprio in concomitanza della cadenza con la quale eseguiva le query.

Successivamente, dopo essere entrato in contatto con l’assistenza, scopro che il team di sviluppo usava le query DNS per informare un host sulla rete pubblica (sitostrano.xyz) della versione (101a) equipaggiata sul quel PLC (b8-d6-07 ultimi 3 byte del MAC address).

Questo “strano modo di fare le cose” è interessante e mi porta allo scenario numero 3.

Ma prima, tornando a noi, ho voluto riportare questo episodio per sottolineare come l’azione di hardening proposta per quanto semplice ed efficace richiede sempre un controllo a priori atte ad implementare adeguate exclusion list laddove si ritenga necessario.

Monitoring

Prima di passare al terzo scenario vorrei spiegare come, in maniera semplice, monitoro le interrogazioni DNS.

La conditio sine qua non è che tutti i firewall inviino i log al syslog, nel mio caso avevo scritto due articoli dove spiegavo la mia infrastruttura ELK (primo e secondo) che uso nel quotidiano.

Successivamente eseguo una query per restituirmi tutti i log che siano indirizzati verso la porta 53 ma con una destination address diversa dall’elenco degli IP dei DNS configurati sulla mia rete.

Questa query mi elenca tutti i traffici DNS sui quali porrò la mia attenzione per le indagini quotidiane.

Scenario 3 – DNS exfiltration

Se con i primi due scenari abbiamo analizzato come con un attento monitoraggio e con una buona dose di regole di firewalling possiamo mitigare gli attacchi di local DNS hijacking, qua ci troviamo davanti a una tipologia di attacco complessa da intercettare.

Se siete arrivati fino a qui sapete come funziona un server DNS, pertanto non sto a tediarvi!

Esempio 1

Immaginiamo che abbiamo una macchina infetta sulla nostra rete che voglia inviare all’esterno, sul server dell’attaccante, le credenziali di accesso (o qualsiasi altro dato) che è riuscito a “rubare”. Il client invia una query DNS tipo 746869732d69732d6d792d736563726574.hacker.it al server della nostra infrastruttura per il dominio dell’hacker “hacker.it” dove però il nome host 746869732d69732d6d792d736563726574 da “convertire in IP” è, in realtà, la password (nel nostro caso codificata in esadecimale) o in generale il dato che si vuole esfiltrare.

Esempio 2

Altra tecnica utilizzata consiste nel far sì che la macchina infetta riceva dei comandi dall’esterno: l’host infetto invierà una richiesta TXT al DNS richiedendo il campo text dell’host comando-malevolo.hacker.it. Nel campo TXT l’hacker invierà il codice di esecuzione, il comando o le informazioni codificate alla macchina infetta. Lascio qui un video di John Hammond dove mostra una PoC che spiega benissimo la tecnica.

Hardening tip #3

È complesso, molto complesso.

Non esistono sistemi di protezione che ci possano difendere in maniera efficiente e puntuale poiché la difesa si può basare solo su dati statistici, ad esempio se notiamo all’interno della nostra infrastruttura un largo uso di query DNS verso un dominio specifico sconosciuto. Inoltre implementare la DPI avrebbe poco senso.

I miei consigli per mitigare (non bloccare) questo tipo di attacco sono:

• loggare tutto il traffico in uscita, utile quantomeno per un’analisi a posteriori
• implementare un controllo sulle connessioni in uscita se sono dirette verso IP noti per essere malevoli. Anche questa tipologia di intervento potrebbe dimostrarsi inefficiente visto che è “buona prassi” da parte dell’attaccante o usare siti compromessi per fare pivoting o creare macchine virtuali temporanee. Lascio comunque a tal proposito un articolo sul come intercettare e bloccare il traffico di rete verso IP noti.
• loggare le query e le response sui DNS della nostra infrastruttura

EOF