cyber security, hacking

Individuazione delle vulnerabilità: attacco e difesa (prima parte)

La gestione delle vulnerabilità è ovviamente un tema ricorrente nelle organizzazione che devono governare infrastrutture IT/OT/IoT dal punto di vista della sicurezza cibernetica. Tutte le componenti, tecnologiche e non, di una organizzazione sono di fatto potenziali target per attacchi atti a raccogliere informazioni o compromettere i sistemi, cosa che, nei contesti di produzione, metto a rischio il funzionamento dell’organizzazione ed in alcuni casi il prodotto stesso (gli smart device sono l’esempio più ovvio).

Negli ultimi giorni ho avuto modo di illustrare alcuni step di attacco ad un collega “temporaneo” (abbiamo “a bordo” un ragazzo in alternanza scuola lavoro con una sincera passione per la tecnologia e la cyber security) e nelle chiacchierate è emerso un elemento che ho visto spesso anche in molti menbri degli uffici IT, compreso il management: di fronte ad un nutrito set di bug e vulnerabilità individuate tramite una o più fonti – non sempre grazie ad una metodologia di gestione del rilevamento delle stesse – si tende al disordine: l’assenza di una procedura definita per la gestione delle vulnerabilità lascia spazio alla propria interpretazione / percezione del rischio e l’organizzazione, se reagisce, lo fa in modo disorganizzato.

Inevitabilmente si tende a correre ai ripari per quanto riguarda le vulnerabilità che sembrano essere quelle più critiche a prescindere dal contesto. E’ vero che le vulnerabilità che consentono lo sviluppo di un attacco diretto sono estremamente pericolose in quanto più semplici — di solito — da sfruttare, ma la contestualizzazione della vulnerabilità può cambiarne sensibilmente il rischio correlato: esporre un sistema con evidenti vulnerabilità che consentono l’esecuzione di codice da remoto (Remote Code Execution) è ovviamente un elemento che rende il target estremamente appetibile, ma se il contesto presenta uno strumento di filtering in grado di riconoscere e bloccare i tentativi di exploiting (come IDP/IPS a livello firewall o un sistema di anti-exploiting a bordo del server) le probabilità che la vulnerabilità sia sfruttabile si riducono enormemente.

Attenzione: si riducono, non svaniscono.

E’ necessario poter correlare una vulnerabilità ad un asset e di quell’asset dobbiamo conoscere il contesto operativo e l’impatto sul business dell’organizzazione.

Dobbiamo necessariamente fare i conti con la realtà ed accettare che non tutte le organizzazioni hanno modo di costruire in tempi rapidi una mappa dei business impact legati agli asset. Inoltre, come accennato, non tutti dispongono di procedure di gestione delle vulnerabilità. Il modello che vorrei quindi proporre in questa mini serie – ed è anche la tesi discussa con il giovanissimo collega – è di approcciare la cosa per gradi mettendoci nella situazione peggiore ma spesso reale di non disporre di un database degli asset e delle loro caratteristiche.

Nota: lo scenario non è in alcun modo da considerarsi sostitutivo alla predisposizione di un processo di asset management e relativi strumenti di gestione. L’obiettivo dell’articolo è ragionare assieme.

Come spesso scrivo nei post e racconto sia nei podcast che di persona, l’approccio dell’attacker è metodico e prevede la qualifica del target per comprendere se esiste una reale convenienza nello sferrare un attacco: costruire un’azione offensiva a scopo estorsione per colpire un piccolo studio professionale è molto diverso rispetto a ciò che comporta la progettazione dello stesso attacco con target una multi nazionale. Cambiano le economie dell’impresa (d’attacco), la possibile revenue, i tempi di realizzazione, ecc. Il modello prevede quindi l’analisi costo/benefici al fine di individuare un target appetibile.

Esistono diversi metodi per individuare target appetibili, uno di questi è legato alle tecnologie in uso dalle organizzazioni. Come avvenuto per recenti attacchi che hanno coinvolto migliaia di organizzazioni, l’attacker può utilizzare una falla nota presente in sistemi e piattaforme largamente utilizzate per costruire campagne di attacco anche massive ma con un vettore molto specifico.

In poche parole si tratta di analizzare le vulnerabilità note di tecnologie che il target utilizza a caccia della falla che potrebbe consentire un accesso ai sistemi in modo relativamente semplice. Ovviamente la quantità di vulnerabilità su cui eseguire questa analisi è enorme ed esistono database utilizzabili sia a fini offensivi che difensivi: di base dobbiamo acquisire un’informazione in relazione alla presenza di tecnologia, all’interno dell’organizzazione, che può essere sfruttata per un attacco informatico.

Esistono meravigliosi tools per verificare se parte del vostro asset presenta delle vulnerabilità critiche: se avete implementato una procedura di Patch Management e/o Vulnerability Management probabilmente subito dopo vi siete dotati di una soluzione software che vi aiuti a governare tale procedure; se avete acquisito la soluzione software ma non avete una procedura ufficiale per la gestione di questi processi, avete un problema di governance e vi suggerisco di affrontarlo rapidamente per non vanificare l’investimento fatto.

Visto che in questa sede parliamo di metodologia e non di tools (per i quali farete le vostre valutazioni) vediamo come possiamo entrare in possesso delle informazioni minime che ci servono per valutare se esiste un reale rischio per la sicurezza dell’organizzazione (se la vediamo dal punto di vista del team che deve difendere l’organizzazione) o una opportunità di business (se la vediamo dal punto di vista dell’attacker). Gli ingredienti sono:

  • elenco asset / tecnologie in uso presso il target
  • elenco vulnerabilità in riferimento alle tecnologie in uso
  • contesto di utilizzo della tecnologia vulnerabile

