Violazione del codice sorgente di LastPass: pubblicazione del rapporto di incident response

Se la grande storia di questo mese sembra destinata a essere la violazione dei dati di Uber, nella quale un hacker sarebbe stato in grado di navigare a suo piacimento attraverso la rete della società di ride-sharing…

…la grande storia del mese scorso è stata la violazione di LastPass, nella quale sembra che un aggressore abbia avuto accesso solo a una parte della rete, ma sia stato in grado di scappare con il codice sorgente proprietario dell’azienda.

Fortunatamente per Uber, l’aggressore sembrava determinato a farsi un po’ di pubblicità acquisendo schermate, diffondendole liberamente online e schernendo l’azienda con messaggi urlati a gran voce del tipo “UBER È STATO VIOLATO”.

Gli aggressori di LastPass, tuttavia, sembrano aver operato in modo più furtivo, apparentemente inducendo uno sviluppatore di LastPass a installare malware che i criminali informatici hanno poi utilizzato per farsi strada nel repository del codice sorgente dell’azienda.

LastPass ha ora pubblicato un rapporto ufficiale di follow-up sull’incidente, basato su ciò che è stata in grado di capire sull’attacco e sugli aggressori all’indomani dell’intrusione.

Ecco cosa sappiamo

Le frasi in grassetto di seguito forniscono uno schema di ciò che LastPass sta affermando:

• L’attaccante “ha ottenuto l’accesso all’ambiente di [d]evelopment utilizzando l’endpoint compromesso di uno sviluppatore”. Partiamo dal presupposto che ciò sia dovuto al fatto che l’attaccante ha impiantato un malware snooping sul computer di un programmatore.
• Non è stato possibile individuare quale sotterfugio sia stato utilizzato per impiantare il malware. È deludente, perché sapere come è stato effettivamente eseguito il tuo ultimo attacco rende più facile rassicurare i clienti sul fatto che le tue procedure di prevenzione, rilevamento e risposta aggiornate probabilmente lo bloccheranno la prossima volta. Vengono in mente molti potenziali vettori di attacco, tra cui: software locale senza patch, “shadow IT” che porta a una configurazione locale non sicura, un errore di phishing click-through, abitudini di download non sicuri, inganno nella supply chain del codice sorgente su cui si basa il programmatore interessato, o un allegato e-mail con trappole esplosive aperto per errore.
• L’attaccante “ha utilizzato il proprio accesso per impersonare lo sviluppatore una volta che quest’ultimo si è autenticato con successo utilizzando la 2FA”. Supponiamo che ciò significhi che l’hacker non ha mai avuto bisogno di acquisire la password della vittima o il codice 2FA, ma ha semplicemente utilizzato un attacco cookie-stealing o estratto il token di autenticazione dello sviluppatore dal traffico di rete (o dalla RAM del computer della vittima) al fine di agganciarsi al suo accesso.
• LastPass non ha notato immediatamente l’intrusione, ma ha individuato ed espulso l’attaccante nel giro di quattro giorni. Come abbiamo notato in un recente articolo sui rischi dell’ambiguità del timestamp nei log di sistema, essere in grado di determinare l’ordine preciso in cui si sono verificati gli eventi durante un attacco è una parte vitale dell’incident response.
• LastPass mantiene fisicamente separate le sue reti di sviluppo e produzione. Questa è una buona pratica di cybersecurity perché impedisce che un attacco alla rete di sviluppo (dove le cose sono inevitabilmente in un continuo stato di cambiamento e sperimentazione) si trasformi in un’immediata compromissione del software ufficiale direttamente a disposizione dei clienti e del resto dell’azienda.
• LastPass non conserva i dati dei clienti nel proprio ambiente di sviluppo. Anche questa è una buona abitudine dato che gli sviluppatori, come suggerisce il nome della loro professione, generalmente lavorano su software che devono ancora essere sottoposti a una revisione completa della sicurezza e al processo di garanzia della qualità. Questa separazione rende anche credibile l’affermazione di LastPass secondo la quale nessun dato del deposito password (che sarebbe stato comunque crittografato con le chiavi private degli utenti) avrebbe potuto essere esposto, una dichiarazione decisamente più forte del semplice “non siamo riusciti a trovare alcuna prova che sia stato esposto”. Tenere i dati del mondo reale fuori dalla rete di sviluppo impedisce anche ai programmatori ben intenzionati di acquisire inavvertitamente dati destinati a essere protetti dalle normative e di utilizzarli per test non ufficiali
• Sebbene il codice sorgente sia stato rubato, l’attaccante non ha lasciato dietro di sé modifiche non autorizzate. Ovviamente, abbiamo solo l’affermazione di LastPass su cui basarci, ma dato lo stile e il tono del resto del rapporto sull’incidente, non vediamo alcun motivo per non prendere l’azienda in parola.
• Il passaggio del codice sorgente dalla rete di sviluppo alla produzione “può avvenire solo dopo il completamento di rigorosi processi di revisione, test e validazione del codice”. Ciò rende credibile per LastPass affermare che nessun codice sorgente modificato o infetto abbia raggiunto i clienti o il resto dell’azienda, anche se l’attaccante fosse riuscito a impiantare un codice malevolo nel sistema di controllo della versione…
• LastPass non memorizza né conosce le chiavi di decrittazione private dei suoi utenti. In altre parole, anche se l’attaccante fosse scappato con i dati delle password, non ne avrebbe tratto alcun vantaggio. (LastPass fornisce anche una spiegazione pubblica di come protegge i dati del vault password contro il cracking offline.)

Cosa fare?

Pensiamo sia ragionevole affermare che le nostre prime ipotesi erano corrette e che, sebbene questo sia un incidente imbarazzante per LastPass e potrebbe rivelare segreti commerciali che la società considerava parte del suo valore per gli azionisti…

…questa violazione possa essere considerata un problema che LastPass deve affrontare internamente, perché in questo attacco non è stata raggiunta alcuna password dei clienti.

Questo attacco, e il rapporto sull’incidente di LastPass, sono anche un buon promemoria del fatto che “divide et impera”, noto in gergo anche come Zero Trust, rappresenta una parte importante della difesa informatica contemporanea.

Come spiega l’esperto di Sophos Chester Wisniewski nella sua analisi del recente hack di Uber, c’è molto di più in gioco se i truffatori che ottengono l’accesso a parte della tua rete possono vagare liberamente nella speranza di ottenere l’accesso a tutto: