Sfide...

Correva il 2004..

Mi chiama un mio conoscente e mi chiede:"Senti, ma te le fai ancora quelle robe lì che cracchi le reti per vedere se sono sicure?" - "Per farlo lo farei anche, ma non gratis" - "Ah, bene..senti: c'è un mio amico che ha il suo capo convinto che gli stiano spiando i server..." - "Ok, ho capito. Lasciami il numero che li richiamo io domani..."
Fu il mio ultimo penetration test da libero professionista.
Da quel 2004 ad oggi non è che non mi sia più capitato di fare ancora attività "hands on", per lavoro o svago, ma si è sempre trattato di qualche rapida analisi "spot" di una applicazione, magari di un po' di sandboxing su qualche malware sample prelevato dal pc di un collega, ma nulla di più.
Son rimasto praticamente 15 anni senza mai provare seriamente a "rootare" un server.
Qualche mese fa, dopo una conferenza a cui ho partecipato ed in cui era presente uno dei più abili redteamers italiani, mi si è ficcato in testa un pensiero: ma io sarei stato ancora in grado?
E' stata la volontà di rispondere a questa domanda a spingermi ad entrare su Hack the Box.
Sono sincero: il challenge d'ingresso iniziale l'ho superato andandomi a cercare la soluzione su Google. E non penso affatto di "aver barato". Non esiste un solo motivo per cui un pentester non dovrebbe andare a cercare ogni possibile soluzione al suo problema, eventualmente anche su youtube. L'abilità di un penetration tester non sta solo nella sua conoscenza di eventuali tecniche "esoteriche". La vera abilità sta nel "pensare fuori dagli schemi" al fine di ottenere il risultato ricercato. Alla fine, anche sapere usare bene Google è una abilità.
Fatto sta che sono entrato e, per la prima volta dopo 15 anni, ho lanciato nmap contro un server ignoto con l'obiettivo di rootarlo.
La faccio breve: il server era facile, le vulnerabilità erano evidenti ed in capo a 3 giorni avevo catturato il flag user. Altri 3 giorni ed avrei rootato la macchina.
Considerato che lavoro, ho una famiglia e quant'altro, mi son potuto dedicare alla cosa solamente la sera dopo cena ed un po' nel pomeriggio di una domenica, credo di essermela cavata bene...
La prima sensazione che ho avuto, dopo tutto questo tempo, è che siano fondamentalmente solo cambiati i tool, per cui tante cose che prima ti dovevi scriptare da solo sono ora già belle e pronte in kali o su github, ma per il resto il processo è esattamente lo stesso di 15 anni fa:

• initial enumeration - fingerprinting (la prima analisi)
• exploit (remote command execution - blind shell)
• low priv shell (foothold)
• privilege escalation
• rooting/exfiltration

Ciò che è cambiato davvero tanto è la sicurezza dei sistemi Windows.
Son sincero: fino a 15 anni fa un server Windows da testare era quasi una garanzia di penetrazione.
Oggi i Windows è decisamente molto più robusto "out of the box" rispetto ad una qualsiasi distro linux.
Ma c'è anche un'altra cosa, che è cambiata: la mia "brainspeed". Se fino ad una quindicina di anni fa il mio cervello "macinava" a ritmi vertiginosi e necessitava di ben poco riposo, oggi il confronto con certi "ragazzini terribili" è impietoso.
Io impiego un paio d'ore ad individuare un vettore di attacco promettente, poi magari ancora una per testare un exploit e guadagnare l'accesso...poi ancora due o tre ore per trovare una vulnerabilità che mi apra la "privesc", altre due orette per capire l'exploit e provare a "rootare"...e nel mezzo metteteci pranzi, cene, sonno notturno, pennichelle, lavoro, bambini, moglie...poi vado sulla pagina descrittiva per postare l'hash che certifica il mio successo nella compromissione del sistema e scopro che il "guru" di turno ha guadagnato il "blood" (il primo "hack vincente") in 15 minuti dal rilascio della macchina.
Poi magari vado sui forum di HTB e leggo di gente che la stessa macchina la ripete più e più volte nella stessa giornata per trovare e provare sempre nuovi vettori di attacco...
Detto ciò, posso dire anche che per me la cosa era ampiamente prevedibile, e non mi turba minimamente. Solo un fulminato (o un genio) può pensare a 46 anni di mettersi in competizione con persone di 20 o 30 anni più giovani di lui e sperare di "vincere".
Sono invece rimasto sorpreso del contrario. Alla fine della fiera, le mie "performances" non sono affatto disprezzabili.
Nella classifica di HTB riesco a mantenermi nella top 100 a livello nazionale e comunque "galleggio" tra i primi 1000 a livello mondiale.
Ma non è questo che mi gratifica di più.
Quello che mi gratifica di più è scoprire che ho sempre la stessa passione ed interesse per il "giocattolo", che ancora riesco ad imparare, imparare, imparare.
Che questo mondo, che oggi viene chiamato "cybersecurity", ma che ai miei tempi si chiamava semplicemente "hacking", c'è ancora tanto spazio anche per un nerd un po' "arruginito" come me.
E che, in ogni caso, se quasi ogni giorno nel mio inbox trovo dei messaggi da ragazzini indiani o neozelandesi che mi chiedono consigli su come fare per approcciare una macchina, tutto sommato la mia competenza ha ancora valore.
E tutto ciò forse mi aiuta a capire un po' meglio come relazionarmi con l'effetto Dunning Kruger, perlomeno con la platea degli utenti di HTB...
...anche se per togliermi i dubbi in merito alla platea generale della comunità infosec mondiale ne corre...
E adesso chiudo che ho l'nmap che corre su "book"