Partiamo leggeri, non censiamo subito gli asset ma preoccupiamoci almeno delle tecnologie in suo. Esiste una convenzione che ci aiuta a definire, in modo univoco, la tecnologia che stiamo utilizzando: si chiama CPE (Common Platform Enumeration). Senza dilungarmi troppo (di seguito qualche link per documentarvi) si tratta di un metodo standard per identificare uno specifico vendor/prodotto/versione/ecc…

Pagina dedicata di wikipedia: https://en.wikipedia.org/wiki/Common_Platform_Enumeration
Mitre specification: https://cpe.mitre.org/specification/

Un primo step potrebbe essere quindi quello di censire i CPE di riferimento per le tecnologie in uso nella nostra organizzazione: se utilizziamo una specifica versione di Microsoft Windows Vista, ma non ricordiamo esattamente l’update o altri parametri di dettaglio, potremmo annotare nella lista il CPE più generico:

cpe:2.3:o:microsoft:windows_vista:6.0:*:*:*:*:*:*:*

Ovviamente questo elenco dovrà essere mantenuto aggiornato, quindi la versione alpha della procedura di inventory delle CPE dovrà prevedere che ogni nuova tecnologia introdotta/individuata nell’organizzazione dovrà essere censita in questa repository.

Una volta gestito questo patrimonio di informazioni (utile per fare una montagna di altre attività virtuose) nel modo più automatizzato ed efficiente possibile, possiamo andare ad analizzare un altro dataset interessante ben più noto dei CPE, ovvero i CVE: Common Vulnerability Enumeration. Esistono diversi siti ed organizzazioni che mettono a disposizione un database con l’aggregato delle CVE rilasciate per i vendor, c’è l’imbarazzo della scelta. Per questo piccolo esperimento utilizziamo una API di https://cve.circl.lu/ che consente di richiedere le ultime 30 CVE pubblicate in formato json.

Esempio di lettura delle CVE tramite API

All’interno di una CVE trovate le informazioni sulla vulnerabilità compreso lo score e le CPE vulnerabili, ovvero l’elenco delle versioni software (talvolta in combinazione con specifici hardware) che presentano la vulnerabilità.

Siamo arrivati all’epilogo di questa prima parte di “avvio” dell’argomento che sintetizzo così: chiunque sia a conoscenza di una specifica applicazione in uso all’interno dell’organizzazione può identificare un potenziale set di vulnerabilità associate. Scopo di questa mini serie è discutere assieme le metodologie per rilevare e correggere le vulnerabilità prima che siano sfruttate. Nel prossimo post discutiamo una bozza di procedura e prendiamo in considerazione alcune tecniche di rilevamento (offensive e difensive) delle vulnerabilità.

cyber security, hacking

La filiera del crimine cibernetico

Alcuni modelli di attacco risultano estremamente efficaci grazie ad una sorta di filiera nell’industria del crimine cibernetico. Esiste, ad esempio, un mercato molto attivo per quanto riguarda database ricchi di anagrafiche con relativi dati personali come indirizzi email, credenziali, profili social, ecc… dati che per essere acquisiti richiedono di per se un attacco finalizzato al furto degli stessi e spesso “monetizzato” ricattando il target di divulgare le informazioni sottratte tramite il data breach a meno che non venga corrisposta una somma in crypto valuta.

Ma l’attacker non si limita alla richiesta di riscatto che, come le statistiche riportano, potrebbe anche non andare a segno. I dati sono infatti spesso messi in vendita su diversi portali nel Dark Web e non (ormai ci sono molti siti che, con meccanismi curiosi basati su “crediti”, consento di entrare in possesso di queste informazioni) o altri metodi più immediati come famosi gruppi e canali su Telegram e simili.

Acquisire un database con credenziali di milioni di utenti è, per ovvie ragioni, un ottimo punto di partenza per l’attacker che cerca nuove vittime: in base al proprio modello di attacco potrà selezionare organizzazioni per le quali possiede informazioni utili ad eseguire azioni offensive: avere a disposizione anagrafiche spesso accompagnate da credenziali personali e/o aziendali (anche se non aggiornate) di membri di un ente o di una azienda consente infatti la progettazione di attacchi molto efficaci. Le credenziali obsolete possono comunque essere utilizzate per campagne di phishing mirate tramite cui acquisire nuove informazioni o altri dati sensibili.

In questi casi, pur avendo provveduto all’introduzione di policies atte a ridurre enormemente il rischio di accessi non autorizzati alla rete tramite credenziali trafugate, si deve far fronte a tecniche di social engineering e phishing particolarmente insidiose: non stiamo parlando della solita email truffaldina che, si spera, gli utenti hanno imparato a riconoscere ed i sistemi di Email Filtering/Security sanno segnalare come “anomala”, il phishing mirato è decisamente più subdolo in quanto le comunicazioni, che possono avvenire via email o altri mezzi, sono costruite per essere verosimili. Non è raro l’utilizzo di informazioni reperite tramite tecniche di analisi come OSInt (tema in parte raccontato in questo podcast) o ricavate da quel tesoretto di dati trafugati tramite altri data breach ed acquistati spesso a prezzi anche molto bassi.

Nota: il “valore economico” dei dati provenienti da un data breach varia in virtù di molti parametri, non ultimo l’epoca a cui risale.

La strategia di difesa deve quindi tenere in considerazione il fatto che l’attacker potrebbe agire sulla base di informazioni anche molto dettagliate sul vostro conto, sia personali che del contesto lavorativo. Per capirci riporto un banale esempio di azione offensiva che mi è capitato di realizzare in occasione di un security test (ovviamente commissionato da una organizzazione che aveva l’esigenza di misurare il proprio grado di consapevolezza) dove è stata progettata una campagna di phishing verso uno specifico gruppo di utenti in riferimento ad una verifica di sicurezza del proprio account aziendale per una applicazione terza (in cloud) il cui utilizzo era emerso grazie alle analisi OSInt (nel caso specifico i record DNS davano evidenza specifica dell’utilizzo del servizio). L’azione, nella sua senplicità, riprendeva qualcosa di estremamente noto alle vittime ed i risultati hanno consentito di misurare il livello di esposizione ad una minaccia estremamente diffusa.

