24.650 BMC esposti rilasciano gli hash delle password IPMI: e non esiste patch

Il 28 luglio 2026 i ricercatori di Lava hanno pubblicato i risultati di una scansione Internet dei servizi IPMI. Su 36.872 baseboard management controller esposti, 24.650 — poco meno di due terzi — hanno restituito un hash derivato dalla password a un client non autenticato che si è limitato a chiederlo. Oltre 14.000 si trovano negli Stati Uniti, il resto è concentrato tra Germania, Cina, Paesi Bassi e Regno Unito, secondo la copertura di BleepingComputer.

Il dato interessante non è il numero. È che non esiste una patch, non è mai esistita e non arriverà. Il difetto sta nella specifica IPMI 2.0, pubblicata nel 2004: ogni implementazione conforme lo riproduce fedelmente. Questo articolo parla di cosa si fa davvero quando il processo di vulnerability management — trova, applica la patch, chiudi il ticket — non ha una mossa valida.

Cosa rilasciano davvero i BMC esposti

Un baseboard management controller è un piccolo computer indipendente saldato sulla scheda madre di quasi ogni server rack. Ha processore, memoria, stack di rete e dominio di alimentazione propri. Funziona a host spento. Può montare virtual media, pilotare la console, spegnere e riaccendere lo chassis e riflashare il firmware. Dell lo chiama iDRAC, HPE iLO, Lenovo XCC, e una fetta ampia del mercato è Supermicro — che nel dataset di Lava rappresentava oltre il 50% dei controller che hanno risposto.

CVE-2013-4786 (CVSS 7.5, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, CWE-255) descrive il meccanismo con precisione: il protocollo RMCP+ Authenticated Key-Exchange (RAKP) usato da IPMI 2.0 restituisce, nel messaggio RAKP 2, un HMAC-SHA1 calcolato sulla password dell'account e su valori di sessione che il richiedente già conosce. Il controller lo invia prima che l'autenticazione sia completata. È previsto dal design: è così che l'handshake di mutua autenticazione dovrebbe funzionare.

La conseguenza è che chiunque raggiunga la porta UDP 623 ottiene un bersaglio per cracking offline. E questo pesa più di quanto sembri:

• Nessun lockout si applica. Blocco account, rate limiting e alert sui login falliti lavorano tutti sui tentativi di login. Qui non ce ne sono. Una richiesta produce un hash; ogni tentativo successivo avviene sull'hardware dell'attaccante.
• Nella maggior parte delle implementazioni non viene generata alcuna voce di log, perché nessuna autenticazione è stata tentata.
• Il budget di tentativi è illimitato. È la differenza fra una policy di password che deve sopravvivere a qualche migliaio di tentativi online e una che deve reggerne qualche migliaio di miliardi offline.

Lava ha rilevato che oltre il 30% degli hash recuperati corrispondeva a password ricavabili da wordlist comuni e da formati di fabbrica prevedibili. Inoltre 6.240 host (16,9%) hanno accettato uno username vuoto e 2.340 (6,3%) usavano password amministrative presenti in dizionari pubblici.

Perché il problema degli hash IPMI non si risolve con una patch

Sono gli schemi di password predefinite di fabbrica a trasformare un attacco offline teorico in un'ora di tempo GPU. I vendor stampano su un adesivo una password per chassis, generata da un formato fisso e stretto: il che significa che lo spazio delle chiavi è noto in anticipo all'attaccante.

Vendor	Formato password di fabbrica	Spazio delle chiavi	Recupero offline (Lava)
Supermicro	10 lettere maiuscole	26¹⁰ ≈ 141.000 miliardi	~1 ora, server a 8 GPU
HPE iLO	8 caratteri, maiuscole + cifre	36⁸ ≈ 2.800 miliardi	~32 secondi, 8× RTX 6000 PRO
HPE iLO	idem	idem	~1 giorno, singolo Apple M3

Un giorno di lavoro di un portatile recupera una password di fabbrica iLO. Trentadue secondi se hai noleggiato la macchina giusta. Supermicro ha dichiarato ai ricercatori che lo scenario è plausibile e che rivedrà la policy sulle password predefinite nelle revisioni future — il che aiuta i server che nessuno ha ancora comprato.

