Discussione Vulnerabilità critiche nel mondo Automotive: impattate Ferrari, BMW e molti altri brand

Stato
Discussione chiusa ad ulteriori risposte.

0xbro

Super Moderatore
24 Febbraio 2017
4,464
179
3,755
1,825
Ultima modifica:
Alcuni ricercatori hanno scoperto una lunga serie di vulnerabilità critiche sui più noti brand automobilistici, alcune delle quali permettevano di aprire, chiudere ed accendere veicoli da remoto.​

img1.jpg


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 More








1     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.​

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.

FiwJWlXXoAMAvmj


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"}

FiwOW57X0AMnI2g


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:​

FiwSytJXoAIoNH2


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]%0d

Per 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]

FiwWw9vX0AATjzN


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.

Fi0po-uVIAI6vOv


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:

Fi0q9OdUUAEGsJd


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"?

Fi0sqCoVQAE9D56


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à.​

Fi0tby1VEAEz5CW


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:

image29.png


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).

image18.png


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 Found

I 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 /%0ddashboard

Si 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​


image1.png


image3.png


device-search-1.png


fleetlocate-1024x506.png


3    Crediti ai ricercatori


Di seguito l'elenco dei vari ricercatori che hanno contribuito alla scoperta delle falle:

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:​
  • 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?​
Io le mie idee credo di essermele fatte, e voi?


Made with ❤ for Inforge

 
Articolo molto interessante.

L'idea che mi sono fatto io è le case automobilistiche stanno correndo più veloce delle competenze che hanno i programmatori che stanno lavorando per loro.
Posso capire che devono lavorare con tempi molto stretti, ma se ci va di mezzo la salute delle persone, piuttosto non fate niente.
Non si può mettere su un sistema con delle falle del genere, non ci possono essere scuse valide.
Bisogna scrivere un software completamente testato con test automatici, devono esserci esperti di sicurezza che controllano bene il codice, devono esserci audit interni ed esterni per valutare tutto...
 
  • Grazie
Reazioni: 0xbro
Ultima modifica:
Questo articolo è una miniera d'oro per gli appassionati di cybersicurezza. Grazie @0xbro! Io personalmente credo che le falle di sicurezza non siano imputabili alle carenze degli sviluppatori, ma piuttosto alla frettolosità nella realizzazione di questi progetti. Manca un vero e proprio piano di sicurezza metodico, che queste aziende trascurano anche per motivazioni economiche. Ma trascurare una cosa del genere è da folli: infatti risparmiare sulla sicurezza, soprattutto oggi, significa fallimento sicuro in caso di compromissione dei sistemi informatici. Questo perché la reputazione dell'azienda/progetto viene rovinata irrimediabilmente. Si pensi alla recente falla scoperta nei sistemi di logging log4j, nonostante la vulnerabilità sia stata fixata nessuno tornerà più ad usare quella libreria.
 
  • Grazie
Reazioni: 0xbro
Non si può mettere su un sistema con delle falle del genere, non ci possono essere scuse valide.
Io personalmente credo che le falle di sicurezza non siano imputabili alle carenze degli sviluppatori, ma piuttosto alla frettolosità nella realizzazione di questi progetti. Manca un vero e proprio piano di sicurezza metodico, che queste aziende trascurano anche per motivazioni economiche.

Sì sono assolutamente d'accordo, bisognerebbe rallentare un po' i tempi e assicurarsi prima di lanciare il prodotto sul mercato che questo sia effettivamente sicuro, in maniera metodica. Ma soprattutto mi ha lasciato senza parole l'utilizzo di software vecchio e mai aggiornato (come nel caso di Spireon), vulnerabile a una classicissima SQL Injection! Sembra quasi che abbiano messo il WAF come per dire "il programma è troppo vecchio, non ho voglia di cercare le vulnerabilità, faccio che mettere un filtro davanti e via così"... davvero senza parole.
 
Ultima modifica:
Articolo davvero interessante, il fatto che queste applicazioni abbiano delle falle è molto grave anche se le vulnerabilità esistono dalla nascita dell'informatica e dei programmi. Questo fa capire come cambiano i tempi...una volta per rubare un'auto bisognava essere abili a forzare le serrature per aprire la portiera e per mettere in moto senza chiavi. Adesso bisogna essere esperti informatici :⁠-⁠)
Da una parte però concordo con il fatto che forse si sta correndo un po' troppo con il progresso per certi aspetti, mi sembra che si stia forzando la digitalizzazione sul settore auto anche su cose non necessarie come i comandi touch per radio e clima. Volkswagen aveva fatto i comandi touch al volante per poi rimettere i tasti fisici (durante la guida i comandi touch venivano premuti per sbaglio, geniale).
Altro aspetto che non trovo sensato è che ad esempio BMW e Mercedes stanno mettendo optional (per esempio sedili riscaldabili) su abbonamento non per effettiva comodità o per avere l'auto tecnologicamente avanzata ma per il solo scopo di risparmiare costi e aumentare il profitto.
Da appassionato di motori ed ex lavoratore del settore sono deluso da che piega sta prendendo l'evoluzione dell'auto (tranne qualche eccezione)
Messaggio unito automaticamente:

Sempre per restare in tema automotive, tecnologia che avanza e pericoli per la sicurezza dell'individuo...

Maxi-tamponamento di 8 veicoli causato dall'improvviso stop di una Tesla​

Articolo originale: https://www.theautopian.com/newly-r...al-problem-of-semi-automated-driving-systems/
Visualizza allegato 67725
Qui il problema per me non è il sistema autopilot di Tesla (di cui ho letto diversi articoli di incidenti anche mortali) ma di chi guida.
Ad oggi anche avendo un sistema del genere bisogna sempre essere concentrati sulla guida e avere il cervello acceso.
Gli adas sono un grande aiuto alla guida ma attualmente non sono in grado di sostituire completamente il guidatore umano.
Messaggio unito automaticamente:

A proposito di guida autonoma per chi non lo sapesse in Italia siamo stati tra i precursori con il progetto argo dell'Università di Parma negli anni 90.
Tempo fa lessi un'articolo che descriveva il software (s.o. Linux) e l'hardware usato per modificare una Lancia Thema.
Se ritrovo l'articolo lo condivido, intanto vi posto questo che descrive brevemente il progetto

Caratteristiche tecniche
Lancia Thema 2000 benzina
Telecamere b/n standard, f=6 mm, 360 linee
Sistema di acquisizioine trinoculare
Sensore di velocità ad effetto Hall
PC Pentium MMX, 200 MHz, Linux
Scheda I/O analogico/digitale
Avvisatori acustici stereofonici
Pannello di controllo a led e pulsanti
Plancia comandi con monitor a colori 6''
Motore elettrico per comando sterzo
Inverter per tensione 220 V @ 50 Hz
Joystick per interventi di emergenza
Max velocità in automatico: 120 km/h
Internet link via 2 canali dati GSM TIM
 
Visualizza allegato 67690

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 More








1     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.​

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.

FiwJWlXXoAMAvmj


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"}

FiwOW57X0AMnI2g


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:​

FiwSytJXoAIoNH2


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]%0d

Per 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]

FiwWw9vX0AATjzN


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.

Fi0po-uVIAI6vOv


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:

Fi0q9OdUUAEGsJd


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"?

Fi0sqCoVQAE9D56


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à.​

Fi0tby1VEAEz5CW


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:

image29.png


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).

image18.png


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 Found

I 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 /%0ddashboard

Si 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​


image1.png


image3.png


device-search-1.png


fleetlocate-1024x506.png


3    Crediti ai ricercatori


Di seguito l'elenco dei vari ricercatori che hanno contribuito alla scoperta delle falle:

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:​
  • 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?​
Io le mie idee credo di essermele fatte, e voi?


Made with ❤ for Inforge



Madooooo Bhro che mina hai tirato fuori ?

Riguardo i tuoi grandi dubbi : " penso che debba succedere qualcosa stile 11 settembre perchè la questione security venga presa con il giusto peso in questi ambiti nella quale l'informatica esce dallo schermo e coinvolge strumenti che utilizziamo tutti i giorni che possono potenzialmente diventare delle armi a tutti gli effetti , ma già questo è allucinante , poi sulle nuove macchine non vedo alcun sistema di sicurezza, basta pensare che con un banale flipper riesci ad aprire lo sportello ricarica di qualsiasi tesla ; nulla di grave ma lascia perplessi la facilità con cui riesci ad interagire abusivamente su una automobile , sono quasi portato a pensare che i sistemi di sicurezza rasentino lo 0
 
