PingBack, il malware che si nasconde dietro un ping
#Pingback è un malware in grado di comunicare con il proprio #C2 tramite il protocollo #ICMP e evadere i controlli #antivirus grazie al fatto che la comunicazione non comporta l'utilizzo di nessunoa porta TCP o UDP.
La tecnica utilizzata per questo tipo di attacco è chiamata #Piggyback che indica la capacità di un attaccante di inserirsi in una comunicazione e sfruttare i momenti di "silenzio" per inviare i propri messaggi.
Il protocollo ICMP è di livello 3, quindi lavorando a livello IP non comporta l'utilizzo di porte che servirebbero al livello successivo e questo aumenta la sua capacità di #steathness (invisibilità rispetto ai classici antivirus).
Questo #malware quando infetta una macchina installa la dll OCI.dll utilizzata dal servizio #MSDTC (Microsoft Distribuited Transaction Coordinator) che viene caricata grazie alla famosisima tecnica Dll Search Order Hijacking (questa tecnica la ho spiegata in un'altra pillola).
In pratica per mettersi in contatto con il proprio C2 viene utilizzato il protocollo ICMP ed in particolare la Echo Request (messaggio ICMP di tipo 8) alla quale associa i sequence number 1234, 1235 e 1236. Il primo sequence number viene utilizzato per indicare che il #payload è un comando da eseguire o un dato, gli altri due vengono utilizzati come Ack.
In pratica la tecnica di Piggyback utilizzata crea un tunnel ICMP!

Pillole di #penetrationtest

MITRE Corporation, con il supporto governativo (US-CERT e la Divisione Nazionale di Sicurezza Cyber del Dipartimento di Sicurezza interna) ha definito un sistema di classificazione per le debolezze e vulnerabilità dei software, nel senso del codice sorgente, ossia osservando e classificando quegli errori introdotti durante la fase di progettazione e sviluppo che portano alle conseguenti vulnerabilità note e individuabili mediante CVE.

Questo sistema è il Common Weakness Enumeration (CWE), anche questo covernato da un sistema numerico, benché non inteso come puro ordinale.

L'intento del sistema è supportare tutti quei metodi (anche automatici) per il controllo e la prevenzione di questi errori nei software: si tratta invero di strumenti e metodi collegati all'attività di Code Review, ma da pentester dobbiamo saper maneggiare questo ulteriore sistema di classificazione quando vogliamo comunicare la fonte della vulnerabilità e supportare gli sviluppatori nella fase di soluzione. Il sistema è alla versione 3.2 dal 2019 e contiene oltre 800 categorie di debolezze e vulnerabilità software (https://cwe.mitre.org)

Prendendo spunto da alcune delle debolezze prese dalla classifica le Top25 del 2019 redatta sempre dal Mitre, possiamo portare un esempio dell'importanza del CWE nel nostro lavoro nell'individuare le cause delle più note vulnerabilità (Buffer Overflow, XSS e SQL Injection e path traversal). Lo standard indica le seguenti debolezze: CWE-119 (Impropria Limitazione delle Operazioni all'interno dei Limiti di un Buffer di Memoria - Buffer Overflow), CWE-79 (Impropria Neutralizzazione dell'Input Durante la Generazione della Pagina Web - XSS), CWE-89 (Impropria Neutralizzazione di Elementi Speciali utilizzati in un Comando SQL - SQL Injection), CWE-22 (Impropria Limitazione dei Nomi di Percorso in una Directory Specifica - Path Traversal).

Quindi, come si evince da questo breve esempio, dopo aver individuato una vulnerabilità (CVE) se da questa è deducibile un CWE, mediante questo potrà essere definita una strategia per la fase di remediation.

Pillole di #penetrationtest

Molti strumenti automatici di VA utilizzano come sistema di classificazione delle vulnerabilità lo standard CVSSv2, benché sappiamo esistere una versione CVSSv3.

La questione è complessa: da un lato abbiamo l'immenso lavoro "editoriale" che ha costituito le basi dati su cui si basano gli strumenti automatici, dall'altro alcune carenze evidenziate da molti vendors nel CVSSv2.

I rilievi hanno avuto un carattere esclusivo riguardante la valutazione del rischio che da una vulnerabilità deriva; le modifiche hanno così portato una maggiore granularità delle metriche con il fine di distinguere, ad esempio, quelle vulnerabilità che abbiano o meno bisogno di interazione utente, o che richiedano o meno un accesso fisico, oppure se una vulnerabilità possa essere alla base di movimenti laterali, ecc.

Ma il problema fondamentale per il CVSS è sempre stato l'impatto: questo infatti non può essere valutato in termini astratti (quindi collocato in basi dati universali), perché fondamentalmente questo può essere inteso solo relativamente ad una specifica organizzazione o azienda che potrebbe subire un attacco mediante una certa vulnerabilità, quindi un indicatore con carattere prevalentemente "soggettivo".

La soluzione a questo problema è stata la eliminazione (nel CVSSv3) di quelle che erano le metriche ambientali del CVSSv2 a favore di un secondo insieme di "metriche di base", noto come "vettore modificato": queste hanno ora lo scopo di adeguare il peso della vulnerabilità in ragione dell'oggetto di indagine, una sorta di "aggiustamento soggettivo" a quei parametri (di base) "oggettivi" forniti da indicatori pubblici. Allo scopo sono state inoltre aggiunte nuove metriche per indicare la rilevanza rispetto alla Riservatezza, Integrità e Disponibilità, che proprio in relazione ad un soggetto di analisi concreto hanno ragion d'essere.

Quindi, anche quando uno strumento automatico cominciasse a basare i suoi report su CVSSv3, questo "adeguamento" sarà comunque onere del pentester, così come in passato.