Guida pratica di Microsoft per capire gli attacchi Pre-Hijacking su come si comportano gli hacker e come difendersi per non cascarci
Microsoft ha pubblicato un report dettagliato su come gli hacker compiono un attacco denominato pre-hijacking che permette di accedere ad un accesso ad un qualsiasi account web senza che un utente completi la registrazione al servizio. Il report ha messo sotto analisi ben 75 siti popolari ed il risulto che quasi il 50% di questi (35) sono vulnerabili a questa tipologia di attacco.
L’accesso avviene creando un account usando l’email dell’utente vittima, accedendo al suo account e completando la registrazione. Ecco come agiscono in dettaglio gli hacker con tutti i passaggi spiegati in dettaglio. Inoltre al fondo trovate alcuni spunti su come proteggervi.
Ecco un esempio di attacco Pre-Hijacking
1. Classic-Federated Merge Attack sfrutta una potenziale debolezza nell’interazione tra i percorsi classici e federati per la creazione di account. L’attaccante utilizza l’indirizzo e-mail della vittima per creare un account tramite il percorso classico e la vittima crea successivamente un account tramite il percorso federato, utilizzando lo stesso indirizzo e-mail. Se il servizio unisce questi due account in modo non sicuro, la vittima e l’aggressore potrebbero avere accesso allo stesso account.

2. Unexpired Session Identifier Attack sfrutta una vulnerabilità in cui gli utenti autenticati non vengono disconnessi da un account quando l’utente reimposta la password. L’attaccante crea un account utilizzando l’indirizzo e-mail della vittima e quindi mantiene una sessione attiva. Quando la vittima recupera l’account, l’attaccante potrebbe ancora avere accesso se la reimpostazione della password non ha invalidato la sessione dell’attaccante.
3. Trojan Identifier Attack sfrutta la possibilità per l’attaccante di collegare un identificatore aggiuntivo a un account creato utilizzando il percorso classico di nome utente e password. L’attaccante crea un account utilizzando l’indirizzo e-mail della vittima e quindi aggiunge un identificatore aggiuntivo (ad es. l’identità federata dell’attaccante o un altro indirizzo e-mail o numero di telefono controllato dall’attaccante) all’account. Quando la vittima reimposta la password, l’attaccante può utilizzare l’identificatore inserito per accedere all’account (ad esempio reimpostando la password o richiedendo un collegamento di accesso una tantum).
4. Unexpired Email Change Attack sfrutta una potenziale vulnerabilità in cui il servizio non invalida gli URL con funzionalità di modifica delle e-mail quando l’utente reimposta la password. L’attaccante crea un account utilizzando l’indirizzo e-mail della vittima e inizia il processo di modifica dell’indirizzo e-mail dell’account in modo che sia l’indirizzo e-mail dell’attaccante. Come parte di questo processo, il servizio in genere invia un URL di verifica all’indirizzo e-mail dell’attaccante, ma l’attaccante non conferma ancora la modifica. Dopo che la vittima ha recuperato l’account e ha iniziato a utilizzarlo, l’attaccante completa il processo di modifica dell’e-mail per assumere il controllo dell’account.
5. Non-Verifying IdP Attack questo attacco è l’immagine speculare dell’attacco di intrusione federato classico. L’autore dell’attacco sfrutta un IdP che non verifica la proprietà di un indirizzo e-mail durante la creazione di un’identità federata. Utilizzando questo IdP non verificante, l’attaccante crea un account con il servizio di destinazione e attende che la vittima crei un account utilizzando il percorso classico. Se il servizio combina erroneamente questi due account in base all’indirizzo e-mail, l’attaccante sarà in grado di accedere all’account della vittima.
Come difendersi da questi attacchi
Reimpostare la password quando la password dell’account viene reimpostata, il servizio deve eseguire le seguenti azioni
- Disconnettersi da tutte le altre sessioni e invalidare tutti gli altri token di autenticazione per quell’account per mitigare l’attacco della sessione non scaduta.
- Annullare tutte le azioni di modifica dell’e-mail in sospeso per quell’account per mitigare l’attacco di modifica dell’e-mail non scaduta.
- Avvisare l’utente di quali identità, indirizzi email e numeri di telefono sono collegati all’account e chiedere all’utente di selezionare eventuali identificatori che non riconoscono o più preferibilmente, di selezionare quali da conservare.
Unire diversi account quando un servizio unisce un account creato tramite il percorso classico con uno creato tramite il percorso federato (o viceversa), il servizio deve garantire che l’utente controlli entrambi gli account. Ad esempio, quando l’utente tenta di creare un account tramite il percorso federato ma esiste già un account classico per lo stesso indirizzo e-mail, all’utente dovrebbe essere richiesto di fornire le credenziali o di reimpostare la password per l’account.
Confermare la modifica dell’e-mail quando il servizio invia una funzionalità per confermare una modifica dell’indirizzo e-mail (ad esempio, un codice o un URL con un token di autenticazione incluso), il periodo di validità di questa funzionalità dovrebbe essere il più basso possibile, entro i limiti dell’usabilità, per ridurre al minimo la finestra di vulnerabilità per l’attacco Unexpired Email Change. Tuttavia, ciò non impedirà all’attaccante di richiedere continuamente nuove funzionalità, quindi il servizio dovrebbe limitare il numero di volte in cui una nuova funzionalità può essere richiesta per un identificatore non verificato.
Eliminare degli account non verificati l’eliminazione regolare degli account non verificati ridurrebbe la finestra di vulnerabilità per la maggior parte degli attacchi di pre-hijacking (ad eccezione dell’attacco IdP non verificato). Tuttavia, ciò non impedirà a un utente malintenzionato di creare nuovi account con gli stessi identificatori. Il servizio dovrebbe quindi monitorare e potenzialmente limitare il numero di volte in cui è possibile creare un nuovo account per lo stesso identificatore non verificato. Tuttavia, questo potrebbe essere utilizzato per montare un attacco Denial-of-Service (DoS) esaurendo la quota di creazione dell’account degli identificatori degli utenti legittimi. Pertanto, il servizio potrebbe invece ridurre la soglia di eliminazione degli account non verificati e sfruttare i framework di rilevamento dei bot per limitare la velocità con cui l’attaccante può creare automaticamente nuovi account.
Autenticazione a più fattori (MFA) gli utenti possono proteggersi dagli attacchi di pre-hijacking attivando l’MFA sui propri account il prima possibile. L’autenticazione a più fattori correttamente implementata impedirà all’attaccante di autenticarsi su un account pre-dirottato dopo che la vittima ha iniziato a utilizzare questo account. Il servizio deve inoltre invalidare tutte le sessioni create prima dell’attivazione di MFA per prevenire l’attacco Unexpired Session.
INDICE DEI CONTENUTI
Lascia un commento
Visualizza commenti