Hacker e supermercato: lezioni di sicurezza OT

Immagina di essere il responsabile del turno di notte in un supermercato a Lione. Alle 3 del mattino, l'equipaggio notturno nota che la brina si sta sciogliendo dalle vetrine dei surgelati. Poi cominciano a suonare gli allarmi dei compressori, non su un solo corridoio ma in tutto il punto vendita. Quando qualcuno capisce cosa sta succedendo, le celle frigorifere sono già state comandate da remoto in modalità sbrinamento, e migliaia di euro di merce surgelata si stanno silenziosamente riscaldando verso la soglia di scarto per legge. È più o meno quello che è successo quest'anno, quando degli attaccanti hanno colpito i controller della refrigerazione di alcune catene di supermercati francesi, ed è un utile campanello d'allarme per chiunque pensi che la sicurezza delle tecnologie operative sia un problema di qualcun altro.

L'attacco non è stato una catena di exploit da film. Secondo i resoconti, gli attaccanti hanno attivato cicli di sbrinamento automatici su controller di refrigerazione esposti a internet, unità commerciali di un importante produttore industriale, e i danni si sono diffusi in negozi di più paesi. Più o meno nello stesso periodo, un incidente separato ha costretto un gruppo belga-olandese della grande distribuzione a mettere offline parti del proprio IT, interrompendo distribuzione e consegne. Coincidenza o coordinamento, il risultato è stato lo stesso: il mondo fisico è stato hackerato attraverso quello digitale.

Perché un congelatore è collegato a internet, comunque?

La reazione più comune a questa storia, e che ha invaso i commenti ovunque, è stata una variante di «ma perché diavolo colleghereste un frigorifero a internet?». Sembra una domanda retorica, ma una risposta reale c'è, e fingere il contrario è il motivo per cui continuiamo ad avere questa discussione ogni pochi anni.

La refrigerazione commerciale non è un frigorifero. Un supermercato di medie dimensioni gestisce un sistema termico distribuito: decine di banchi espositivi, celle frigorifere e congelatori, rack di compressori, condensatori, tutti orchestrati da controller che bilanciano temperatura e costi energetici. Il caso a favore della connettività remota è concreto:

• Diagnostica remota. Un installatore di refrigerazione che serve centinaia di negozi può individuare la firma di un compressore che si sta guastando giorni prima del guasto. Mandare un tecnico a premere fisicamente un pulsante per un normale sbrinamento costa denaro vero; un comando remoto non costa nulla.
• Ottimizzazione energetica. I supermercati sono tra gli edifici più energivori per metro quadro. Le catene regolano le temperature dei banchi e i programmi di sbrinamento su tutto il proprio parco punti vendita, e alcune partecipano a programmi di demand-response in cui l'utility le paga per ridurre il carico durante le crisi della rete.
• Registrazione per la conformità. Le normative sulla sicurezza alimentare richiedono registrazioni continue della temperatura. I controller in rete producono automaticamente una traccia di audit: niente fogli di carta, niente registri cartacei falsificati.
• Confronto tra flotte. Quando gestisci 2.000 negozi, notare che i compressori di un solo punto vendita assorbono il 15% in più di energia rispetto agli altri è il modo per scoprire le perdite di refrigerante prima che diventino riparazioni da cinque cifre.

Quindi la connettività non è una stupidaggine. La stupidaggine è l'implementazione. I primi resoconti suggeriscono che molti di questi controller fossero raggiungibili direttamente via internet, alcuni con modem cellulari e schede SIM proprie, collocati su indirizzi IP pubblici senza VPN, senza gateway, senza liste di autorizzazione. E la storia dell'autenticazione, secondo un resoconto molto condiviso, era un utente admin abbinato a una password derivata dalla data del giorno. Non è una superficie di attacco; è una porta aperta con tanto di zerbino di benvenuto.

Ecco come appare davvero un attacco OT

Gli ingegneri del software tendono a immaginare i cyberattacchi come furti di dati: database esfiltrati, credenziali trapelate, messaggi di ransomware. Gli attacchi OT sono diversi per natura, non solo per grado. Il bersaglio non è un'informazione ma un processo fisico. Il payload non è una cifratura; è un comando dall'aspetto legittimo inviato a un dispositivo che si fida di chiunque si presenti.

Nota quanto sia elegante l'attacco di sbrinamento. Gli attaccanti non hanno dovuto scrivere malware, scalare privilegi o nemmeno capire a fondo il protocollo. Lo sbrinamento è una funzione normale e autorizzata del controller: esiste perché la brina si accumula sulle serpentine dell'evaporatore e va sciolta periodicamente. L'attaccante l'ha semplicemente invocata fuori programma, su larga scala. Nessun interblocco di sicurezza è scattato, perché dal punto di vista del controller non è stato richiesto nulla di anomalo. È l'equivalente OT del problema del «confused deputy»: il dispositivo esegue fedelmente comandi che non avrebbe mai dovuto ricevere.