Sandboxed malware analysis

Che titolone eh? Chiariamo da subito un concetto: il 99% delle piattaforme antivirus/antimalware si basano su due metodi di rilevamento: 

• le signatures
• l'analisi euristica.

Con le prime si va banalmente a consultare un database di hash di files o di stringhe caratteristiche per individuare una corrispondenza con un qualche pattern noto. Come funziona il tutto? Semplificando possiamo immaginare l'apparizione di un nuovo malware "in the wild" basato su un singolo eseguibile. Qualche utente sospettoso o qualche team di ricerca invia una copia dell'eseguibile "sospetto" ai centri di analisi e costoro sostanzialmente fanno due cose: calcolano l'hash del file e cercano nell'eseguibile delle stringhe. I risultati vengono ficcati nel file delle definizioni dei nostri antivirus e costituisce la "signature" del malware in questione. L'antivirus in real-time verificherà i files che entrano nel sistema e ne farà l'hashing e la ricerca di stringhe all'interno. Se troverà una corrispondenza, segnalerà l'elemento come infetto.

L'analisi euristica è un po' più sofisticata, ma meno accurata. Si basa sostanzialmente su una analisi del codice da cui cercare di "intuirne" l'esecuzione e definirne pertanto la sua "malevolenza" o meno. Si imposta normalmente una soglia per definirne l'accuratezza o, come alcuni in gergo dicono, il "paranoid level". Se il codice analizzato comporta operazioni quali la scrittura su aree di sistema, l'esecuzione da entry point non sicuri o l'attivazione di sessioni tramite protocolli noti (ad esempio irc), eccetera, allora l'antivirus segnalerà l'attività sospetta.

Fin qui tutto tranquillo, no? Beh, ad essere sinceri manca una "lieve" copertura: chi ci difende da un malware che sfrutta tecniche avanzate di evasione (Advanced Evasion Techniques)? Come fare a capire se un processo che non conosciamo è legittimo o se fa parte di una sofisticata minaccia persistente (Advanced Persistent Threat)?

Non possiamo.

Con gli strumenti di tradizionale endpoint security non è possibile intercettare questo genere di minacce.

Occorre una analisi specializzata basta su tecniche di sandboxing.

Cos'è una sandbox? Avete presente nei parchi giochi quei recinti con la sabbia dove si fanno giocare i bambini? Ecco, il paragone con l'informatica è questo: così come nelle sandbox "fisiche" si lasciano liberi i bambini di fare quello che gli pare essendo sicuri che non faranno danni, così nelle sandbox informatiche si lasciano liberi i malware di fare quello che gli pare, essendo sicuri che non faranno danni e dandoci l'opportunità di analizzarne il comportamento.

Chi dispone di un server VmWare può creare uno switch logico e qui collegare il client "tipo". Chi invece usa VmWare player dovrà configurare le schede di rete delle vm in host mode, in maniera tale da non farle interagire al di fuori del sistema.

Ma mettere in piedi una macchina virtuale da sola e lanciarci un virus mica ci permette di sapere come si comporta la minaccia. Occorre come minimo un altro sistema per l'analisi. Io uso normalmente due distro specifiche per il pentesting e l'analisi forense: REMnux, che è sostanzialmente fatta apposta per il reverse engineering dei malware e la sempre ottima Kali. A queste conviene associare alcuni elementi sulla macchina di test: 

• Un debugger per poter analizzare il processo in esecuzione (e per questo IDA o OllyDBG andranno benissimo)
• Degli strumenti per l'analisi dei process trees ed il monitoring di sistema (la suite sysinternals contiene una quantità impressionante di strumenti per la gestione ed il monitoring dei sistemi microsoft)
• Uno sniffer (e qui, ovviamente, Wireshark la fa da padrone incontrastato)
• Un buon hex editor fa comodo (Io uso PSPad)
• Un unpacker può essere utile (Qui ne trovate una buona collezione)

Una delle prime cose che è utile fare per procedere con l'analisi è CREARE UN CLEAN SNAPSHOT DELLA MACCHINA DI TEST!! So che sembra ovvio, ma credetemi: quando si viene messi sotto pressione è facile dimenticarsi di mantenere uno snapshot aggiornato e pulito da usare come base.

