Nessun malware, nessun riscatto, nessuna patch: il caso KNXlock

Una parola cambiata in un database

Il 15 luglio 2026, dentro il record di CVE-2023-4346, un campo è passato da none ad active.

È il vettore SSVC che CISA mantiene per ogni vulnerabilità: la voce exploitation. Fino al primo ottobre 2024 diceva none. Da mercoledì dice active, e la CVE è entrata nel catalogo delle Known Exploited Vulnerabilities con scadenza 29 luglio.

La cosa curiosa è che l'attacco che quella CVE descrive è successo nell'ottobre del 2021.

Cosa è successo davvero

La ricostruzione arriva da Limes Security, la società austriaca che ha gestito il caso e ha poi segnalato la vulnerabilità a CISA. Nell'ottobre 2021 un'azienda di ingegneria tedesca chiede aiuto: avevano progettato il sistema di automazione di un sito di medie dimensioni su KNX, lo standard di building automation più diffuso in Europa. Qualcuno era entrato da internet e aveva chiuso fuori i proprietari.

L'edificio conteneva diverse centinaia di componenti KNX. Tre quarti non funzionavano più.

Non è stato usato malware. Non è stato usato un exploit. Gli attaccanti hanno fatto due cose, entrambe previste dal protocollo. Primo: hanno scaricato i dispositivi — in gergo KNX, unload, l'operazione che rimuove l'applicazione dal dispositivo. Secondo: hanno impostato la BCU key, la password da 4 byte che lo standard prevede per impedire modifiche non autorizzate ai dispositivi.

1. 01
   Accesso dalla rete

   il bus KNX era raggiungibile da internet
2. 02
   UNLOAD

   l'applicazione viene rimossa dal dispositivo — previsto dal protocollo
3. 03
   SET BCU KEY

   4 byte, la password che lo standard offre per bloccare le modifiche
4. 04
   Nessun reset

   i vendor: dispositivi da considerare bricked

L'analogia che usa Limes è precisa: è come formattare il disco di un computer e poi mettere una password sul disco. La macchina si accende e non fa niente, e senza quella password non puoi più installarci sopra nulla.

L'edificio aveva perso la sua intelligenza. Non solo i sistemi complessi: anche gli interruttori della luce e il controllo delle tapparelle. L'ingegnere ha raccontato che alla fine hanno fatto funzionare l'intero edificio in modalità manuale, ricablando componenti per azionarli dal quadro elettrico.

La risposta dei vendor

Qui il caso smette di essere una storia di sicurezza informatica e diventa una storia di progettazione.

L'azienda di ingegneria ha chiamato i produttori dei dispositivi. Più di uno. La risposta è stata unanime: nessun reset è possibile, i dispositivi sono da considerare bricked. Il consiglio: smontare e sostituire tutto. Fra hardware, installazione e verifica, oltre centomila euro.

Non era un errore dei vendor. La BCU key fa esattamente quello per cui è stata progettata: impedire che qualcuno modifichi un dispositivo senza conoscere la password. Ha funzionato perfettamente. Solo che a impostarla non era stato il proprietario.

È questo che rende il caso diverso dai soliti. Non c'è una vulnerabilità di memoria, non c'è un input non validato, non c'è una riga di codice sbagliata. La CWE assegnata è la 645, Overly Restrictive Account Lockout Mechanism: il difetto è che il meccanismo di blocco è troppo efficace. E infatti non esiste una patch. L'advisory CISA non dice "aggiornate": dice di impostare la BCU key in ogni progetto KNX già completato e di consegnarla al proprietario dell'edificio con la documentazione. La difesa è occupare il posto prima che lo occupi qualcun altro.

Limes le chiavi le ha recuperate, alla fine, ma per una via non prevista: dump della memoria direttamente dalle CPU — possibile solo dove la protezione della CPU non era attiva — e brute force ristretto all'area in cui la chiave era plausibilmente scritta. Sull'autenticazione il bruteforce era stato scartato subito: i dispositivi rispondono così lentamente che ci sarebbero voluti anni.

Il dettaglio che dice tutto

