Migliaia di server violati in pochi minuti con una falla BMC vecchia di 20 anni

Un componente nascosto dentro quasi ogni server può offrire a un aggressore un livello di controllo paragonabile all’accesso fisico alla macchina. Si tratta del Baseboard Management Controller (BMC), un piccolo computer indipendente dal sistema operativo, progettato per consentire agli amministratori di riavviare il server, aprire una console remota, montare immagini ISO, aggiornare il firmware e modificare la configurazione hardware anche quando il sistema principale non risponde.

Una ricerca pubblicata da Lava mostra però quanto possa diventare pericoloso lasciare questa interfaccia esposta su Internet: i ricercatori hanno individuato 36.872 sistemi raggiungibili pubblicamente e, in circa due casi su tre, hanno ottenuto materiale crittografico utile per tentare il recupero offline delle password.

Lava mette a disposizione anche una mappa interattiva, continuamente aggiornata, che indica dove si trovano i sistemi più esposti.

Il controller BMC e la relazione con il protocollo IPMI

Il BMC è il componente hardware che rende possibile la gestione remota del server; IPMI, invece, è uno dei protocolli usati per comunicare con quel controller. IPMI definisce i comandi, i messaggi e le procedure con cui un amministratore può interrogare il controller BMC o impartirgli ordini attraverso la rete.

La versione 2.0 della specifica risale al 2004 e introdusse, tra le altre cose, un meccanismo di autenticazione più evoluto chiamato RAKP. Proprio in questa procedura si trova la debolezza catalogata come CVE-2013-4786, resa pubblica nel 2013 dalle analisi di Dan Farmer e Rapid7: un client non autenticato può ottenere dal controller un valore crittografico derivato dalla password e usarlo per tentare il recupero della credenziale offline.

A oltre 20 anni dalla pubblicazione di IPMI 2.0, migliaia di BMC continuano a esporre il servizio sulla porta UDP 623 direttamente verso Internet. La novità, quindi, non riguarda la scoperta di un difetto sconosciuto, ma il fatto che una debolezza progettuale mai davvero rimossa oggi si combina con password prevedibili e con una potenza di calcolo enormemente superiore a quella disponibile quando il protocollo fu definito.

I numeri raccolti da Lava rendono bene l’idea. Su 36.872 indirizzi IP che esponevano il servizio, 24.650 controller hanno restituito almeno una risposta RAKP contenente un codice derivato dalla password prima che il client completasse l’autenticazione. In 6.240 casi i ricercatori hanno associato un nome utente vuoto a una password debole; altri 2.340 sistemi usavano account come ADMIN o root con credenziali presenti nelle comuni raccolte di password. Il gruppo non ha utilizzato le credenziali recuperate per accedere ai server: ha verificato i candidati offline e ha comunicato i risultati ai gestori.

Quali server utilizzano il controller BMC

Per capire la gravità dell’esposizione bisogna separare il BMC dal server che amministra. Il controller possiede un proprio processore, memoria, firmware, interfaccia di rete e sistema operativo embedded, spesso basato su Linux. Può usare una porta Ethernet dedicata oppure condividere una scheda di rete con l’host tramite una modalità sideband. In entrambi i casi continua a funzionare anche quando il server è spento, purché l’alimentatore fornisca la tensione di standby.

I produttori assegnano nomi diversi a questa tecnologia: HPE usa iLO, Dell iDRAC, Lenovo XClarity Controller, mentre Supermicro integra una propria piattaforma BMC.

Esiste inoltre OpenBMC, progetto open source adottato in varie infrastrutture cloud e hyperscale.

Le funzioni offerte cambiano da un prodotto all’altro, ma il nucleo rimane simile: telemetria dei sensori, controllo dell’alimentazione, accesso KVM remoto, gestione degli utenti, aggiornamenti firmware e virtual media.

Il virtual media, per esempio, permette di presentare al server un’immagine ISO remota come se fosse un DVD o una chiavetta collegata fisicamente. È una funzione preziosa per installare un sistema operativo su una macchina distante migliaia di chilometri; nelle mani sbagliate, però, consente di avviare strumenti arbitrari, sostituire il software installato o intervenire prima ancora che parta il sistema operativo.

Un BMC compromesso, però, opera al di fuori del perimetro osservato da antivirus, EDR e agenti di monitoraggio installati sull’host. L’attaccante può quindi mantenere una posizione privilegiata senza lasciare le tracce tipiche di un’intrusione nel sistema operativo.

Come IPMI consegna all’esterno un valore derivato dalla password

La debolezza centrale riguarda il meccanismo RAKP, acronimo di RMCP+ Authenticated Key-Exchange Protocol. IPMI 2.0 lo usa per negoziare una sessione autenticata tra il client amministrativo e il controller. Durante lo scambio, il richiedente invia il nome dell’account; il BMC risponde con un codice HMAC calcolato usando la password dell’utente e una serie di dati di sessione noti anche al client.

