Come ti cracko l'automobile

Un gruppo di ricercatori sperimenta con i circuiti elettronici a bordo delle automobili. E scopre che violare il sistema automotive si può: e i danni possono essere anche gravi

Roma – Internet, si sa, può essere un posto molto pericoloso con malware, cyber-criminali e truffe in attesa dietro l’angolo di un qualsiasi sito web. Ma il pericolo digitale della navigazione si trasforma in un vero e proprio rischio per la vita se l’utente è alla guida di un auto ripiena di circuiti integrati e sistemi informatici aggiornabili.

Solleva la delicata questione un team composto da esperti della University of Washington e della University of California, San Diego autore dello studio Experimental Security Analysis of a Modern Automobile . Nel loro lavoro, i ricercatori hanno messo mani, portatile e cavi di collegamento sulla porta di diagnostica standard On-Board Diagnostics (OBD-II) obbligatoria per tutti i veicoli in circolazione negli States.

Lo studio si è concentrato su due modelli di automobili scelti come “rappresentativi dei sistemi di controllo basati sui network computerizzati che hanno proliferato in molte delle auto di oggi”. I ricercatori hanno scoperto che è possibile “hackerare” l’auto da remoto istruendo il computer di bordo per fargli compiere ogni genere di follia , dalla frenata forzata allo spegnimento del motore, sino alla disabilitazione completa dei freni.

Lo studio indica come sull’auto bersaglio sia stato installato un software apposito che ha permesso ai ricercatori di prendere il controllo del mezzo da remoto, attraverso quella stessa rete cellulare che le aziende produttrici impiegano per impacchettare ogni genere di caratteristiche aggiuntive “interconnesse” alle proprie vetture – diagnostica remota, recupero di un mezzo rubato, aggiornamenti e via elencando.

C’è chi vorrebbe sfruttare questa proliferazione di sistemi digitali a bordo per mettere in piedi un modello di “auto come piattaforma”, dando il via allo sviluppo di software di terze parti installabile via OBD-II come se si trattasse di un iPad o un gadget tecnologico qualsiasi. Ma come dimostra la ricerca della due università statunitensi il succitato modello è affetto da una insicurezza di fondo che ne mette pesantemente in discussione le finalità, perché se di un iPad pienamente operativo se ne può fare ampiamente a meno lo stesso non vale per il perfetto funzionamento e la piena disponibilità dei sistemi digitali di cui è dotata la propria automobile .

La nuova ricerca serve appunto a sollevare la questione prima che sia troppo tardi: pur considerando la non secondaria necessità di ottenere l’accesso “locale” al computer di bordo per portare a segno l’attacco, il lavoro delle università USA dimostra come le manie da “cloud computing” che hanno preso il sopravvento anche sulle più avvedute società di software in attività ben poco si adattino all’automotive interconnesso che in molti vorrebbero far entrare in produzione.