Il vettore CVSS assegnato da ICS-CERT è AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. Base score 7.5.

Guardate le ultime tre lettere.

Non viene rubato niente. Non viene alterato niente. L'edificio semplicemente si ferma. È il profilo di rischio più insolito che si veda in una CVE, e descrive con precisione un attacco che non voleva dati.

E il riscatto? Non è mai arrivato. Nessuna richiesta, nessun contatto. Limes avanza due ipotesi, dichiarate come tali: o era vandalismo digitale avanzato, o gli attaccanti non sono riusciti a capire, da internet, a chi indirizzare la nota. Non lo sappiamo, e chi vi dice il contrario sta indovinando.

1. Ottobre 2021
   L'attacco

   Un'azienda di ingegneria tedesca perde il controllo dell'edificio. Tre quarti dei componenti fuori uso.

2. Marzo 2023
   La tecnica

   MITRE crea T0892 Change Credential. Contributore: Felix Eberstaller, di Limes.

3. Agosto 2023
   La CVE

   CISA pubblica ICSA-23-236-01. CVE-2023-4346, CVSS 7.5.

4. Ottobre 2024
   exploitation: none

   Il vettore SSVC di CISA dice: nessuno sfruttamento osservato.

5. 15 luglio 2026
   exploitation: active

   La CVE entra nel catalogo KEV. Scadenza: 29 luglio.

Cosa dichiariamo di non sapere

Molto, in questo caso.

Non c'è attribuzione: nessun gruppo, nessuna nazionalità, nessun movente confermato. CISA scrive di aver ricevuto segnalazioni di sfruttamento attivo, ma non pubblica indicatori, né conteggi di vittime, né una finestra temporale. Il dato dei 16.000 sistemi potenzialmente vulnerabili nell'area DACH viene da scansioni di Alpha Strike Labs riportate da Limes nell'agosto 2023: è una stima di esposizione, non di compromissione, e ha tre anni. Non sappiamo, soprattutto, perché CISA abbia flaggato adesso una CVE ferma dal 2023 — se ci siano nuovi casi nel 2026 o se sia una riclassificazione di segnalazioni note. L'unica cosa documentata è che Limes riceveva ancora segnalazioni nel 2023, due anni dopo il primo caso.

Sull'ID MITRE, invece, il terreno è solido, ed è una catena verificabile: T0892 Change Credential è stato creato il 30 marzo 2023 nella matrice ATT&CK for ICS, il contributore accreditato è Felix Eberstaller — lo stesso ricercatore di Limes che ha segnalato CVE-2023-4346 a CISA — e la descrizione della tecnica cita «una catena di incidenti avvenuta in Germania, dove gli avversari hanno chiuso fuori gli operatori dai controller del sistema di automazione dell'edificio abilitando una BCU key precedentemente non impostata». Non è una mappatura ragionata: è la tecnica nata da questo caso.

L'unico altro esempio che MITRE elenca sotto T0892 vale da solo il viaggio: durante gli attacchi wiper in Polonia del 2025, gli attaccanti hanno cambiato la password dei device server seriali Moxa NPort per ostacolare il ripristino. Contesto diverso, stessa idea. La lezione di KNXlock non riguarda KNX.

Cosa portarsi a casa

I protocolli di controllo industriale sono più potenti di quanto la maggior parte delle persone immagini, e le funzioni di protezione che contengono non sanno chi sia il legittimo proprietario. Sanno solo chi è arrivato prima.

Se gestite un impianto KNX: la BCU key va impostata, in ogni progetto, e consegnata al committente con la documentazione. Una chiave impostata da voi è una chiave che nessun altro può impostare. Il resto sono i fondamentali che CISA ripete da vent'anni, e qui valgono più che altrove perché non c'è una patch a fare da rete: i dispositivi di controllo non raggiungibili da internet, rete di automazione separata da quella aziendale, accesso remoto solo via VPN aggiornata — ricordando che una VPN è sicura quanto i dispositivi che ci sono attaccati.

E se avete un backup della configurazione ma non della chiave, non avete un backup.