Man in the Middle6 con IPV6

A cura di: Antonio Sagliocca ( Team Hackerhood )

Il protocollo #IPv6, la versione dell’ “Internet Protocol” successiva alla #IPv4 sta prendendo piede ma, mentre nelle reti pubbliche viene sempre più spesso configurato ed utilizzato, in quelle interne le aziende faticano ad adottarlo.

Tale nuovo protocollo #Internet è sorto per sopperire alla diminuzione e, in futuro alla mancanza, di indirizzi IP versione IPv4 e apporta, al contempo, nuovi servizi, migliorando la configurazione e la gestione delle reti. Gli indirizzi IPv4 sono indirizzi a 32 bit (es. 192.168.1.23) e sono oltre quattro miliardi, mentre gli indirizzi IPv6 sono indirizzi più lunghi, a 128 bit (es. 2001:0db8:0000:ffff:0000:0000:0345:ffff), e ne sono pertanto possibili circa 340 trilioni di trilioni di trilioni.

Nelle reti Microsoft, da Windows Vista in poi, IPv6 è abilitato di default, tanto sui sistemi client che in quelli Server. Inoltre il protocollo IPv6 ha una priorità maggiore rispetto al protocollo precedente. Ciò significa che i computer Windows, sia in fase di avvio, che periodicamente, cercheranno prima una rete IPv6 a cui collegarsi e qualora questa non sia disponibile si collegheranno alla tradizionale IPv4. Spesso molti Amministratori di sistema lasciano abilitato di default il protocollo IPv6 sui sistemi ma non lo configurano, prediligendo quello IPv4, senza però conoscere le conseguenze, in termini di sicurezza, che ciò comporta.

Del resto, di come abusare delle reti IPv6 se ne parlava già nel 2011, quando Alex Waters dell’istituto Infosec illustrava #SLAAC (Stateless Address Auto Configuration), un attacco Man-in-the Middle che permette lo #sniffing del traffico delle macchine compromesse. Questo è un attacco di non facile implementazione, molto rumoroso e destabilizzante per la rete perché richiede alcuni pacchetti e servizi esterni per funzionare e prevede la creazione di una rete overlay IPv6 sulla IPv4 esistente, che impatta su tutti i dispositivi presenti sulla rete. Dopo SLAAC i metodi e i tool per abusare delle reti IPv6 progredirono.Diqualche anno fa il toolkit “THC-IPV6 Attack” entrato nella distribuzione Kali Linux come strumento per testare i punti deboli del protocollo IPv6 e ICMPv6, e che ha rappresentato una fonte di ispirazione per mitm6, un tool facile da configurare che attacca in modo selettivo gli host e che verrà illustrato in questo articolo.

Il problema fondamentale è che in una rete in cui il protocollo IPv6 è abilitato ma non configurato, un attaccante potrebbe agire come un router ed assegnare alla vittima un indirizzo IPv6 e soprattutto un indirizzo DNS IPv6. Peraltro, nel momento dell’avvio, ma anche ogni circa 30 minuti, i computer #windows richiederanno nella rete una configurazione IPv6. E riceveranno quella che il router dell’attaccante (che funge da server DHCPv6) fornirà loro. Sarà proprio l’indirizzo del Server DNS IPv6, assegnato alla vittima, che permetterà l’attacco, perchè l’indirizzo DNS IPv6 (controllato dall’attaccante) sarà preferito rispetto all’indirizzo DNS IPv4 e di conseguenza ogni query DNS della vittima sarà ricevuta dall’attaccante che la sfrutterà a proprio vantaggio falsificando le risposte. Grazie ad altri protocolli legittimi di Windows, poi, l’attaccante riuscirebbe ad ottenere e inoltrare l’HASH delle credenziali dell’utente (Domain User o Domain Admin) a vari servizi all’interno della rete oppure al Domain Controller tentando l’autenticazione verso #LDAPS.

Pertanto, lo sfruttamento di questa tecnica e, senza necessità di conoscere alcuna credenziale, sarà possibile per l’attaccante recuperare le informazioni di ogni utente, computer, gruppo e policy del dominio, aggiungere un oggetto utente di dominio o computer, da lui controllati, nell’ Active Directory dell’azienda target e creare le condizioni per ulteriori pericolosi e gravi attacchi, come la compromissione di macchine del dominio.

