aprile 2022 – Rocco Sicilia

Attack Simulation, preparazione di uno scenario

26 aprile 2022 Rocco Sicilia

A seguito di specifici Security Assessment è normale che emergano vulnerabilità anche gravi per le quali, tipicamente, si suggerisce di eseguire un patching del sistema o altre azioni di mitigazione. Purtroppo va considerato che in alcune situazioni in patching non è applicabile, spesso per ragioni non tecniche. Per portare un esempio particolarmente emblematico basta far riferimento all’evoluzione dei sistemi di automazione industriale, macchine o intere linee di produzione realizzate per restare operative per decenni e che spesso presentano componenti software che, semplicemente, non si possono aggiornare perché non è mai stata rilasciata una nuova versione. In questi casi non è raro trovare sistemi operativi particolarmente datati con tutti i problemi a livello di gestione della sicurezza che questo comporta.

E’ opportuno essere pragmatici ed agire in un’attica di gestione del rischio, cosa che non significa – purtroppo – necessariamente eliminare ogni tipo di rischio. Una volta rilevata una possibile debolezza per la quale non è possibile applicare le più classiche remediation potrebbe essere utile approfondire l’analisi per cercare di stimare nel modo più preciso possibile quanto sia sfruttabile la falla ed i possibili impatti sul business del potenziale target.

Progettare e realizzare simulazioni di attacco può essere un utile strumento di verifica in quanto da la possibilità di esplorare realisticamente ciò che potrebbe avvenire e come gli eventuali sistemi di sicurezza reagirebbero a certe sollecitazioni. Inoltre, in caso di detection, l’attività è utile anche per verificare l’efficienza delle procedure di incident responce dei team operativi.

In questi giorni sto preparando uno scenario molto semplice che coinvolgerà parte del team target in qualità osservatori al fine di comprendere alcuni aspetti delle attività offensive. Vista la natura in parte didattica dell’attività ho pensato di condividere parte dello scenario ed approfittare di una delle sessioni live su Twitch per giocare un po’ con lo scenario.

Elementi base del lab

Come accennavo lo scenario è molto semplice in quanto presenta sistemi molto obsoleti che devono necessariamente esporre servizi vulnerabili. Nel caso specifico si tratta di sistemi Microsoft Windows fuori supporto e non aggiornabili che presentano le vulnerabilità note Blue Keep (CVE-2019-0708) e Ethernal Blue (CVE-2017-0144), le macchine server utilizzano proprio uno dei servizi vulnerabili in quando espongono delle share folder.

I sistemi vulnerabili sono confinati in una rete server (blue network nello schema) e sono raggiungibili solo da alcuni sistemi client che per ragioni operative devono accedere alle share dei citati server. La visibilità tra le reti è garantita da un firewall che, nella configurazione di base, non applica controlli specifici per il controllo delle minacce.

Per il lab di base utilizzo quindi i seguenti sistemi:

Virtual Machine “client” con sistema operativo Microsoft Windows 7
Virtual Machine “server” con sistema operativo Microsoft Windows 7
Virtual Machine “server” con sistema operativo Ubuntu Linux 22.04 LTS
Virtual Machine “firewall” con vAppliance Endian (v3.3.2) Community Edition

Preparazione macchina client

Il sistema client è veramente base, una semplice installazione di Windows 7 va benissimo. Le uniche configurazione della macchina sono a livello rete e gli utenti. La configurazione di rete del mio sistema è la seguente:

Nel mio lab il gateway della rete client è il Firewall che a sua volta ha un gateway per le reti esterne. In questo modo dando ai sistemi che compongono il laboratorio un DNS è possibile farli accedere alla rete internet. La configurazione rispecchia lo scenario reale.

Per quanto riguarda gli utenti l’esigenza è di avere un utente amministratore locale ed un utente non privilegiato. Nello scenario reale questo sistema sarebbe membro di un dominio Active Directory ma in questo caso ci accontentiamo della doppia utenza. E’ ovviamente previsto, in fase di attacco, l’accesso fisico al sistema con una sessione attiva dell’utente non privilegiato.