Esistono infinite sfumature che possono essere utilizzate in un attacco di phishing mirato ed è relativamente semplice aggirare o eludere meccanismi di protezione. Ad esempio l’utilizzo di email regolarmente registrare con provider di tutto rispetto: è raro che un indirizzo email opportunamente formattato sia considerato una minaccia (asdfgh88@da.ru è ben diverso da franca.rossi@protonmail.com). Inoltre l’email non è certo l’unico canale per innescare un dialogo. E’ sensibilmente aumentato l’utilizzo di tecniche di impersonation finalizzate alla raccolta di informazioni… e visto l’attuale contesto, in cui è praticamente impossibile incontrare persone o enti che non fanno uso di social network, è ovvio che le tecniche di social engineering siano sempre più utilizzate e risultino particolarmente efficaci.

Ed arriviamo al problema del percepito: si tende ad osservare la singola azione, la singola minaccia quando il tema va approcciato facendo dieci passi indietro per osservare il contesto nella sua interezza e complessità. Le singole azioni “chirurgiche” di mitigation e remediation, se non le contestualizziamo in un processo più ampio, rischiano di essere inefficaci. Non ha senso combattere le singole minacce una ad una — oggi il phishing, domani le vulnerabilità dei sistemi di perimetro, settimana prossima la gestione dei dati sensibili — ovvio che è sempre meglio di niente, ma questo è “agire a sentimento” (per non dire a caso) per combattere un avversario che ha strategie e tattiche ben definite e collaudate. Chi la spunterà?

Va costruita una strategia che prenda in esame come siamo fatti (come persone e come organizzazioni) che sia la base per definire azioni e tempi, con ordine e KPI misurabili. Va gestita questa cosa delle “sicurezza cibernetica”, con metodo.

Per quanto mi riguarda per capire il contesto dovete circondarvi di persone — consulenti, dipendenti… come vi pare — che lo hanno vissuto, che fanno parte del complesso e vasto mondo delle sicurezza cibernetica (sul versante etico e legale ovviamente ma bel consci di come sia fatto alche l’altro versante). Orientarsi in questo universo è indispensabile per prendere decisioni efficaci ed efficienti.

Da non dimenticare che le aziende operano in un contesto di mercato dove, solitamente, esiste una certa competizione: non ci si può permettere di non considerare il vantaggio competitivo nell’ottenere una postura di sicurezza migliore rispetto agli altri attori di mercato, è evidente la restituzione di valore in termini di qualità, affidabilità, resilienza. E’ un processo già avviato, probabilmente accelerato dall’attenzione (spesso maldestra a dir la verità) dei media, ma è ovvio che il cliente (prima di tutte le aziende ma lo stesso discorso vale per l’end user) comincerà a prediligere il fornitore più affidabile anche dal punto di vista della sicurezza cibernetica. Ne va del suo business.

hacking

La curiosità che genera competenza e comprensione

L’essere curiosi, ovviamente in modo sano, è alla base della crescita (e non mi azzardo ad andare oltre per quanto riguarda i temi socio-psico-umano-robe).

It’s the law!

Molto più pragmaticamente posso dire che la curiosità è ciò che ha spinto il sottoscritto e molte altre persone che hanno vissuto la scena acara (a prescindere dall’epoca) a studiare come dei matti argomenti distanti da qualsiasi corso o università. Moltissime persone che lavorano nel campo della sicurezza informatica hanno acquisito competenza ed esperienza grazie alla capacità di non smettere mai di studiare, sperimentare, applicare, migliorare… in un loop infinito.

Sono certo che moltissimi professionisti del settore si trovano a dover rispondere a domande che fanno un po’ tenerezza, tipo: ma che scuola devo fare per diventare un hacker etico / pen tester / bug hunter?
Indubbiamente ci sono favolosi percorsi di studio e corsi che consento di avvicinarsi a questo mondo e di acquisire le nozioni tecniche per svolgere attività sia in ambito offensivo che difensivo, ma la materia è così vasta e richiede un background così forte che non c’è corso che tenga… non esiste una scorciatoia, bisogna studiare come dei dannati (anche grazie ai corsi) e passare ore, giorni e notti su documenti, libri, codice, laboratori, esperimenti…

Perché il punto non è sapere come funziona una cosa, il punto è capire perché funziona (cit. Capitano James T. Kirk) e se non siete mossi dalla curiosità di scavare a fondo il “perché” non sarà mai così chiaro.

Se questo approccio può aiutare le nuove leve a costruire una reale competenza, in questo come in altri campi, è anche vero che aiuta i professionisti a mantenere un adeguato livello di preparazione sia sul piano tecnico che sul piano manageriale. Gestire la sicurezza informatica (me lo vedrete scrivere fino a quando non vi sanguineranno gli occhi) non è una questione tecnologica, è un approccio, un modo di pensare ed agire che deve costantemente adattarsi a nuovi scenari.

Chi pretende oggi di gestire il fenomeno degli attacchi informatici con le stesse metodologie e procedure che utilizzava 3 anni fa (senza mettere in dubbio i successi del passato) rischia di passare dei brutti momenti. In pochi anni non solo sono cambiati i vettori d’attacco ma sono cambiate anche le strategie, i metodi di qualifica dei target, le “leve”. Dobbiamo uscire dalla trappola della “spesa” per difendersi e ragionare sugli “investimenti” per competere sul mercato. Essere cyber-sicuri è un vantaggio di business: significa essere affidabili, tutelare meglio i dati dei nostri clienti, offrire beni e servizi di qualità anche in relazione alla sicurezza.

