trycatchhcf/packetwhisperPacketWhisper: Esfiltrare furtivamente i dati e aggirare l'attribuzione utilizzando query DNS e steganografia testuale. Evita i problemi associati ai tipici metodi di esfiltrazione DNS. Trasferisci dati tra sistemi senza che i dispositivi comunicanti si connettano direttamente tra loro o a un endpoint comune. Nessuna necessità di controllare un server DNS.
PacketWhisper - Trasferisci furtivamente dati e sconfiggi l'attribuzione utilizzando query DNS e steganografia basata su testo, senza la necessità di server dei nomi o domini controllati dall'attaccante; Eludi i dispositivi DLP/MLS; Sconfiggi i controlli di whitelisting dei dati e dei server dei nomi DNS. Converti qualsiasi tipo di file (es. eseguibili, Office, Zip, immagini) in un elenco di Fully Qualified Domain Names (FQDNs), usa le query DNS per trasferire dati. Semplice ma estremamente efficace.
(Aggiornamento 27/05/2020: Sì, migrerò tutti i miei progetti Github a Python3 durante l'estate del 2020.)
Joe Gervais (TryCatchHCF)
L'esfiltrazione DNS tradizionale si basa su uno dei seguenti metodi: tunneling DNS; nascondere i dati nei campi delle query DNS; o payload codificati/cifrati che vengono suddivisi e utilizzati come sottodomini nella query DNS. Tutti questi metodi richiedono che l'attaccante controlli un dominio e/o un server dei nomi DNS associato per ricevere i dati, il che porta all'attribuzione. Questi approcci sono anche vulnerabili al blacklisting (comune) e al whitelisting (sempre più comune) dei server dei nomi DNS. Un altro problema è che gli analisti DFIR conoscono questi metodi e i sistemi SIEM spesso rilevano e segnalano la loro presenza.
PacketWhisper supera queste limitazioni.
E se i dati potessero essere trasferiti utilizzando i server DNS whitelistati del target, senza che i sistemi comunicanti si connettano mai direttamente tra loro o a un endpoint comune? Anche se il confine di rete impiegasse il whitelisting dei dati per bloccare l'esfiltrazione?
Per realizzare tutto ciò, PacketWhisper combina le query DNS con la steganografia basata su testo. Sfruttando il Cloakify Toolset, trasforma il payload in un elenco di stringhe FQDN. PacketWhisper utilizza quindi l'elenco di FQDN per creare query DNS sequenziali, trasferendo il payload attraverso (o all'interno) i confini di rete, con i dati nascosti in bella vista e senza che i due sistemi si connettano mai direttamente tra loro o a un endpoint comune. I cifrari utilizzati da PacketWhisper forniscono molteplici livelli di inganno per evitare di generare allarmi e per fuorviare i tentativi di analisi.
Per ricevere i dati, catturi il traffico di rete contenente le query DNS, utilizzando il metodo più conveniente per te. (Vedi "Catturare il file PCAP" più avanti per esempi di punti di cattura.) Quindi carichi il file PCAP catturato in PacketWhisper (in esecuzione su qualsiasi sistema sia conveniente), che estrae il payload dal file e lo Decloakifica nella sua forma originale.
DNS è un protocollo interessante da utilizzare perché, sebbene sia un mezzo relativamente lento per trasferire dati, il DNS è quasi sempre consentito attraverso i confini di rete, anche nelle reti più sensibili.
Nota importante: Stiamo usando le query DNS per trasferire i dati, non ricerche DNS riuscite. PacketWhisper non ha mai bisogno di risolvere con successo alcuna delle sue query DNS. In realtà PacketWhisper non guarda nemmeno le risposte DNS. Questo amplia i nostri casi d'uso e sottolinea il fatto che non abbiamo mai bisogno di controllare un dominio per cui stiamo eseguendo query, né di controllare un server dei nomi DNS che gestisce le richieste DNS.
Quindi usando PacketWhisper, trasformiamo un payload che assomiglia a questo:
In un elenco di FQDN come questo:
Che PacketWhisper trasforma in query DNS che appaiono nel traffico di rete come questo:
Che catturi come file PCAP in qualsiasi punto del percorso di risoluzione DNS, e poi carichi quel PCAP nella tua copia locale di PacketWhisper per recuperare il payload:
Vedi le slide del DEF CON 26 (incluse nel progetto) della mia presentazione al Packet Hacking Village. Le slide presentano il background sull'esfiltrazione DNS, la steganografia basata su testo / Cloakify Toolset, e come PacketWhisper li combina in un metodo per trasferire dati. Ho creato appositamente le slide per essere utili da sole, quindi il background e le informazioni dovrebbero essere complete. Tuttavia puoi anche guardare il video della mia presentazione al DC26 Packet Hacking Village che fornisce un contesto aggiuntivo.
Ho incluso un file PCAP di esempio nel progetto (chiamato intelligentemente "sample.pcap") che contiene payload separati per ciascuno dei cifrari. Avrebbero potuto essere qualsiasi tipo di file, ovviamente, ma in questo caso ho trasmesso solo file di testo nel PCAP. Caricalo in PacketWhisper e provalo!
Come test rapido nel tuo ambiente, esegui PacketWhisper da una VM, poi invia un file mentre effettui una cattura di pacchetti sull'interfaccia di rete della VM tramite il sistema host. Puoi quindi caricare il file PCAP in qualsiasi istanza di PacketWhisper sia conveniente per decodificare il file. Ricorda solo che non è un trasferimento veloce. File più piccoli e pazienza sono tuoi amici.
Domanda: "Perché non hai usato Scapy o il toolset dnspython?"
Risposta: Odio le dipendenze di progetto nei miei strumenti operativi. Mantengo i miei progetti il più atomici e autonomi possibile per la massima affidabilità, specialmente lato client dove potrei non controllare l'ambiente e/o avere privilegi minimi. Con la struttura di PacketWhisper, posso farlo funzionare su un host shell limitato semplicemente comprimendo il progetto ed estraendolo sull'host di destinazione.
Domanda: "Perché PacketWhisper non è un fork del Cloakify Toolset?"
Risposta: Stessa risposta di sopra. Abbiamo bisogno solo di un sottinsieme molto specifico delle capacità di Cloakify, e aggiungere tutto il resto a PacketWhisper porterebbe solo a una directory disordinata e strumenti/cifrari che PacketWhisper non può utilizzare. Poiché possiedo entrambi i progetti, prometto di sincronizzare eventuali modifiche tra i due.
$ python packetWhisper.py
I cifrari basati su FQDN consistono in 3 categorie:
Sottodomini FQDN unici e casuali
MODALITÀ DI CIFRATURA CONSIGLIATA PER LA MAGGIOR PARTE DEI CASI D'USO
Si tratta di FQDN con elementi casuali incorporati nei sottodomini. Questo aiuta a prevenire la memorizzazione nella cache DNS, consentendo anche di trasferire dati oltre i dispositivi di rete NAT che potrebbero trovarsi lungo il percorso della query DNS. Poiché l'indirizzo IP del sistema mittente non è disponibile oltre il dispositivo NAT, i sottodomini generati dal cifrario contengono elementi tag unici per aiutarci a identificare i payload di PacketWhisper nella cattura di pacchetti.
Questi cifrari imitano i formati di vari servizi che si affidano a sottodomini complessi come mezzo per identificare una sessione, un utente, contenuti memorizzati nella cache, ecc. Questo approccio aiuta le query DNS di PacketWhisper a mimetizzarsi con il resto del traffico di rete.
La prima parte del nome del sottodominio è in realtà una stringa proveniente dall'elenco del cifrario. Il resto del nome del sottodominio è randomizzato per rendere ogni FQDN unico, impedendo alla cache DNS di bloccare prematuramente il percorso della query DNS. Aggiungiamo quindi il nome di dominio. Costruiamo gli FQDN in questo modo per assomigliare ai soliti FQDN associati al dominio selezionato, per mimetizzarsi meglio con il normale traffico web osservato su qualsiasi rete.
FQDN unici ripetuti
Creati per distinguersi da tutte le altre query DNS sulla rete, ma senza alcuna randomizzazione coinvolta. Ciò significa che la cache DNS potrebbe interferire, ma come beneficio collaterale le tue query DNS saranno facili da trovare anche nella più grande raccolta di pcap multi-cliente. Questo perché gli FQDN sono endpoint insoliti, come l'elenco di "John" (alieni Red Lectroid) presso i fittizi Yoyodyne Propulsion Systems del film 'Buckaroo Banzai Across the 8th Dimension'.
FQDN di siti web comuni
Si tratta di FQDN costruiti a partire da URL di siti web comuni.
NOTA: Poiché la maggior parte degli ambienti è NAT al perimetro (rimuovendo la visibilità dell'indirizzo IP del client), questa modalità è generalmente utile solo per trasferire dati tra sistemi connessi alla stessa rete locale /24 (ad esempio, il WiFi per gli ospiti del tuo bar preferito).
Poiché i cifrari di siti web comuni hanno solo l'indirizzo IP di origine come modo per distinguere le loro query da tutte le altre query DNS simili sulla rete, PacketWhisper trasmetterà una query DNS unica di "sequenza di knock" all'inizio e alla fine del payload, che ci aiuta a individuare l'host trasmittente dal file pcap in seguito.
Esempio di FQDN: www.github.com
Una volta selezionato un cifrario, PacketWhisper codifica (Cloakifica) il payload in un elenco di stringhe FQDN secondo il cifrario desiderato. Quindi genera sequenzialmente richieste DNS per inviare i dati lungo il percorso di risoluzione DNS. PacketWhisper aggiunge un piccolo ritardo tra ciascuna query DNS, che aiuta a prevenire richieste DNS fuori ordine.
L'elemento chiave qui è ovviamente essere in grado di catturare il traffico di rete contenente le query DNS generate da PacketWhisper. Ci sono molte opzioni, poiché devi solo essere da qualche parte, ovunque, con visibilità sul percorso della query DNS.
Esempi di punti di cattura:
Usa la tua immaginazione. Qualsiasi dispositivo lungo il percorso di risoluzione DNS è un'opzione, inclusi i display a parete. "Aspetta, cosa?"
NOTA: Le connessioni VPN bloccano la visibilità tra l'host e il nodo di uscita VPN. Se il client da cui stai trasferendo ha una connessione VPN attiva, non sarai in grado di vedere alcuna query DNS a meno che tu non possa catturare a monte del nodo di uscita VPN. Anche la cattura sullo stesso sistema fallirà. Poiché molti di voi probabilmente usano VPN, se vuoi testare PacketWhisper, prova a trasmettere da una macchina virtuale (VM) ospitata e cattura il traffico sull'interfaccia di rete della VM sul sistema host.
Una volta catturato il file pcap, recupera il payload eseguendo PacketWhisper su un sistema che abbia tcpdump (incluso in Linux e MacOS) o WinDump (Windows) installato. PacketWhisper ti chiederà quale cifrario è stato utilizzato, quindi estrarrà il payload dal pcap e infine decodificherà il payload estratto con il cifrario corrispondente.
Nota importante: All'interno dello stesso PCAP, puoi trasmettere un payload per cifrario utilizzato. Un PCAP contenente più di un payload che utilizza lo stesso cifrario causerà problemi. Ad esempio, il mio file 'example.pcap' fornito contiene 5 payload, uno per ciascuno dei cifrari operativi attualmente disponibili. Se uno dei payload avesse utilizzato lo stesso cifrario di un altro, PacketWhisper non riuscirebbe a estrarre nessuno dei due. La soluzione semplice è suddividere il file PCAP (è per questo che il codice di trasmissione di PacketWhisper stampa la data-ora UTC all'inizio e alla fine della trasmissione). Sto lavorando per permettere più payload con lo stesso cifrario, la soluzione è già pronta, devo solo trovare il tempo per implementarla.
Assicurati che il tuo file PCAP sia effettivamente in formato PCAP. Se hai usato tcpdump o WinDump per catturare il file, sarai a posto. Wireshark offre tuttavia un'ampia varietà di opzioni "Salva con nome..." per salvare il traffico di Wireshark, solo una delle quali è effettivamente compatibile con tcpdump/PCAP. Sto lavorando a una migliore segnalazione degli errori per aiutare a individuare gli errori in anticipo.
Non è uno schema di crittografia sicuro. PacketWhisper non è uno schema di crittografia sicuro. È vulnerabile agli attacchi di analisi delle frequenze. Usa la categoria di cifrari 'Sottodomini FQDN unici e casuali' per aggiungere entropia e attenuare gli attacchi di analisi delle frequenze. Se è richiesta la segretezza del payload, assicurati di crittografare il payload prima di utilizzare PacketWhisper per elaborarlo.
Non è un metodo di trasferimento ad alta larghezza di banda. PacketWhisper si basa su query DNS, che sono basate su UDP, il che significa che l'ordine di consegna (o anche la consegna riuscita) della richiesta non è garantito. PacketWhisper per impostazione predefinita aggiunge un piccolo ritardo (1/2 secondo) tra ciascuna query DNS. Puoi trasferire in sicurezza payload a una velocità di circa 7,2K all'ora (120 byte al minuto). Questo si basa sulla dimensione del payload originale, non sul file di output Cloakificato. Puoi optare per nessun ritardo tra le query, il che accelera drasticamente il trasferimento ma a rischio di un aumento del rumore di rete e di payload corrotti.
E ammettiamolo, se disponi di modalità di trasferimento dati non DNS, puoi semplicemente usare il progetto principale Cloakify Toolset per nascondere il file in bella vista (magari trasformare il payload in un elenco di mostri di PokemonGo con coordinate LatLon) e utilizzare tutta l'alta larghezza di banda disponibile tramite FTP/HTTP/ecc. Il DNS è estremamente utile quando altri protocolli sono bloccati, ma sii sempre consapevole delle tue opzioni.
DNS è DNS. Diversi sistemi operativi hanno diverse politiche di caching DNS, ecc. Le reti potrebbero essere giù, isolate, ecc. PacketWhisper include un rapido controllo manuale per vedere se può risolvere FQDN comuni, ma il DNS è spesso un business disordinato. Ricorda il vecchio mantra di risoluzione dei problemi IT: "È sempre il DNS."
Vedi le slide del DEF CON 26 (incluse nel progetto) della mia presentazione al Packet Hacking Village. Le strategie di mitigazione sono trattate verso la fine della presentazione. Come in tutte le cose, "La sicurezza a strati" è tua amica, specialmente poiché i percorsi di risoluzione DNS coprono vaste aree di territorio al di fuori del controllo della tua organizzazione.
Aggiungerò modalità per le trasmissioni DNS broadcast locali MDNS e LLMNR. Queste sono pensate per essere utilizzate da sistemi connessi alla stessa rete locale, e elimineranno la necessità per il dispositivo di cattura di avere accesso alla Modalità Promiscua durante l'esecuzione di catture di pacchetti wifi. (Questi protocolli inviano traffico a x.y.z.255 sulla rete host, trasmettendo traffico a tutti gli altri sistemi sulla stessa rete locale.)
Aggiungerò anche più cifrari, ma per le esigenze quotidiane la raccolta attuale di cifrari è tutto ciò di cui ho mai avuto bisogno. Ne trarrai buon profitto.
Sto anche lavorando per consentire più payload che utilizzano lo stesso cifrario in un singolo file PCAP. La soluzione è già stata prototipata, ma rende il flusso di lavoro di estrazione del PCAP più brutto per l'utente. Operativamente potrebbe essere più problematico che utile. Preferisco sempre una funzionalità operativa più pulita rispetto alla complessità di un coltellino svizzero.
