Ho detto più volte, in passato, che la sicurezza IT resterà una faccenda “just for the show”, e quindi per showmen, finché non arriverà il vero merdone. Quello successo in Francia non è ancora il vero merdone, ma è abbastanza grosso da mandare un messaggio chiaro. Eppure è finito tutto in pasto ai giornali, senza un’analisi seria e senza una reale voglia di capire che cosa sia successo, e perché.

Un’azienda che installa e gestisce impianti di refrigerazione ha un problema molto concreto: deve sapere che cosa succede ai frigoriferi dei propri clienti, possibilmente prima che se ne accorga il cliente.

Per questo esistono sistemi di controllo connessi a Internet che monitorano le temperature, rilevano le anomalie e inviano allarmi al personale delle operations. Un compressore che si ferma, una temperatura che supera la soglia, un impianto che esce dai parametri di funzionamento: tutto viene segnalato, e si può mandare subito un tecnico sul posto.

Dal punto di vista operativo è una soluzione sensata: riduce i tempi di intervento e permette di gestire da remoto un gran numero di impianti sparsi sul territorio. Ma introduce anche un problema di sicurezza troppo spesso sottovalutato: il sistema con cui il gestore controlla i frigoriferi può diventare lo stesso sistema con cui un aggressore ne prende il controllo.

Quando gli hacker decidono di cuocere i frigoriferi

Nella notte tra l’11 e il 12 ottobre 2026, centinaia di supermercati francesi sono stati colpiti da un attacco informatico ai sistemi di refrigerazione. Niente registratori di cassa, niente database dei clienti: gli aggressori hanno preso di mira i controller elettronici che regolano temperature e cicli di funzionamento di frigoriferi, congelatori e celle frigorifere.

Questi dispositivi sono collegati a Internet proprio per consentire il monitoraggio remoto e la ricezione degli allarmi. Il problema è che molti erano raggiungibili direttamente dalla rete pubblica, e che su questi controller esistevano vulnerabilità note da tempo, per le quali il produttore aveva già rilasciato aggiornamenti.

Una volta dentro, gli aggressori hanno forzato gli impianti in sbrinamento continuo, portando le temperature fino a 50 °C. Secondo Le Monde, in alcuni congelatori e celle il ciclo di sbrinamento è stato allungato da un’ora a otto, per ritardare gli allarmi. Risultato: tonnellate di merce fresca e surgelata finite nella spazzatura.

Il primo bersaglio sono stati i controller Danfoss; la notte successiva è toccato a quelli Dixell e Copeland. Il CERT-FR, il centro governativo francese di risposta agli incidenti informatici, che fa capo all’ANSSI, ha pubblicato un’allerta con le indicazioni per mettere in sicurezza i dispositivi: prima di tutto, toglierli dall’esposizione diretta su Internet.

Chi abbia condotto l’attacco, e attraverso quale falla, non è ancora stato accertato: la procura di Parigi ha aperto un’indagine. Ma il caso dimostra già una cosa: quando un sistema informatico controlla un impianto fisico, la sua compromissione produce danni materiali, e subito. Non serve violare una centrale nucleare: può bastare un frigorifero.

Arrivano i cazzari della sicurezza

Come avrete notato, da qualche tempo la sicurezza informatica è diventata un argomento di cui si parla moltissimo. Appunto: si PARLA. Ci sono persone che, senza saper scrivere un Hello World in Java, sbarcano il lunario parlando di sicurezza.

Il caso francese le ha eccitate parecchio: Internet ribolle di articoli dall’aria competente che spiegano come gli endpoint non fossero protetti, il perimetro di qua, il perimetro di là. Ma di una cosa nessuno parla.

Ed è proprio quello il vero problema, che affligge più o meno tutto il mondo del M2M (machine-to-machine) e dei dispositivi connessi ed esposti su Internet.

A danno fatto, cioè, è emerso che le vulnerabilità erano note, che le patch esistevano, ma che gli impianti colpiti montavano firmware vecchi, mai aggiornati. E così parte la caccia: quale anello di quale catena decisionale ha lasciato il supermercato esposto?

Tranne che...

Il problema nasce da un malcostume così diffuso che nessuno se n’è accorto

Le aziende costruttrici, per fare damage control sul proprio marchio, si sono affrettate a precisare che le patch erano state rilasciate da tempo e che erano i clienti a non aver aggiornato il firmware.

Danfoss lo ha detto già lunedì, a poche ore dall’attacco: buona parte delle unità colpite montava firmware non aggiornato, e da tempo l’azienda raccomandava ai clienti di tenere aggiornati i sistemi supportati e di sostituire quelli vecchi. Copeland, proprietaria di Dixell, ha fatto lo stesso, parlando di una vulnerabilità presente in una generazione di controller fuori produzione e ormai a fine vita.

