VicOne ha individuato 28 zero-day in meno di due giorni, usando una ricerca assistita dall'IA su software e strumenti che supportano l'ecosistema della physical AI. Tra i progetti coinvolti ci sono quelli sviluppati o mantenuti, tra gli altri, da Google, NVIDIA e Meta. Queste vulnerabilità zero-day nella robotica sono state classificate come tali solo in base alla validazione iniziale.
Il conteggio non è definitivo. Potrebbe cambiare dopo la revisione da parte dei produttori e delle autorità che gestiscono le vulnerabilità, e per alcune delle falle non esistono ancora codici di tracciamento CVE. La divulgazione coordinata è ancora in corso, quindi i dettagli delle singole falle non sono stati pubblicati.
Cosa riguardano le scoperte
Molti degli strumenti coinvolti servono ad addestrare, simulare, testare e far funzionare i robot. Per questo il caso è diverso da una falla nel firmware di un singolo robot. Una debolezza in uno strumento di addestramento o di simulazione può influenzare i modelli che un team costruisce, i risultati dei test di cui si fida e le istruzioni che alla fine arrivano a una macchina.
VicOne ha suddiviso le scoperte in tre fasi del ciclo di vita della robotica: sviluppo e addestramento, simulazione e validazione, distribuzione ed esecuzione. In questo insieme di ricerche, il 75% delle scoperte riguardava strumenti di sviluppo, addestramento, simulazione o validazione. La maggior parte dell'esposizione si colloca quindi nei passaggi che un robot attraversa prima di essere messo in servizio.
La rapidità conta per via di ciò che è uno zero-day: una falla finora sconosciuta e per cui non esiste una correzione disponibile. Secondo VicOne, l'IA può accelerare alcune parti della ricerca sulle vulnerabilità, tra cui l'analisi del codice, la ricostruzione di come i sistemi comunicano e la verifica della sfruttabilità di una presunta debolezza. L'azienda aggiunge che anche gli attaccanti potrebbero usare capacità simili. Una scoperta più rapida non significa che sia avvenuto un attacco, ma può lasciare ai team poco tempo per capire se usano il software coinvolto e a cosa potrebbe accedere o cosa potrebbe modificare un attaccante.
Tre fasi, tre tipi di esposizione
VicOne descrive uno scenario per ciascuna fase. Nessuno viene presentato come un esito dimostrato per tutte le scoperte. Gli effetti reali dipendono dall'accesso dell'attaccante, dalla progettazione del sistema e dall'eventuale presenza di altre protezioni che impediscano alle modifiche di raggiungere il comportamento fisico.
Nello sviluppo e nell'addestramento, un team potrebbe scaricare un modello preaddestrato da adattare al proprio robot. Il caricamento di un file malevolo potrebbe dare all'attaccante accesso al sistema di addestramento e, con esso, la possibilità di alterare i dati di training o il modello. Un modello manipolato potrebbe comportarsi normalmente nei test di routine e poi reagire in modo errato a un certo oggetto, a una scena o a un comando dopo il rilascio.
Nella simulazione e nella validazione, importare una scena o un modello di robot compromesso potrebbe dare all'attaccante accesso all'ambiente di simulazione. Con un controllo sufficiente, l'attaccante potrebbe cambiare le letture simulate dei sensori, le condizioni fisiche o i risultati dei test. Un robot potrebbe così superare test che avrebbero dovuto rivelare comportamenti pericolosi, e il team lo approverebbe sulla base di prove fuorvianti.
Nella distribuzione e nell'esecuzione, un attaccante potrebbe modificare i file che influenzano la pianificazione del movimento, oppure inviare dati di mappa malevoli che mandano in crash il display di monitoraggio dell'operatore. Anche la compromissione di un computer per il controllo remoto potrebbe mettere a rischio le istruzioni inviate al robot. A seconda delle protezioni in atto, queste debolezze potrebbero alterare i movimenti o impedire agli operatori di vedere cosa sta accadendo.
Una dimostrazione sull'arresto remoto e il problema delle patch
In una dimostrazione separata, i ricercatori di VicOne hanno sfruttato una vulnerabilità per impedire il funzionamento del comando di arresto remoto di un robot. Il caso è più circoscritto rispetto alle 28 scoperte, ma mostra una funzione di protezione che smette di funzionare a causa del software che la supporta.
VicOne sostiene inoltre che la pubblicazione di una patch non chiude il lavoro. I team devono comunque individuare i sistemi interessati, verificare la compatibilità e controllare che l'aggiornamento mantenga il comportamento previsto. Un test superato in precedenza resta una prova utile, ma una debolezza appena scoperta può riguardare condizioni che quel test non ha mai esaminato.
L'azienda propone tre domande. Dove viene usato il software coinvolto, compresi i computer di addestramento, gli ambienti di simulazione e i robot in servizio? Cosa potrebbe modificare la debolezza: i modelli, i risultati dei test, la visibilità dell'operatore o il comportamento del robot? Come si verifica la protezione, cioè sia che la correzione chiuda la falla sia che il sistema aggiornato funzioni ancora come previsto? Dove un aggiornamento immediato non è praticabile, secondo l'azienda i team potrebbero dover adottare misure temporanee, come limitare l'accesso a un servizio interessato mentre si prepara una correzione validata.
Cosa significa per il settore e cosa non è dimostrato
Il punto più utile delle scoperte è dove si collocano. La sicurezza dei robot viene spesso discussa guardando alla macchina in fabbrica o sul campo. Questo insieme di casi colloca invece la maggior parte delle debolezze segnalate a monte, negli strumenti che decidono cosa impara un robot e se viene giudicato sicuro. Un ambiente di test compromesso è un problema particolare perché può danneggiare le prove su cui si fonda l'approvazione di sicurezza, senza alcun guasto visibile nel robot stesso.
L'insieme riguarda anche progetti di grandi organizzazioni, molto diffuse, il che suggerisce che l'esposizione non sia limitata a software di nicchia. I team che costruiscono su strumenti open condivisi ereditano le falle di quegli strumenti e potrebbero non considerarli parte della propria superficie di attacco.
Diversi aspetti restano non dimostrati. Le 28 scoperte derivano dalla validazione iniziale di VicOne, pubblicata in un contenuto che promuove anche i prodotti dell'azienda, e nessun soggetto indipendente ha confermato il conteggio. La fonte non indica quanto sia grave ciascuna falla, quante siano sfruttabili in una distribuzione tipica o se qualcuna sia già stata usata in un attacco. Gli scenari sono conseguenze potenziali, non dimostrate.
Anche l'affermazione sulla rapidità manca di un termine di paragone. Trovare 28 potenziali zero-day in meno di due giorni è un dato notevole, ma la fonte non lo confronta con il tempo che richiederebbe una ricerca manuale tradizionale sullo stesso software. Non chiarisce nemmeno quanta parte del lavoro sia stata svolta dall'IA e quanta dai ricercatori. Il dato sostiene la tesi più limitata che la ricerca assistita dall'IA possa far emergere rapidamente molti candidati. Non dimostra che lo stesso ritmo valga per vulnerabilità confermate, corrette e divulgate.
Il prossimo elemento da seguire è il processo di divulgazione. Mentre i produttori rivedono le scoperte, il conteggio finale, le assegnazioni CVE e le patch mostreranno quante di queste vulnerabilità zero-day nella robotica reggono alla verifica, e con quale rapidità i progetti coinvolti potranno rilasciare correzioni che i team di robotica siano in grado di validare.