Non è un percorso che ha una fine, è una costante ricerca del miglioramento e va alimentata con la curiosità.

cyber security, hacking

Capacità di reagire: modi e tempi

Nelle ultime settimane ho avuto modo di osservare e riflettere sulla capacità, di organizzazioni ed aziende, di reagire a specifici eventi legati alla sicurezza informatica. In particolare ho preso in esame la reattività ad eventi di segnalazione di una minaccia e la reattività ad eventi di rilevamento di un incident.

i tratta di due casistiche molto diverse tra loro in quanto la prima genera (o dovrebbe generare) valutazioni di rischio ed eventuali azioni di prevenzione mentre la seconda innesca (o dovrebbe innescare) azioni di gestione dell’incident.

La percezione del rischio

Ciò che è chiaro è che non tutti percepiscono il rischio allo stesso modo: la segnalazione di una minaccia, per quanto contestualizzata, viene spesso qualificata secondo la propria percezione personale e soggettiva di quanto il rischio sia elevato. Non sempre viene eseguita una valutazione di merito sui dati a disposizione secondo criteri oggettivi.

Ve la ricordate questa, vero?

Un buon metodo, secondo la mia esperienza ovviamente, è quello di mettere a fattor comune dati oggettivi come lo score della minaccia / vulnerabilità (dato che è facilmente reperibile dai security bulletins che voi tutti controllate) con il coefficiente di impatto che l’asset ha nella vostra infrastruttura. Questo secondo dato, che effettivamente non tutti gestiscono, deriva da una valutazione che le organizzazioni devono fare per comprendere quanto un asset ha impatto sul proprio business (si, è la Business Impact Analysis). Per semplificare il dato che serve avere è un coefficiente che vi aiuti a comprendere quanto un certo asset (o gruppo di asset) è critico per il funzionamento della vostra organizzazione o di uno specifico servizio. Facciamo un esempio facile facile: quanto è critica la posta elettronica per la vostra azienda? O meglio: quanto del vostro business viene impattato da un fermo dei servizi di posta o da un data breach che impatta i servizi di posta? Sulla base di questa informazione oggettiva che l’IT assieme al Management deve definire sarà possibile dedurre l’impatto del servizio in oggetto.

Ora è più facile: se mi viene notificata una minaccia con score elevato (9/10 è elevato nel caso ci siano dubbi) che coinvolge un asset che è stato classificato di elevato impatto (secondo la scala che avete deciso di applicare)… bhe, c’è poco da dire, siete di fronte ad un rischio elevato e dovere intervenire a prescindere dalle vostre opinioni soggettive.

Nota: l’ho molto semplificata, l’obiettivo in questa sede è trasferire il concetto di obiettività della valutazione.

La qualifica dell’impatto

In un contesto di security incident ovviamente la faccenda è un po’ diversa: non si parla più di minaccia e rischio ma di impatti e conseguenze e ancora una volta torna utile avere una mappa di impatto per comprendere dove mettere le mani e che azioni intraprendere.

Non serve aver gestito security incident (tema su cui ho un po’ di esperienza) o averne subiti (tema su cui chi vuole può contribuire in forma anonima per condividere la propria esperienza) per comprendere come sia complesso prendere decisioni razionali durante un evento di questo tipo. Mettersi a qualificare l’impatto sulla base della propria comprensione dell’aziende e dell’infrastruttura ad incident in corso è qualcosa di poco proponibile. La qualifica dell’impatto deve essere snella e definibile su dati oggettivi come la valutazione di impatto dei sistemi coinvolti (che dovrebbe già esistere), la classificazione dei dati presente sui sistemi coinvolti (che dovrebbe già esistere), l’elenco delle risorse da coinvolgere in relazione ai sistemi/servizi impattati. Vietato improvvisare… o meglio, chi non ha dati oggettivi e si trova a dover improvvisare si espone a rischi elevatissimi.

Reazione

Arrivo al vero tema del post… la reazione in termini di tempi e modi. E’ ovvio che se non c’è una procedura per gestire un evento come un incident o una notifica di potenziale vulnerabilità dei sistemi i team interessati agiranno a propria discrezione: chi subito, chi quando ha tempo, chi mai. E’ inoltre ovvio che, anche nel caso di una reazione immediata, l’assenza di una procedura porta ad azioni a discrezione della singola persona la cui efficacia dipenderà dal grado di competenza e conoscenza del sistema e del contesto. Quindi si ottengono risultati apprezzabili o meno a seconda di chi opera. Non lo trovo uno scenario accettabile per un’organizzazione il cui business potrebbe essere pesantemente impattato da un security incident.

L’assenza di procedure a supporto di una reazione commisurata all’evento spesso porta con se l’assenza di una metodologia per la gestione di un evento di incident e, per ovvia ragioni, l’assenza di strumenti adeguati sia a livello di tools che a livello di skills specifiche.

Come sempre faccio degli esempi idioti ma molto reali: nel corso di azioni di mitigation può capitare di dover eseguire azioni con impatti su grandi quantità di sistemi come il cambio di una policy o un banale reset password di decine di server e apparati. Eseguire queste operazioni in 25 secondi grazie a procedure e strumenti già definiti o eseguirle in 4 ore a mano (con relative implicazioni legate al fattore umano) è ciò che può cambiare gli esiti e gli impatti dell’incident sul business. In alcuni casi basterebbero poche procedure ben strutturate e qualche script in python per ribaltare la situazione (voglio essere provocatorio ma non è un’affermazione così lontana dalla realtà).