Ma se si legge con attenzione, la storia è un po’ diversa. Secondo la stessa Danfoss, i dispositivi colpiti erano di due tipi. Da una parte gli AK-SM 800A, ancora supportati, per i quali gli aggiornamenti esistevano ma non erano stati installati. Dall’altra gli AK-SM 800 e gli AK-SC 355, modelli vecchi che non ricevevano più aggiornamenti di sicurezza da anni. Per questi ultimi, la patch non è che non sia stata applicata: non esisteva proprio. Il costruttore aveva semplicemente smesso di supportarli, mentre continuavano a funzionare, connessi a Internet, dentro i supermercati.

E non stiamo parlando di vulnerabilità oscure. Ad agosto i ricercatori di Claroty avevano pubblicato un’analisi dettagliata delle falle degli AK-SM 800A, tra cui una che permetteva di aggirare l’autenticazione dell’interfaccia web di amministrazione. Danfoss aveva corretto il problema. Nel frattempo, in Francia, migliaia di console Danfoss restavano raggiungibili direttamente da Internet.

Se state pensando che tutto si sarebbe potuto evitare non esponendo le macchine su Internet, usando l’autenticazione multifattore o qualcun’altra delle minchiate che propongono i reparti Security delle aziende, siete fuori strada. Non mi riferisco a questo.

Mi riferisco a una cattiva abitudine ormai così diffusa che ogni mattina passiamo un sacco di tempo solo per riuscire a loggarci da qualche parte al lavoro. La stessa per cui, se al ristorante vogliamo pagare con l’app, restiamo lì davanti al cameriere imbarazzato perché prima dobbiamo autenticarci, e per autenticarci serve l’app di autenticazione, e così via.

Mi riferisco all’abitudine di DELEGARE LA SICUREZZA ALL’UTENTE DELLA MACCHINA.

Se andiamo a vedere che cosa sarebbe dovuto succedere quando il supporto al firmware è terminato (per l’AK-SM 800, secondo Danfoss, la fine vita risale al 2021), la risposta ufficiale è: sostituire il sistema. Non i frigoriferi, a dire il vero, ma la centralina che li gestisce. Che però continuava a funzionare benissimo: la si butta via perché il costruttore ha deciso che non la aggiorna più?

In alternativa, qualcuno avrebbe dovuto togliere da Internet i dispositivi non più supportati. E non è che sia impossibile: esistono i firewall apposta, e in una grande azienda su Internet ci sta solo quello che ci deve stare.

Per i dispositivi invece ancora supportati, per i quali il produttore aveva rilasciato l’aggiornamento ma nessuno lo aveva installato, la conclusione è la stessa: ha sbagliato l’utilizzatore finale, che non ha tenuto aggiornata la macchina.

In entrambi i casi, tutto viene scaricato sull’UTILIZZATORE FINALE, direttamente o tramite proxy.

---

Potrei affrontare il problema dal punto di vista tecnico, ma perderei l’attenzione del lettore. Facciamo allora qualche esempio concreto.

I miei genitori, che vivono ancora in Italia, comunicano con me attraverso dei tablet su cui ho installato alcuni programmi. Siccome ospito sia un server Matrix (una fork di Conduit scritta da me) sia un server XMPP, potevo scegliere tra i due.

E qui viene il bello.

La mia prima scelta cade su Matrix: più moderno, client più ricchi, più opzioni, eccetera.

E qui comincia il dramma.

A un certo punto il “meraviglioso” client Matrix, Element, rivolge una richiesta ai miei genitori. Hanno due tablet e un cellulare (mio padre ha ancora le mani da fabbro: un dito suo vale due dita mie, e le tastiere del telefono non riesce a usarle), quindi si trovano in una situazione multi-client. E i tablet si aggiornano.

Risultato: Element chiede di “verificare la sessione”. Non chiede, sia chiaro, di premere un pulsante. Non fa una domanda semplice. No: propone tre strade, tutte a carico dell’utente. La prima è prendere un altro dispositivo già verificato, accettare la richiesta e confrontare una sequenza di emoji sui due schermi, controllando che siano identiche e nello stesso ordine. La seconda è inquadrare con la fotocamera un QR code mostrato sull’altro dispositivo. La terza, se non c’è un altro dispositivo verificato a portata di mano, è inserire la “chiave di sicurezza”: un codice di 48 caratteri (Il numero deriva dalla specifica Matrix: la chiave è composta da un prefisso di 2 byte, 32 byte di chiave e 1 byte di parità, codificati in base58, il che dà 48 caratteri, mostrati in gruppi di 4.), generato a caso quando si è attivata la cifratura, che si suppone l’utente abbia conservato da qualche parte. Con tre dispositivi in casa, i miei genitori hanno l’imbarazzo della scelta. E digitare 48 caratteri, che goduria!!!!

