Fasi di un attacco informatico: l’Information Gathering

Si tratta di una fase di pre-attacco in cui un penetration-tester/hacker cerca di raccogliere quante più informazioni possibili sull’obiettivo che sta tentando di violare, informazioni che verranno utilizzate in seguito nella fase di analisi e sfruttamento delle vulnerabilità. Da ciò si evince che una buona Information Gathering può fare la differenza, poiché maggiore è la quantità di dati raccolti dall’attaccante durante questa fase, maggiore è la superficie d’attacco a sua disposizione (e quindi la probabilità di trovare vulnerabilità critiche).

 

Le tecniche di Information Gathering si possono dividere in due categorie:
  • tecniche di ricognizione attiva
  • tecniche di ricognizione passiva
Tecniche di ricognizione attiva: implicano che l’attaccante interagisca direttamente con il bersaglio e comprendono la scansione delle porte e dei servizi attivi, l’enumerazione di file, directory e server nascosti, ma anche il fingerprint del sistema operativo, il banner grabbing e così via. Queste tecniche richiedono una maggiore preparazione da parte di chi le esegue, poiché, oltre a lasciare tracce, possono essere rilevate e bloccate dal firewall.
Tecniche di ricognizione passiva: sfruttano siti web di terze parti e strumenti che non inviano traffico all’infrastruttura target e pertanto non generano log sui suoi server. Un tipico esempio è l’interrogazione di banche dati e/o archivi pubblicamente accessibili, dai quali estrapolare informazioni relative a domini, sottodomini, DNS e quant’altro. Il principale vantaggio della ricognizione passiva è il fatto che il bersaglio non è in grado di identificare le informazioni oggetto dell’indagine.

 

Nei prossimi post analizzerò in dettaglio alcune tecniche di Information Gathering, con uno sguardo particolare ai tools più utilizzati in questa fase, come Fierce, DirBuster e SubBrute.

Che cos’è una backdoor e come rilevarla da riga di comando

Quando un aggressore scopre una vulnerabilità in un sito, il più delle volte tenta di sfruttarla installandovi una backdoor, ossia uno script, generalmente in PHP, progettato con l’intento di garantire un accesso remoto al server anche dopo che la vulnerabilità è stata risolta.

Una backdoor può essere richiamata dal browser come una normale pagina web, e fornisce all’attaccante la possibilità di compiere diverse operazioni, tra cui visualizzare e prelevare dati sensibili, creare nuove directory e caricare altri script.

Rientrando nella definizione di malware, le backdoors non sono facilmente identificabili, poiché, una volta installate, si confondono con i file di sistema attraverso nomi apparentemente innocui e funzioni utilizzate anche dagli sviluppatori.

Qui di seguito, mostro un metodo molto utile per verificare se sul proprio server Linux è presente codice potenzialmente dannoso. Avendo accesso alla macchina remota via SSH, possiamo eseguire comandi ed avviare programmi direttamente da una shell.

Find e grep

Tramite questi due tools , si utilizza la tecnica del pattern matching su stringhe al fine di individuare i file che contengono le funzioni PHP sospette, come eval(), gzinflate(), base64_decode(), str_rot13() ecc. L’output del comando verrà inviato all’interno di /tmp/potential_malware.txt:

sshcl2

Con un qualsiasi editor di testo possiamo aprire il file per vedere se la ricerca ha dato riscontri:

sshcl5

Sfruttamento di una code injection (parte 2): dimostrazione pratica

N.B.: le informazioni contenute in questo post sono a carattere didattico e illustrativo, pertanto non mi assumo alcuna responsabilità in merito ad eventuali usi scorretti. Tutti i test sono stati effettuati in un ambiente appositamente predisposto su macchine fisiche e virtuali di mia proprietà.

Nell’esempio che segue mostrerò come lanciare un attacco client-side tramite il modulo  ausiliario HTTP JavaScript Keylogger di Metasploit, che imposta un server web in grado di comunicare con un payload .js e catturare tutto ciò che la vittima digita sulla tastiera.

Dopo aver avviato Metasploit Framework e caricato il modulo, è necessario settare alcuni parametri, come l’ip del nostro listener, la porta e l’uripath (facoltativo):
drivebypost3
Nella sua forma più semplice, il payload da incorporare utilizza la seguente sintassi:
xsspost2
Tuttavia, in uno scenario reale, è molto probabile che l’attaccante nasconda il codice dannoso per renderlo meno visibile al rilevamento umano e automatico. Tale processo prende il nome di “obfuscation” e sfrutta diverse tecniche di encoding/scrambling. Ad esempio, il codice sopra, se offuscato diventa:
xsspost33
A questo punto, non ci resta che iniettarlo nella pagina vulnerabile e vedere cosa accade sul server quando la vittima viene agganciata:
xsspost465