MFA fatigue e push bombing: quando il prompt di approvazione diventa l'attacco
L'autenticazione a più fattori funziona al meglio quando il secondo fattore chiede un'azione deliberata. Un prompt di approvazione push chiede molto meno: un singolo tocco. Gli attacchi di MFA fatigue — detti anche push bombing — sfruttano proprio quel varco. Un attaccante che possiede già una password valida genera tentativi di accesso ripetuti, inondando il telefono della vittima di richieste di approvazione finché una non viene accettata, per riflesso, per fastidio o nella convinzione che approvare faccia finalmente smettere le notifiche.
Come si svolge un attacco di push bombing
Lo schema è costante nei casi documentati dai team di sicurezza. L'attaccante parte da credenziali rubate altrove — i log di infostealer venduti in blocco sono un'origine comune — e verifica che la password funzioni ancora. Poi ripete i tentativi di accesso, generando notifiche push sul dispositivo registrato della vittima. Ogni prompt è identico a uno legittimo, e anni di approvazioni quotidiane innocue hanno addestrato molti utenti ad approvare quasi senza pensare. Le campagne aggiungono spesso un secondo strato: una chiamata o un messaggio di chi si spaccia per l'assistenza IT, esortando l'obiettivo ad accettare i prompt perché smettano. Dal lato dell'utente questo disorienta di proposito. Il prompt si presenta come se l'utente avesse avviato lui l'accesso, ma nulla nella notifica prova chi l'ha fatto. In teoria il prompt è un controllo di sicurezza; in pratica è un messaggio sul tuo schermo che chiunque possieda la tua password può generare, e rigenerare, finché la fatica non fa il resto. Trattare quel prompt come input non fidato è esattamente il cambio mentale che questi attacchi aggirano.Uber, settembre 2022: il caso da manuale
L'esempio più citato resta la violazione di Uber del settembre 2022. Come ha riferito TechCrunch, Uber ha attribuito l'intrusione a un hacker legato a Lapsus$ e ha detto che la password aziendale di un contractor esterno era stata probabilmente comprata su un marketplace della dark web, secondo i report dai log del malware infostealer RedLine. La password da sola non bastava, perché l'account richiedeva un secondo fattore. L'attaccante ha generato prompt push per oltre un'ora, poi ha contattato il contractor su WhatsApp fingendosi l'IT di Uber, dicendogli che le notifiche si sarebbero fermate una volta accettate. L'esito, l'attaccante l'ha poi riassunto a TechCrunch in una frase:And well, he accepted and I added my device.Con quell'approvazione l'attaccante ha registrato il proprio dispositivo per la MFA ed è entrato nella rete interna di Uber via VPN. Come ha documentato BleepingComputer, l'accesso si è allargato in fretta: sul Slack di Uber è comparso un messaggio che annunciava l'intrusione, e l'attaccante ha raggiunto console cloud, il dominio Windows e i ticket HackerOne dell'azienda, scaricando secondo i report report privati di vulnerabilità prima che l'accesso venisse tagliato. Su una condivisione di rete, uno script PowerShell esponeva credenziali amministrative della piattaforma di accesso privilegiato di Uber. La copertura di TechCrunch ha notato che il number matching, secondo i report, non era attivo dove contava.
Cisco: la stessa leva, usata diversamente
Il team di risposta agli incidenti di Cisco, Talos, ha documentato un caso parallelo nello stesso anno. Il 24 maggio 2022 Cisco è venuta a conoscenza di una compromissione iniziata con l'account Google personale di un dipendente, in cui si sincronizzavano credenziali aziendali salvate su Chrome. L'attaccante ha combinato chiamate di vishing fingendosi un'organizzazione di assistenza fidata con richieste push MFA ripetute, finché una non è stata accettata, ottenendo accesso via VPN. Talos ha valutato, con confidenza da moderata ad alta, che l'attore fosse un broker di accesso iniziale legato a UNC2447, Lapsus$ e agli operatori del ransomware Yanluowang, e ha descritto l'attività come pre-ransomware: prima l'accesso, poi la monetizzazione. Due violazioni, stessa porta: il prompt push, approvato sotto pressione.Number matching e la scala delle mitigazioni
Le mitigazioni sono ben note. Le indicazioni della CISA sono dirette: «la MFA resistente al phishing è lo standard che tutti i leader del settore dovrebbero puntare a raggiungere, ma qualsiasi MFA è meglio di niente». L'agenzia indica FIDO/WebAuthn come unica opzione resistente al phishing ampiamente disponibile e, dove non è fattibile, raccomanda «la MFA con number matching per bloccare il bombardamento push mobile». Microsoft ha reso il number matching lo standard per le notifiche push di Authenticator: la schermata di accesso mostra un numero e l'approvazione richiede di digitarlo nell'app. Un prompt fuori contesto non ha un numero da digitare, ed è esattamente per questo che la tecnica sconfigge l'approvazione a occhi chiusi.- Tratta ogni prompt inatteso come input non fidato: negalo, segnala l'accaduto e cambia la password che stava testando.
- Preferisci fattori che chiedono un'azione deliberata — codici dell'autenticatore o chiavi hardware — al semplice push di approvazione con un tocco.
- Non sincronizzare mai credenziali di lavoro o di alto valore in un profilo browser personale; l'attaccante di Cisco è entrato proprio da lì.
- Riserva le chiavi di sicurezza hardware agli account più importanti; secondo TechCrunch sono state quelle a reggere a un attacco simile presso Cloudflare.