Nel caso di IPMI, la chiave deriva dalla password dell’account: il controller invia il risultato prima di aver accertato che chi lo richiede conosca davvero quella password.

Un soggetto non autenticato può quindi raccogliere la risposta e provare localmente migliaia o miliardi di possibili credenziali, confrontando ogni HMAC calcolato con quello ricevuto dal BMC.

Dopo aver acquisito una singola risposta, l’aggressore remoto non deve più comunicare con il bersaglio per ogni tentativo. I limiti sul numero di login, i blocchi temporanei e molti sistemi di rilevamento delle autenticazioni fallite perdono quindi efficacia. Dal server arriva una sola richiesta apparentemente innocua; il lavoro più rumoroso si sposta sulle CPU o sulle GPU dell’aggressore.

La richiesta di riscatto trovata su un pannello HPE iLO 4

Durante l’indagine, i ricercatori di Lava hanno trovato una pagina di accesso HPE iLO 4 che mostrava una richiesta di riscatto nel campo Security Notice. Il messaggio sosteneva che i dati del server fossero stati cifrati e chiedeva 0,3 BTC, accompagnando la pretesa con un riferimento a RSA-2048 e un indirizzo email usa e getta.

Lava non ha potuto verificare se i dischi fossero davvero cifrati: la modifica dell’avviso dimostrava tuttavia che qualcuno, non autorizzato, aveva ottenuto accesso all’interfaccia amministrativa.

Nel 2021 fu scoperto la campagna iLOBleed, un impianto persistente individuato nel firmware HPE iLO 4 e collegato ad attacchi distruttivi. Il malware manipolava il processo di aggiornamento e poteva simulare l’installazione di firmware legittimi, mantenendo il controllo sul controller. Episodi simili mostrano perché un incidente sul BMC non possa essere gestito come una normale infezione del sistema operativo.

Come verificare se i controller sono esposti

Il primo controllo consiste nel fare un inventario di tutti i controller BMC, compresi quelli installati su server dismessi, appliance, nodi di laboratorio e macchine fornite da terzi. L’elenco dovrebbe includere indirizzo IP, modello, versione firmware, interfaccia fisica, VLAN, account autorizzati e servizi attivi. Senza un inventario affidabile è facile applicare una regola firewall ai server principali e dimenticare apparati secondari (che potrebbero essere sfruttati dagli aggressori per attivare movimenti laterali).

Dal perimetro esterno occorre verificare che la porta UDP 623 non risponda sugli indirizzi pubblici. La scansione va svolta con autorizzazione e senza limitarsi a TCP: IPMI usa soprattutto UDP, quindi un controllo tradizionale delle sole porte TCP può restituire un falso senso di sicurezza. È opportuno cercare anche pannelli Web e API pubblicati sulle porte 80, 443 o su porte personalizzate.

Un secondo test deve partire dalle reti interne. L’assenza di esposizione pubblica è necessaria, ma non sufficiente: ransomware e attaccanti già presenti nella LAN cercano spesso interfacce di gestione per aumentare privilegi e persistenza.

Servizi come Shodan e altri motori di ricerca per dispositivi connessi possono aiutare a individuare esposizioni già indicizzate. Non sostituiscono una verifica diretta: i risultati possono essere incompleti, obsoleti o associati a indirizzi riassegnati.

La rete di gestione deve essere separata

La mitigazione principale non richiede un nuovo prodotto: più semplicemente, IPMI non deve essere raggiungibile da Internet. La porta UDP 623 va bloccata sul firewall perimetrale e, quando il protocollo non serve, disattivata direttamente sul controller. Pubblicare il pannello dietro un semplice cambio di porta non offre una protezione significativa; gli scanner individuano rapidamente servizi collocati su porte non standard.

I BMC dovrebbero risiedere in una VLAN di management dedicata, separata sia dalla rete utenti sia dai workload di produzione. Le access control list devono applicare il principio del minimo privilegio: soltanto pochi sistemi amministrativi possono iniziare connessioni verso i controller, mentre i BMC non dovrebbero raggiungere liberamente Internet o altre reti interne.

L’accesso remoto può passare attraverso una VPN con autenticazione a più fattori oppure un bastion host rinforzato. Meglio evitare regole che consentono a un’intera rete aziendale di collegarsi ai BMC: un computer compromesso non deve poter interrogare centinaia di controller.

Supermicro raccomanda esplicitamente di mantenere i controller su reti accessibili localmente, limitare il traffico sulle porte sensibili e filtrare UDP 623 e TCP 5900 tramite firewall e router. La guida del produttore suggerisce anche aggiornamenti firmware periodici, firme crittografiche e strumenti dedicati per il provisioning. Sono indicazioni corrette, ma la loro efficacia dipende dall’applicazione coerente su tutto il parco macchine.