Ciò che trovo paradossale è il fatto che in molte aziende trovo le tecnologie abilitanti ad una gestione virtuosa della sicurezza informatica ma spesso mancano i processi per una efficiente ed efficacie gestione del proprio patrimonio digitale. La domanda su cui riflettere che vi lascio per il week-end è: quanta tecnologia avete adottato senza una strategia di gestione e delle procedure dedicate?

hacking

Esperimento podcast

La riflessione che mi ha portato a valutare il podcast è che non tutti hanno il tempo di leggersi con calma uno o più articoli anche se molto corti. E’ un tema di contesto: chi si sposta con un mezzo pubblico potrebbe facilmente ritagliarsi uno spazio quotidiano di aggiornamento sul tema di interesse, mentre chi abitualmente utilizza l’auto ha dei vincoli oggettivi e deve eventualmente definire uno spazio di lettura in un momento che probabilmente è già allocato dalle attività del day-by-day.

Ho quindi pensato di proporre un podcast partendo direttamente con una rubrica settimanale, che ho chiamato Sintesi Cibernetica, spazio di 7-10 minuti dedicato a pochi temi che hanno catturato la mia attenzione nel corso delle settimana appena trascorsa.

Inizialmente avevo valutato un’uscita il venerdì pomeriggio per poi passare alla domenica. Un mix di cause hanno portato al cambio di giornata: vorrei essere costante ed il venerdì non è sempre un giorno semplice, inoltre ho avuto la sensazione ci fosse una bassa propensione all’attenzione. La domenica è diventato il giorno ufficiale e dopo i primi due episodi mi sento di confermarlo.

Primi feedback: contenuti buoni, tono di voce troppo basso. Altri suggerimenti spaziano dal mettere un sottofondo musicale al creare una sigla standard. Devo rifletterci un po’ su, non amo particolarmente la sovrastruttura in un progetto che ha come l’informare al fine di avviare delle riflessioni in chi vi si imbatte.

Oggi la terza puntata. Devo selezionare i temi.

hacking

Dove la rete satellitare “tocca” Internet

Come avevo accennato in un podcast di qualche giorno fa, uno dei temi di ricerca che sto portando avanti ha a che fare con le comunicazioni satellitari, o per meglio dire riguarda le tecnologie che ci consentono di comunicare con e tramite i sistemi satellitari.

Potrebbe sembrare un tema distante ma in questa epoca storica è in corso una vera e propria rivoluzione in merito a ciò che stiamo mandando in orbita bassa e a come possiamo utilizzare questi oggetti. Qualche nota di contestualizzazione è doverosa per comprendere il tema.

Scenario

Per prima cosa va detto che i satelliti moderni posso essere anche molto piccoli: esistono diverse aziende che producono e lanciano mini satelliti delle dimensioni di pochi centimetri ed equipaggiati con non poca tecnologia per la rilevazione e la comunicazione a terra (personalmente seguo il progetto CubeSat nato presso l’Università Politecnica della California). Parallelamente grazie a progetti come il celeberrimo SpaceX (e ne stanno arrivando altri) i costi per mandare asset in orbita si stanno riducendo enormemente.

L’ovvia conseguenza è un aumento del “traffico” in orbita bassa, ovvero in quella regione attorno al nostro pianeta in cui vengono tipicamente collocate le costellazioni di satelliti per le comunicazioni, il tracciamento della posizione e rilevamenti di ogni tipo, per uso civile, commerciale e militare.

Da quando i satelliti sono diventati uno strumento anche ad uso civile, se un’azienda ha bisogno di eseguire un determinato tipo di rilevamento o deve comunicare, ad esempio, con la propria flotta navale/aerea/stellare (Starfleet, cit.) si può rivolgere ad un ente che si occupa di lanciare e gestire i propri satelliti tramite cui eroga un servizio e, nei limiti della tecnologia e degli strumenti disponibili, l’azienda cliente è messa in condizione di fruire dei servizi offerti.

Il nuovo modello che sta emergendo frammenta ulteriormente le competenze, consentendo — per come la vedo io — un miglioramento in termini di usabilità ed accesso a questo tipo di tecnologia. Il modello si presenta più o meno così:

  • chi ne capisce di satelliti si dedica alla progettazione e realizzazione di strumenti ricchi di tecnologia ma molto piccoli e leggeri
  • chi ne capisce di razzi e vettori si dedica a progettare ed implementare un servizio di trasporto in orbita bassa
  • chi ne capisce di telecomunicazioni si dedica a costruire una rete di comunicazione satellitare che sia in grado di dialogare con molte tipologie di satellite e mette a disposizione le interfacce

A questo punto le aziende il cui modello di business dipende o sfrutta una tecnologia che necessita di una rete satellitare possono rivolgersi ad una serie di interlocutori specializzati che gli consentiranno di acquisire una tecnologia come i CubeSat, di spararla in orbita e di collegarla a sistemi a terra che consentano l’accesso ai dati/servizi di cui hanno bisogno, senza doverti preoccupare dell’immensa infrastruttura che c’è dietro e con investimenti molto inferiori rispetto a solo 10 anni fa.

Un bel tassello di questo complesso puzzle lo mette a disposizione Amazon con il servizio AWS Ground Station che da la possibilità ad un’azienda di interconnettere un proprio satellite alle “stazioni a terra” di Amazon che gestiranno la comunicazione con l’orbita bassa. Inoltre il servizio mette a disposizione gli strumenti per collezionare i dati ed eseguire le eventuali analisi. Anche su questo fronte credo si possa ipotizzare che Amazon non sarà certo l’unica a muoversi in questo campo.

Dal punto di vista del White Hat

Premetto che questo tipo di tecnologia mi affascina enormemente, tanto quanto mi affascina l’hacking, la fisica e l’esplorazione spaziale. Sono frontiere che vengono quotidianamente abbattute, sono nuovo opportunità per la specie se sapremo utilizzarle.