Questo schema si generalizza in modo deprimente. Gli impianti di trattamento delle acque sono stati «attaccati» da qualcuno che ha spostato un cursore di dosaggio chimico. I sistemi di gestione degli edifici sono stati presi sotto controllo attraverso l'accesso remoto del fornitore di HVAC. Quasi sempre la capacità pericolosa non è un bug, ma una funzionalità, raggiungibile da persone che non avrebbero mai dovuto raggiungerla. Ecco perché la soluzione non è una code review migliore. È l'architettura.

Le vulnerabilità OT più pericolose non sono bug di corruzione della memoria. Sono funzioni legittime esposte a chiamanti illegittimi.

La patch che nessuno ha applicato

Ecco il dettaglio che dovrebbe far rabbrividire ogni ingegnere della sicurezza: la vulnerabilità alla base di questi controller era stata divulgata pubblicamente mesi prima, in un processo coordinato con il produttore. I ricercatori di sicurezza avevano pubblicato un'analisi dettagliata. Esistevano patch per almeno alcuni modelli. E l'attacco è avvenuto comunque.

È il segreto sporco della patch industriale. Nell'IT aziendale siamo viziati: esce una CVE critica e nel giro di pochi giorni i nostri strumenti di gestione delle flotte hanno sollecitato, pianificato e distribuito la correzione. Nell'OT non funziona così. Il controller di un banco surgelati di un supermercato può funzionare per quindici anni. È di proprietà del punto vendita, manutenuto da un installatore esterno, prodotto da un fornitore e configurato da un tecnico che ha lasciato l'azienda sei anni fa. Chi, esattamente, è responsabile dell'applicazione di un aggiornamento firmware su 2.400 siti in nove paesi? In pratica: nessuno.

Peggio ancora, il fornitore ha evidentemente rilasciato la correzione senza segnalarla chiaramente come critica per la sicurezza. Per un manutentore con una lista d'attesa di apparecchiature davvero guaste, «aggiornamento firmware disponibile» suona come lavoro facoltativo. È un fallimento della comunicazione tanto quanto tecnico. Se rilasci una patch per una vulnerabilità che permette a estranei di sbrinare la spesa di un intero paese, le note di rilascio dovrebbero dirlo con parole che un responsabile della manutenzione non possa non notare. Il divario tra specifica e implementazione non crea solo bug: crea intere flotte di dispositivi non aggiornati che i gestori non sanno essere vulnerabili.

Fail-safe by default: progettare per il giorno peggiore

Parliamo di come sarebbe una buona soluzione, perché i principi qui non sono esotici. Sono le stesse idee di progettazione difensiva che applichiamo al software critico per la sicurezza, solo raramente imposte nel mondo OT. Ho già scritto di ingegneria difensiva che resiste alle catastrofi, e i controller di refrigerazione sono un caso da manuale.

Limitare la frequenza dei cambi di stato pericolosi

Un ciclo di sbrinamento è fisicamente sicuro se eseguito di tanto in tanto e distruttivo se eseguito di continuo. Quindi fai rispettare la fisica nel firmware: dopo il completamento di uno sbrinamento, rifiuta un altro per un intervallo minimo, indipendentemente da qualsiasi comando remoto. Chi può inviare una richiesta di sbrinamento ne può inviare mille; il dispositivo non dovrebbe accettare più di quanto la fisica consenta. Costa poche righe di codice e un timer, e limita il raggio d'azione di qualsiasi compromissione del piano di controllo.

Gli interblocchi locali battono l'autorità remota

Se la temperatura della cella è già sopra una soglia, o i sensori del prodotto segnalano calore, un comando di sbrinamento remoto dovrebbe essere rifiutato e registrato in modo evidente. Il controller ha i dati dei sensori per capire che un comando è folle. Fagli usare quei dati. Un comando che spingerebbe il sistema verso uno stato noto come pericoloso non è un comando; è un errore.

Comandi firmati, non password

Le password sui dispositivi embedded sono una causa persa: saranno quelle di default, condivise, scritte su un post-it o derivate dalla data. Il modello più solido è asimmetrico: i controller verificano una firma su ogni comando remoto rispetto a una chiave pubblica del fornitore o dell'operatore impressa in fase di provisioning. Così rubare una password non serve; serve la chiave di firma, che vive in un HSM nel centro operativo, non su 2.400 banchi surgelati. Sì, questo significa infrastruttura di gestione, rotazione e revoca delle chiavi. Sì, ne vale la pena. Abbiamo risolto questo problema per gli aggiornamenti software un decennio fa; i canali di comando meritano lo stesso trattamento.

Considera la rete come ostile