Nota a margine: il client nello scenario reale potrebbe essere una macchina Windows 7 o Windows 10. In questa sessione ci accomodiamo sul sistema operativo più datata.

Preparazione macchina server Windows

Di base si tratta di una macchina praticamente identica alla macchina client se non per la posizione nella rete (come da schema), la configurazione della share e le relative regole del firewall locale. A dire il vero nello scenario reale il firewall locale è disabilitato, quindi questa sarà la configurazione di partenza anche nel lab.

Preparazione macchina server Linux

Si tratta di un semplice ambiente LAMP basato su Ubuntu Linux e in questo scenario probabilmente non verrà utilizzato, ma visto che l’obiettivo è sfruttare il laboratorio anche per altre sessioni ha senso tenerla pronta.

Preparazione macchina Firewall

Come accennato nel mio caso ho scelto una semplice vAppliance Endian per la quale ho configurato tre zone e relative reti:

Green: corrisponde alla LAN della rete di laboratorio e su questa interfaccia è anche attiva la Management Console disponibile alla URL https://ip:10443
Blue: corrisponde al segmento SERVER della rete di laboratorio
Uplink: corrisponde alla WAN della rete di laboratorio

In configurazione di default la zone Green e la zona Blue sono in piena visibilità, quindi il sistema client potrà dialogare da subito con il sistema server e il traffico potrà essere registrato nei logs del firewall:

Preparazione macchina c&c

Come accennato anche nella live del 21 aprile (online ancora per qualche giorno) per pura comodità la macchina che utilizzeremo come c&c sarà il sistema Kali del mio lab ma, visto l’utilizzo che vogliamo farle nei primi test, va benissimo una qualsiasi macchina linux che sia in grado di ospitare un web server. Nel laboratorio utilizzerò Apache con Php e Python.

Questo sistema verrà utilizzato come una macchina già compromessa o comunque sotto il controller dell’attacker che è in grado di accedervi remotamente e comodamente via ssh.

Prima fase dell’attacco

Come anticipato lo scenario prevede un accesso fisico al sistema client da cui si dovrà poi sviluppare l’attacco. Partirei quindi da una serie di rilevamenti sul sistema di partenza per poi usare la macchina come base per una scansione mirata nella rete target.

Una delle ipotesi di partenza è che l’attacker sia ragionevolmente certo di trovare le vulnerabilità citate, il sistema di scansione dovrà quindi operare in modo chirurgico. Una volta individuati i sistemi potenzialmente vulnerabili si dovrà procedere con l’exploiting del sistema con lo scopo di creare un accesso permanente alla macchina.

Oltre alla definizione dei singoli strumenti per eseguire le azioni offensive l’obiettivo di questa prima fase è quello di costruire i tools da eseguire rapidamente sul sistema su cui si ha la possibilità di accedere fisicamente. Per verificare l’efficienza dell’operazione l’azione verrà cronometrata.

Il base ai risultati della prima fase, che in parte potremo discutere nella prossima live del 28 aprile, valuteremo le attività della seconda fase in cui coinvolgeremo il sistema c&c.

hacking

Password policies e resistenza agli attacchi

17 aprile 2022 Rocco Sicilia

Un post di riflessione in merito ai corretti (a mio parere) spunti che Paolo Perego propone in questo sui articolo. Non ripeto quello che ha scritto Paolo, leggetelo e valutate voi stessi, il suo post merita. Parto direttamente dalle sue conclusioni: dove sta la debolezza di una passphrase rispetto ad una password complessa?

Provo ad affrontare il tema dal punto di vista dell’attacker che ha ovviamente l’obiettivo di eseguire il cracking di un accesso ad un sistema o ad una applicazione. Nel post di Paolo si fa riferimento al contesto dei portali e siti web ma il tema della verifica della robustezza prescinde il contesto. Per procedere quindi con le specifiche prove utilizzo un piccolo lab composto dalla solita kali (per comodità) che farà sia da base offensiva che da target con un utente “test” per il quale ho configurato un semplice accesso SSH. Come password utilizzeremo quella proposta da Paolo: “Il colore della mia stanza è blu”.

