Un cyber attacco ha permesso di rubare l'equivalente di 35 milioni di dollari dai portafogli virtuali dei clienti del broker maltese di criptovalute Crypto.com. L'attacco si sarebbe verificato nel fine settimana, e il bottino include criptovalute quali Ethereum, Bitcoin e altre. Il gestore ha rassicurato i clienti di avere ripristinato lo stato dei conti antecedente l'attacco, rimborsando tutti i prelievi fantasma di cui i clienti sono stati vittime.

Quello che rende interessante questo episodio non è l'epilogo, quanto lo svolgimento dell'attacco: come precisa il report stesso di Crypto.com, infatti, "le transazioni sono state approvate senza che il controllo di autenticazione 2FA fosse inserito dall'utente". Un episodio gravissimo, di cui non si trova spiegazione nelle note ufficiali, che non chiariscono lo svolgimento dei fatti.

Al momento non è dato sapere se i codici 2FA siano stati inseriti da qualcuno (anche se non dai clienti) per ottenere l'autorizzare ai prelievi, o se il meccanismo di autenticazione 2FA sia stato del tutto bypassato. Più di una persona, leggendo questa notizia, si sarà chiesto come può accadere un evento simile, ecco alcune ipotesi.

La prima possibilità è che si sia verificato un errore di gestione nel sistema 2FA, come per esempio un problema nel generatore casuale di codici spediti via SMS che abbia prodotto sequenze indovinabili. In genere i codici sono, appunto, casuali. Ma se vengono generate sequenze intuibili, come 44556, 44557, 44558, eccetera, un attaccante in agguato può prevedere il codice corretto da inserire per alcuni o per tutti gli utenti.

La seconda opzione è che si sia verificata a monte una violazione del database di autenticazione 2FA. In genere, un sistema di generazione di codici basato su app sfrutta un secret condiviso, noto come seed. La generazione e convalida del codice avviene nel momento in cui sia il client che il server hanno accesso al seed al momento dell'accesso. Una violazione lato server potrebbe avere fornito a un attaccante i dettagli necessari per calcolare le sequenze di codice monouso per alcuni o tutti gli utenti.

Una terza opzione potrebbe riguardare un server di autenticazione configurato in modo errato o preventivamente attaccato. Per esempio, una vulnerabilità potrebbe avere spinto il server ad accettare una richiesta di accesso sul lato client di modificare le impostazioni di configurazione utilizzate, ad esempio includendo intestazioni HTTP non documentate o aggiungendo parametri URL speciali che sostituiscono in modo imprevisto le impostazioni di sicurezza esistenti.

Ancora, fra le moltissime ipotesi si può mettere sul banco anche la presenza di controlli deboli per il rilevamento di comportamenti rischiosi da parte del personale IT. Per intenderci, è quello che è accaduto in Twitter nel 2020 quando un attaccante ha potuto impossessarsi degli account di alto profilo e pubblicare messaggi fraudolenti a loro nome.

In realtà ci sono moltissime altre opzioni possibili, e solo un'indagine sui sistemi potrà chiarire del tutto l'accaduto. Quello che è certo è che Crypto.com ha preferito andarci cauta, e per evitare che si riproponesse una situazione del genere ha migrato i sistemi "verso un'infrastruttura 2FA completamente nuova". Considerata la cifra che ha dovuto rimborsare ai clienti, è evidente l'intenzione di non avere più un problema analogo in futuro.