Chi lavora e fa ricerca nel campo della sicurezza cibernetica e ha un po’ di esperienza, al solo pensiero di prendere un oggetto che orbita attorno al pianeta e che rileva dati potenzialmente molto delicati e metterlo in comunicazione, seppur tramite più layer fisici e logici, con la rete internet attraverso un servizio cloud… probabilmente è svenuto prima di aver letto tutta la frase.

Non c’è nulla di sbagliato nelle intenzioni, esiste però qualche trilione di fattori da considerare per implementare e renderle fruibili queste infrastrutture in modo sicuro. Qualche tempo fa ho azzardato una previsione — non ricordo se l’ho scritta o detta — in relazione ai sistemi di comunicazione satellitare identificando come potenziale punto debole la Ground Station. Prendendo visione di come si stanno rendendo accessibili queste tecnologie mi viene qualche dubbio anche sulle possibilità di configurazione ed integrazione delle piattaforme cloud, non per fattori legati alla tecnologia, bensì in riferimento alla capacità di costruire adeguate policy di sicurezza.

Lo scenario e così complesso e la tecnologia così potente da richiedere una riflessione subito, ben prima che diventi qualcosa di largamente utilizzato. A questo tema sicuramente dedicherò qualche laboratorio di approfondimento e ne parlerò nei prossimi podcast. Mi piacerebbe sentire la campana di qualcuno del settore aerospaziale (militare e/o civile).

hacking

Exchange 0-day, una settimana dopo

Mi ero ripromesso di dedicare qualche minuto ad un approfondimento su quanto accaduto dopo la pubblicazione del post del CSIRT ed aver atteso una settimana ha consentito di considerare diversi eventi e di approfondire alcune analisi così da elaborare qualche considerazioni su una situazione che, a parer mio, è tutt’altro che risolta.

I fatti sono noti a tutti: il 03 marzo viene annunciato da tutti i siti di settore che è stato individuato un attacco 0-day in grado di sfruttare una serie di vulnerabilità di Microsoft Exchange (2013, 2016, 2019) con l’obiettivo di compromettere il sistema e, potenzialmente, rubare informazioni sensibili come il contenuto della posta elettronica del server attaccato.

Come ho scritto in un post poco dopo l’annuncio, si è trattato della “ricetta perfetta”: Exchange è largamente utilizzato da aziende medie e grandi, le vulnerabilità sono sfruttabili da remoto se il sistema espone funzionalità fruibili via https (cosa che ovviamente fanno tutti) e l’annuncio parlava di 0-day, non solo di vulnerabilità… quindi doveva essere chiaro che l’attacco era già cominciato.

Un post interessante lo trovate sul blog di FireEye dove vengono illustrati alcuni comportamenti osservati già da gennaio 2021 in relazione alle vulnerabilità CVE-2021–26855 e CVE-2021–26858. Le attività analizzate si riferivano allo sfruttamento delle vulnerabilità per il posizionamento di una web shell sul sistema target.

Quello che di fatto abbiamo osservato è che la fase “1” dell’attacco, relativa all’exploiting atto al posizionamento della web shell, era già in corso e sono certo che molti di quelli che si sono apprestati ad installare le patch suggerite da Microsoft hanno potuto verificare la presenza della web shell nel path c:\inetpub\wwwroot\apsnet_client\ del sistema Exchange sotto forma di file *.aspx; nel seguente repo di GitHub è stato riportato un elenco di possibili nomi dei file che vengono caricati attribuiti ad una famosa web shell nota con il nome di China Chopper.

Note: questo potrebbe dar sostanza ai sospetti di Microsoft stessa sul gruppo responsabile di questa campagna di attacchi che si ritiene essere HAFNIUM.

La prima doverosa nota tecnica si riferisce al comportamento dei firewall che tipicamente vengono configurati con un NAT per esporre i servizi di Exchange: molti firewall sono in grado di rilevare specifiche minacce grazie alle funzionalità di inspection, ma nel caso specifico l’azione avviene all’interno di una sessione HTTPS e quindi, a meno che il Firewall o il WAF non sia configurato per eseguire attività di SSL decryption, resta assolutamente invisibile al sistema di presidio del perimetro esterno.

Una volta portata a termine la prima fase dell’attacco, avendo a disposizione una web shell ricca di funzionalità, l’attacker è in grado di tentare ulteriori azioni anche contando sulla presenza delle altre vulnerabilità rese note nello stesso contesto (CVE-2021–26857 utilizzata per eseguire codice arbitrario sul sistema con utente SYSTEM e CVE-2021–27065 utilizzata per la scrittura arbitraria di file sul file system del server Exchange).

Nel caso specifico ciò che avviene è un tentativo di garantirsi un accesso persistente al sistema (il mio Red Team ha intercettato l’installazione di DLL e la registrazione di servizi al fine di garantire il dialogo persistente verso il server di Command and Control) e successive azioni che puntano al furto delle informazioni contenute nel sistema con particolare riferimento ai dati in memoria gestiti dal processo LSASS (quindi anche le credenziali) ed i dati presenti sul file system (le mailbox).

Le evoluzioni di questi comportamenti sono presentate anche in un post di Microsoft che è stato via via aggiornato e che da qualche spunto interessante.

Sulle azioni successive al primo exploit ci sono ulteriori elementi di analisi che possono essere utili ad una detection e mitigation dell’attacco. In particolare le attività che portano ad un dialogo verso il C2 server possono essere intercettate dai firewall che mettono a disposizione specifiche funzionalità di verifica del traffico e delle destinazioni. Una certa reattività potremmo aspettarcela anche dai sistemi di anti-exploiting di cui, spero, tutti facciate uso anche se, devo essere onesto, i rilevamenti fatti mi hanno lasciato perplesso su quest’ultimo fronte.