Il protocollo IPv6 attivo e non configurato nella rete aziendale espone a seri rischi. Ancora troppi Amministratori di rete non conoscono quali ne possono essere le conseguenze.

Vedremo come un attaccante presente nella rete (dipendente infedele, ospite, …) agirà come router IPv6, con funzione di server DHCPv6, rispondendo alla richiesta di configurazione di una vittima (computer windows) e assegnandole un indirizzo IPv6 e un indirizzo del Server DNS Ipv6 (che corrisponde alla macchina dell’attaccante). Questo server DNS è preferito rispetto al server DNS IPv4, quindi qualsiasi richiesta DNS proveniente dalla vittima potrà essere sfruttata a suo vantaggio. Vedremo come, sfruttando successivamente le richieste di configurazione di WPAD, sarà possibile per l’attaccante autenticarsi al servizio LDAPS e scaricare tutte le informazioni di utenti, gruppi, computer e policy del dominio. Ma vedremo anche che, a seconda dei privilegi della vittima, sarà possibile per l’attaccante creare un oggetto computer, con delega sulla macchina vittima, o addirittura un oggetto utente in Active Directory che potranno essere utilizzati per successivi gravi attacchi.

Il Laboratorio

Per illustrare l’attacco ci serviremo di un piccolo laboratorio costituito da un Domain Controller (AZIENDAX-DC con IP 10.10.10.100) configurato anche come Certification Autority e due client Windows 10 Professional (AZIENDAX-CLI1 con IP 10.10.10.10 e AZIENDAX-CLI2 con IP 10.10.10.20), tutti facenti parte del dominio AZIENDAX.LOCAL. Inoltre tutte le macchine sono aggiornate e su nessuna è stato disabilitato il firewall o Windows Defender.

1 – Spoofing DNS IPv6 – mitm6.py

Lo strumento che permette all’attaccante di agire come router si chiama mitm6, un tool facile da configurare che attacca in modo selettivo gli host, che funge da server DHCP IPv6 e che assegna gli indirizzi e il DNS IPv6 alla vittima falsificando successivamente le risposte DNS e riducendo al minimo l’impatto sul normale funzionamento della rete. Si tratta di uno script python che non richiede quasi nessuna configurazione e permette di eseguire l’attacco in pochi secondi.

Nell’immagine in basso vediamo la configurazione di un computer client in una rete con IPv6 abilitato. In assenza di un server DHCP IPv6 il computer avrà un indirizzo IPv6 che acquisisce automaticamente localmente e il server DNS della rete IPv4 (10.10.10.100).

Text

Description automatically generated

Figura1: la configurazione di rete del client di dominio AZIENDAX-CLI1 in assenza di un router IPv6 ma con IPv6 abilitato. L’indirizzo IPv6 è stato acquisito localmente dal computer.

L’attaccante avvia quindi mitm6 specificando con il parametro -d il dominio che gli interessa (aziendax.local). Il tool inizia l’ascolto sull’interfaccia primaria della macchina attaccante (con il parametro -i si potrebbe specificare un’interfaccia diversa e con -hw una specifica macchina) in attesa che i client Windows richiedano una configurazione IPv6 tramite DHCPv6. Per impostazione predefinita, ogni macchina Windows a partire da Windows Vista richiede questa configurazione.

Durante il suo funzionamento mitm6 invierà anche periodicamente dei messaggi RA (Router Advertisment) per avvisare i client che è presente una rete IPv6 e che quindi possono chiederne la configurazione. Questo in alcuni casi velocizza l’attacco ma non è necessario affinché l’attacco funzioni, è infatti possibile eseguire questo attacco anche su reti che dispongono di protezione contro l’attacco SLAAC con tecnologia tipo RA Guard.

Quindi mitm6 risponderà a tali richieste DHCPv6, assegnando alla vittima un indirizzo IPv6 (ultima riga dell’immagine in basso) e il Server DNS. Va notato che mitm6 attualmente si rivolge solo ai sistemi operativi basati su Windows, poiché altri sistemi operativi come macOS e Linux non utilizzano DHCPv6 per l’assegnazione del server DNS.

Text

Description automatically generated

Figura2: Avvio del tool mitm6, si vede l’indirizzo IPv6 acqusito dall’attaccante e l’indirizzo assegnato al client AZIENDAX-CLI1.

