Okta ha confermato che la violazione subita a gennaio è collegata con gli attacchi contro il 2,5% dei suoi clienti. Lapsus$ tuttavia rivendica un attacco ben più invasivo di quello denunciato.
Autore: Redazione SecurityOpenLab
Le indagini aperte dopo la violazione di un server Azure DevOps di Microsoft, Okta ha ammesso che il 2,5% dei suoi clienti, ossia circa 375 aziende, sono state attaccate dal gruppo Lapsus$. Siamo quindi di fronte all’ennesimo attacco alla supply chain andato a buon fine. Nel giro di poche settimane sono state attaccate Nvidia, Samsung, Microsoft, Vodafone, Ubisoft e altre aziende. In tutti i casi sono stati esfiltrati dati dai repository di codice sorgente, e gli attacchi sono stati rivendicati dal gruppo criminale Lapsus$.
Con il caso Microsoft, venuto alla luce nel fine settimana, c’è stata la svolta nelle indagini: i cyber criminali hanno pubblicato uno screenshot dai sistemi interni di Okta, in cui un ricercatore per la sicurezza ha scoperto date che coincidevano con una violazione di Okta avvenuta a fine gennaio.
L’azienda, che è uno dei principali fornitori di sistemi per la gestione degli accessi, ha inizialmente negato il legame fra il suo attacco e quello a Microsoft. Tuttavia, i sospetti erano forti e sono iniziate indagini approfondite. Okta ha confermato che la violazione subita a gennaio è collegata con gli attacchi ai clienti. Microsoft ha confermato che uno dei suoi dipendenti è stato compromesso dal gruppo di hacking Lapsus$.
https://twitter.com/BillDemirkapi/status/1506107157124722690?s=20&t=OaqtoWp2RFBF4rq6M76zPw
Nell’incidente di sicurezza subito da Okta a gennaio 2022, attaccanti non identificati hanno compromesso un notebook di uno dei suoi ingegneri di supporto, che aveva i permessi per la reimpostazione delle password dei clienti. Gli attaccanti ebbero accesso al sistema per cinque giorni tra il 16 e il 21 gennaio 2022, durante i quali riuscirono ad accedere al pannello di assistenza clienti di Okta e al server Slack dell'azienda.
La finestra temporale indicata coincide con la data che era presente nello screenshot di Lapsus$. Non solo: negli screenshot si vedeva un indirizzo email di un dipendente Okta che sembrava avere privilegi di superuser, che hanno consentito ai threat actor di elencare gli utenti, reimpostare le password, reimpostare la MFA e accedere ai ticket di supporto. Okta ha precisato che tale accesso non permetteva agli attaccanti la creazione o l'eliminazione di utenti o il download di database dei clienti, in quanto "i tecnici del supporto hanno accesso a dati limitati”.
Okta ha calcolato che la violazione in questione ha compromesso il 2,5% circa dei suoi 15.000 clienti, che sono stati identificati e contattati. Fra questi c’è uno dei dipendenti di Microsoft, dal cui account gli attaccanti hanno avuto accesso ai codici sorgente che sono stati esfiltrati e successivamente messi in rete.
Microsoft, dal canto suo, ha confermato che uno degli account dei propri dipendenti è stato compromesso da Lapsus$. L’azienda sostiene comunque che gli attaccanti hanno avuto un accesso limitato ai repository del codice sorgente. Nella dichiarazione ufficiale si legge che "nessun codice cliente o altro dato è stato coinvolto nelle attività osservate. La nostra indagine ha rilevato che era stato compromesso un singolo account, ottenendo un accesso limitato. I nostri team di cybersecurity response si sono mossi rapidamente per correggere l'account compromesso e prevenire ulteriori attività".
A conclusione delle indagini interne, Microsoft non ha condiviso il modo in cui l'account è stato compromesso, ma ha fornito una panoramica generale delle tattiche, tecniche e procedure (TTP) messe in campo da Lapsus$.
Quando è emerso il caso Microsoft era stato chiamato in causa anche Cloudflare perché, sempre negli screenshot pubblicati dagli attaccanti, si vedeva un indirizzo email di un dipendente Cloudflare la cui password stava per essere reimpostata. L’azienda ha condotto le sue indagini interne, e ha reso noto che l'account email aziendale presente negli screenshot di Lapsus$ era stato sospeso circa 90 minuti dopo che il suo Security Incident Response Team (SIRT) aveva ricevuto la prima notifica di un potenziale problema, la mattina del 22 marzo. Significa che il sistema di difesa ha funzionato e che la reazione è stata immediata ed efficiente.
A seguito dell’indagine Cloudflare ha pubblicato in maniera trasparente una nota ufficiale in cui sottolinea che “i servizi Okta vengono utilizzati internamente per la verifica dell'identità dei dipendenti, che è integrata nello stack di autenticazione. I clienti non hanno nulla di cui preoccuparsi, a meno che non utilizzino essi stessi Okta".
Per scongiurare ogni possibile problema, Cloudflare ha anche controllato tutte le reimpostazioni delle password o dell'MFA dal 1 ° dicembre 2021. Per i 144 account in cui si era verificata questa evenienza, è stata forzata la reimpostazione della password.
In relazione alle dichiarazioni sopra riportate, Lapsus$ ha ribattuto con un punto di vista differente. Gli attaccanti sostengono di non avere affatto compromesso il notebook di un dipendente Okta, ma di avere violato il loro thin client (sistema a basse prestazioni che si connette in remoto in un ambiente virtuale). Se la cosa fosse verificata sarebbe molto più grave.
I threat actor sostengono infatti di "aver effettuato l'accesso al portale dei superuser con la possibilità di reimpostare la password e la MFA di circa il 95% dei client". A questo punto è lecito aspettarsi che la questione non sia affatto chiusa.