Firmware e catena di fornitura hardware: le nuove sfide di cybersecurity per le imprese italiane

Negli ultimi sette giorni, il flusso di advisory pubblicato da CISA ha messo in luce una serie di vulnerabilità che colpiscono il firmware di dispositivi utilizzati negli ambiti industriali, commerciali e delle infrastrutture critiche. Sebbene molti di questi avvisi siano già stati collegati a temi come le credenziali deboli o gli attacchi supply‑chain su pacchetti software, un filo conduttore meno esplorato è la sicurezza intrinseca del firmware stesso e il modo in cui la sua integrità influisce sull’intera catena di fornitura hardware. Questo articolo esamina le scoperte più rilevanti, ne interpreta le implicazioni per le imprese italiane e propone azioni concrete basate su trasparenza, firme di codice e threat intelligence condivisa.

Le vulnerabilità critiche del firmware industriale scoperte da CISA

Le advisory recenti descrivono falle che permettono l’esecuzione di codice arbitrario, la modifica non autorizzata del firmware o il bypass di meccanismi di autenticazione. Alcuni esempi rappresentativi sono:

• CareCam Pro IP Cameras – Il bootloader utilizza una credenziale hard‑coded per l’autenticazione CareCam Pro IP Cameras. Un attaccante con accesso fisico può ottenere privilegi di bootloader, modificare il firmware e prendere pieno controllo del dispositivo. La vulnerabilità è classificata CVSS v3.1 6.8 (MEDIUM) e CVSS v4.0 7.0 (HIGH).

• Tycon Systems TPDIN‑Monitor‑WEB3 – Versioni ≤ 2.2.9 presentano credenziali hard‑coded, CSRF e mancata autorizzazione Tycon Systems TPDIN‑Monitor‑WEB3. Queste falle consentono attacchi man‑in‑the‑middle, reset di fabbrica o esfiltrazione di credenziali, con CVSS v3.1 8.8.

• IXON VPN Client – Prima della versione 1.4.7, l’iniettamento di sequenze CRLF non neutralizzate permette l’esecuzione di comandi con privilegi root/SYSTEM IXON VPN Client. CVSS v3.1 9.6 indica un rischio critico di esecuzione di codice remoto.

• Rockwell Automation ControlFLASH – L’installer concede permessi di scrittura al gruppo “Everyone” sulla directory di installazione, permettendo l’esecuzione di codice arbitrario con i privilegi dell’utente loggato Rockwell Automation ControlFLASH. CVSS v3.1 7.3.

• Pyramid Solutions NetStaX EtherNet/IP Stack – Un overflow dello stack dovuto a richieste Class 3 esplicite eccessive può causare corruzione della memoria, crash del dispositivo o vettori di attacco remoto senza segnalazione di errore CIP Pyramid Solutions NetStaX EtherNet/IP Stack. CVSS v3.1 9.8, il valore più alto tra quelli riportati.

• Rockwell Automation ArmorStart LT – Script cross‑site scripting memorizzati e allocazione illimitata di risorse consentono l’iniezione di script malevoli nelle pagine web gestite dal dispositivo Rockwell Automation ArmorStart LT. CVSS v3.1 7.5.

• OPCFoundation OPC UA LocalDiscoveryServer (LDS) – Durante l’installazione, un attaccante può intercettare una finestra di console ad alta privilegio ed eseguire comandi arbitrari OPCFoundation OPC UA LocalDiscoveryServer (LDS). CVSS v3.1 4.6.

Queste vulnerabilità condividono una caratteristica comune: il punto di debolezza risiede nel firmware o nel software di basso livello che viene distribuito insieme all’hardware. Quando il firmware è compromesso, l’intero dispositivo può diventare un punto di ingresso persistente nella rete, vanificando le difese perimetrali e gli strumenti di endpoint tradizionali.

L’importanza della trasparenza della catena di fornitura: SBOM e attestazioni di firma

Per mitigare il rischio derivante da firmware compromesso, le organizzazioni devono adottare una visione di supply‑chain integrity che vada oltre la semplice patching. Due strumenti emergono come fondamentali:

1. Software Bill of Materials (SBOM) – Un elenco formale di tutti i componenti, librerie e moduli presenti nel firmware. Conoscere esattamente cosa è presente permette di verificare rapidamente se una versione contiene una libreria vulnerabile (ad esempio, una versione di U‑Boot con credenziali hard‑coded). L’adozione di SBOM è già richiesta in diversi contesti governativi e sta guadagnando trazione nel settore manifatturiero italiano, dove la complessità delle catene di fornitura globale rende difficile tracciare l’origine di ogni modulo.