La posizione di Dell sul difetto di fondo è coerente da oltre un decennio e vale la pena riportarla, perché ridefinisce l'intero esercizio:

Si tratta di un problema intrinseco alla specifica IPMI v2.0.

Non c'è una versione corretta. Non c'è un advisory da seguire. I moduli Metasploit che estraggono questi hash (auxiliary/scanner/ipmi/ipmi_dumphashes) e che abusano del cipher zero circolano dalla ricerca originale su IPMI di Dan Farmer e HD Moore del 2013, e Tenable ha un plugin Nessus dedicato da allora. Tutto di questo attacco è pubblico, strumentato e banalmente automatizzabile da tredici anni. L'esposizione è rimasta comunque — e fra maggio e luglio 2026 Lava ha osservato la comparsa di circa 60 nuovi indirizzi IPMI esposti al giorno.

Il resto della famiglia IPMI

Trattarlo come un singolo CVE ne sottostima la portata. La stessa specifica ha prodotto un flusso costante di difetti di autenticazione, attraverso vendor diversi e due decenni:

• CVE-2013-4782 — cipher suite 0 sui BMC Supermicro. L'attaccante fornisce qualsiasi password ed esegue comandi IPMI arbitrari. CVSS v2 10.0. Il cipher zero è una modalità "nessuna autenticazione" prevista dalla specifica, distribuita attiva.
• CVE-2013-4037 e CVE-2013-4038 — la stessa classe RAKP nell'Integrated Management Module di IBM. Vendor diverso, stesso protocollo, stesso anno.
• CVE-2021-39296 — OpenBMC 2.9: messaggi IPMI costruiti ad arte aggirano completamente l'autenticazione e restituiscono il controllo totale del sistema. La reimplementazione open source ha ereditato la classe.
• CVE-2024-3411 — CVSS 9.1, pubblicato ad aprile 2024, CWE-331: le sessioni autenticate IPMI non generano entropia sufficiente, quindi session ID prevedibili consentono il session hijacking. Confermato su Dell iDRAC8 e sull'implementazione IPMI 2.0 di Intel.

Vent'anni dopo la pubblicazione, nel 2024 la specifica generava ancora difetti critici di autenticazione. È questo il vero risultato. Chi pensa di gestire il rischio un CVE alla volta sta sottoscrivendo un abbonamento a vita.

Il computer più privilegiato che nessuno monitora

Un BMC compromesso non equivale a un server compromesso. È peggio, in un modo preciso che cambia la risposta agli incidenti.

Il controller sta sotto il sistema operativo. Non può eseguire il vostro agente EDR — non c'è dove installarlo. Non compare nell'inventario delle patch del sistema operativo. Spesso non compare affatto nella CMDB, perché è stato configurato da chi ha montato l'hardware nel rack. E da lì un attaccante può montare una ISO come virtual media e avviare l'host da quella, leggere e scrivere memoria e dischi dell'host, catturare la console o riflashare il firmware per persistere attraverso una reinstallazione completa del sistema operativo.

Quest'ultimo punto non è ipotetico. Il rootkit iLOBleed, documentato mentre persisteva dentro il firmware iLO 4 di HPE, è sopravvissuto alla cancellazione dei dischi ed è stato collegato ad attacchi distruttivi contro server. La scansione di Lava ha trovato una pagina di login iLO 4 esposta che mostrava già una richiesta di riscatto da 0,3 BTC con rivendicazione di cifratura RSA-2048: qualcuno era arrivato prima.

Entrambi i fronti regolatori si sono mossi. NSA e CISA hanno pubblicato una guida congiunta sull'hardening dei BMC nel giugno 2023, avvertendo che un BMC trascurato offre all'avversario una testa di ponte con capacità di esecuzione pre-boot. E lo stesso giorno in cui è uscita la ricerca di Lava, CISA, FBI e l'Australian Cyber Security Centre hanno rilasciato CI Fortify — Advice for isolating vital systems, che stabilisce che le zone di management usate per amministrare l'infrastruttura devono a loro volta essere isolate dagli attaccanti. Quello è il controllo. È l'unico controllo.