Alfonso Maruccia

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • Andreabont scrive:
    C'è già
    Si chiama ActiveX, e tutti conosciamo i suoi effetti indesiderati...
  • Jeujeu scrive:
    All'autore dell'articolo
    Nel titolo in homepage non si legge il ++ di C++
  • MeX scrive:
    mmmm...
    "Native Client è una tecnologia che permette alle web application di eseguire codice nativo sul browser superando le limitazioni tipiche di JavaScript e degli altri linguaggi interpretati e accedendo in modo più diretto alle risorse hardware."e la sicurezza?
  • ciuffo scrive:
    no no no l'ho pensato prima di google
    no no no l'ho pensato prima di google
  • incompenso scrive:
    no no...
    l'ho pensato prima io :D
  • bubu scrive:
    ActiveX in salsa Google
    come da oggetto :-P
    • il_ragno scrive:
      Re: ActiveX in salsa Google
      Proprio quello che pensavo io.LOL
      • lordream scrive:
        Re: ActiveX in salsa Google
        estremizzo ma l'ho pensato anche io..
        • MAH scrive:
          Re: ActiveX in salsa Google
          pure io l'ho pensato subito
          • FDG scrive:
            Re: ActiveX in salsa Google
            - Scritto da: MAH
            pure io l'ho pensato subitoE avete pensato male. Gli ActiveX si basano su COM, cioè componenti supportati nativamente da Windows, e possono fare parecchie cose. Da questo nasce la loro pericolosità.Un Native Client di Chrome al contrario può fare veramente poco. Al momento manco è possibile accedere al filesystem in nessun modo.http://code.google.com/p/nativeclient-sdk/wiki/Porting#Eliminate_file_accessPerché invece di spararle a caso non andate a documentarvi?
          • bubu scrive:
            Re: ActiveX in salsa Google
            - Scritto da: FDG
            - Scritto da: MAH


            pure io l'ho pensato subito

            E avete pensato male. Gli ActiveX si basano su
            COM, cioè componenti supportati nativamente da
            Windows, e possono fare parecchie cose. Da questo
            nasce la loro pericolosità.Errato, un ActiveX non è pericoloso in quanto tale, la pericolosità è intrinseca nel kernel di gestione degli ActiveX (notoriamente 'buggoso', passami il termine), esattamente come lo è nel kernel di gestione di qualsiasi altra 'sandbox'.
            Un Native Client di Chrome al contrario può fare
            veramente poco. Al momento manco è possibile
            accedere al filesystem in nessun modo.Vedi sopra, ad esempio, anche Java può essere pericoloso se il suo interprete/JIT è implementato male (http://java.sun.com/security/chronology.html)Cosa ti fa credere che un Native Client Chrome sia esente da tali problematiche?
            Perché invece di spararle a caso non andate a
            documentarvi?Tu invece sì che ti sei documentato!! :-PCerto, tutti professori qui dentro!
          • FDG scrive:
            Re: ActiveX in salsa Google
            - Scritto da: bubu
            Errato, un ActiveX non è pericoloso in quanto
            tale, la pericolosità è intrinseca nel kernel di
            gestione degli ActiveX (notoriamente 'buggoso',
            passami il termine), esattamente come lo è nel
            kernel di gestione di qualsiasi altra 'sandbox'.Se, vabbeh, quindi anche JavaScript è pericoloso e quindi da evitare.
            Vedi sopra, ad esempio, anche Java può essere
            pericoloso se il suo interprete/JIT è
            implementato male...Infatti come ho detto prima...
            (http://java.sun.com/security/chronology.html)
            Cosa ti fa credere che un Native Client Chrome
            sia esente da tali problematiche?Non è esente dalle problematiche dovute agli errori, come qualsiasi altra cosa che riguarda browser, web, javascript...Quindi, o ActiveX è trattato male ingiustamente oppure...La differenza è che, da quel che vedo, sul native client di base puoi fare poco. Ovvio che aumenta la superficie d'attacco, ma non quanto fa ActiveX.
            Tu invece sì che ti sei documentato!! :-P
            Certo, tutti professori qui dentro!Oppure...-----------------------------------------------------------Modificato dall' autore il 18 maggio 2010 15.26-----------------------------------------------------------
          • bubu scrive:
            Re: ActiveX in salsa Google
            - Scritto da: FDG
            Se, vabbeh, quindi anche JavaScript è pericoloso
            e quindi da evitare.Teoricamente anche il parser dell'HTML potrebbe essere buggato... ma comunque non è quanto ho scritto nel mio primo post.PS: tempo fà hanno trovato un baco in un algoritmo di decodifica immagini per Win, per cui era possibile (lo è ancora per sistemi non aggiornati) bucare un PC semplicemente mandandolo in una pagina con un'immagine infettata da codice maligno, come vedi, non basta nè Javascript, nè AciveX, nè NC.

            Vedi sopra, ad esempio, anche Java può essere

            pericoloso se il suo interprete/JIT è

            implementato male...

            Infatti come ho detto prima...Ergo, mi dai ragione... ma comunque non è quanto ho scritto nel mio primo post.

            Cosa ti fa credere che un Native Client Chrome

            sia esente da tali problematiche?

            Non è esente dalle problematiche dovute agli
            errori, come qualsiasi altra cosa che riguarda
            browser, web, javascript...Ergo, mi dai ragione... ma comunque non è quanto ho scritto nel mio primo post.
            Quindi, o ActiveX è trattato male ingiustamente
            oppure...Guarda che io non ho mai spezzato una lancia a favore di ActiveX... ed inoltre non è quanto ho scritto nel mio primo post
            La differenza è che, da quel che vedo, sul native
            client di base puoi fare poco. Ovvio che aumenta
            la superficie d'attacco, ma non quanto fa ActiveX.Ma perchè ti sei fissato tanto sulla sicurezza degli ActiveX? (e comunque, non è quanto ho scritto nel mio primo post)

            Tu invece sì che ti sei documentato!! :-P

            Certo, tutti professori qui dentro!

            Oppure...Oppure potresti evitare di sollevare questioni inutili, dando degli ignoranti a destra e manca, dicendo di consultare la documentazione e bla bla bla... Siamo su PI, non in un dottorato di ricerca, e se a molte persone NC ricorda ActiveX forse un nesso in comune potrebbe anche esserci, perlomeno all'apparenza.La questione 'sicurezza' l'hai sollevata tu, ed ora scrivi che, per poco che faccia, NC aumenta la superficie d'attacco (per fortuna te ne sei accorto), ma non ai livelli degli ActiveX (ecchissenefrega, scusa..)La questione 'portabilità' l'hanno fata notare poco sopra, ma anche qui c'è un non vago nesso con gli ActiveX.Il fatto è che a me continuano a sembrare due prodotti simili per i risultati a cui mirano. Poi, che uno si appoggi alle COM/DCOM e l'altro a LLVM o Web Services o piccioni viaggiatori o altro ancora, francamente non mi interessa una mazza!Una macchina è sempre una macchina, che vada a benzina, diesel o GPL...Saluti
          • FDG scrive:
            Re: ActiveX in salsa Google
            - Scritto da: bubu
            Ergo, mi dai ragione... ma comunque non è quanto
            ho scritto nel mio primo post.In verità non hai scritto molto, tranne che fare un paragone con ActiveX...
            Ma perchè ti sei fissato tanto sulla sicurezza
            degli ActiveX?Perché è la prima cosa che viene in mente leggendo "ActiveX"
            Oppure potresti evitare di sollevare questioni
            inutili, dando degli ignoranti a destra e manca...Ho detto di leggervi la documentazione, non vi ho dato genericamente degli "ignoranti".
            ...Siamo su PI, non in un dottorato di
            ricerca, e se a molte persone NC ricorda ActiveX
            forse un nesso in comune potrebbe anche esserci,
            perlomeno all'apparenza.Apparenza, perché manco hanno gli stessi obiettivi. La piattaforma di Google è il web. ActiveX era il tentativo di Microsoft di portare COM sul web e far ritornare lo sviluppo su Windows, quindi mantenere gli sviluppatori focalizzati sulla _sua_ piattaforma. Questo NC ha uno scopo diverso, cioè dare qualche strumento in più agli sviluppatori web che hanno bisogno di prestazioni... IMHO, più che di prestazioni si tratta di vedere in che direzione si può andare (anche una ragione per cui Google ha deciso di fare Chrome).
          • bubu scrive:
            Re: ActiveX in salsa Google
            - Scritto da: FDG
            In verità non hai scritto molto, tranne che fare
            un paragone con ActiveX...Appunto

            Ma perchè ti sei fissato tanto sulla sicurezza

            degli ActiveX?

            Perché è la prima cosa che viene in mente
            leggendo
            "ActiveX"Pensa te, io invece ho pensato subito al legame Chrome-NC = IE-ActiveX(e forse non sono stato il solo a quanto pare leggendo il thread)
            Ho detto di leggervi la documentazione, non vi ho
            dato genericamente degli "ignoranti".Tratto da un altro tuo post:
            'Come si dice dalle mie parti, sono nati "imparati"?'Diciamo che hai usato una sottile ironia, eh? ;-)
            Apparenza, perché manco hanno gli stessi
            obiettivi. La piattaforma di Google è il web.
            ActiveX era il tentativo di Microsoft di portare
            COM sul web e far ritornare lo sviluppo su
            Windows, quindi mantenere gli sviluppatori
            focalizzati sulla _sua_ piattaforma. Questo NC ha
            uno scopo diverso, cioè dare qualche strumento in
            più agli sviluppatori web che hanno bisogno di
            prestazioni... IMHO, più che di prestazioni si
            tratta di vedere in che direzione si può andare
            (anche una ragione per cui Google ha deciso di
            fare Chrome).Scusa ma anche girandola in questo modo non posso fare a meno di notare l'assonanza.Microsoft ha la sua piattaforma che consiste nel parco macchine desktop, per cui sforna gli ActiveX per mantenere gli sviluppatori focalizzati lì (l'hai detto tu proprio qui sopra).Non ti sembra che Google, che ha la sua piattaforma nel cloud computing, stia sfornando i NC per mantenere (o meglio, aggiungere) gli sviluppatori focalizzati su Chrome? Il fatto che Google stia per rilasciare ChromeOS, che si basa fondamentalmente su Chrome, non ti fa pensare che stia cercando di creare un parco applicazioni un pochino corposo prima di lanciare ChromeOS? Con il SUO framework, Google permetterà alle applicazioni di utilizzare meglio la CPU, liberando quella dei SUOI server! Il bello è poi che a Google basta scrivere le magiche parole "open source" che tutti pendono dalle sue labbra..Decisamente un'altra assonanza con il concetto ActiveX: a mio parere M$ stà agli AX come Google stà ai NCPraticamente Google stà cercando il modo per far sì che le pecore invitino a cena i lupi!(chi vivrà vedrà, MS ai tempi non c'è riuscita, ma si sa... M$ è cattiva, gli altri sono scesi in terra per grazia divina)
          • bibop scrive:
            Re: ActiveX in salsa Google
            il discorso poteva essere anche decente fino alle ultime tre righe... poi ha messo in giusta luce tutto il resto... ... ho perso 120 secondi di vita a leggere vuoto spinto...
          • nick scrive:
            Re: ActiveX in salsa Google

            il discorso poteva essere anche decente fino alle
            ultime tre righe... poi ha messo in giusta luce
            tutto il resto... ... ho perso 120 secondi di
            vita a leggere vuoto
            spinto...Non preoccuparti: per quello che vale la tua vita, non hai perso proprio nulla.
          • tunele scrive:
            Re: ActiveX in salsa Google
            ciò che accomuna le due tecnologie non è tanto la pericolosità come hai fatto giustamente notare, ma la non portabilità. E' questo che salta subito agli occhi ed è questo che probabilmente ne segnerà il declino, allo stesso modo per cui è avvenuto l'inesorabile declino di activex. Nessuno sviluppatore si sognerebbe di creare qualcosa che funzioni per un solo browser, che per altro detiene una fetta di mercato bassissima. Almeno activex girava sul browser che all'epoca era quasi lo standard dei browser in commercio, nel senso che aveva una penetrezione elevatissima. Chrome è molto lontano invece dall'essere leader. Quindi a che serve questa tecnologia? Da quello che so Activex è ancora utilizzato per poco, su applicazioni aziendali, dove ci si può permettere di certificare l'applicazione per un solo browser. Non credo che questa tecnologia possa trovare campo nemmeno per questo tipo di utilizzi. Quindi l'unica speranza è che il framework che sta alla base della tecnologia presentata nell'articolo venga adottato da tutti i browser in commercio. Altrimenti sarà destinata a perire in brevissimo tempo.
          • Cla scrive:
            Re: ActiveX in salsa Google
            Dimentichi che Native client è opensource.. bisogna vedere come reagiranno gli altri browser, ma ipoteticamente potrebbe essere adottato da tutti se porterà reali vantaggi.ActiveX è solo ed esclusivamente per Windows-IE, tutt'altra cosa..
          • poiuy scrive:
            Re: ActiveX in salsa Google
            Guarda, sebbene concordi con quel che dici, provo a proporre un punto di vista diverso.Google punta su javascript per le esigenze "normali" e per tutte quelle web application che vogliano rivolgersi a tutti.Native Client sembra fatto apposta per quella piccola percentuale di casi dove hai bisogno di più.Mi spiego meglio: in un ottica di "cloud computing" una azienda potrebbe decidere di vendere il proprio prodotto utilizzando Chrome come UI.Così come quando compri un programma hai dei vincoli (S.O., Hardware minimo, etc...), in questo caso il vincolo sarebbe Chrome.
          • il signor rossi scrive:
            Re: ActiveX in salsa Google
            - Scritto da: tunele
            ciò che accomuna le due tecnologie non è tanto la
            pericolosità come hai fatto giustamente notare,
            ma la non portabilità. beh... C e C++ sono ormai standardizzati, se uso librerie open source portabili (verosimile, visto che perlomeno dovrà girare su win, mac e linux) ecco fatta la portabilità. Certo, non come javascript, ma non si può avere tutto!
          • urrr scrive:
            Re: ActiveX in salsa Google
            si, ma questi si basano sul "motore" di chrome... cioè senza chrome non ci fai una cippa.Dovrebbe avere un sucXXXXX smisurato prima che gli altri browser lo implementino imho.A meno che non rilascino un motore indipendente da chrome, multipiattaforma
          • FDG scrive:
            Re: ActiveX in salsa Google
            - Scritto da: tunele
            ciò che accomuna le due tecnologie non è tanto la
            pericolosità come hai fatto giustamente notare,
            ma la non portabilità. E' questo che salta subito
            agli occhi ed è questo che probabilmente ne
            segnerà il declino, allo stesso modo per cui è
            avvenuto l'inesorabile declino di activex.Questo è un altro argomento...
Chiudi i commenti