Nel settembre 2022 un attaccante che aveva acquistato la password di un collaboratore esterno di Uber ha tentato l’accesso più e più volte. Ogni tentativo inviava al collaboratore una richiesta di approvazione a due fattori. Le prime hanno bloccato l’attaccante. Poi una è stata accettata, e l’attaccante è entrato (aggiornamento sulla sicurezza di Uber). Un mese prima, Cisco aveva descritto lo stesso schema nella propria violazione: telefonate da parte di qualcuno che si spacciava per l’assistenza e una raffica di richieste push finché un dipendente non ne ha accettata una (Cisco Talos).
Entrambe le aziende avevano l’autenticazione a più fattori attiva. Gli attaccanti non hanno forzato il secondo fattore: lo hanno aggirato, con tecniche che funzionano proprio perché l’MFA in uso chiede a una persona stanca di prendere una decisione di sicurezza nel momento peggiore possibile.
Se la vostra MFA è un codice via SMS o un push «Approvi?» a un tocco, questo merita dieci minuti della vostra attenzione. Quei due metodi sono ormai quelli attorno ai quali gli attaccanti costruiscono il piano, non quelli che li fermano.
Tre attacchi che battono «un po’ di MFA»
- Push-bombing (MFA fatigue, MFA bombing, 2FA bombing). L’attaccante ha già la password: da un dump di una violazione, da un phishing o dal riutilizzo. Avvia un accesso dopo l’altro, scatenando una raffica di richieste di approvazione sul telefono dell’utente finché, per confusione o solo per farla smettere, qualcuno tocca Approva. Un tocco ed è dentro.
- SIM swap. Gli SMS non sono mai stati concepiti come canale di sicurezza. Un attaccante che convince (o corrompe) un operatore mobile a spostare un numero su una nuova SIM riceve ogni codice monouso inviato a quel numero. Nessun malware, nessuna pagina di phishing: solo una telefonata a un servizio di assistenza.
- Adversary-in-the-middle (AiTM). Una pagina di login falsa e convincente fa da proxy verso quella reale in tempo reale. La vittima inserisce la password, il sistema reale chiede il secondo fattore e la vittima lo fornisce, perché sta davvero cercando di accedere. Il proxy dell’attaccante raccoglie la sessione che ne risulta. L’MFA «ha funzionato». L’account è comunque perso.
L’agenzia statunitense per la cybersicurezza CISA cita tutti e tre gli attacchi nelle proprie linee guida e traccia un confine netto: solo l’autenticazione FIDO/WebAuthn e quella a chiave pubblica (PKI) contano come resistenti al phishing, perché la chiave è legata all’indirizzo del sito reale e una pagina che lo imita non può usarla. L’approvazione push, anche con il number matching, non rientra in quell’elenco (scheda informativa CISA).
Cosa ferma ciascun attacco
Questi attacchi hanno punti deboli diversi, quindi vale la pena essere precisi su cosa sconfigge cosa.
- SIM swap e intercettazione dei codici: eliminate il codice. Se la chiave dell’utente viene generata nell’hardware sicuro del telefono e non lo lascia mai, non c’è alcun segreto condiviso in un database e nulla che arrivi via SMS. Non c’è nulla da intercettare, e spostare un numero di telefono non sposta nulla che un attaccante possa usare.
- Push-bombing: lasciate che l’utente legga ciò che sta approvando. Nessuna chiave e nessun dato biometrico può aiutare una volta che la richiesta raggiunge il telefono, perché l’attacco si limita a chiedere all’utente di dire sì. Un dato biometrico conferma soltanto che a toccare è il proprietario del telefono, non che l’accesso sia legittimo. Ciò che funziona è una richiesta che porta con sé una descrizione specifica e leggibile di ciò che si sta esattamente approvando: quale servizio, quale azione, da dove. Una richiesta che l’utente non ha mai avviato si vede subito che non è sua, e quindi la rifiuta. La scadenza delle richieste e i limiti alla frequenza con cui possono essere attivate tolgono all’attacco il volume da cui dipende.
- Adversary-in-the-middle: l’approvazione da sola non lo ferma. Qui l’utente non viene indotto ad approvare l’accesso di qualcun altro. Approva il proprio, sul sito sbagliato. Ciò che aiuta è mostrare da dove proviene la richiesta: se l’approvazione indica l’indirizzo da cui è arrivato l’accesso, un proxy in un altro Paese salta all’occhio a un utente che guarda. Questo aumenta il costo dell’attacco, ma non lo rende impossibile. Dove il modello di minaccia richiede la resistenza al phishing in senso stretto, la risposta sono le chiavi FIDO legate al sito, insieme a sessioni di breve durata e a criteri di accesso che limitano dove le sessioni possono essere usate.
È questa la differenza tra un’MFA che un attaccante ha già imparato ad aggirare con uno script e un’MFA che rende ciascuno di questi attacchi visibile o inutile.
Dove si inserisce Notakey
Notakey elimina il codice e rende leggibile ogni approvazione.
- La chiave dell’utente viene generata all’interno dell’hardware sicuro del telefono e non lo lascia mai. Non c’è alcun SMS da intercettare né alcun codice da ritrasmettere.
- La notifica è solo un campanello. Quando l’utente apre l’app, questa scarica la scheda di approvazione via HTTPS dal server presso cui è stata registrata: ciò che l’utente legge proviene quindi dal vostro server, non dalla notifica, e la sua firma copre esattamente quella richiesta.
- Contro il push-bombing, la difesa è ciò che l’utente legge: la scheda mostra quale servizio sta facendo la richiesta e che cosa si sta approvando, così una richiesta che nessuno ha avviato è evidente al primo sguardo e viene rifiutata. Le richieste scadono e un limitatore integrato pone un tetto alla frequenza con cui possono essere attivate, così la raffica di richieste su cui si basa l’attacco viene interrotta.
- Contro l’adversary-in-the-middle, il server può essere configurato per mostrare sulla scheda l’indirizzo IP da cui arriva la richiesta, il nome del servizio o l’URL, così l’utente vede da dove proviene realmente l’accesso. Non sosteniamo nulla di più: rende visibile un proxy a un utente che guarda, ma non rende l’attacco impossibile.
- Copre le vie che gli attaccanti usano davvero: si vedano le guide pratiche per la 2FA su una VPN tramite RADIUS, il desktop remoto di Windows e l’SSH su Linux.
Vedetelo con i vostri occhi
Il modo più rapido per cogliere la differenza è approvare una transazione che potete davvero leggere: un’azione specifica, firmata dal vostro telefono, invece di una richiesta priva di contesto.
Provate la demo dal vivo per firmarne una in circa due minuti, oppure richiedete una demo e mapperemo i vostri accessi VPN, SSO o Windows su un progetto pilota sulla vostra infrastruttura.