Qui il problema per me non è il sistema autopilot di Tesla (di cui ho letto diversi articoli di incidenti anche mortali) ma di chi guida.
Ad oggi anche avendo un sistema del genere bisogna sempre essere concentrati sulla guida e avere il cervello acceso.
Gli adas sono un grande aiuto alla guida ma attualmente non sono in grado di sostituire completamente il guidatore umano.
Assolutamente d'accordo con te! Credo ci sia un problema di fondo di troppa sufficienza e "fiducia" da parte dei guidatori. E' vero che la macchina sa e può fare tutto da sola, ma ciò non significa che possa permettermi di dormire al volante o farmi i fatti miei. Al minimo errore, se non si è reattivi, è la fine - per sè e per chi ci sta attorno.

A proposito di guida autonoma per chi non lo sapesse in Italia siamo stati tra i precursori con il progetto argo dell'Università di Parma negli anni 90.
Tempo fa lessi un'articolo che descriveva il software (s.o. Linux) e l'hardware usato per modificare una Lancia Thema.
Se ritrovo l'articolo lo condivido, intanto vi posto questo che descrive brevemente il progetto
Wow! Molto interessante, non lo sapevo! Assurdo pensare che i primi esperimenti del genere siano datati 1998 e come la tecnologia si sia evoluta da quel giorno, molto affascinante!

Riguardo i tuoi grandi dubbi : " penso che debba succedere qualcosa stile 11 settembre perchè la questione security venga presa con il giusto peso in questi ambiti nella quale l'informatica esce dallo schermo e coinvolge strumenti che utilizziamo tutti i giorni che possono potenzialmente diventare delle armi a tutti gli effetti , ma già questo è allucinante , poi sulle nuove macchine non vedo alcun sistema di sicurezza, basta pensare che con un banale flipper riesci ad aprire lo sportello ricarica di qualsiasi tesla ; nulla di grave ma lascia perplessi la facilità con cui riesci ad interagire abusivamente su una automobile , sono quasi portato a pensare che i sistemi di sicurezza rasentino lo 0
Spero di no, soprattutto perché da come si evince dalla ricerca è possibile effettuare attacchi anche su larga scala - e sarebbero devastanti. Siano sempre lodati i ricercatori autonomi che segnalano responsabilmente le falle!
 
Siano sempre lodati i ricercatori autonomi che segnalano responsabilmente le falle!


Articolo vecchio ma inquietante, sono riusciti addirittura a disabilitare i freni (non ho idea come dal momento che i freni sono ancora ad azionamento meccanico/idraulico con poca elettronica, forse hanno lavorato sulla centralina abs).
Secondo me i sistemi di sicurezza non dovrebbero essere modificabili da remoto ma solo con l'accesso fisico al veicolo.
Non oso immaginare una possibile applicazione dei ransomware ai veicoli, per esempio dover pagare un riscatto per sbloccare i freni o l'auto stessa...poi magari mi faccio troppe paranoie...​
 
Veramente interessante e ben documentato. Spaventoso come sia semplice avere controllo totale e spero le case automobilistiche ne siano a conoscenza
 
Veramente interessante e ben documentato. Spaventoso come sia semplice avere controllo totale e spero le case automobilistiche ne siano a conoscenza
In linea di massima la "awareness" sull'argomento a livello globale è sempre maggiore, e questo è un grosso bene.
Per farti capire il livello di importanza: ZDI (Zero Day Initiative) è un associazione che fa da intermediario per la pubblicazione di vulnerabilità 0-day. Sono anche i creatori della Pwn2Own, una competizione in cui vari ricercatori si sfidano nella ricerca di 0-day. Da questo/il prossimo anno, alla P2O verrà introdotta una nuova categoria completamente dedicata al mondo automotive, proprio per incentivare la ricerca in questo settore. Penso sia un enorme passo avanti per il mondo della security dei veicoli
 
  • Mi piace
Reazioni: TheWorm91
Stato
Discussione chiusa ad ulteriori risposte.