E se non si fa niente? La sessione resta non verificata, compare un “leggibilissimo” avviso sulle chiavi di cifratura e, ciliegina sulla torta, i messaggi cifrati più vecchi non si possono leggere, perché le chiavi per decifrarli vengono scaricate solo dopo la verifica. Cosa che ovviamente l’utente medio capirà al volo.

Quando tutte queste cose random hanno cominciato ad accadere, ovviamente i miei sono andati nel panico e mi hanno chiesto cosa fare. Anziche' lanciarli in una complessa procedura che comunque andava rifatta ad ogni cazzo di aggiornamento, o altro, ho deciso in fretta: "riapri Whatsapp". Fine. E non me ne frega niente se voi crociati contro le malvagie multinazionali adesso mi odiate: parliamo di due ottantenni piuttosto svegli, ma pur sempre ottantenni, e non ho alcuna intenzione di lasciare che questa cattiva abitudine di scaricare sull’utente decisioni informate sulla sicurezza dell’endpoint arrivi fino a loro. È una scelta sbagliata, punto.

Certo, la volta successiva che sono sceso in Italia mi sono messo di buzzo buono e ho installato un client XMPP. Solo che al primo avviso su OMEMO ho dovuto fare marcia indietro e tornare a WhatsApp.

E non è nemmeno colpa di un client fatto male. Lo sviluppatore di Conversations, il client XMPP più diffuso su Android, ha introdotto apposta una modalità chiamata “Blind Trust Before Verification”: il client si fida a scatola chiusa dei nuovi dispositivi dei contatti, finché qualcuno non decide di verificarli. Un compromesso dichiarato, nato proprio per ridurre gli avvisi, e che lo stesso autore ammette essere tale, visto che la cifratura senza verifica serve a poco. Il risultato è lo stesso: prima o poi la decisione torna all’utente.

E no, non parlatemi di Telegram. Quando ho chiesto il codice da inserire nel client, Telegram ha provato a mandarmelo per email, cosa che fa dal 2022. Sul MIO server. Che non accetta posta in chiaro senza STARTTLS, OVVIAMENTE. Il codice non è mai arrivato. Avete capito bene: Telegram ha tentato di mandare un codice di accesso su SMTP in chiaro. Pagliacci!!

---

Ed è questo il punto. Non voglio sostenere che due ottantenni e una cugina “utente evoluta” rappresentino il cliente medio. Il problema è capire chi sia, questo utente medio.

Se ipotizziamo che le competenze informatiche siano distribuite a caso, diciamo secondo una gaussiana, metà della popolazione sta per definizione sotto la media. E siccome per prendere una decisione informata sulla sicurezza di un endpoint serve una competenza ben superiore a quella media, scopriamo subito che stiamo chiedendo di decidere, e quindi di sbagliare, a più della metà delle persone.

E la gaussiana è l’ipotesi ottimista. Quando l’OCSE è andata a misurare davvero queste competenze, su 33 paesi ricchi, il quadro è risultato molto peggiore: solo il 5% della popolazione ha competenze informatiche elevate, e appena un terzo riesce a portare a termine compiti di media complessità. Il 26% degli adulti non era proprio in grado di usare un computer. E parliamo di persone tra i 16 e i 65 anni: gli over 65, che in media se la cavano peggio, nello studio non c’erano nemmeno. I miei genitori, per dire, sarebbero rimasti fuori dal campione.

E la cosa incredibile è che questa mentalità ha contagiato anche il mondo dell’open source, che è nato anche come ribellione contro gli Unix proprietari come AIX, dove ti servivano settantadue certificazioni prima di poter anche solo PENSARE di guardare il monitor di un RS/6000.

Infatti, quando lo faccio notare, quelli che il software lo SCRIVONO mi rispondono quasi subito: è colpa dell’utente. Il ragionamento è più o meno questo: “Io, a 13 anni, ho imparato a usare OdioBSD con il suo terminale EBCDIC in esadecimale, 100% User Enemy. La shell era Fottitish, che rispondeva a ogni comando sbagliato con un core dump - su seriale - e ti lasciava arrangiare. Come editor c’era solo Bestemmiacs, che per salvare un file voleva sei tasti premuti in contemporanea, uno dei quali col gomito. I pacchetti si installavano con pkg_soffri, che risolveva le dipendenze chiedendoti di risolverle tu con un sottofondo death metal tibetano, e il filesystem era il glorioso DataLOSS_FS, così chiamato per ovvi motivi. Il manuale? 'man odio', che rimandava a 'man rtfm', che rimandava a 'man odio'. E sono venuto su benissimo. (E anche il mio amichetto, Satana Manson!.) Potranno pure imparare un pochino di informatica anche loro, 'sti babbani? Mica gli chiedo di leggere in binario, cribbio: ma l’esadecimale lo sanno anche i babbani!”