Per chiudere qualche suggerimento (banale ma doveroso):

  • Non avere ancora installato i fix? Mi complimento per il coraggio… fateli ma mettete anche in conto una bonifica del sistema.
  • Avete versioni precedenti di Exchange? Avete un problema ben peggiore perché state utilizzando un sistema end of support per gestire un asset fondamentale per la vostra organizzazione.
  • Avete applicato i fix subito dopo gli annunci? Bene, assicuratevi che il primo exploit non sia stato lanciato e verificate il traffico del vostro Exchange server sul firewall.
  • Precauzionalmente eseguite un cambio password del Domain Admin (due volte) e, già che ci siete, forzate un cambio password all’utenza.

Come sempre mi piacerebbe confrontarmi con chi si trova a gestire il problema all’interno delle organizzazioni. Ogni vostro contributo è prezioso alla community.

hacking

Punti di vista

Premetto che in questo pezzo vorrei far cadere qualche tabù, temi che tutti conosciamo bene ma che talvolta causano un po’ di imbarazzo. Mettiamolo da parte e guardiamoci serenamente in faccia… siamo tra professionisti.

Parte della mia ricerca in relazione allo studio delle tecniche di attacco è focalizzata sulla “percezione di sé”, ovvero come ognuno di noi interpreta la propria realtà. Quando osserviamo il nostro contesto abbiamo una percezione parziale di ciò che esiste dettata da molteplici aspetti: la nostra capacità di osservazione, il nostro grado di conoscenza del contesto, le nostre competenze… ma anche le nostre abitudini, la nostra esperienza, la nostra scala di valori. Analizzarsi è complesso e, pur non essendo impossibile, è estremamente inefficiente. Diventa più sensato, ritengo quasi in tutti i casi, sfruttare un punto di vista terzo e possibilmente non interessato, indipendente, agnostico. Su questo assunto ho basato parte del mio approccio in tema di gestione della sicurezza cibernetica delle organizzazioni.

Il punto di vista dell’organizzazione (del team IT di solito, ma in generale di chi ha ruoli di responsabilità) da solo non basta: è limitato a ciò che si conosce di sé e difficilmente è oggettivo, o quanto meno al sottoscritto non è ancora capitato di leggere un’analisi auto-prodotta oggettiva negli ultimi 20 anni.

Il punto di vista di chi vende, implementa e gestisce soluzioni (indispensabili, non lo dirò mai abbastanza) non è sufficiente a superare il traguardo dell’obiettività in quanto esiste un interesse specifico, soprattutto da parte dei vendor che producono soluzioni tecnologiche, di vendere la propria tecnologia.

Nota sui vendor: non me ne vogliate, fate cose meravigliose e ogni giorno che passa non mancano novità strabilianti, ma è un dato di fatto che ognuno porta la propria bandiera a prescindere da tutto… non ho mai visto un vendor non dire “la mia soluzione è quella migliore”. Non è una critica, è un dato di fatto, teniamolo in considerazione.

L’elemento terzo, indipendente e non legato ad interessi specifici, diventa necessario per portare un punto di vista disinteressato, o meglio, interessato ad un miglioramento della postura dell’organizzazione in tema di sicurezza cibernetica, a prescindere dal logo delle soluzioni che l’azienda vorrà adottare e dalla posizione dei team interni. L’obiettivo è migliorare e transita necessariamente per un cambiamento, fattore che tende a spaventare molto.

Dobbiamo scrollarci di dosso un po’ di paura. Dobbiamo voler cambiare. A chi leggerà queste quattro righe chiedo di fare una riflessione e, per chi lo vorrà, si potrebbe anche organizzare una chiacchierata tra attori interessati al tema.

hacking

L’approccio che genera competenza che genera valore

Ho avuto un giro di incontri e dialoghi fortunati (virtuali ovviamente): in tre occasioni, a distanza di pochi giorni, ho potuto discutere con altrettanti manager e figure di responsabilità di tre aziende molto strutturate — dimensioni oserei dire “ginormiche” — in merito alla gestione della sicurezza cibernetica all’interno del processo creativo e produttivo.

(Credit: Kahveci)

Nonostante le differenze a livello di modello di business e di mercato (il comune denominatore è la realizzazione di device interconnessi) delle tre organizzazioni il tema era sostanzialmente lo stesso e ruotava attorno alla stessa domanda: come si può implementare un modello di sviluppo che dia delle garanzie sulla sicurezza del prodotto finale dal punto di vista dell’esposizione alle minacce cibernetiche?

La portata del tema, credo sia chiaro, è immensa… è ovvio che le garanzie sulla sicurezza dei device (per lo più IoT in questo caso) che si connettono alle reti domestiche ed aziendali diventeranno un termine di paragone per l’utenza che ne dovrà valutare l’acquisto e l’impiego, su questo credo non ci siano dubbi.
La mia riflessione è però relativa ad un altra questione: è meritevole di attenzione l’approccio che le organizzazioni adotteranno per avviare un processo di crescita virtuoso che parta dalle fondamenta delle organizzazioni stesse, dalle persone.

Le persone, oltre ad essere il propulsore delle organizzazioni, sono anche parte della “miscela propulsiva” con le loro idee e le loro attitudini. Un corretto approccio alla gestione della sicurezza informatica, maturato all’interno di un percorso di consapevolezza, è ciò che potrebbe portare i componenti delle organizzazioni a farsi delle domande sul modo in cui agiscono (nel privato come in un contesto lavorativo), sulle procedure che seguono (e che non seguono), sul design di una soluzione, sugli impatti di una scelta strategica.