Dopo aver avviato il tool mitm6 il computer della vittima avrà due indirizzi IPv6 (immagine in basso), con quello assegnato da mitm6 nella parte superiore e due Server DNS, dove in alto c’è quello con indirizzo IPv6, impostato da mitm6, e controllato dal criminale, che sarà preferenziale rispetto a quello IPv4.

Faccio notare come il tempo di lease dell’indirizzo IPv6 impostato da mitm6 sia di soli 5 minuti a dimostrazione di come, cessato l’attacco, la rete torni allo stato precedente in pochi minuti.

Per evitare che le risposte DNS vengano memorizzate nella cache, tutte le risposte vengono inviate con un TTL di 100 secondi, il che assicura che la cache venga cancellata entro pochi minuti dall’uscita dallo strumento.

Inoltre mitm6 non si imposta come gateway sulla macchina della vittima e quindi gli host non tenteranno effettivamente di comunicare con gli host IPv6 al di fuori del loro segmento di rete locale o VLAN. Ciò limita l’impatto sulla rete in quanto mitm6 non tenta l’attacco su tutto il traffico nella rete, ma effettua invece uno spoofing selettivo degli host (il dominio su cui viene filtrato può essere specificato durante l’esecuzione del tool).

Text

Description automatically generated

Figura3: la configurazione di rete del computer dopo l’avvio del tool mitm6. Si può vedere l’indirizzo IPv6 e il server DNS assegnato dal tool, il tempo di lease, e soprattutto lo stesso Gateway predefinito.

Nell’immagine in basso si vedono i valori IPv6 che mitm6  ha assegnato a entrambe le macchine della rete (AZIENDAX-CLI1 e AZIENDAX-CLI2), e si leggono anche le risposte falsificate che sta restituendo a queste. Si tratta di diverse risposte a query DNS di richiesta di configurazione del servizio WPAD che i due sistemi inviano al router IPv6. La seconda parte dell’attacco sarà proprio sfruttare questo servizio legittimo di autenticazione, attivo di default, per carpire le credenziali dell’utente e inoltrarle al Domain Controller.

Graphical user interface, text, application, chat or text message

Description automatically generated

Figura4: lo stato del tool mitm6 dopo un po’ di tempo dall’avvio dell’esecuzione. Si vedono le risposte inviate dal tool alle query DNS ricevute dai client.

WPAD

Il rilevamento automatico del proxy Web (WPAD – Web Proxy Auto-Discovery) è una funzionalità di Windows, anch’essa attiva di default, il cui uso legittimo è quello di rilevare e configurare automaticamente un proxy di rete utilizzato per la connessione a Internet nelle reti aziendali. Ma da sempre è stata abusata da criminali e penetration tester.

Storicamente l’indirizzo del server che contiene il file wpad.dat (con le informazioni di configurazione) veniva risolto tramite DNS o, in mancanza di risposta, tramite protocolli di trasmissione non sicuri come il Link-Local Multicast Name Resolution (LLMNR) da parte dei computer della rete che ne avevano bisogno. Un malintenzionato, quindi, che fingeva di avere il file wpad.dat sulla sua macchina richiedeva l’ autenticazione ai computer per accedere a tale file, cosa che avveniva per impostazione predefinita senza necessità di interazione degli utenti dei computer. Ciò forniva al criminale le credenziali NTLM degli utenti e l’attaccante poteva usarle per inoltrarle e autenticarsi verso altre macchine o servizi della rete. Ma nel 2016, dopo il bollettino di Sicurezza Microsoft MS16-077 che mitigava in parte questa vulnerabilità, la posizione del file wpad.dat viene chiesta solo tramite DNS e l’autenticazione non avviene più automaticamente. Se è vero che esistono ancora sistemi che non sono patchati per il bollettino MS16-077, e quindi rimangono vulnerabili, è vero altresì che molti attacchi di inoltro delle credenziali NTLM non possono più avvenire sui sistemi aggiornati.

Entrambe le protezioni introdotte da Microsoft sono però superabili grazie a mitm6.

Infatti appena una macchina vittima riceve l’indirizzo del server DNS IPv6, inizia a richiedere, nella rete, la configurazione WPAD all’attaccante (come si vede nell’immagine in alto). Questo risponderà comunicandogli il proprio indirizzo IP, a indicare che è lui che possiede il file. Questo funziona anche se l’azienda sta già utilizzando un file wpad (in questo caso però si interrompe qualsiasi connessione ad internet).