Se un dispositivo esce di fabbrica con un modem cellulare e una credenziale predefinita, finirà in un motore di ricerca di dispositivi esposti nel giro di poche settimane dal deployment. L'unica soluzione duratura è progettare come se l'esposizione fosse garantita: connessioni in entrata rifiutate per default, telemetria solo in uscita verso un broker, piano di gestione raggiungibile solo attraverso un tunnel con autenticazione reciproca. «Non esporlo a internet» è un consiglio; «rendere sopportabile l'esposizione» è ingegneria.

L'isolamento non è facoltativo: segmentazione fatta bene

Ogni framework di sicurezza OT (IEC 62443, le linee guida del NIST, il classico modello di Purdue) dice la stessa cosa: tieni i sistemi di controllo lontani dalle reti piatte. Eppure il modem cellulare nel banco surgelati è l'anti-pattern fatto persona. Aggira completamente il firewall aziendale, creando migliaia di punti di ingresso non monitorati e indirizzabili singolarmente, che il team di sicurezza potrebbe nemmeno sapere che esistano.

L'architettura che funziona davvero è questa:

1. I controller vivono su una VLAN OT dedicata senza alcuna rotta verso internet e senza alcuna rotta verso l'IT aziendale. Solo un singolo gateway può comunicare con loro.
2. Il gateway applica liste di autorizzazione dei protocolli: il controller parla Modbus o il protocollo del fornitore verso il gateway e nient'altro. Le anomalie qui sono allarmi ad alto segnale, perché il traffico legittimo è noioso e prevedibile.
3. L'accesso remoto passa per un jump host con MFA, registrazione delle sessioni e credenziali a tempo. L'installatore di refrigerazione ottiene una finestra di quattro ore verso un punto vendita specifico, non una VPN permanente verso l'intero parco.
4. Telemetria solo in uscita. Se il cloud del fornitore ha bisogno dei dati di temperatura, è il gateway a inviarli. Nulla viene prelevato dall'interno.
5. Inventaria tutto. Non puoi segmentare ciò che non conosci. Quella connettività cellulare nel banco surgelati è esattamente il tipo di connessione ombra che gli inventari non registrano, finché Shodan non te la trova.

Niente di tutto questo è ipotetico o costoso rispetto all'alternativa. La parte difficile è organizzativa, non tecnica: richiede che il team delle strutture, il team di sicurezza IT e i fornitori si mettano d'accordo su chi possiede cosa. Nella maggior parte delle organizzazioni della grande distribuzione, l'OT cade nella fessura tra questi team: troppo fisico per l'IT, troppo connesso per le strutture. Quell'ambiguità è la vera vulnerabilità, ed è la stessa che trasforma le lacune nell'autenticazione cloud in violazioni invisibili, come abbiamo visto nei punti ciechi del logging dell'autenticazione cloud: se nessuno possiede la telemetria, nessuno vede l'attacco.

Cosa dovrebbero portarsi a casa gli ingegneri del software

Potresti non toccare mai un controller di refrigerazione, ma le modalità di guasto qui sono quelle di ogni sistema connesso, e sono sempre più un problema tuo. Il confine tra IT e OT continua a dissolversi: i robot del tuo magazzino, l'HVAC del tuo ufficio, gli strumenti del tuo laboratorio e il tuo edificio intelligente girano tutti su Linux embedded e parlano con il cloud. Alcuni macchinari di laboratorio ospedalieri ora si rifiutano di eseguire test se l'account di abbonamento non è ricaricato, il che significa che un'interruzione di fatturazione o una violazione connessa a internet può bloccare la diagnostica medica. Abbiamo costruito questo mondo, una funzione comoda alla volta.

Quindi le lezioni si trasferiscono direttamente. Inventaria la tua esposizione: se non sai cosa è in ascolto, lo troverà qualcun altro. Tratta le operazioni pericolose come privilegiate anche quando sono «funzionalità normali», perché l'attaccante che raggiunge il tuo piano di controllo userà le tue funzionalità contro di te. Firma ciò che conta e fai scadere tutto il resto. Progetta lo stato di guasto in modo che sia quello sicuro: un controller che perde la connettività deve continuare a raffreddare, non presumere che ogni comando in coda sia affidabile. E quando rilasci una correzione di sicurezza, dillo a voce alta: una patch che nessuno applica è indistinguibile dal non avere alcuna patch.

L'attacco al supermercato sarà ricordato soprattutto per la sua assurdità: hacker contro piselli surgelati. Ma il prossimo non prenderà di mira il gelato. Colpirà la stessa classe di controller esposti, non aggiornati e con autenticazione debole, in un magazzino farmaceutico a temperatura controllata, nell'impianto di raffreddamento di un data center o in un sistema idrico municipale. L'hardware è lo stesso. Le credenziali sono altrettanto pessime. L'unica variabile è cosa si scalda, allaga o si spegne quando qualcuno digita la password del giorno.