Dalla targa allo sblocco dell'auto: così una falla esponeva veicoli connessi

Una targa automobilistica può diventare il punto di partenza per prendere il controllo di un’auto connessa, aprirne le portiere e persino avviare il motore da remoto. Non serviva compromettere la centralina elettronica o intercettare il segnale della chiave: una vulnerabilità nei servizi cloud può consentire di ottenere gli stessi privilegi del proprietario. È quanto hanno dimostrato i ricercatori Shubham Shah e Sam Curry, individuando una catena di problemi di sicurezza nei sistemi di autenticazione utilizzati da 2 produttori automobilistici.

La ricerca racconta un’indagine condotta nel corso del 2026. Le applicazioni per gestire le auto tramite smartphone esistono da oltre un decennio, ma la crescente disponibilità di funzioni telematiche ha ampliato le conseguenze di un eventuale accesso abusivo.

Nei test documentati, gli esperti sono riusciti a inviare comandi a veicoli reali portando le aziende coinvolte a rilasciare correzioni per i problemi scoperti.

Come una targa può portare all’account del proprietario

L’indagine è partita dall’analisi dell’app Android di uno dei produttori automotive. Shah ha esaminato il pacchetto APK, ricostruendo le chiamate HTTP verso i server della casa costruttrice: l’obiettivo era individuare i servizi che ricevono i comandi per aprire le portiere, consultare le informazioni del veicolo e gestire le altre funzioni a distanza.

Tra i sottodomini accessibili pubblicamente è comparso uno strumento amministrativo denominato TEST HARNESS: il relativo codice JavaScript conteneva chiavi API incorporate, sufficienti per interrogare diverse interfacce destinate alla gestione degli account e delle automobili.

In Australia, attraverso servizi di consultazione delle immatricolazioni, è possibile risalire dal numero di targa al VIN (Vehicle Identification Number), identificativo univoco del veicolo. Gli endpoint individuati consentivano poi di collegare il VIN all’identificativo dell’utente e recuperare informazioni personali, compreso l’indirizzo email associato all’account. Già questo è un grosso problema.

Credenziali amministrative nascoste nel JavaScript

Analizzando ulteriormente i file dell’applicazione Web, i ricercatori hanno individuato credenziali amministrative relative a ForgeRock OpenIDM, componente della piattaforma di gestione delle identità utilizzata dal produttore.

Le credenziali sembravano appartenere a un ambiente di staging, impiegato per i test; funzionavano però anche sui sistemi di produzione. Un errore grave: distribuire segreti amministrativi nel JavaScript utilizzato dagli utenti finali significa renderli recuperabili da chiunque possa scaricare quei file.

Combinando segmenti di percorso e caratteri codificati, i ricercatori hanno individuato una struttura di URL che permetteva di raggiungere le API interne del servizio. Si tratta di una forma di path confusion: due componenti elaborano lo stesso indirizzo in maniera differente, creando opportunità per aggirare le restrizioni.

Shah racconta anche un dettaglio interessante: dopo diversi tentativi manuali falliti, ha utilizzato OpenAI GPT-5.6 Sol Ultra per analizzare il codice sorgente di OpenIDM e individuare una combinazione di percorso che funzionasse correttamente.

Il problema più grave: modificare le password e aggirare l’MFA

Una volta raggiunte le interfacce amministrative, i ricercatori potevano intervenire sui profili utente, modificandone la password mediante le API di OpenIDM.

Restava però un ostacolo: l’autenticazione a più fattori (MFA): cambiare una password non dovrebbe permettere di superare anche la verifica aggiuntiva richiesta dall’applicazione. Nell’implementazione in questione, tuttavia, una configurazione OAuth consentiva di ottenere token attraverso la trasmissione diretta delle credenziali.

Combinando tale meccanismo con un successivo scambio dei token, gli esperti potevano ottenere una sessione utilizzabile dall’app mobile senza completare la normale verifica multifattore.

Con il token dell’utente, le API REST e GraphQL accettavano richieste analoghe a quelle inviate dall’applicazione ufficiale: apertura e chiusura delle portiere, avvio del motore e altre operazioni.

Negli Stati Uniti l’attacco è arrivato fino ai server di autenticazione

La seconda parte della ricerca descrive una catena ancora più articolata: gli esperti hanno sfruttato una differenza nell’interpretazione degli URL tra il WAF (Web Application Firewall) e il server Java Jetty per raggiungere la console amministrativa di Apache Felix, componente utilizzato nell’architettura OSGi di OpenIDM. I ricercatori hanno addirittura ottenuto la possibilità di eseguire codice sui server di produzione, una vera e propria condizione di Remote Code Execution (RCE).

Da lì hanno raggiunto le API amministrative tramite localhost, recuperato le credenziali interne e modificato email e password di account di prova autorizzati. Il normale processo di autenticazione, compresa la verifica OTP, ha quindi consentito di ottenere token validi per i servizi telematici.

I test hanno dimostrato accesso alla posizione del veicolo, ai dati diagnostici e ai comandi remoti. Gli autori precisano che il completamento dell’intera catena è stato verificato su account e automobili statunitensi, mentre l’accesso ai sistemi di identità coinvolgeva directory presenti in più regioni.

Come impedire che un difetto del cloud diventi un rischio per l’automobile

Le due case automobilistiche, come accennato in apertura, hanno corretto le vulnerabilità e ruotato le credenziali compromesse in circa 2 ore dalla segnalazione.

Ancora una volta, la vicenda ha evidenziato lacune sul piano della sicurezza che interessano anche società di grandi dimensioni, come i produttori di veicoli. Eliminare le credenziali predefinite, impedire l’accesso pubblico alle console amministrative, custodire i segreti fuori dai bundle JavaScript e verificare che firewall e applicazioni interpretino gli URL allo stesso modo sono misure di sicurezza minime per le quali non bisognerebbe mai scendere a compromessi. Servono inoltre controlli di autorizzazione sulle singole operazioni, non soltanto sulla validità dei token OAuth.

Le funzioni più sensibili dovrebbero richiedere una verifica aggiuntiva dell’identità e una gestione rigorosa delle sessioni: il semplice possesso di un token non dovrebbe garantire automaticamente accesso illimitato ai comandi fisici del veicolo.

Per gli automobilisti, invece, aggiornare l’app, proteggere l’account e attivare MFA resta importante, ma sono attenzioni che ovviamente non possono risolvere vulnerabilità che consentono di aggirare completamente l’autenticazione.

Quali case automobilistiche sono coinvolte? I nomi restano un mistero

I ricercatori hanno scelto di non rivelare i nomi delle case automobilistiche coinvolte, oscurando anche domini, identificativi delle applicazioni e altri riferimenti che avrebbero permesso di riconoscerle. Gli autori non spiegano esplicitamente le ragioni della scelta, ma la decisione appare coerente con la volontà di evitare ulteriori rischi per gli automobilisti e concentrarsi sulle vulnerabilità tecniche, già corrette dopo la segnalazione.

Va detto però che, “unendo i puntini” e incrociando gli indizi disseminati nei resoconti tecnici, è possibile formulare supposizioni piuttosto convincenti sull’identità dei produttori. Preferiamo comunque rispettare la riservatezza mantenuta dagli autori della ricerca: i nomi, anche se sospettiamo di averli individuati, non li riveleremo neanche sotto tortura.