Per superare la seconda protezione, in cui le credenziali non vengono più fornite per impostazione predefinita, alla richiesta del file wpad l’attaccante non chiederà direttamente l’autenticazione, come una volta, ma fornirà invece un file WPAD valido (ma falso, creato dall’attaccante) in cui è indicato che la macchina dell’aggressore è impostata come proxy. Pertanto quando la vittima vorrà navigare in internet, utilizzerà la macchina dell’attaccante come proxy. Questo avviene con qualsiasi browser, sia esso Firefox, Chrome o Edge, in quanto utilizzano tutti, per impostazione predefinita, la configurazione wpad. A questo punto quando il browser della vittima si collegherà al server “proxy” dell’attaccante riceverà una richiesta di autenticazione. Edge, Chrome e Firefox eseguiranno automaticamente l’autenticazione al proxy, inviando l’HASH NTLM delle credenziali dell’utente all’attaccante.

In Firefox questa impostazione può essere configurata digitando sulla barra degli indirizzi

about:config” e cercando il parametro “network.automatic-ntlm-auth.allow-proxies“.

Figura5: le opzioni del browser firefox. E’ evidenziata quella relativa all’invio automatico delle credenziali NTLM da parte del browser in caso di richiesta di autenticazione.

2 – Inoltro delle credenziali – ntlmrelayx.py

Il criminale, che a questo punto dispone dell’HASH delle credenziali dell’utente vittima, potrà inoltrarlo a diversi servizi come LDAPS, SMB o HTTP. Nel nostro attacco sfrutterà l’autenticazione verso il servizio LDAPS dopo essersi accertato che vi sia una Certification Authority nella rete. Nell’immagine in basso vediamo che l’attaccante, utilizzando una scansione nmap, trova la porta 636/tcp aperta sul Domain Controller a conferma di ciò.

Text

Description automatically generated

Figura6: l’attaccante con una scansione nmap verifica se esiste nella rete un sistema con la porta 636/tcp aperta che identifica ldaps, e quindi una certification authority. 

Per poter inoltrare le credenziali nel momento in cui mitm6 le cattura è necessario il tool ntlmrelayx che si trova nel toolkit Impacket.

L’attaccante lancerà ntlmrelayx subito dopo aver avviato mitm6. Lo lancerà con l’opzione -6 per indicare che oltre al traffico IPv4 deve anche ascoltare quello IPv6, -t per indicare il target verso cui si vuole autenticare (nel nostro caso ldaps all’indirizzo del Domain Controller), -wh per indicare il falso file wpad e con -l la directory in cui inserire tutti i file con le informazioni del dominio. Vediamo, nella foto in basso, i due comandi che saranno lanciati dal criminale.

Figura7: L’avvio dei comandi mitm6 e ntlmrelayx.

2a – Utente non privilegiato (domain user)

Dopo alcuni minuti ntlmrelayx riesce ad autenticarsi, attraverso l’inoltro delle credenziali di un domain user passate da mitm6 a ldaps. Come vediamo nell’immagine in basso, siccome l’utente a cui sono state “sniffate” le credenziali è un utente non privilegiato, quello che l’attaccante è riuscito a recuperare sono tante informazioni sul dominio che troverà nella cartella indicata con il parametro -l sul comando di ntlmrelayx (nel nostro caso “ipv6dir”).

A screenshot of a computer

Description automatically generated with medium confidence

Figura8: L’esito positivo dei comandi mitm6 e ntlmrelayx, si vede l’autenticazione al servizio ldaps e il download delle informazioni del dominio nella cartella indicata dal criminale sull’ultima riga.

Ecco le informazioni sul dominio contenute nella cartella che l’attaccante ha indicato e più in basso, il contenuto di uno dei file, quello chiamato domain_users.html.

Vediamo l’elenco degli utenti con anche l’appartenenza ai gruppi, la loro creazione, i flag, e la descrizione. Come vediamo può essere sfuggito qualcosa all’amministratore di rete sull’utente “giuseppe”.

Graphical user interface, text

Description automatically generated
Graphical user interface

Description automatically generated with medium confidence

Figure 9 e 10: Si vedono i file contenenti le informazioni sul dominio scaricate dal tool e il contenuto del file con la lista degli utenti di dominio. E anche una descrizione molto utile all’attaccante, dimenticata dall’amministratore di rete.