Wordlist

Partiamo dalle basi dell’attacco ad una credenziale: il brute forcing utilizzando un elenco di parole predefinite. In questo caso i tipici dizionari presenti nei diversi tools (kali compresa) riportano tipicamente un elenco di parole, non di frasi. Una wordlist classica sarebbe quindi poco efficace verso una passphrase salvo la creazione di diverse combinazioni di words obiettivamente molto onerosa da costruire in termini di tempi di generazione e volumi di dati. Escluderei quindi questa tecnica tra quelle efficaci.

Generazione di credenziali

E’ probabilmente più funzionale tentare di generare una credenziale partendo da un dato che non ci è però dato sapere in anticipo, ovvero il fatto di essere di fronte ad una passphrase e non una password.

Se l’attacker partisse da questo assunto (cosa di per se non particolarmente realistica senza dati a supporto della tesi) potrebbe valutare l’utilizzo di varie combinazioni di parole comuni a formare una frase semplice da ricordare. Non mi stupirebbe scoprire che molti utenti, in questo scenario, potrebbero voler utilizzare delle citazioni famose o frasi che possano essere in qualche modo riferibili al sistema a cui si sta accedendo.

In tal senso un potenziale approccio potrebbe essere l’utilizzo di tools come cewl per creare una lista si parole partendo dal sito del target o da altri contenuti (es: racconti o testi comuni) per provare a costruire poi delle frasi.

Plausibile ma sicuramente non comodo e credo, anche in questo caso, poco efficace.

Un altro approccio, visto che le passphrase di base sono stringhe relativamente lunghe, è il brute force più tradizionale con calcolo delle varie combinazioni. Mettiamoci in un caso relativamente comodo dove la frase è tipicamente composta da caratteri alfabetici con degli spazi come separatori. Assumiamo anche di conoscere la lunghezza della passphrase del target, un metodo realistico in alcuni scenari di attacco è contare ad orecchio le digitazioni dell’utente. Nell’esempio di Paolo ci troviamo comunque davanti ad un frase di 32 caratteri.

Cosa succedere se proviamo a generare frasi di 32 caratteri alfabetici con crunch?

Non impossibile ma decisamente improbabile.

Crack degli hash

Qualche giorno fa ho parlato di credential stuffing. Supponiamo quindi che a causa di un Data Breach gli hash delle passphrase siano disponibili all’attacker. Ai nostalgici verrà subito in mente di utilizzare tools come John the Ripper ma di base le difficoltà saranno le stesse descritte nei precedenti due casi in quanto le tipiche modalità di utilizzo di questi tools prevedono l’impiego di wordlist o utilizzano funzioni di generazione di stringhe.

Le mie conclusioni

Ho voluto scrivere questo post per non rischiare di generare una “battaglia di opinioni”. Paolo ha proposto una riflessione corretta che ho voluto mettere alla prova con qualche esempio reale e ritengo che non vi siano motivazioni che rendano una passphrase meno sicura di una “strong password”… anzi in un certo senso la lunghezza gioca un ruolo a favore non banale.

cyber security, hacking

Cloud Security: assessment e detection [prima parte]

14 aprile 202214 aprile 2022 Rocco Sicilia

Quella che voglio fare è una prima riflessione ad “alta voce” su un tema che, per una serie di coincidenze, ho toccato in diverse occasioni negli ultimi giorni. Scrivo quindi di getto qualche pensiero e annoto pubblicamente qualche risorsa per dar seguito poi a qualche approfondimento.