Mettere in discussione il modello corrente, individuandone e correggendone le falle, è ciò che consentirà alle organizzazioni di crescere. Se questo percorso viene indotto coinvolgendo gli interessati, ovvero i creatori e gli utilizzatori del “modello corrente”, non solo vi sarà l’opportunità di migliorare il modello ma si potrà instillare nei membri dell’organizzazione la capacità di mettere in discussione i modelli in uso al fine di migliorarli.

Esco dalla narrazione dei concetti e torno nel “mondo vero”. Mettendo in discussione il processo, ad esempio, di sviluppo software (vale per qualsiasi processo) di una divisione aziendale che si occupa di scrivere parte di una applicazione o del firmware di un device posso verificare se il modus operandi del team è, in qualche modo, exploitable. Esiste una procedura di validazione del codice? E’ documentata e nota a tutti? Viene rispettata? Come viene gestito il codice? Come viene eseguito il testing della soluzione? Esiste un piano di remediation? Esiste un piano di analisi dei bug? […] Io, da solo, posso formulare un centinaio di domande solo per questo contesto… un team interdisciplinare con specifiche competenze e con il corretto mindset è la base per iniziare mettere in discussione il modello, per perfezionarlo e per contagiare (mi concederete il termine) l’intero team di sviluppo e gli altri team affinché il modello diventi parte dell’organizzazione stessa. Da processo ad approccio.

Una nota conclusiva forse banale ma che mi ha fatto riflettere: il fatto che mi sia trovato a discutere questo tema con più persone di uno specifico settore non è da leggersi come una coincidenza, è un trend, un meraviglioso trend che porta le organizzazioni a ragionare sul valore del prodotto finale e sugli impatti delle scelte che sono chiamate a fare in tema di gestione della sicurezza informatica e tutela della privacy.

hacking

Supply Chain Attack

Di per se il concetto è molto semplice: viene colpito un elemento vulnerabile di una organizzazione in un contesto di intima relazione con altre organizzazioni al fine di colpire l’intero cluster.

Le organizzazioni (aziende, enti privati e pubblici, associazioni, ecc) sono oggi molto legate tra loro in rapporti di cooperazione, fornitura di asset e servizi, partnership. E’ del tutto ovvio, se non indispensabile, che si avviino relazioni intime in cui le stesse fondamenta dell’organizzazione dipendono dai servizi erogati dai propri partner. Viviamo quindi in un contesto sociale e di mercato in cui nulla è isolato dal resto del mondo e pochi elementi di questa maglia possono influire sull’intera struttura.

Banalizzando: se la mia azienda vende prodotti o servizi tramite una piattaforma online, ospitata da una qualsiasi piattaforma cloud che il mercato offre, è ovvio che un fault sulla piattaforma in questione si ripercuote sul mio business e sulla mia reputazione; in un contesto di security incident questa proprietà transitiva rischia di essere parecchio fastidiosa. E’ inoltre ovvio che se il servizio da me erogato non è fruibile o ha subito un incidente riguardante — ad esempio — il furto di dati, l’impatto di ciò che è accaduto al mio fornitore arriva a toccare al mio cliente finale che, tipicamente, verrà da me a chiedere spiegazioni.

Legami di questo tipo esistono a tutti i livelli e possiamo fare mille esempi. Gli studi professionali gestiscono dati talvolta riservati dei propri clienti e probabilmente lo fanno tramite un sistema informatico che, a sua volta, è gestito da personale interno o esterno che deve necessariamente dotarsi di strumenti e tecnologia. Hardware e software vengono tipicamente acquistati da aziende specializzate nella produzione di questi asset o acquisiti a servizio per sostituire soluzioni on premise.
Un’anomalia software dal punto di vista della sicurezza informatica mette quindi a repentaglio l’organizzazione che utilizza il software/servizio che presenta l’anomalia, ma anche i dati che vengono con esso gestiti. Ne siamo tutti ben consapevoli.

Ciò che è recentemente accaduto a SolarWinds è semplicemente l’esempio di più eclatante per impatto, ma la modalità è sempre quella: SolarWinds è stata colpita direttamente al fine di manomettere il software dalla stessa azienda distribuito. A seguito del rilascio delle nuove versioni, opportunamente modificate degli attacker, le organizzazioni clienti (e che organizzazioni) hanno di fatto installato una versione vulnerabile la cui falla era ben nota agli attacker che hanno così potuto colpire, senza troppa fatica, i clienti di SolatWinds tra cui ci sono nomi come il Pentagono, la NASA, la NSA e Microsoft. Letteralmente un disastro, un meteorite di cui i danni dell’impatto non sono ancora chiari.

Ma questo è solo un evento, l’ennesimo, non è il messaggio che voglio condividere. La riflessione su cui vorrei portarvi si riferisce all’esigenza di cambiare modo di ragionare in relazione all’approccio alla sicurezza informatica. Dobbiamo uscire dalla gabbia mentale in cui ci siamo chiusi per anni dove la sicurezza di fa acquistando una soluzione o un servizio.

Nell’attuale contesto il tema lo si affronta con la volontà di agire secondo una logica cyber-sicura, le nostre organizzazioni devono essere intrinsecamente sicure: dobbiamo implementare processi sicuri, dobbiamo imparare ad usare gli strumenti in modo sicuro, comunicare in modo sicuro, gestire i dati in modo sicuro, lavorare in modo sicuro a tutti i livelli (non solo IT).

Costruire una cultura della sicurezza informatica ci porterà a realizzare prodotti e servizi che sin dalle fasi di design saranno stati concepiti in un contesto dove la sicurezza dei dati e delle infrastrutture era un valore intrinseco del processo di produzione, valore che può essere trasferito nel risultato del nostro lavoro e come tale verrà percepito dai nostri clienti e collaboratori.

Le nostre organizzazioni fanno parte della stessa enorme catena: impariamo a collaborare con anelli robusti ed accertiamoci di essere un anello robusto con cui sia vantaggioso collaborare.