Questo post è disponibile anche in: 日本語 (Giapponese)
Dannoso attori hanno utilizzato il Comando & Controllo (C2) canali di comunicazione oltre il DNS (Domain Name Service) e, in alcuni casi, hanno anche utilizzato il protocollo di sottrarre dati. Questo è al di là di ciò che una connessione “heartbeat” C2 comunicherebbe., I malintenzionati hanno anche infiltrato dati/payload dannosi nel sistema delle vittime tramite DNS e, da alcuni anni, la ricerca dell’Unità 42 ha descritto diversi tipi di abusi scoperti.
DNS è un protocollo fondamentale e fondamentale di Internet – spesso descritto come la “rubrica di internet” – mappatura dei nomi di dominio agli indirizzi IP, e molto altro, come descritto nel nucleo RFC per il protocollo. L’ubiquità del DNS (e la frequente mancanza di controllo) può consentire metodi molto eleganti e sottili per comunicare e condividere i dati, oltre le intenzioni originali del protocollo.,
Oltre agli esempi di utilizzo del DNS già menzionati, esistono una serie di strumenti che possono consentire, tra le altre cose, ai loro aggressori di creare canali segreti su DNS allo scopo di nascondere la comunicazione o bypassare le politiche messe in atto dagli amministratori di rete. Un caso d’uso popolare è quello di bypassare hotel, café ecc registrazione della connessione Wi-Fi utilizzando il DNS spesso aperto e disponibile. In particolare questi strumenti sono liberamente disponibili online in luoghi come GitHub e possono essere facili da usare. Ulteriori informazioni su questi strumenti sono disponibili nella sezione Appendice alla fine di questo rapporto.,
In questo rapporto introduciamo i tipi, i metodi e l’utilizzo dell’infiltrazione e dell’esfiltrazione dei dati basati su DNS e forniamo alcuni suggerimenti verso i meccanismi di difesa.
DNS
DNS utilizza la porta 53 che è quasi sempre aperta su sistemi, firewall e client per trasmettere query DNS. Piuttosto che il più familiare Transmission Control Protocol (TCP) queste query utilizzano User Datagram Protocol (UDP) a causa della sua bassa latenza, larghezza di banda e l’utilizzo delle risorse rispetto query TCP equivalenti., UDP non ha funzionalità di errore o controllo del flusso, né ha alcun controllo di integrità per garantire che i dati arrivino intatti.
In che modo l’uso di Internet (navigazione, app, chat, ecc.) Se la query DNS UDP fallisce (è un protocollo best-effort dopo tutto) in prima istanza, la maggior parte dei sistemi riproverà un numero di volte e solo dopo più errori, potenzialmente passare a TCP prima di riprovare; TCP viene utilizzato anche se la query DNS supera i limiti della dimensione del datagramma UDP – in genere 512 byte per DNS ma può dipendere dalle impostazioni di sistema.,
La figura 1 seguente illustra il processo di base del funzionamento del DNS: il client invia una stringa di query (ad esempio, mail.googlecom in questo caso) con un certo tipo-in genere A per un indirizzo host. Ho saltato la parte in cui i sistemi DNS intermedi potrebbero dover stabilire dove esiste”. com”, prima di scoprire dove si può trovare “googlecom” e così via.
Figura 1., Operazione DNS semplificata
Una volta che un nome viene risolto in una cache IP aiuta anche: il nome-IP risolto viene in genere memorizzato nella cache sul sistema locale (e possibilmente su server DNS intermedi) per un periodo di tempo. Le query successive per lo stesso nome dallo stesso client non lasciano il sistema locale fino alla scadenza della cache. Naturalmente, una volta noto l’indirizzo IP del servizio remoto, le applicazioni possono utilizzare tali informazioni per abilitare altri protocolli basati su TCP, come HTTP, per svolgere il loro lavoro effettivo, ad esempio assicurando che le GIF di Internet cat possano essere condivise in modo affidabile con i colleghi.,
Quindi, tutto sommato, alcune dozzine di query DNS UDP extra dalla rete di un’organizzazione sarebbero abbastanza poco appariscenti e potrebbero consentire a un payload dannoso di trasmettere a un avversario; i comandi potrebbero anche essere ricevuti all’applicazione richiedente per l’elaborazione con poca difficoltà.
Se si vuole andare in profondità su come funziona DNS – tutta la strada da voi digitando i tasti per scrivere il nome di dominio che si desidera sfogliare – quindi si prega di leggere questo articolo.,
Data Trail
Proprio come quando si naviga in Internet, sia ruotando da un risultato del motore di ricerca o accedendo direttamente a un URL del sito web, anche le query DNS lasciano una traccia. La quantità di una traccia dipende dai sistemi e dai processi coinvolti lungo il percorso, dalla query che lascia il sistema operativo, alla ricezione dell’indirizzo IP risultante.,
Concentrandosi solo sul lato server e, usando alcuni esempi di base, è possibile per i server DNS-specialmente quelli con registrazione estesa o debug abilitata – raccogliere un intero host (senza giochi di parole) di informazioni sulla richiesta e sul client che la richiede.,
Questo articolo fornisce un’idea del tipo di informazioni che possono essere ricavate dal log del server DNS; un avversario operativo ad un server riceve l’IP remoto di inviare la richiesta – anche se questo potrebbe essere l’ultimo hop o l’IP del server DNS, non l’esatta del client richiedente IP – così come la stringa di query stessa, e qualunque sia la risposta dal server.
DNS Tunneling
Ora che abbiamo una comprensione comune di DNS, come funziona in una rete, e le capacità di tracciamento lato server, cerchiamo di scavare un po ‘ più in profondità le capacità di tunneling., In questa sezione descriveremo come i beacon command and Control (C2) possono operare su DNS e come è possibile l’esfiltrazione e l’infiltrazione dei dati.
C2
Un canale C2 spesso serve a due scopi per l’avversario. In primo luogo, può agire come un beacon o heartbeat che indica che il loro payload remoto è ancora in funzione – ha ancora un heartbeat – come è beaconing-out (comunicare) al loro server.
Si potrebbe considerare l’operazione DNS di base, come mostrato in Figura 1 sopra, come un esempio di un battito cardiaco., Se l’impianto dannoso sul sistema client invia ripetutamente una query al server dell’attore attraverso l’infrastruttura DNS, l’attore potrebbe dire dai registri che un impianto è in esecuzione. Ciò che diventa difficile è distinguere tra più vittime che sono infettati con l’impianto.
Si consideri un altro esempio descritto nella Figura 2 di seguito, in cui il sistema client è compromesso da malware che sta costruendo stringhe di query dall’aspetto strano da inviare su DNS., Query come queste agiscono ancora come un battito cardiaco che indica all’avversario che il loro carico utile è ancora attivo, tuttavia forniscono anche alcuni meta-dati di base sulla vittima e, soprattutto, modi per identificare in modo univoco una vittima da un’altra.
Figura 2., Esempio Operazione di query DNS C2
I nomi utente e i nomi host potrebbero non essere sempre univoci e alcuni IP potrebbero essere duplicati su più reti utilizzando NAT (Network Address Translation), tuttavia i sistemi hanno identificatori univoci universali (UUID) o altre proprietà, che una volta combinati potrebbero creare un identificatore univoco per un determinato host o vittima.
Alcuni dei meta-dati dall’host compromesso potrebbero essere inviati come testo in chiaro, ma potrebbero apparire più sospetti a prima vista a chiunque veda tali stringhe in una query DNS., In molti casi i dati conterranno caratteri non supportati dal DNS, nel qual caso sarà richiesta la codifica. Nella Figura 2 è possibile vedere l’equivalente codificato base64 per i metadati, che viene costruito utilizzando una notazione delimitata ‘ ‘ ‘ per una semplice analisi e decodifica sul lato server, come mostrato nella Figura 3 di seguito.
Figura 3., Server-side DNS logs tracking C2 comunicazione
Figura 3 mostra un esempio di ciò che un log DNS grezzo da un’applicazione server DNS può essere simile, con voci di riga per la query del malware e la risposta del server DNS, NXDOMAIN (o dominio inesistente), in questo caso.
In qualche modo, un registro come questo, o forse un piccolo database contenente i record decodificati da loro, potrebbe essere paragonato ai pannelli di controllo botnet più sgargianti che consentono al pastore di botnet di controllare i loro sistemi di vittime zombie.
Exfiltration
Quindi, cos’altro potrebbe essere inviato nelle query DNS?, Bene, qualsiasi cosa in teoria, purché sia codificata correttamente e non abusi dei limiti di dimensione UDP. Un modo per aggirare quest’ultimo vincolo potrebbe essere quello di inviare più messaggi di record e averli cuciti insieme in qualche modo sul lato server. Le complicazioni si presenterebbero tuttavia in datagrammi caduti o mancanti.
A differenza di TCP che garantisce la ritrasmissione di pacchetti falliti, UDP non ha tale meccanismo., Sarebbe necessario un algoritmo per capire quanti messaggi verranno inviati e controllare che arrivi il numero corretto, ma più complicato di così, in qualche modo chiedere al client di ritrasmettere di nuovo determinati segmenti dei dati fino all’arrivo del 100%. A seconda della quantità di dati da trasmettere – ogni PDF sul sistema, per esempio – può prendere un’età, e guardare estremamente sospetto agli amministratori di rete.,
Infiltrazione
Al contrario, l’infiltrazione dei dati sia che si tratti di codice, comandi o un file binario da scaricare su disco ed eseguire potrebbe essere molto più semplice, specialmente usando il tipo DNS di TXT (al contrario del record host di tipo A). I tipi TXT sono stati progettati per fornire testo descrittivo, come i dettagli del servizio, i nomi dei contatti, i numeri di telefono, ecc.
Indovina cosa sembra piace il testo? Dati non testuali codificati Base64!, La figura 4 seguente mostra la query identica inviata al sito dannoso come in Figura 2, tuttavia, il tipo è ora TXT sia sulla richiesta che sulla risposta e i dati di risposta contengono i primi 300 caratteri di un file eseguibile binario codificato che potrebbe essere eseguito dal malware client. Ancora una volta, usando i log, l’avversario sarebbe in grado di sapere quale client ha chiesto il payload e che il payload è stato inviato (chissà se è effettivamente arrivato…).
Figura 4., Esempio Query DNS C2 con risposta di tipo TXT
Ma come fa l’impianto dannoso a sapere di cambiare il tipo in TXT o quando richiedere ciò che si trova all’interno dei dati “di testo”? Potrebbe essere integrato nel payload per interrogare ad un certo punto della sua esecuzione o dopo un certo periodo di tempo, ma in realtà, sarà guidato dall’attore usando il secondo scopo di un controllo del canale C2.
Nei miei precedenti esempi di comunicazione DNS C2 la risposta dal server DNS era NXDOMAIN., Questo messaggio ovviamente raggiunge il sistema client (e il malware) e potrebbe essere utilizzato un messaggio o un’istruzione per il payload, ma è limitante senza parametri e dettagli. Inserisci NOERROR.
NOERROR, come suggerisce il termine, significa che tutto ha funzionato bene-la tua richiesta è stata elaborata e una risposta ti aspetta. Con un NOERROR arriva una risposta che può essere elaborata. Di solito questo è l’IPv4 (per le richieste di tipo A) o IPv6 (per le richieste di tipo AAAA) o potrebbe essere TXT, come mostrato in Figura 4 sopra., Concentrandosi su un semplice esempio-la risposta all’indirizzo IPv4 – il malware non ha bisogno di un IP reale con cui comunicare, a differenza del tuo browser che ha chiesto ” dov’è googlecom?”. Il malware è già in comunicazione con la sua destinazione utilizzando il C2 su DNS.
Ciò per cui il malware può utilizzare la risposta IP è uno qualsiasi dei 4.294.967.296 possibili comandi o istruzioni. Ancora una volta, mantenendo questo molto semplice ancora, è possibile che un particolare valore nel 4 ° ottetto dell’IP, diciamo, 100, indicherebbe al malware di inviare una query DNS TXT al dominio dell’attore per raccogliere ed eseguire un payload., Il valore 10 nel primo ottetto potrebbe significare disinstallare e cancellare le tracce del payload dannoso dal sistema operativo e dai registri eventi. Letteralmente, le opzioni sono infinite, così come i livelli di possibile sofisticazione.
Dato che l’avversario ha il controllo sul server DNS e che alcune applicazioni o demoni del server DNS sono altamente configurabili, è possibile inviare risposte condizionali al malware sui sistemi delle vittime in base alle richieste inviate da loro.,
Ad esempio, se la query in entrata contiene un determinato flag – un carattere – come primo sottodominio del nome di dominio, potrebbe essere letta da un programma in esecuzione all’interno del servizio DNS sul server e fornire una risposta personalizzata al client. Questo potrebbe essere utilizzato per il malware di lavorare attraverso una serie di attività automaticamente, e riferire di conseguenza agli attori di ricevere il loro prossimo compito.
Conclusione
DNS è uno strumento molto potente utilizzato quasi ovunque che consente ad applicazioni e sistemi di cercare risorse e servizi con cui interagire., DNS fornisce una base di comunicazione che consente protocolli di livello superiore e più potenti per funzionare, ma può significare che è trascurato da un punto di vista della sicurezza, soprattutto se si considera la quantità di malware viene consegnato tramite protocolli di posta elettronica o scaricato dal web utilizzando HTTP.
Per questi motivi, DNS è la scelta perfetta per gli avversari che cercano un protocollo sempre aperto, spesso trascurato e probabilmente sottovalutato per sfruttare le comunicazioni da e verso host compromessi., Unità 42 ha visto più istanze di malware, e gli attori dietro di loro, abusando DNS per avere successo nei loro obiettivi, come discusso in questo rapporto.
Le organizzazioni possono difendersi dal tunneling DNS in molti modi diversi, sia che si utilizzi la piattaforma operativa di sicurezza di Palo Alto Networks o la tecnologia Open Source.,seguenti:
- Blocco domain-names (o IPs o di geolocalizzazione regioni) si basa sul noto, la reputazione o pericolo percepito;
- Regole “strane” DNS stringhe di query;
- Regole circa la lunghezza, il tipo o le dimensioni di entrambi in uscita o in entrata, le query DNS;
- Generale indurimento dei sistemi operativi client e comprensione per la risoluzione dei nomi capacità, come pure il loro specifico ordine di ricerca;
- Utente e/o il comportamento del sistema di web analytics che automaticamente individuare anomalie, come nuovi domini a cui si accede in particolare quando il metodo di accesso e la frequenza sono anormali.,
- Palo Alto Networks ha recentemente introdotto un nuovo servizio di sicurezza DNS focalizzato sul blocco dell’accesso a nomi di dominio dannosi.
Ulteriori informazioni possono essere trovate anche nella documentazione ATT&CK framework sul sito web di Mitre. In particolare, le seguenti tecniche si riferiscono ai concetti discussi in questa relazione.,>
Thanks to Yanhui Jia, Rongbo Shao, Yi Ren, Matt Tennis, Xin Ouyang, John Harrison and Jens Egger for their input on this report.,
Appendix: Toolkit List
| Tool Name | Description |
| dns2tcp | dns2tcp was written by Olivier Dembour and Nicolas Collignon. It is written in C and runs on Linux. The client can run on Windows. It supports KEY and TXT request types. |
| tcp-over-dns | tcp-over-dns (TCP-over-DNS) was released in 2008., Ha un server basato su Java e un client basato su Java. Funziona su Windows, Linux e Solaris. Supporta la compressione LZMA e il tunneling del traffico TCP e UDP. |
| OzymanDNS | OzymanDNS è scritto in Perl da Dan Kaminsky nel 2004. Viene utilizzato per impostare un tunnel SSH su DNS o per il trasferimento di file. Le richieste sono codificate base32 e le risposte sono record TXT codificati base64., |
| iodio | iodio è un programma di tunneling DNS rilasciato per la prima volta nel 2006 con aggiornamenti fino al 2010. È stato sviluppato da Bjorn Andersson e Erik Ekman. Iodio è scritto in C e funziona su Linux, Mac OS X, Windows e altri. Iodio è stato portato su Android. Utilizza un’interfaccia TUN o TAP sull’endpoint. |
| SplitBrain | SplitBrain è una variante di OzymanDNS., |
| DNScat-P/dnscat2 | DNScat (DNScat-P) è stato originariamente rilasciato nel 2004 e la versione più recente è stata rilasciata nel 2005. È stato scritto da Tadeusz Pietraszek. DNScat si presenta come uno strumento “Swiss-Army knife” con molti usi che coinvolgono la comunicazione bidirezionale attraverso DNS. DNScat è basato su Java e gira su sistemi Unix like. DNScat supporta un record e le richieste di record CNAME (Pietraszek, 2004)., Poiché ci sono due utility denominate DNScat, questo verrà indicato come DNScat-P in questo documento per distinguerlo dall’altro. |
| DNScapy | DNScapy è stato sviluppato da Pierre Bienaime. Utilizza Scapy per la generazione di pacchetti. DNScapy supporta il tunneling SSH su DNS incluso un proxy Socks. Può essere configurato per utilizzare i record CNAME o TXT o entrambi in modo casuale. |
| TUNS | TUNS, un tunnel IP su DNS, è stato sviluppato da Lucas Nussbaum e scritto in Ruby., Non utilizza alcun tipo di record sperimentale o raramente utilizzato. Utilizza solo record CNAME. Regola il MTU utilizzato a 140 caratteri per abbinare i dati in una richiesta DNS. TUNS può essere più difficile da rilevare, ma si tratta di un costo di prestazioni. |
| PSUDP | PSUDP è stato sviluppato da Kenton Born. Inietta i dati nelle richieste DNS esistenti modificando le lunghezze IP / UDP., Richiede a tutti gli host che partecipano alla rete segreta di inviare le loro richieste DNS a un servizio di broker che può contenere messaggi per un host specifico fino a quando una richiesta DNS proviene da quell’host. Il messaggio può quindi essere inviato nella risposta. |
| La tua libertà | HTTPS/UDP/FTP/DNS/ECHO VPN& soluzione di tunneling per Windows, Mac OSX, Linux e Android., Bypassare i proxy e accedere a Internet in modo anonimo |
| Hexify | Uno strumento è stato sviluppato da Infoblox per fare il test penetrante per il tunneling DNS., |
Appendix: Malware List
| Malware Name | Description |
| DNS_TXT_Pwnage | A backdoor capable of receiving commands and PowerShell scripts from DNS TXT queries., |
| DNSMessenger | DNSMessenger è Trojan di Accesso Remoto (RATTO) che apre una backdoor in modo che gli hacker possono controllare la macchina compromessa da remoto |
| per piattaforme petrolifere – BONDUPDATER | Trojan contro una Medio-Orientale, il governo può utilizzare Un record e record TXT all’interno della sua DNS protocollo di tunneling per la sua C2 comunicazioni |