Parto dallo scenario: molte aziende ed organizzazioni hanno spostato – e continuano a spostare – workload e dati in cloud sfruttando i vantaggi ed i servizi dei diversi provider ed in particolare dei tre big: AWS, Azure, GCP. Osservo due principali comportamenti: chi “sposta” ciò che fino a ieri gestiva con una Virtual Machine nella sua forma più simile, come una instance, e chi (a mio parere più saggiamente) approfitta dell’occasione per rivedere anche la forma dei propri workload e fa uso di containers, soluzioni as-a-Service per storage e basi dati, soluzioni/implementazioni serverless. Non è questa l’occasione per discutere di quale sia la strategia migliore per spostare i workload in cloud, parlatene con i vostri cloud architect che sapranno consigliarvi a dovere, il tema che voglio affrontare è come gestire la sicurezza dei dati e dei servizi una volta che li avete spostati… tema che sarebbe meglio affrontare prima di spostare i workload, giusto per non andare poi a mettere pezze.

Parto da qualche domanda che credo dovremmo porci:

Nella realizzazione del nuovo scenario sono state considerate le linee guida del provider in termini di sicurezza dei sistemi e dei dati? (Security by design)
Una volta spostati i dati ed i servizi, dobbiamo ancora preoccuparci di verificare l’esposizione a minacce? (Security Assessment e Security Test)
Come gestiamo la detection di eventuali attività sospette? Le procedure e gli strumenti che abbiamo implementato per i sistemi “on prem” sono ancora valide? E le competenze?
Come reagiamo ad eventuali incident? Abbiamo adeguato le procedure e le strategie di incident management? Ci siamo dotati di strumenti coerenti al nuovo assetto tecnologico?

Discutendo con qualche addetto ai lavori è emerso che non tutte le scelte fatte per i sistemi ospitati “tra le mura aziendali” conservino la loro validità una volta spostati e trasformati i workload. Inoltre capita frequentemente di approcciale la gestione di ciò che è in cloud adattando procedure storicamente applicate per i workload attivi presso i Data Center dell’organizzazione. E’ sicuramente vero che la gestione di alcuni aspetti va in delega al provider ma è altrettanto vero che la delega non piò essere totale: molte configurazioni degli ambienti restano a discrezione dell’organizzazione a partire dagli accessi ed i profili degli utenti, l’eventuale software che chiediamo di eseguire alle piattaforme cloud ha le stesse esigenze del software che facciamo girare all’interno del nostro (Virtual) Data Center, temi come la riservatezza e l’integrità dei dati restano in buona parte in carico al cliente della piattaforma. Per farla breve la sicurezza delle informazioni va gestita in ogni caso, cambiano probabilmente alcuni dettagli operativi ma le metodologie base non cambiano.

Ovviamente gli aspetti da considerare sono moltissimi, in questa prima riflessione volevo partire dagli argomenti che recentemente mi è capitato di affrontare: Assessment e Detection.

Security Assessment

Sul fronte dei security assessment l’esigenza è forse palese: probabilmente non ci si metterà ad eseguire scansioni delle vulnerabilità delle piattaforme cloud (o forse si, io un check lo farei comunque o quanto meno farei delle valutazioni di merito) ma indubbiamente ha senso verificare la coerenza delle configurazioni applicate in fase di attivazione dei servizi al fine di non esporre vulnerabilità logiche e by desing. Inoltre, come accennavo, è probabile che l’organizzazione debba utilizzare componenti software di terze parti o auto-prodotte all’interno della propria piattaforma cloud, questi elementi avranno le stesse esigenze di gestione e manutenzione di prima anche se sarà probabilmente un po’ più semplice agire mitigation e remediation grazie agli strumenti che i cloud provider stessi mettono a disposizione.

Nota a margine. Il tema degli strumenti di gestione o a supporto delle applicazioni in cloud non è banale, disporre di molte opzioni anche a livello di soluzioni di protection rapidamente implementabili è un indiscutibile vantaggio di gestione. Un esempio banale: un security test mette in evidenza una vulnerabilità software in una applicazione web per la quale non esiste una fix e si mitiga con una configurazione a livello di Web Application Firewall probabilmente già disponibile tra le funzionalità attivabili all’interno dell’ecosistema cloud.

