Ora vediamo regolarmente i risultati sconvolgenti di un successo bombardamento a spinta attacchi, poiché questa tattica diventa un metodo di attacco comune. Oggi le organizzazioni si trovano ad affrontare un maggior numero di attacchi push bombing di autenticazione a più fattori (MFA), in cui un aggressore è generalmente già in possesso di uno dei fattori di autenticazione, come nome utente/password. L'attaccante può quindi richiedere notifiche push che arrivano allo smartphone dell'utente.
Gli attacchi dinamitardi si basano su Stanchezza da AMF. Anche se ricevere una notifica push inaspettata non è un evento normale, l'utente potrebbe approvare la richiesta. Anche se l'utente fa la scelta giusta e rifiuta la richiesta la prima volta, potrebbe essere stancato o confuso dai messaggi. È sufficiente un solo "consenti" e l'attaccante viene autenticato. A seconda della struttura dell'ambiente e degli altri controlli di sicurezza in atto, questo può consentire all'attore della minaccia di accedere alle applicazioni, alle reti o ai file aziendali. Di recente abbiamo descritto in dettaglio le specifiche che ID Plus per rilevare e proteggere da questi attacchi in un blog chiamato Protezione dagli attacchi MFA Prompt Bombing.
Affrontare la fatica dell'MFA è una sfida interessante per la sicurezza della maggior parte delle organizzazioni. Anche se questo tipo di attacco non dovrebbe essere un evento quotidiano, se si verifica, il team di sicurezza deve saperlo e rispondere. Non solo significa che siete sotto attacco, ma anche che probabilmente alcune credenziali sono già compromesse. Il bombardamento immediato rientra nella categoria dei casi poco frequenti e ad alto rischio. Questo post illustra alcuni dei metodi fondamentali per affrontare questo tipo di attacco dal punto di vista di un team operativo di sicurezza.
Per essere preparati al Push Bombing e combattere la stanchezza da MFA, è necessario iniziare dall'elemento umano.
- Consapevolezza dell'utente. Gli utenti devono essere più che consapevoli: devono essere informati, vigili e preoccupati. Ma, allo stesso tempo, promuovere la consapevolezza della cybersecurity deve essere facile per loro, altrimenti falliranno. Un corso di sensibilizzazione alla sicurezza una volta all'anno può soddisfare le esigenze di conformità e fornire qualche beneficio, ma non è sufficiente per contrastare un attacco sofisticato. Agli utenti va detto che se non sono stati loro a iniziare una comunicazione, devono considerarla sospetta. Se gli utenti dispongono di strumenti e formazione adeguati, possono avere una possibilità.
- Educazione dell'utente. Assicuratevi che i vostri utenti finali sappiano che è possibile che ricevano una richiesta push-to-auth sbagliata e che non debbano fare automaticamente clic su "ok" sulla stessa finestra di dialogo che hanno visto 100 volte. Affinché questo messaggio raggiunga alcuni o la maggior parte degli utenti, il vostro programma di sicurezza deve prevedere un qualche tipo di comunicazione regolare agli utenti e un modo per far persistere la comunicazione: prendete in considerazione un avviso via e-mail, pubblicate l'avviso su una pagina di blog persistente a cui tutti gli utenti possono accedere e aggiungete collegamenti all'avviso in altra documentazione aziendale, nella vostra landing page sulla sicurezza o rendetelo un tema per il Cyber Security Awareness Month.
- Risorse dell'utente. Ricordate che per eseguire con successo gli attacchi MFA Fatigue e Prompt Bombing, è più che probabile che un attaccante sia già in possesso delle credenziali dell'utente. Gli aggressori più avanzati inizieranno lo spear phishing e potrebbero inviare SMS, avvisi WhatsApp, telefonate o e-mail all'utente per aggiungere confusione all'MFA Fatigue. Affinché gli utenti siano in grado di contrastare questi tentativi, devono essere sicuri di come segnalare un problema e capire davvero come l'Help Desk, il Service Desk e il team di sicurezza comunicano con loro. Anche in questo caso, non si tratta di una formazione annuale, ma di una comunicazione costante agli utenti e di una comprensione generale di come trovare le risorse necessarie e di come dovrebbero funzionare le cose. Se ogni utente sa di dover chiamare immediatamente il ServiceDesk e quest'ultimo dispone di una documentazione aggiornata, o anche se qualcuno del team ricorda l'esistenza di questa risorsa e riesce a trovarla, l'organizzazione è ben posizionata.
- Azioni dell'utente. Un utente senza risorse e non formato è un buon bersaglio. Gli utenti sanno che devono sempre richiedere il contatto con il Service Desk tramite gli strumenti appropriati (Teams, Slack, ecc.) e non accettano telefonate senza che prima sia stata verificata la comunicazione? Stabilite le aspettative e fornite un modo per verificare se l'utente non è sicuro.
In sintesi, dovreste porvi queste domande sul vostro programma di sicurezza e utilizzare le risposte per migliorare i vostri processi, se necessario:
- Gli utenti sanno cosa fare se ricevono una richiesta push auth inaspettata?
- Gli utenti possono segnalare rapidamente un problema di sicurezza?
- Tutti gli utenti sanno come contattare il vostro Service Desk?
- Il vostro Service Desk sa come rispondere a un problema di sicurezza?
- Gli utenti hanno la possibilità di rivolgersi direttamente al team di sicurezza?
- Gli utenti sanno come il Service Desk li contatta legittimamente e che non ci si deve fidare dei contatti al di fuori di questo meccanismo?
- Gli utenti sanno come convalidare un contatto legittimo?
Il primo modo per prevenire l'affaticamento da MFA è non permettere che si verifichi. Non utilizzare le password elimina il principale vettore di attacco: una coppia di nome utente e password che può persistere per mesi. Considerate l'utilizzo di FIDO come fattore primario. Ma FIDO potrebbe non essere ancora pratico per tutti... e se così fosse, cosa dovreste fare?
Come spesso accade per la sicurezza, la migliore prevenzione tecnica è una difesa a più livelli. Ecco alcuni elementi da considerare. Scegliete quelli che si adattano meglio al vostro ambiente:
- Se vi affidate ancora a nomi utente e password, assicuratevi di avere almeno un caveau di password o, meglio ancora, una soluzione completa di Privileged Authentication Management (PAM) per gli accessi più sensibili. Assicuratevi anche che venga utilizzata correttamente; potrebbe essere il momento di fare un check-up.
- Se c'è il sospetto che le credenziali siano state compromesse, forzare la reimpostazione della password. La reimpostazione impedirà il push bombing in futuro.
- Anche se non è una buona pratica cambiare arbitrariamente le password (per una serie di motivi), obbligare a cambiare la password limita il tempo in cui le credenziali compromesse possono essere facilmente utilizzate per il push bombing.
- Rivedete la vostra configurazione MFA per assicurarvi che i modelli di accesso abbiano senso. È possibile configurare anche le migliori soluzioni MFA in modo da consentire un numero eccessivo di accessi con una verifica limitata.
- Si applicano anche le migliori pratiche di buon senso in materia di password. Istruite gli utenti spiegando loro perché non dovrebbero condividere le password tra i servizi. In questo modo, se si verifica una compromissione, si limita la superficie di attacco per il push bombing.
- Se vi affidate troppo all'autenticazione push o per proteggere dati troppo sensibili, prendete in considerazione la possibilità di aumentare la frequenza delle richieste di one-time password (OTP) utilizzando token morbidi o rigidi. Le richieste OTP saranno viste dall'attaccante in uno scenario di attacco e non arriveranno mai all'utente.
Per rilevare una falsa richiesta di autenticazione push in modo programmatico, è necessario che molte cose funzionino correttamente. I log del sistema di autenticazione devono essere impostati al giusto livello, inviati al raccoglitore di log appropriato, analizzati correttamente e il contenuto deve essere in grado di generare un avviso appropriato. Da lì, un Security Operations Center (SOC) vigile e attivo 24 ore su 24, 7 giorni su 7, deve ricevere e riconoscere questo avviso con un runbook aggiornato su cosa fare in seguito. Non sembra facile, e non lo è. Una serie di strumenti e meccanismi può ridurre l'impegno richiesto, ma il punto principale è che dovete identificare l'evento di log che vi interessa, considerare le soglie che vi interessano e capire quali azioni dovete intraprendere quando ricevete un avviso e convalidare l'intero processo.
Si potrebbe prendere in considerazione l'idea di avere un avviso significativo per un rifiuto dell'autenticazione push e di ridurre la frequenza se questo fa troppo rumore. Ricordate che se i vostri utenti sono ben addestrati, possono segnalarvi un problema molto rapidamente. Potrebbero persino essere più veloci di un SIEM nell'analizzare i registri, nel trasmettere l'avviso e nel far sì che il SOC lo rilevi e risponda. È sempre bene avere un piano di backup e più livelli di sicurezza e monitoraggio.
Esaminare gli eventi di log e gli scenari "what-if" basati su un attacco. Dovete assicurarvi di identificare e ricevere i dati giusti. Verificare la presenza di un evento di log specifico di un utente che nega una richiesta push come elemento di maggiore interesse. Un altro elemento di interesse sono le richieste di autorizzazione push abbandonate.
Ricordate che il rilevamento di una richiesta push errata significa che probabilmente è stata rilevata anche una compromissione delle credenziali. Quindi, anche se un utente dice "No" alla richiesta push, potreste già essere a rischio se nella vostra rete aziendale c'è un qualsiasi luogo in cui una combinazione di nome utente/password potrebbe consentire l'accesso. Se si dispone di un rilevamento per le richieste push auth errate, questo può servire come meccanismo di rilevamento per le credenziali compromesse.
Gli utenti di RSA possono vedere come ID Plus utilizzi l'autenticazione basata sul rischio e altre funzionalità per individuare e difendersi dai bombardamenti tempestivi.
La risposta appropriata al push-bombing dipende dalla soglia che si è disposti a rispettare. Tuttavia, anche con un solo Push to Authenticate inaspettato, l'utente dovrebbe vedersi interrompere la sessione ed essere costretto a cambiare la password. Ricordate che si tratta di un evento poco frequente. Siate sicuri, non dispiaciuti. La modifica della password impedirà anche potenziali attacchi futuri con quelle specifiche credenziali utente.
Anche se le password stanno dimostrando la loro età, se fanno parte dell'MFA della vostra organizzazione, sviluppate e documentate un processo affidabile per forzare la reimpostazione della password e ottenete il consenso della leadership per attivare la modifica della password e la revoca della sessione in caso di sospetta compromissione. Più a lungo un aggressore ha accesso alla vostra rete, più danni può fare. Considerate i tempi di risposta. Se ricevete un allarme, contattate rapidamente e in modo proattivo gli utenti o i loro manager su un canale fidato e stabilite il meccanismo di contatto più adatto alla vostra organizzazione, ad esempio un modulo di posta elettronica, per far sapere agli utenti e ai loro manager cosa è successo e metterli in allerta. La comunicazione contribuisce a creare un clima di fiducia che darà i suoi frutti in caso di problemi di sicurezza futuri.
Tenete presente che il push-bombing è un tipo di attacco e che dovreste dare priorità a qualsiasi risposta ad esso nel vostro programma generale in relazione alla probabilità e al rischio per il vostro ambiente. Se un attaccante ha successo, dovrete fare affidamento sugli altri controlli di sicurezza per limitare i danni e garantire una rapida ripresa.