Remediation

Non esiste una patch, quindi questo runbook è più lungo del solito su discovery, controlli e hunting — e non ha assolutamente nulla sotto la voce "installa la versione corretta".

1. Sono impattato?

Se possedete server fisici, assumete di sì. La domanda è se il controller sia raggiungibile e se la password sia quella di fabbrica.

# Trova i listener IPMI sui vostri range (UDP 623 — le scansioni TCP li mancano tutti)
nmap -sU -p 623 --script ipmi-version 10.0.0.0/8

# Verifica host per host che l'hash RAKP torni davvero indietro
msfconsole -q -x "use auxiliary/scanner/ipmi/ipmi_dumphashes; \
  set RHOSTS 10.0.0.0/24; set OUTPUT_HASHCAT_FILE /tmp/ipmi.hashes; run; exit"

# Testa il cipher zero — bypass totale dell'autenticazione, peggio della fuga di hash
msfconsole -q -x "use auxiliary/scanner/ipmi/ipmi_cipher_zero; set RHOSTS 10.0.0.0/24; run; exit"

# Dall'host stesso, enumera account e configurazione del canale
ipmitool user list 1
ipmitool lan print 1

Poi valutate onestamente la superficie esterna: interrogate i vostri range pubblici sulla UDP 623 dall'esterno della rete. Circa 60 organizzazioni al giorno scoprono per caso di appartenere a questo dataset.

2. Patch — cosa è realmente disponibile

Per CVE-2013-4786 in sé: nulla, in modo permanente. Ciò che è aggiornabile:

• Firmware del BMC — portate iDRAC / iLO / XCC / Supermicro all'ultima versione. Questo chiude i bug implementativi come CVE-2021-39296 e CVE-2024-3411, non la disclosure RAKP.
• Migrate a Redfish dove l'hardware lo supporta e disabilitate completamente l'interfaccia IPMI-over-LAN. Redfish è basato su HTTPS e non prevede lo scambio di hash pre-autenticazione. È l'unica modifica che rimuove davvero la vulnerabilità invece di nasconderla.

3. Non potete rimuovere IPMI? Controlli compensativi

Qui non sono un "nice to have": sono la remediation.

• Bloccate la UDP 623 su ogni perimetro di rete, e verificatelo con una scansione dall'esterno verso l'interno, non con una revisione delle regole di firewall.
• Spostate ogni BMC su una VLAN di management out-of-band dedicata, raggiungibile solo via bastion host o VPN. È il controllo specifico richiesto sia dal CSI NSA/CISA sia da CI Fortify.
• Ruotate ogni password di fabbrica. Lunga e casuale: è lo spazio delle chiavi, non l'entropia della vostra policy, a determinare la sopravvivenza. Se la password è sull'adesivo dello chassis, consideratela pubblica.
• Disabilitate cipher suite 0, IPMI 1.5, l'utente anonimo/null e l'autenticazione "NONE". Il cipher zero rende irrilevante la fuga di hash, perché non serve alcun cracking.
• Impostate password degli account BMC non riutilizzate altrove. L'hash che rilasciate diventa un seme per credential stuffing sul resto del parco macchine.

4. Cercate tracce di compromissione

Segnale	Dove	ATT&CK
UDP 623 in ingresso da fuori la VLAN di management	Firewall / netflow	T1046 Network Service Discovery
Risposte RAKP messaggio 2 verso sorgenti esterne	Cattura sul segmento di management	T1190 Exploit Public-Facing Application
Login BMC riuscito da ASN o geolocalizzazione nuovi	Syslog del BMC (inoltratelo: quasi nessuno lo fa)	T1078.001 Valid Accounts: Default Accounts
Eventi di mount virtual media / attach ISO	LC log iDRAC, IML iLO, event log XCC	T1542.001 Pre-OS Boot: System Firmware
Cicli di alimentazione o sessioni console (KVM) inattesi	Event log del BMC	T1021 Remote Services
Versione firmware divergente dalla golden image	API di inventario del vendor / Redfish	T1542.001
Riuso delle credenziali BMC craccate su account di sistema	Log di identity	T1110.002 Brute Force: Password Cracking