Proviamo a ragionare sulla metodologia e per questa prima analisi restiamo sui classici: NIST, Security Testing and Assessment Methodologies. Il documento, che credo non abbia bisogno di presentazioni, illustra metodologia e fasi per un security assessment e ci ricorda le motivazioni per il quale ha senso condurre questo tipo di analisi:

Conferma se i sistemi sono stati opportunamente resi sicuri
Identifica eventuali requisiti di sicurezza dell’organizzazione non soddisfatti (*)
Soddisfa il requisito di eseguire una valutazione/misurazione periodica del sistema
Non sostituisce i controlli si di e la gestione della sicurezza dei sistemi

(*) Da notare che il framework parte da un assunto: che l’organizzazione abbia definito dei requisiti di sicurezza. Partiamo quindi da questo punto, abbiamo definito dei requisiti di sicurezza per ciò che stiamo implementando in cloud? Ci sono scelte e valutazioni che le organizzazione devono necessariamente eseguire in autonomia ma qualche spunto, se non sapete da dove partire, spesso viene dato proprio dai cloud provider.

Detection

Il secondo argomento parte da una domanda facile: come gestire il rilevamento dei security incident per un workload in cloud? Ovviamente rilevare l’icident è solo la scintilla di tutto ciò che riguarda poi la gestione dell’incident stesso, ma in questo momento restiamo solo sul tema della detection e, sempre per semplicità, restiamo ancora su NIST come riferimento.

A pagina 7 del documento “Framework for Improving Critical Infrastructure Cybersecurity” c’è una definizione abbastanza chiara:

NIST – Framework for Improving Critical Infrastructure Cybersecurity

Chiaramente la funzione di detection ha lo scopo di individuare eventuali eventi di interesse per la gestione della sicurezza dell’infrastruttura e dei dati da essa gestiti. Per gestire la detection dobbiamo quindi necessariamente accedere agli eventi che interessano i workload tenendo in considerazione il fatto che in molti casi non si parla più di Syslog e Windows Events. Le diverse piattaforme mettono infatti a disposizione in forme diverse gli eventi che interessano i vari servizi, di solito grazie a delle API che consentono di interrogare i sistemi oggetto di interesse.

Va anche considerato che strumenti che tipicamente vengono utilizzati dalle organizzazioni come SIEM e XDR devono disporre di opportune funzionalità per accedere a questo patrimonio di informazioni e devono anche sapere cosa farci con quei dati. Provo a chiarire il tema con un esempio: se il nostro SIEM deve analizzare i log provenienti da una istance o da un container probabilmente poco cambia rispetto a ciò che arrivava dalla virtual machine (sui container ci sarebbe di più da dire, eventualmente ne parlo in una live), ma se gli eventi sono prodotti dalla piattaforma che gestisce le nostre applicazioni in modalità serverless (es: procedure di integrazione, scripts di automazione) i nostri sistemi sono in grado di analizzare correttamente eventi di questo tipo?

Tecnologicamente è più che fattibile, è necessario tenere a mente che il passaggio di un workload in cloud richiede ancora che venga gestita la detection e che potremmo dover adeguare procedure e strumenti.

Best Practices

Nella maggior parte dei casi parliamo dei tre big player citati, ma in generale tutti i provider di servizi mettono a disposizione delle linee guida per affrontare diversi aspetti della sicurezza dei sistemi e dei dati all’interno dell’universo cloud.

In questa prima parte vorrei quindi dare un’occhiata a cosa suggeriscono a livello di best practices i tre provider di riferimento: AWS, Azure e GCP.

Inizio da AWS che aggrega in un pagina una serie di temi per i quali rimanda a diversi articoli e trainng: https://aws.amazon.com/it/architecture/security-identity-compliance/.

I titolo sono più che eloquenti. Il tema Identity e Access Management è evidentemente un argomento cruciale per una piattaforma cloud dove dovranno probabilmente accedere più utenti con credenziali di servizio per la gestione delle diverse componenti. E’ quindi opportuno proteggere opportunamente questo livello di accesso e profila correttamene gli utenti in modo da non dare privilegi elevati a chiunque.