---

Questa cultura di scaricare decisioni informate sulle spalle dell’utente non è casuale. E se è riuscita a infilarsi perfino nella mente granitica del sistemista Unix forgiato da OdioBSD versione OrdaMongola, figuriamoci se non è finita ovunque. Ormai siamo tutti abituati all’idea che tocchi a noi gestire diciassette sistemi di OTP diversi. Quello di Microsoft vuole che tu copi nell’app un numero di due cifre mostrato sullo schermo. Quello di Cisco, Duo, nella versione “Verified Push” di cifre ne vuole tre. Il classico autenticatore TOTP ne vuole sei. Ognuno con la sua logica, la sua app, le sue notifiche, i suoi aggiornamenti obbligatori. E porcamadonna, ma che cazzo: RADIUS, in confronto, era una manna dal cielo.

Il problema nasce dal cosiddetto “Disclaimer of Warranty”, la clausola di esclusione della garanzia. Non dico che fuori dall’IT non esista, ma quelli dell’IT ormai sono surreali. Non ho voglia di spiegarlo in termini tecnici, quindi vi faccio un esempio.

Se Volkswagen avesse usato lo stesso Disclaimer of Warranty di Microsoft Windows 11, di fronte allo scandalo delle emissioni diesel avrebbe potuto rispondere, LEGALMENTE: “Ehi. Innanzitutto io l’auto non ve l’ho MAI venduta: ve la lascio usare in licenza. Secondo, voi la prendete AS IS, così come la vedete dal concessionario, e non è colpa mia se ci avete messo il carburante e poi l’avete accesa. Terzo, non garantisco che sia adatta ad alcuno scopo particolare: che diavolo significa che volevate viaggiare con la nostra auto?”

E quando un intero settore ragiona così da quarant’anni, non c’è da stupirsi se poi chiede all’utente finale decisioni informate che magari richiedono di leggere il codice Verilog di ogni ASIC e di ogni SoC, e di essere certificati in cinquecento specialità della sicurezza informatica. Come sarebbe a dire che non avete un’appliance Juniper davanti al forno di casa? Cavolo, ma uno straccio di rack da 42U in salotto no, eh?

---

E per questo il dramma dei frigoriferi francesi sta passando sotto gli occhi di tutti senza che nessuno noti il problema vero. Le decisioni informate sulla sicurezza dei frigoriferi sono state delegate, o peggio “cascaded”, agli utenti. Ma nessuno se ne accorge: siamo troppo impegnati a usare il quarantaduesimo fattore di autenticazione dei nostri preservativi, che vogliono il login prima di scopare.

Alla fine, tutti i cazzari della sicurezza informatica, quelli che magari ci spiegano quanto siano devastanti gli attacchi al layer 8, 9 e 10, sono così ipnotizzati da quarant’anni di questa mentalità da non accorgersi che, delegando tutto all’utente finale, gli attacchi al layer 8, 9 e 10 li stiamo COSTRUENDO noi. E poi pretendiamo che il problema sia l’exploit, o il firmware, o la rete untrusted.

Ma il problema sta nel produttore. Nella sua mentalità, e nel fatto che, per proteggere le aziende del software, si sia concesso loro un livello di irresponsabilità senza precedenti nel mondo industriale.

Ho già scritto che entro la fine del 2026 arriva la nuova direttiva europea sulla responsabilità per prodotti difettosi, la 2024/2853, che va recepita dagli Stati membri entro il 9 dicembre. Per la prima volta il software è considerato un prodotto a tutti gli effetti, e la responsabilità del produttore non potrà più essere limitata o esclusa per contratto. Addio disclaimer, almeno sulla carta.

Ma finché non vedrò come verrà applicata, onestamente non ci crederò. Anche perché, guarda caso, il caso francese ci sarebbe rimasto fuori comunque: la direttiva vale solo per i prodotti immessi sul mercato dopo il 9 dicembre 2026, tutela solo le persone fisiche ed esclude i danni a beni usati esclusivamente per scopi professionali. I frigoriferi di un supermercato, appunto.

Guarda caso.

Questa mentalità è ormai troppo diffusa, troppo interiorizzata.

E deve sparire da tutta la supply chain del software.

E questo richiede molto tempo.

A meno che non arrivi un incidente talmente grave da costringere i politici a fare davvero delle regole. Regole che siano regole.