Estraete l'event log del BMC per l'intera finestra di retention, non solo per l'ultima settimana: questa esposizione è raggiungibile da quando l'host è stato montato nel rack.

5. Bonificate e verificate

L'ordine conta. Ruotare le credenziali prima di isolare l'interfaccia significa solo rilasciare il nuovo hash.

1. Isolate per primo — togliete il BMC dalla rete instradabile o bloccate la 623 sul perimetro.
2. Riflashate il firmware del BMC da immagini firmate dal vendor, e non fidatevi di un percorso di aggiornamento in-band su un host sospetto. Gli impianti firmware come iLOBleed sopravvivono alle reinstallazioni del sistema operativo e possono falsificare la stringa di versione che il controller dichiara.
3. Ruotate le credenziali BMC, poi ogni credenziale che quel BMC poteva raggiungere: le sessioni console catturano ciò che vi è stato digitato.
4. Ri-verificate dall'esterno: riscansionate i range pubblici sulla UDP 623 e rieseguite ipmi_dumphashes da una posizione di rete non fidata. Un risultato pulito ottenuto da dentro la VLAN di management non dimostra nulla.
5. Registrate formalmente il rischio residuo. Poiché non esiste patch, il rischio è accettato in modo permanente e il controllo compensativo è l'unica cosa che vi separa dal finding. Quell'accettazione va documentata, assegnata a un responsabile e ritestata, non data per scontata.

Quando non c'è una patch, il controllo è l'evidenza

È qui che il normale flusso di compliance si rompe. La domanda dell'auditor — "dimostrami che CVE-2013-4786 è stato risolto" — non ha risposta, perché non sarà mai risolto. La risposta onesta è: l'interfaccia non è raggiungibile, ecco la prova, ed ecco la prova del mese scorso e di quello prima. La segmentazione non è uno stato che si raggiunge una volta. È un'affermazione che decade ogni volta che qualcuno monta un server, cambia una regola di firewall o attiva una nuova gabbia in colocation.

Zero Hunt mappa ogni finding, scansione e remediation su 32 framework — fra cui NIS2, ISO 27001, DORA e NIST CSF — con scoring pesato per severità e mappatura incrociata dei controlli, così che un difetto di protocollo non correggibile venga registrato una sola volta come rischio accettato con un controllo compensativo assegnato, e soddisfi contemporaneamente i requisiti di segregazione di rete e gestione out-of-band di tutti, invece di ripetere il lavoro tre volte. Ogni report è firmato ECDSA al momento della scrittura, con catena di custodia per costruzione, e il Trust Center esporta il pacchetto che l'auditor richiede. Il punto non è la documentazione. È che "abbiamo isolato il management plane" diventa un'asserzione datata, firmata e verificabile, invece di una dichiarazione fatta a memoria in riunione.

Produrre quell'evidenza richiede però di testare davvero il confine, ed è la seconda metà del discorso. Lo swarm di 10 agenti AI esegue il Recon sul perimetro reale e non sulla CMDB, e l'agente Credential porta con sé un corpus di oltre 330 set di credenziali predefinite da SecLists — gli stessi formati di fabbrica che hanno reso banalmente indovinabili 2.340 host del campione di Lava. Ogni exploit gira in un container Docker effimero con hardening gVisor opzionale, quindi validare un'interfaccia di management non mette mai a rischio l'host dell'appliance. E poiché le campagne sono attivate dai cambiamenti oltre che pianificate, un nuovo asset che compare sul perimetro — un server appena montato con ancora la password dell'adesivo sul BMC — fa partire una campagna completa entro un'ora, invece di aspettare che il pentest annuale trovi ciò che uno scanner Internet-wide trova in un pomeriggio.

Le 24.650 organizzazioni di questo dataset non hanno deciso di esporre il proprio management plane dei server. Semplicemente non hanno mai controllato, e nessuno ha mandato loro una patch a ricordarglielo.

Se volete vedere cosa risponde davvero il vostro perimetro sulla UDP 623, contattateci o leggete perché validare l'esposizione è diverso dallo stimarla.