Una falla logica nel sistema di autenticazione forte dell’app PosteID è stata recentemente individuata grazie a un’attività di ricerca applicata sulle vulnerabilità (hacking etico) svolta nell’ambito del progetto Securing softWare frOm first PrincipleS (SWOPS), che afferisce allo Spoke 6 della Fondazione Security and Rights in CyberSpace (SERICS), fondazione che ha come scopo principale la ricerca scientifica e tecnologica in ambito cyber security.

La ricerca, condivisa preventivamente con Poste Italiane, ha permesso di attivare un percorso di risoluzione e aggiornamento delle procedure di sicurezza a tutela degli utenti finali.

Il beneficio di resilienza complessiva dato dalla chiusura della falla è il risultato di due elementi complementari e paralleli: il rispetto di una appropriata e concordata tempistica di divulgazione della vulnerabilità, cosiddetta responsible disclosure (solitamente allineata ai tempi della Policy di Divulgazione Vulnerabilità, VDP) da parte dei ricercatori SERICS e l’attivazione del processo di gestione della vulnerabilità (Vulnerability management – VM) da parte del team di security dell’Identity provider Poste che ha risolto il problema rendendo irripetibile l’attacco.

Tutto è stato documentato nel paper di ricerca dal titolo “The Postman: A Journey of Ethical Hacking in PosteID/SPID Borderland” pubblicato su Arxiv.org.

Vulnerabilità nell’app PosteID: dalla scoperta alla risoluzione

L’analisi è stata condotta da Gabriele Costa, professore associato di informatica e leader del progetto SWOPS di SERICS insieme a Federico Chiesa, laureato in Informatica dell’Università di Firenze.

La falla è stata identificata nel meccanismo di registrazione di un nuovo dispositivo nell’ambito del processo di autenticazione SPID tramite app PosteID (Android application), uno degli strumenti più diffusi per l’accesso ai servizi digitali della pubblica amministrazione.

L’attività è formalmente iniziata nell’ottobre 2023, quando da parte dei ricercatori è stata richiesta l’autorizzazione per effettuare una valutazione di sicurezza dell’applicazione Android PosteID.4 ricevendo un ok a procedere.

Successivamente, la valutazione della sicurezza è stata condotta fino al maggio 2024, quando una vulnerabilità è stata identificata e confermata tramite un exploit proof-of-concept.

La divulgazione e collaborazione con l’identity provider ha permesso, dopo una serie di incontri, di presentare, documentare e dimostrare la vulnerabilità, nonché di dimostrare la potenziale ripetitività dell’attacco di escalation dei privilegi che permette in sostanza di autenticare un nuovo dispositivo Android come Client SPID lecito (anche se invece è opera di un avversario malevolo) e di eliminare il dispositivo dell’utente originale che, da quel momento veniva escluso, dalle interazioni dell’app.

In particolare, è attraverso tecniche di reverse engineering e di analisi dinamica, che i ricercatori hanno individuato la falla legata ai sistemi operativi Android che, in specifiche condizioni, avrebbe permesso una azione malevola di registrazione fraudolenta di un nuovo dispositivo aggirando la procedura di identificazione ‘forte’ senza il consenso dell’utente vero e proprio.

La vulnerabilità è stata classificata con un livello di rischio CVSS pari a 8,3 e i ricercatori hanno suggerito appropriate contromisure che sono state prese in carico dal team di sicurezza di poste ID.

La nuova release dell’applicazione è stata rilasciata a marzo 2025 e dopo le verifiche finali di impossibilità di ripetizione dell’attacco, il paper di ricerca ha potuto essere pubblicato a luglio 2025, dando evidenza di tutti i passaggi e degli strumenti sviluppati e utilizzati.

Il punto di criticità

La criticità che ha permesso di identificare la vulnerabilità è legata all’uso di SMS come mezzo di verifica OTP.

Infatti, ripercorrendo il procedimento dimostrativo del problema il punto critico viene evidenziato: l’avvio della dimostrazione è rappresentato dalla installazione, da parte di un ipotetico utente di un’app apparentemente innocua pubblicata su Google Play da parte di un avversario malevolo; l’app è malevola perché progettata per fingersi come un nuovo dispositivo verso l’app di Poste ID.

Utilizzando le credenziali di base (livello 1, username e password), l’accesso alla rete e la possibilità di leggere gli SMS dell’utente lecito, l’app malevola intercetta il codice OTP (un codice univoco che dovrebbe funzionare da verifica di autenticazione forte per un utente di app Poste ID che volesse registrare un altro dispositivo come client autenticato) e completa la procedura d’iscrizione (enrollment), associando se stessa come fosse un dispositivo all’identità digitale dell’utente che, a sua volta, viene estromesso perché l’app malevola a quel punto può cancellare gli altri dispositivi precedentemente registrati.

Il meccanismo appena descritto avrebbe garantito ad un avversario digitale di ottenere accesso ai servizi SPID, escludendo l’utente legittimo e potenzialmente operando sui suoi servizi critici come il conto corrente o la richiesta di certificati personali.

Cosa imparare da questa ricerca

Vi sono diversi insegnamenti che si possono trarre da quanto accaduto.

Rispetto di linee guida e best practice come elemento prioritario

L’uso degli SMS come meccanismo di autenticazione out-of-band è sconsigliato sia dalle linee guida NIST (digital identity guidelines), sia dal PCI-CSS in materia di autenticazione multifattore. Infatti entrambe disapprovano l’utilizzo dell’autenticazione a mezzo SMS, perché gli SMS sono vulnerabili a intercettazione (attacchi man-in-the-middle), reindirizzamento, furto dell’identità (SIM swapping).

È auspicabile, quindi, che qualsiasi app in commercio sia verificata da questo punto di vista per rendere il processo di autenticazione forte non basato su SMS, bensì su metodi e contromisure indicati come più sicuri da NIST e PCI-DSS.

In caso si abbiano dubbi sulle proprie applicazioni aziendali e sui criteri di autenticazione forte adottati è consigliabile contattare i ricercatori SERICS per far valutare e testare le proprie applicazioni.

Valutazione attenta della fase di design di una applicazione

Tale valutazione andrebbe effettuata con appropriati test di verifica, perché in caso di problemi non riscontrati per tempo, il rimedio ultimo potrebbe dover essere la riprogettazione dell’intero sistema con correlati costi aggiuntivi.

Collaborazione efficace fra i team di security

Un altro passaggio importante è rappresentato dalla collaborazione efficace tra i team di security del soggetto proprietario del sistema vulnerabile e i team di test/ricerca applicata delle vulnerabilità (hacking etico) rispettando i tempi di divulgazione della vulnerabilità (Responsible disclosure o nel rispetto di una eventuale policy per la disclosure della vulnerabilità, VDP) e governando efficacemente il processo di gestione stessa della vulnerabilità per arrivare alla sua chiusura e risoluzione in un contesto protetto per tutte le parti interessate.

Resilienza aumentata

Ciò è possibile grazie al binomio ricerca-applicazioni aziendali. Il codice dimostrativo dell’attacco è stato sviluppato da Federico Chiesa come parte del suo percorso di studio, e rappresenta un esempio concreto di come la ricerca applicata possa essere un valido strumento di aumento della resilienza per le aziende di ogni ordine e grado.