Poiché per impostazione predefinita, qualsiasi utente in Active Directory può creare fino a 10 account computer, l’attaccante può utilizzare le credenziali dell’utente non privilegiato per creare un oggetto computer, controllato da lui, in Active directory.

Potrà farlo utilizzando ntlmrelayx e aggiungendo l’opzione –delegate-access.

Il risultato sarà quello illustrato nell’immagine in basso. E’ stato creato un oggetto computer in Active Directory e gli sono stati concessi i diritti di delega sul computer vittima (aziendax-cli1).

Graphical user interface, text, application

Description automatically generated
Graphical user interface, text, application

Description automatically generated

Figura 11 e 12: L’attacco ha avuto successo e il criminale è riuscito ad aggiungere un oggetto computer in Active Directory.

2b – Utente privilegiato (domain admin)

Se invece le query intercettate da mitm6 fossero quelle di un domain admin, quindi di un utente privilegiato, allora senza alcun comando in più, ma semplicemente avviando insieme mitm6 e ntlmrelayx, oltre all’enumerazione del dominio, come visto sopra, ci sarà anche la creazione di un utente di dominio a completa disposizione dell’attaccante che potrà utilizzare, ad esempio, per autenticarsi ad una macchina di dominio e da lì eseguire molti successivi attacchi. Nelle immagini in basso vediamo la creazione dell’utente in Active Directory.

Graphical user interface, text

Description automatically generated
Graphical user interface, text, application

Description automatically generated

Figura 13 e 14: L’utente di cui l’attaccante ha recuperato l’HASH è un domain admin e pertanto il tool è riuscito a creare un utente di dominio in Active Directory.

Conclusioni

Abbiamo visto quanto pericoloso può essere lasciare nelle reti aziendali abilitato il protocollo IPV6 senza configurarlo. Ma poiché l’attacco che ne scaturisce è costituito da diversi componenti, esistono diverse mitigazioni da poter attuare.

  • mitm6 sfrutta il fatto che Windows richiede una configurazione IPv6 anche in ambienti solo IPv4. Disabilitare completamente IPv6 può avere effetti indesiderati sulla rete.

Se non viene utilizzato IPv6 internamente, il modo più sicuro per impedire mitm6 è bloccare il traffico DHCPv6 e i Router Advertisment (RA)  in entrata in Windows Firewall tramite i Criteri di gruppo. L’impostazione delle seguenti regole predefinite su “Blocca” anziché “Consenti” impedisce all’attacco di funzionare:

(Inbound) Core Networking – Dynamic Host Configuration Protocol for IPv6(DHCPV6-In)

(Inbound) Core Networking – Router Advertisement(ICMPv6-ln)

(Outbound) Core Networking – Dynamic Host Configuration Protocol for IPv6(DHCPV6-Out)

  • mitm6 sfrutta WPAD

Se WPAD non è in uso internamente, disabilitarlo tramite Criteri di gruppo, disabilitando il servizio WinHttpAutoProxySvc.

  • Inoltro delle credenziali a LDAPS

L’inoltro a LDAP e LDAPS può essere mitigato abilitando sia la firma LDAP (LDAP signing), la firma SMB (SMB signing) e l’associazione del canale LDAP.

  • Sfruttamento della delega basata sulle risorse

Questo è difficile da mitigare in quanto è un concetto legittimo di Kerberos. La superficie di attacco può essere ridotta assegnando gli utenti amministrativi al gruppo Utenti protetti o contrassegnandoli come account sensibili che non possono essere delegati, il che impedirà qualsiasi rappresentazione di tali utenti tramite delega.

  • Snooping DHCP (IPv4): lo snooping DHCP elimina essenzialmente i pacchetti DHCP IPv4 che non provengono da un server DHCP autorizzato. Un server DHCP autorizzato viene configurato in base alla porta di commutazione dello switch e all’indirizzo MAC del server DHCP legittimo. In altre parole, il semplice spoofing dell’indirizzo MAC da solo non equivale a poter offrire richieste DHCP. Questo potrebbe anche essere configurato in base alla VLAN.
  • Rilevamento di dispositivi non autorizzati (IPv4 e IPv6): le organizzazioni dovrebbero avere visibilità sul proprio ambiente in relazione ai nuovi dispositivi connessi. Questo non solo aiuterebbe a identificare un potenziale server DHCP falso, ma anche qualsiasi altro dispositivo sconosciuto sulla rete.

Tags:

Comments are closed