Ultima modifica:
Vulnerabilità critiche nel mondo Automotive: impattate Ferrari, BMW e molti altri brand
Tempo di lettura stimato: 11 minuti
Fonte dell'articolo: Web Hackers vs. The Auto Industry: Critical Vulnerabilities in Ferrari, BMW, Rolls Royce, Porsche, and More1 Pre-ambolo della ricerca
Tutto ha inizio durante la fine del 2022, quando Sam Curry e altri amici stavano visitando l'Università del Maryland e ad un tratto di imbattono in una serie di scooter elettrici sparsi per il campus. Presi dalla tentazione, il gruppo ha dato un'occhiata all'applicazione mobile del vendor. Il risultato è ben "documentato" dal video che hanno fatto:
Segnalata la falla, nei mesi successivi il gruppo ha proseguito la propria ricerca su molti altri brand, incentrando le analisi sulle API utilizzate dai sistemi telematici dei "veicoli connessi" e su potenziali altre falle architetturali.
2 Alcune vulnerabilità interessanti
Vista l'enorme quantità di vulnerabilità che sono state identificate, indicheremo di seguito solo alcune tra quelle più interessanti. Potete (e dovreste 
) comunque leggere l'elenco dettagliato dei findings sul blog ufficiale del ricercatore.
) comunque leggere l'elenco dettagliato dei findings sul blog ufficiale del ricercatore.2.1 Hyundai, Genesis - Full Remote Vehicle Access and Full Account Takeover
Sia l'applicazione di Hyundai, sia quella di Genesis, consentono ai propri utenti di avviare/arrestare/aprire/chiudere il proprio veicolo. Dal momento che i ricercatori disponevano di un veicolo Hyundai, hanno iniziato ad intercettare ed analizzare le richieste HTTP eseguite dall'applicazione verso le rispettive API.
Una richiesta di esempio per aprire il veicolo è la seguente (l'access token è il JWT generato a seguito del login):
HTTP:
POST /ac/v2/rcs/rdo/unlock HTTP/1.1
Access_token: token
{"userName":"EMAIL","vin":"VIN"}
La costa strana di questa richiesta è che l'email dell'utente viene nuovamente inviata al server all'interno del body della richiesta POST, quando in realtà il server dovrebbe ricavarsela dall'access token. Come reagisce il server se inviamo una email differente da quella utilizzata per loggarsi?
Se si modifica il parametro email con qualcosa di diverso dall'email del JWT, il server restituisce "unauthorized". Sembra che il server confronti l'email inviata nel JSON con l'indirizzo email estratto dal nostro JWT, eseguendo una sorta di pre-flight check... E' necessario trovare un modo per ingannare il server e far sì che l'e-mail della vittima venga accettata.
Giocando con la registrazione di un utente, i ricercatori hanno scoperto che non il server non richiedeva la conferma dell'email all'utente e che inoltre permetteva di inserire caratteri pericolosi all'interno del campo email:
Se si modifica il parametro email con qualcosa di diverso dall'email del JWT, il server restituisce "unauthorized". Sembra che il server confronti l'email inviata nel JSON con l'indirizzo email estratto dal nostro JWT, eseguendo una sorta di pre-flight check... E' necessario trovare un modo per ingannare il server e far sì che l'e-mail della vittima venga accettata.
Giocando con la registrazione di un utente, i ricercatori hanno scoperto che non il server non richiedeva la conferma dell'email all'utente e che inoltre permetteva di inserire caratteri pericolosi all'interno del campo email:
Dopo numerosi tentativi, grazie a questa falla i ricercatori sono riusciti a registrare due account "differenti" aventi però la stessa email in comune:
Codice:
Victim email:
[email protected]
Attacker email:
[email protected]%0dPer verificare il corretto funzionamento della vulnerabilità hanno quindi inviato una richiesta HTTP all'endpoint che elenca i veicoli abbinati all'account in questione, ottenendo tutti i VIN della vittima:
Codice:
Email nel JWT: [email protected]%0d
Parametro JSON: [email protected]
Con la stessa tecnica hanno quindi provato ad aprire da remoto ed accendere il veicolo della "vittima" (posseduto comunque dai ricercatori), confermando l'impatto e la criticità della falla. Grazie a questa sequenza era infatti possibile controllare OGNI veicolo di OGNI utente appartenenti ai vendor Hyundai e Genesis:
2.2 Nissan, Infinity - Full Vehicle Takeover via Mass Assignment
L'applicazione telefonica di Nissan è piuttosto semplice: si crea un account, si aggiunge la propria auto fornendo una prova di proprietà, e, dopo quello che si presume essere un processo di approvazione manuale, l'auto viene associata al proprio account per poterla comandare a distanza.
La domanda nasce spontanea: può un ipotetico attaccante aggirare il caricamento manuale dei documenti del veicolo e registrare così un'auto senza esserne il vero proprietario, conoscendone "solo" il VIN?
La richiesta inviata a seguito della registrazione è la seguente:
Il JSON contiene diverse informazioni, tra cui il VIN, l'email e i dati personali inseriti dall'utente, ma anche il campo
"accountSource": "customer". Questo campo è interessante: cosa succede se lo si modifica e si invia "dealer" al posto di "customer"?
Ha funzionato! La modifica ha completamente bypassato il caricamento della documentazione e ha permesso di inviare comandi arbitrari al veicolo registrato, permettendo di aprirlo, accenderlo e, soprattutto, tracciarlo per tutta la città.
2.3 Spireon - SQL Injection & Authorization Bypass to compromise 15 mln telematics systems
All'inizio degli anni '90 e 2000 c'erano alcune società come OnStar, Goldstar e FleetLocate che offrivano dispositivi autonomi installabili nei veicoli per tracciarli e comandarli da remoto. Spireon ha poi acquistato molte di queste società, radunandole tutte quante sotto lo stesso tetto.
Spireon è stato un target molto promettente data l'affermazione fatta dell'azienda sul loro sito marketing di possedere oltre 15 milioni di veicoli connessi. Compromettere le funzionalità di amministrazione di questi dispositivi vorrebbe dire essere in grado di eseguire azioni contro oltre 15 milioni di veicoli con funzionalità molto interessanti, come ad esempio inviare finti segnali agli agenti di polizia di una città, disabilitare l'avviamento dei veicoli, ecc.
Il target di partenza è stato, ovviamente, admin.spireon.com, che si presenta come un portale di amministrazione molto datato:
Provando i classici payload manuali di SQL Injection si viene respinti da un WAF, ma provando un approccio più metodico, inviando prima un singolo apice, poi due, e comparando i risultati, è possibile notare che il form va in errore con un numero dispari di apici e che molto probabilmente è vulnerabile!
Il payload è molto semplice:
victim' # e taglia semplicemente il controllo della password dalla query. In questo modo è possibile loggarsi con una qualsiasi password come utenti "admin" o "administrator" ed accedere alla pagina /dashboard (oltre a tutte le altre pagine del portale).
Tramite una delle pagine del portale era possibile interrogare tutti i dispositivi Spireon, compresi quelli delle vecchie compagnie, recuperare la posizione in tempo reale di qualsiasi dispositivo, inviargli comandi arbitrari e svolgere altre azioni critiche. Ulteriori analisi però hanno condotto alla scoperta dell'url di backend delle API utilizzate dal portale, che sarebbe dovuto essere esposto solo in intranet ma che invece era raggiungibile anche da rete pubblica.
Fuzzando il backend in cerca di qualche errore di autorizzazione che permettesse di identificare i vari endpoint, i ricercatori hanno individuato alcuni comportamenti anomali dell'applicazione: inviando una qualsiasi stringa con "admin" o "dashboard", il sistema triggera una risposta HTTP 403 forbidden, ma restituisce 404 se invece non si include questa stringa.
Codice:
GET /anything-admin-anything --> HTTP 403 Forbidden
GET /anything-anything --> HTTP 404 Not FoundI ricercatori hanno quindi preso le parole bannate e le hanno aggiunte a una custom wordlist avente i caratteri di fuzzing (da %00 a %FF) inseriti dietro il primo e dopo l'ultimo carattere delle parole. Durante la scansione, hanno notato che due particolari richieste HTTP restituivano una risposta
200 OK:
Codice:
GET /%0dadmin
GET /%0ddashboardSi trattava di un portale amministrativo per gestire completamente l'applicazione principale di Spireon, con decine di endpoint utilizzati per interrogare tutti i veicoli connessi, inviare loro comandi, visualizzare tutte le informazioni dei clienti e tanto altro.
Accesso TOTALE su 15 milioni di device, tra cui apparati di ordine pubblico, della sanità e militari
3 Crediti ai ricercatori
Di seguito l'elenco dei vari ricercatori che hanno contribuito alla scoperta delle falle:
- Sam Curry (https://twitter.com/samwcyo)
- Neiko Rivera (https://twitter.com/_specters_)
- Brett Buerhaus (https://twitter.com/bbuerhaus)
- Maik Robert (https://twitter.com/xEHLE_)
- Ian Carroll (https://twitter.com/iangcarroll)
- Justin Rhinehart (https://twitter.com/sshell_)
- Shubham Shah (https://twitter.com/infosec_au)
4 Conclusioni
Ho trovato il lavoro di ricerca davvero molto interessante e ricco di spunti, sia professionalmente, sia dal punto di vista personale. Consiglio ancora una volta a tutti quanti di leggere l'articolo originale poiché molto più dettagliato e con molte più vulnerabilità di quelle raccontate in questo post, ma soprattutto assorbitene il maggior numero possibile di informazioni e di tecniche.
Ancora una volta si è dimostrato come la tecnologia corra e si evolva rapidamente - con veicoli connessi ad internet, auto-piloti, intelligenze artificiali, ecc. - ma di come nonostante tutto il processo di messa in sicurezza dei vari apparati non riesca a seguire questo trend evolutivo di pari passo. Dove si debbano ricercare le colpe è ancora poco chiaro. Nell'incompetenza degli addetti ai lavori? O nelle "esigenze di business" sempre più frenetiche e avanguardistiche?
Non si sa, ma resta il fatto che mi sorge un grande dubbio vista la scarsa attenzione posta alla sicurezza da parte di questi grandi brand:
Ancora una volta si è dimostrato come la tecnologia corra e si evolva rapidamente - con veicoli connessi ad internet, auto-piloti, intelligenze artificiali, ecc. - ma di come nonostante tutto il processo di messa in sicurezza dei vari apparati non riesca a seguire questo trend evolutivo di pari passo. Dove si debbano ricercare le colpe è ancora poco chiaro. Nell'incompetenza degli addetti ai lavori? O nelle "esigenze di business" sempre più frenetiche e avanguardistiche?
Non si sa, ma resta il fatto che mi sorge un grande dubbio vista la scarsa attenzione posta alla sicurezza da parte di questi grandi brand:
- I tempi sono davvero maturi per poterci permettere dei veicoli così avanzati, senza che compromettano la sicurezza e privacy di ogni utente?
- Non è forse il caso di rallentare questa pazza corsa all'avanguardia tecnologica e concentrarsi maggiormente sul creare prodotti sicuri dal day one?
Made with ❤ for Inforge