AWS dedica inoltre uno spazio dedicato al tema della Detection dove cita una soluzione interna alla piattaforma – Security Hub – che consente di gestire alcune minacce (solitamente quelle più comuni) con delle azioni preimpostate (playbook); su questo elemento siamo già su un altro tema che in realtà ha un capitolo dedicato: le azioni di mitigation e remediation. Viene inoltre citata un’altra componente che dalla documentazione mi sembra più “core” per la funziona di detection che è GuardDuty.

Anche per Azure abbiamo a disposizione molta documentazione, devo dire tantissima ma anche molto sparsa. Ho trovato utile partire da un documento di sintesi con una top 10 di argomenti con i relativi rimandi alla documentazione dedicata: https://docs.microsoft.com/…/cloud-adoption-framework/secure/security-top-10.

Noto subito un certo allineamento di argomenti: anche Azure parte dal tema degli utenti suggerendo formazione specifica e ovviamente una corretta gestione delle profilazioni. Si fa quindi riferimento a role-base access control e identity and key management.

Su fronte della detection trovo un approccio interessante che titola “Integrate native threat detection”. In sintesi si parla di integrare le funzionalità di detection di Azure direttamente all’interno del proprio SIEM di riferimento. In questo caso si sta facendo riferimento, se comprendo bene, alle funzionalità di Microsoft Defender for Cloud, componente che vale quindi la pena di indagare meglio.

Anche per Google Cloud esiste una montagna di documentazione con una main page che raccoglie le best practice: https://cloud.google.com/security/best-practices. La struttura della documentazione di BigG è ovviamente differente rispetto ad Azure e AWS e anche in questo caso bisogna andare un po’ a caccia dei temi. Già nella main page li parla però di moltissimi aspetti tra cui il già citato tema dell’Access Management e un interessante documento che titola “Security best practice checklists”.

Sul tema Detection anche Google risponde con una propria soluzione: https://chronicle.security/. Di fatto un SIEM “cloud-native” (su questa denominazione potremmo discutere all’infinito) per le operazioni di detection and response.

Qualche conclusione non concludente

Come scrivevo l’obiettivo di questo primo post era far(mi/ci) un’idea come si stanno muovendo i big player sul fronte della gestione delle minacce in un contesto che varia rapidamente ed è sicuramente molto diverso da quello che le aziende tipicamente gestiscono internamente.

Partire dalla letteratura mi aiuta a organizzare le idee per andare poi a selezione gli argomenti da approfondire. Quindi per ora mi fermo qui e agli interessati lascio il link al mio canale Twitch dove questa sera – giovedì 14 aprile – alle 21:30 faccio una sessione di studio in cui leggiamo e chiacchieriamo a ruota libera su questo tema: https://www.twitch.tv/roccosicilia.

cyber security, hacking

La disponibilità di credenziali negli attacchi informatici

3 aprile 20223 aprile 2022 Rocco Sicilia

Anche in questo breve post resto sul tema della “recon” con un focus particolare: la ricerca e l’impiego di credenziali valide per l’attuazione di un attacco informatico. Tra le attività che l’attacker esegue, una volta mappate le tecnologie in uso dall’organizzazione terget ed i servizi esposti in rete pubblica (posta elettronica, accessi VPN, portali aziendali, ecc.), vi è la ricerca di credenziali valide per accedere ai servizi individuati.

E’ ovvio che conoscere una credenziale valida consentirebbe all’attacker di accedere a nuove informazioni se non direttamente alla rete target. E’ quindi assolutamente logico verificare se gli utenti dell’organizzazione siano già stati vittime di data breach con relativo furto di una credenziale.

