Cybersecurity
CODESYS sotto attacco: tre falle concatenate per inserire una backdoor nel PLC
Tre CVE concatenate nel runtime CODESYS Control permettono a un utente Service di sostituire l'applicazione del PLC con una versione backdoor ed eseguire codice come root.
CODESYS è uno dei runtime più diffusi al mondo per la programmazione dei controllori industriali: lo si ritrova, sotto forma di OEM rebrandizzato, in PLC e dispositivi di automazione di centinaia di costruttori. Proprio per questa pervasività una catena di vulnerabilità divulgata di recente dalla ricerca di sicurezza OT merita attenzione: dimostra come un account con privilegi apparentemente limitati possa arrivare al controllo totale del dispositivo.
Il punto debole: privilegi "Service" più potenti del previsto
Nell'architettura CODESYS il codice scritto secondo lo standard IEC 61131-3 viene compilato in codice macchina e caricato nello stesso processo del runtime, che gira come root. Chi riesce a sostituire l'applicazione del PLC, di fatto esegue codice nativo con i massimi privilegi sul dispositivo.
Il livello di accesso Service, storicamente considerato di servizio e a bassa criticità, dispone però del permesso di scrittura sulle cartelle delle applicazioni, necessario per la funzione di backup e ripristino. È da qui che parte tutto.
Tre vulnerabilità che si rafforzano a vicenda
L'attacco non sfrutta una singola falla, ma le concatena. Le tre CVE coinvolte:
| CVE | Tipo | CVSS | In sintesi |
|---|---|---|---|
| CVE-2025-41658 | Permessi di default errati | 5.5 | Accesso al file con gli hash delle password CODESYS |
| CVE-2025-41659 | Permessi errati su risorsa critica | 8.3 | Accesso al materiale crittografico sensibile |
| CVE-2025-41660 | Trasferimento di risorse non validato | 8.8 | Ripristino di applicazioni manomesse senza controlli |
Il dettaglio che rende fragile il modello è strutturale: i backup (file .tbf) sono semplici archivi ZIP che contengono l'applicazione compilata (Application.app), il relativo checksum e i metadati. Quel checksum è un CRC32, pensato per rilevare errori di trasmissione, non per resistere a manomissioni deliberate.
La catena di sfruttamento
Con credenziali Service valide, ma senza alcun accesso locale al sistema operativo, un attaccante può procedere così:
- Esfiltra l'applicazione di boot tramite la funzione di backup.
- Recupera il materiale crittografico abusando di CVE-2025-41659, aggirando cifratura e firma del codice quando presenti.
- Manomette il binario compilato, iniettando codice malevolo.
- Ripristina l'applicazione alterata sfruttando CVE-2025-41660, che non valida l'integrità del pacchetto.
- Attende il riavvio: al successivo avvio il codice iniettato gira come
root. - Escala i privilegi modificando il database utenti di CODESYS fino a ottenere il ruolo
Administrator.
Cosa significa per un impianto
Tradotto nel linguaggio del MITRE ATT&CK for ICS, lo scenario tocca tecniche pesanti: sostituzione dell'applicazione legittima (T0839), manipolazione del controllo con alterazione di setpoint e override degli interlock (T0831), furto di informazioni operative come logica di controllo e credenziali integrate (T0882).
In un contesto reale (una linea di produzione, una sottostazione, un impianto di trattamento acque) le conseguenze vanno dal fermo produttivo al danno fisico, fino a condizioni operative non sicure difficili da diagnosticare, perché il PLC continua ad apparire formalmente integro.
Mitigazioni
CODESYS ha rilasciato patch coordinate. Le azioni prioritarie:
- Aggiornare il runtime CODESYS Control alla versione
4.21.0.0o superiore. - Rendere obbligatoria la firma del codice prima del deploy: nella nuova versione è attiva per default.
- Segmentare la rete per ridurre l'esposizione delle interfacce di programmazione.
- Irrobustire la gestione delle credenziali, trattando gli account
Servicecome privilegiati a tutti gli effetti.
L'angolo MON5
In molti impianti il problema, prima ancora della patch, è sapere dove sia presente CODESYS: spesso è annidato dentro dispositivi di fornitori diversi e non compare in alcun inventario aggiornato. Una visibilità accurata degli asset OT permette di mappare quali controllori espongono il runtime vulnerabile e di correlare ciascuna CVE con il contesto reale (criticità della linea servita, esposizione di rete, finestre di manutenzione disponibili).
Dove l'aggiornamento immediato non è praticabile (caso frequente quando il fermo macchina costa caro) il monitoraggio passivo delle anomalie offre una rete di sicurezza: ripristini di applicazione inattesi, accessi anomali alle funzioni di backup o modifiche al database utenti diventano segnali rilevabili senza interrompere la produzione, restringendo la finestra in cui una backdoor può restare silente.
Analisi e commento a cura di MON5 su ricerca e dati di pubblico dominio del settore OT/ICS.
Articoli correlati
Cybersecurity
Firmware tampering nei dispositivi di campo: come avviene e come rilevarlo
Il firmware dei dispositivi di campo OT è un bersaglio privilegiato per attacchi persistenti e difficili da rilevare. Come avviene il tampering, perché è così insidioso e quali contromisure esistono.
Cybersecurity
L'AI ha cambiato la scoperta delle vulnerabilità: ma c'è un gap OT da non ignorare
I nuovi modelli AI scoprono vulnerabilità in modo autonomo e su scala industriale. Ma gli strumenti restano tarati sull'IT: il mondo OT rischia di rimanere indietro proprio mentre gli attaccanti accelerano.
Cybersecurity
OPC-UA: il protocollo più diffuso nell'OT e i suoi problemi di sicurezza più comuni
OPC-UA è lo standard de facto per la comunicazione nei sistemi SCADA moderni, ma viene spesso distribuito con configurazioni di sicurezza degradate per compatibilità con client legacy. Ecco cosa si vede nel traffico e cosa può sfruttare un attaccante.
Hai la visibilità sulla tua rete OT?
MON5 mappa asset, vulnerabilità e anomalie in tempo reale — senza fermare la produzione.