1. Attestazioni di firma e secure boot – Firmare digitalmente il firmware e verificare tali firme durante il boot assicura che solo codice autorizzato venga eseguito. Anche se un attaccante riesce a ottenere accesso fisico al dispositivo, senza la chiave privata corrispondente non potrà sostituire il firmware con una versione malevola. Le advisory su CareCam e Tycon evidenziano l’assenza di meccanismi di firma efficaci nel bootloader, suggerendo che l’implementazione di secure boot con chiavi gestite da un HSM o da un TPM possa aumentare significativamente la resilienza.

Le aziende italiane che producono o integrano dispositivi OT dovrebbero richiedere ai fornitori SBOM aggiornati e verificare le firme del firmware prima del deployment. Analogamente, i responsabili degli acquisti possono inserire clausole contrattuali che obbligano i fornitori a fornire prove di firma e a partecipare a programmi di verifica di terze parti.

Integrazione di threat intelligence e pratiche di secure development

Le informazioni sulle vulnerabilità attivamente sfruttate, raccolte nel Known Exploited Vulnerabilities (KEV) Catalog di CISA, offrono una fonte preziosa di threat intelligence operativa. Nell’ultima settimana sono state aggiunte quattro nuove CVE (Adobe Commerce, Windows Link Following, Heap‑Based Buffer Overflow, N‑able N‑central) e, pochi giorni prima, la vulnerabilità V8 di Chromium CISA Adds Four Known Exploited Vulnerabilities to Catalog; CISA Adds One Known Exploited Vulnerability to Catalog. Sebbene queste CVE riguardino principalmente software tradizionale, il principio alla base del KEV – priorizzare la correzione di vulnerabilità con prova di sfruttamento attivo – è direttamente applicabile al firmware.

Le organizzazioni possono:

• Alimentare i propri sistemi di gestione delle vulnerabilità con feed KEV e impostare regole di priorità che trattino le vulnerabilità del firmware con lo stesso livello di urgenza riservato alle CVE di sistemi operativi.
• Eseguire test di penetrazione specifici sul firmware (ad esempio, analisi di bootloader, verifica di credenziali hard‑coded, fuzzing di stack e heap) prima di accettare un nuovo lotto di hardware.
• Adottare un ciclo di vita di sviluppo sicuro (SSDL) per il firmware interno, includendo revisioni del codice, analisi di componenti terzi e test di penetrazione in fase di build.

Un ulteriore livello di difesa proviene dalla condivisione di informazioni sulle campagne di knowledge distillation condotte da aziende cinesi di AI, che hanno estratto miliardi di token da modelli statunitensi frontier China-Based Artificial Intelligence Companies Conducting Industrial-Scale Distillation Campaigns Against U.S. AI Companies. Sebbene il focus sia sull’appropriazione di proprietà intellettuale AI, la tecnica dimostra come attori sofisticati possano sfruttare canali di comunicazione legittimi (API, richieste di servizio) per raccogliere dati sensibili. Le stesse pratiche di monitoraggio del traffico e di limitazione delle richieste possono essere applicate per proteggere gli endpoint di gestione del firmware (porte di amministrazione, interfacce web) da abusi che potrebbero facilitare l’iniezione di codice malevolo.

Raccomandazioni operative per le imprese italiane

Basandosi sulle evidenze delle advisory CISA e sulle migliori pratiche di supply‑chain security, le aziende italiane possono adottare le seguenti azioni:

1. Inventario dettagliato del firmware – Mantenere un registro aggiornato di tutti i dispositivi OT/IoT presenti, con versione esatta del firmware, hash e riferimenti allo SBOM.
2. Verifica delle firme – Implementare procedure di controllo della firma digitale durante il provisioning e, ove possibile, abilitare il secure boot a livello hardware.
3. Richiedere SBOM ai fornitori – Includere nei contratti di fornitura l’obbligo di fornire SBOM in formato standard (SPDX o CycloneDX) e di notificare tempestivamente qualsiasi modifica critica.
4. Integrazione KEV – Sincronizzare il feed KEV di CISA con il proprio sistema di gestione delle vulnerabilità e impostare alert automatici per le CVE che riguardano componenti presenti nello SBOM.
5. Segmentazione di rete e privilegi minimi – Isolare i dispositivi con firmware critico in VLAN dedicate, applicare regole di firewall stringenti e garantire che gli account di servizio abbiano solo i privilegi strettamente necessari.
6. Formazione e consapevolezza – Sensibilizzare i team tecnici sui rischi delle credenziali hard‑coded, sull’importanza del controllo delle impostazioni di boot e sulle tecniche di iniezione tramite CRLF o XSS che possono compromettere interfacce di gestione.

Adottando queste misure, le imprese italiane non solo riducono la probabilità di un compromesso tramite firmware malevolo, ma aumentano anche la propria capacità di rispondere rapidamente quando nuove vulnerabilità vengono pubblicate, trasformando la sicurezza del firmware da un reattivo intervento di patching a una strategia proattiva di integrità della catena di fornitura.