A causa di una cattiva abitudine degli utenti capita ancora molto spesso che vengano utilizzare credenziali uguali o simili per accessi differenti (es: posta elettronica personale ed aziendale). Va considerato che le credenziali utilizzate in un contesto aziendale sono spesso dei veri e propri passepartout nominali che danno accesso a molte applicazioni e sistemi, compreso l’accesso VPN alla rete aziendale. Questa combinazione di fattori rende il fenomeno del “password reuse” una concreta minaccia per le organizzazioni in quanto l’attacker che entra in possesso di una credenziale proveniente da un qualsiasi data breach in cui sia stato coinvolto un membro dell’organizzazione target potrebbe trovarsi nelle condizioni di accedere a servizi dell’organizzazione stessa utilizzando la stessa identica credenziale o versioni simili di questa.

Facciamo un esempio banale. L’utente Mario Rossi utilizza come password una sequenza alfanumerica a cui aggiunge un progressivo nel passaggio da una piattaforma all’altra: asd23qwe!01, asd23qwe!02, asd23qwe!03, ecc. L’attacker che dovesse entrare in possesso di una delle password potrebbe tentare la generazione di diverse combinazioni da provare sulle varie piattaforme. Tools come crunch possono essere utilizzati per generare potenziali password utilizzando un set specifico di caratteri in modo da restringere il campo a quelli tipicamente utilizzati dalla vittima.

Esempio di generazione stringe con crunch

Il concetto è semplice: si ottiene un dizionario qualificato di password per uno specifico utente da passare poi a tools di brute forcing o a semplici scripts in grado di eseguire un test di accesso all’applicazione target. Metto a disposizione un piccolo esempio per eseguire il test in sequenza di un accesso via SSH dato un utente valido ed un dizionario di password: https://github.com/roccosicilia/sToolz/tree/master/RedTeam/BruteForce. Chi ha familiarità con il mondo del pen-testing probabilmente conosce tools come Hydra, una semplice utility che può essere istruita per eseguire tentativi di accesso anche a webform sulla base di un dizionario predefinito.

L’assunto, come detto, è di disporre di un potenziale set di credenziali valide provenienti da data breach passati. Esistono diverse fonti, assolutamente legali ed utilizzate anche in contesti di difesa, da dove è possibile raccogliere informazioni in merito a passati data breach ed eventuali credenziali trafugate. Uno dei più noti è Have I Been Pwned dove è possibile verificare la presenza di una propria credenziale in un Data Breach e, accedendo alle API, è possibile anche consultare il contenuto dei dati relativi al breach, credenziali comprese. Altri due servizi molto interessanti a mio parere sono BreachDirectory e LeakCheck (quest’ultimo è un referral link).

Su BreachDirectory vorrei organizzare un approfondimento sfruttando il piano base di rapidapi.com che mi consente di fare un paio di prove utili a comprende quanto sia fin troppo facile accedere a questa tipologia di dati.

Semplicemente accedendo dalla homr del sito al link del menu “api” si viene rediretti alla dashboard di rapidapi da dove è possibile accedere alla struttura della API ed a diversi esempi di codice utilizzabile per creare un semplice script:

Anche con competenze estremamente base in un qualsiasi linguaggio di scripting (rapidapi riporta esempi per decine di sintassi) è possibile costruire una request base per ricerche mirate o semplici automatismi per sfogliare le voci dei database a caccia di set di informazioni su più target.

Contromisure

Come accebbato tutto ha origine da un malcostume degli utenti, avendo quindi cura di utilizzare differenti credenziali per i diversi servizi a cui ci si registra la possibilità di essere vittime di credential struffing si riduce enormemente. Un altro ausilio è l’utilizzo di sistemi di autenticazione multi fattore così da non delegare alla segretezza della password la sicurezza degli accessi ai propri sistemi/servizi.

A somma di queste sane abitudini ed in considerazione del trend in crescita dei data breach potrebbe aver senso anche monitorare, tramite i servizi disponibili anche sui portali citati, la propria presenza nei database che aggregano tali informazioni.

Ho personalmente potuto osservare l’efficacia di tecniche come il credential stuffing e non è il caso di sottovalutare il fenomeno. In generale credo si sia tutti abbastanza concordi nel considerare i meccanismi di autenticazione basati sulla coppia user/password non particolarmente sicuri. È il caso di passare oltre.