In questo articolo Indice dei contenuti 3 sezioni
Partire da una semplice targa e arrivare ad aprire le portiere di un’auto connessa, fino ad avviarne il motore da remoto. È quanto sono riusciti a fare i ricercatori Shubham Shah e Sam Curry durante un’indagine condotta nel corso del 2026, che ha portato alla luce una catena di problemi di sicurezza nei sistemi di autenticazione usati da 2 produttori automobilistici. Non c’era bisogno di manomettere la centralina elettronica né di intercettare il segnale della chiave. Bastava una vulnerabilità nei servizi cloud per ottenere gli stessi privilegi del legittimo proprietario.
Le app che permettono di gestire la propria auto connessa dallo smartphone esistono da oltre un decennio, ma con la crescita delle funzioni telematiche le conseguenze di un accesso abusivo sono diventate molto più serie. Nei test documentati i due esperti hanno inviato comandi a veicoli reali, spingendo le aziende coinvolte a rilasciare correzioni.
Dalla targa all’account del proprietario
Tutto è cominciato dall’app Android di uno dei costruttori. Shah ha analizzato il pacchetto APK ricostruendo le chiamate HTTP verso i server della casa madre, con l’obiettivo di capire quali servizi ricevessero i comandi per aprire le portiere o consultare le informazioni del veicolo. Tra i sottodomini accessibili pubblicamente è spuntato uno strumento amministrativo chiamato TEST HARNESS, il cui codice JavaScript conteneva chiavi API incorporate, sufficienti per interrogare diverse interfacce dedicate alla gestione di account e automobili.
In Australia, grazie ai servizi di consultazione delle immatricolazioni, dalla targa si può risalire al VIN, cioè il codice identificativo univoco del mezzo. Gli endpoint scoperti permettevano poi di collegare il VIN all’identificativo dell’utente e di recuperarne i dati personali, email compresa. Scavando ancora nei file dell’applicazione Web sono emerse credenziali amministrative di ForgeRock OpenIDM, la componente usata dal produttore per gestire le identità. Sembravano appartenere a un ambiente di test, eppure funzionavano anche in produzione. Un errore grave, perché lasciare segreti di questo tipo nel JavaScript distribuito agli utenti significa metterli a disposizione di chiunque scarichi quei file. Giocando con segmenti di percorso e caratteri codificati, i ricercatori hanno poi trovato un indirizzo capace di raggiungere le API interne sfruttando una forma di path confusion, in cui due componenti leggono lo stesso URL in modo diverso. Dopo vari tentativi manuali andati a vuoto, Shah si è affidato a un modello di intelligenza artificiale di OpenAI per esaminare il codice sorgente di OpenIDM e trovare la combinazione giusta.
Password modificate e verifica multifattore aggirata
Arrivati alle interfacce amministrative, i ricercatori potevano cambiare la password dei profili utente. Restava l’ostacolo dell’autenticazione a più fattori, che in teoria dovrebbe resistere anche a una password modificata. Una configurazione OAuth però consentiva di ottenere token inviando direttamente le credenziali e, con un successivo scambio di token, si otteneva una sessione valida per l’app senza passare dalla verifica aggiuntiva. A quel punto le API REST e GraphQL accettavano le stesse richieste dell’app ufficiale, dall’apertura e chiusura delle portiere all’avvio del motore.
Negli Stati Uniti la catena si è fatta ancora più articolata. Sfruttando una differenza nel modo in cui il Web Application Firewall e il server Java Jetty interpretavano gli URL, gli esperti hanno raggiunto la console amministrativa di Apache Felix, parte dell’architettura OSGi di OpenIDM, arrivando a eseguire codice sui server di produzione in una vera condizione di Remote Code Execution. Da lì sono passati alle API amministrative tramite localhost, hanno recuperato le credenziali interne e modificato email e password di account di prova autorizzati. Il normale processo di accesso, verifica OTP inclusa, ha fornito token validi per i servizi telematici, con accesso a posizione del veicolo, dati diagnostici e comandi remoti. L’intera catena è stata verificata su account e automobili statunitensi, mentre i sistemi di identità coinvolti includevano directory di più regioni.
Correzioni in circa 2 ore e nomi tenuti riservati
Le due case automobilistiche hanno sistemato le vulnerabilità e cambiato le credenziali compromesse in circa 2 ore dalla segnalazione. La vicenda ricorda quali siano le misure minime da non trascurare mai, cioè eliminare le credenziali predefinite, chiudere al pubblico le console amministrative, tenere i segreti fuori dai bundle JavaScript e assicurarsi che firewall e applicazioni leggano gli URL allo stesso modo. Servono anche controlli di autorizzazione sulle singole operazioni e non solo sulla validità dei token OAuth, oltre a verifiche aggiuntive per le funzioni più delicate, visto che il semplice possesso di un token non dovrebbe aprire la strada ai comandi fisici dell’auto connessa. Per gli automobilisti aggiornare l’app, proteggere l’account e attivare la verifica multifattore resta utile, anche se nessuna di queste accortezze può bloccare falle capaci di scavalcare del tutto l’autenticazione.
Quanto all’identità dei produttori, Shah e Curry hanno scelto di non rivelarla, oscurando anche domini, identificativi delle applicazioni e ogni altro riferimento che avrebbe permesso di riconoscere i marchi coinvolti.
Fonte: TecnoAndroid