Il vault ha retto. Non era quella la via d'accesso.
LastPass è stata violata di nuovo e il vault ha retto. La via d'accesso era un token OAuth morto proveniente da un'integrazione abbandonata, la classe di segreto che quasi nessuno tratta come tale.
LastPass è stata violata di nuovo questo mese. La parte che tutti si aspettano non si è verificata. Nessun vault è stato forzato. Nessuna master password è stata compromessa. I segreti cifrati sono rimasti intatti. LastPass ha confermato che i suoi "prodotti, servizi e infrastruttura non sono stati interessati" e che i vault dei clienti "sono rimasti sicuri". [1]
Gli attaccanti non si sono mai avvicinati al vault. Sono entrati attraverso un fornitore.
Ecco la catena, perché il meccanismo è il punto centrale. L'11 giugno un gruppo che si fa chiamare Icarus è entrato in Klue, una piattaforma di market intelligence che @LastPass utilizzava internamente. La loro via d'accesso, secondo @HuntressLabs, che ha gestito l'incidente: "una credenziale API dormiente da tempo, creata in origine per un prototipo di integrazione con terze parti poi abbandonato". [2] Una chiave creata per un progetto che non esisteva più, per uno scopo che nessuno ricordava, ancora attiva. Da dentro Klue hanno inserito codice malevolo che ha raccolto i token OAuth che Klue deteneva per i propri clienti: le autorizzazioni permanenti che gli permettevano di leggere @salesforce, Slack, HubSpot e altro per conto di quelle aziende. Uno di quei token era quello di LastPass. Con esso, gli attaccanti hanno letto il CRM Salesforce di LastPass. Nomi, email, numeri di telefono, indirizzi, contenuti dei ticket di supporto. Poi la nota di estorsione. Pagate, o finisce sul sito di leak.
LastPass non è stata l'unica nel raggio dell'attacco. Huntress, Recorded Future, Tanium, Jamf, BeyondTrust. Aziende di sicurezza, nella maggior parte dei casi. Di quelle che lo fanno di mestiere.
Quindi merito dove è dovuto. La crittografia di LastPass ha fatto esattamente ciò che prometteva. Il vault non è la storia. La storia è una classe di segreto che quasi nessuno tratta come un segreto: il token a lunga durata che risiede dentro un'integrazione SaaS che avete approvato una volta e non avete più guardato. Non scade. Non sa di essere stato rubato. Concede molto più del motivo per cui è stato creato, e continua a concederlo, in silenzio, finché un essere umano non ricorda di andare a disattivarlo. Di solito nessun essere umano lo fa.
Questo è il cambiamento. Il modello di minaccia è passato da "riescono a forzare il vault?" a "quante chiavi dimenticate sono lasciate socchiuse in porte che avete smesso di sorvegliare". Una credenziale morta proveniente da un prototipo abbandonato è bastata per raggiungere i dati dei clienti di una serie di aziende. La matematica non è mai stata il punto debole. Lo è stato il proliferare.
È esattamente il fallimento che una credenziale dovrebbe essere progettata per rifiutare. Un segreto emesso da Clavitor è di breve durata e con ambito limitato. Viene negoziato per una singola operazione, scade da solo ed è vincolato e attribuito alla macchina che lo ha usato. Un token di quel tipo non può diventare ciò che ha causato il danno qui: un'autorizzazione dimenticata, raccolta molto tempo dopo che qualcuno ne ricordava l'esistenza, riutilizzata dall'infrastruttura di un estraneo senza nulla che la riconduca a un autore. Scompare prima di poter essere trovato e non è mai andato oltre il suo unico compito.
C'è un limite che vale la pena dichiarare apertamente. Clavitor governa le credenziali che detiene, non l'autorizzazione OAuth permanente che avete consegnato alla piattaforma di un fornitore. Quel token vive nel loro sistema, sotto i loro controlli, e nessun vault ci si introduce per farlo scadere al vostro posto. Ciò che cambia è tutto ciò che rientra nell'ambito di Clavitor. Si rifiuta di essere il posto dove un segreto a scadenza infinita può restare in silenzio. La disciplina la cui assenza ha aperto Klue (vite brevi, ambito stretto, attribuzione reale) è qui l'impostazione predefinita, non un'opzione che qualcuno avrebbe dovuto ricordare.
La domanda che resta è scomoda. Quanti token attivi risiedono in fornitori che avete integrato un anno fa e dei quali non avete più pensato?
Abbiamo raccolto le poche proprietà che una credenziale dovrebbe possedere prima di affidarle qualsiasi cosa. [3]
Clavitor (@clavitorai) è il vault di credenziali costruito per gli agenti AI, e contro di essi. clavitor.ai
Fonti
[1] BleepingComputer, "LastPass conferma la violazione dei dati nell'attacco alla supply chain di Klue" — @BleepinComputer
[2] Riscontri di Huntress sull'incidente, riportati da Help Net Security, "La violazione di Klue porta al furto dei dati Salesforce, Huntress tra le vittime" — @HuntressLabs, @helpnetsecurity
[3] Le dieci regole della gestione delle credenziali (Articolo nativo su X) — @clavitorai