Solitamente, la prima cosa che si fa è attivare il Wireshark per tenere sotto controllo il traffico di rete, quindi il process explorer e process monitor di sysinternals per vedere la catena di processi che il malware andrà eventualmente attivare ed i cambiamenti al sistema che effettuerà. Se saremo fortunati, il malware andrà a scrivere qualcosa nel registro o sul filesystem per potersi attivare allo startup. In alcuni casi i malware "creano" dei processi figlio tramite la generazione dinamica di codice batch che richiama altri processi. Il motivo di tale comportamento è presto detto: un antivirus euristico che analizza un binario capisce subito se questo vuole scrivere sul registro. Ma se l'eseguibile crea un batch che a sua volta fa una push nel registro della chiave per l'autostartup, l'antivirus non lo potrà mai intercettare... Altro strumento comodo per tenere sotto controllo il registro è autoruns, sempre della sysinternals suite. Permette di visualizzare tutti i processi che vengono avviati automaticamente dal sistema, assieme agli entry point ed ai triggers. Magari il malware è un bot che fa parte di una botnet. In tal caso wireshark ci mostrerà i tentativi di contatto con il CnC (Command and Control) server. A questo punto può capitare che l'analisi diventi impossibile, perchè alcuni bot e malware capiscono di trovarsi in esecuzione su una sandbox perchè non riescono a contattare il server CnC e pertanto si mettono in "quiet mode" o, addirittura, si autoterminano. Alcuni malware molto avanzati fanno una rapida scansione del sistema prima di qualsiasi altra operazione e, se rilevano di trovarsi in un ambiente virtuale, escono dall'esecuzione immediatamente. Si tratta in ambo i casi di tecniche di evasione fatte per impedire l'analisi. In tal caso, occorrererà per forza creare una sandbox fisica se si vorrà continuare l'analisi...

Quando i malware cominciano a generare traffico di rete, è il momento di mettere in funzione i sistemi di analisi. In primo luogo garantire la name resolution: andremo quindi a configurare come dns sul client l'indirizzo della nostra macchina di analisi, dove attiveremo fakedns (in REMnux) o dnschef (in Kali) per rispondere alle richieste con l'indirizzo della macchina di analisi stessa.

Ad ogni DNS request, le macchine di analisi risponderanno con il proprio indirizzo, così da permettere alle sessioni di rete di avere un terminatore. A questo punto, in funzione dei protocolli che verranno impiegati dal client di test, si potrà cercare di capire il tipo di servizio che viene richiesto: di solito i malware comunicano con l'esterno con IRC, FTP, HTTP, TFTP, SFTP, HTTPS. Ultimamente IRC viene sfruttato sempre di meno perchè la maggior parte dei firewall aziendali bloccano il traffico IRC...Una volta capito il tipo di servizio richiesto, si può cercare di rispondere con un setup..Attivare un server ftp o http per rispondere ci permetterà di scoprire che cosa il client cerca di recuperare dalla rete: a questo punto potremo provare ad andare a recuperare manualmente i componenti in giro sfruttando le richieste stesse per "popolare" il server web o ftp di ciò che il malware richiede, siano essi stringhe di comandi o parti di codice per fare altre e più complesse operazioni. Di recente mi è capitato di analizzare un malware che richiedeva, tramite varie richieste ftp ed http ad alcuni siti di personal storage in Russia, pezzi di eseguibili di altri programmi, principalmente per scattare foto dalla webcam del pc infetto, scaricare archivi di posta, cercare numeri di carte di credito o password, scattare screenshots o generare spam.

!!!ATTENZIONE!!!

La malware analysis su sandbox è una attività che comporta diversi rischi:

• Può richiedere moltissimo tempo: ci sono dei malware che apparentemente non fanno proprio nulla di nulla per ore prima di attivarsi. Altri addirittura hanno come trigger solo lo scoccare di un momento specifico e poi non vengono più eseguiti. Ecco a cosa serve avere uno snapshot aggiornato: se un malware ha come trigger l'esecuzione solo a mezzanotte del 31/12, bisognerà fare in modo che il nostro client di prova sia configurato in modo tale da avere l'orologio fissato a pochi minuti prima della mezzanotte del 31/12.
• Spesso occorre recuperare su siti "poco raccomandabili" dei pezzi di codice. Questo espone il pc al rischio di essere infettato da altri malware. E' buona norma pertanto non collegarsi con macchine o browser facilmente attaccabili. Una buona soluzione consiste nel recupero tramite wget di ciò che serve. o, più in generale, ricorrere a client testuali da riga di comando. Meno estensioni si usano meglio è.
• In alcuni casi i server remoti sono gestiti direttamente dai creatori dei malware. Meglio non attirare troppo la loro attenzione con molteplici contatti, magari anche ripetuti in un periodo di tempo breve...
• Il fatto che un malware sembri non fare nulla di nocivo non significa che ci si può giocare liberamente o "adattarselo per fare uno scherzo". Se credete di aver scoperto un nuovo malware, segnalatelo tramite le pagine di segnalazione malware dei fornitori di IT Security più noti (e.g.: McAfee Threat Center).

Buon divertimento!