Sabato 19 luglio, il mondo della cybersecurity è stato scosso da una serie di avvisi di emergenza che hanno riguardato Microsoft SharePoint Server. Si tratta di quattro vulnerabilità, note con il nome di “ToolShell”, 2 delle quali erano state già identificate e corrette con una patch rilasciata a inizio luglio. Le falle consentono l’esecuzione di codice remoto non autenticato (RCE) a livello SYSTEM di Windows.

Finora, gli attacchi di sfruttamento di massa hanno già colpito l’Amministrazione di sicurezza nucleale degli Stati Uniti e oltre 400 altre  organizzazioni, tra cui multinazionali, servizi sanitari, enti governativi, operatori finanziari e infrastrutture energetiche critiche. L’attività di sfruttamento è stata rilevata inizialmente da Eye Security e tre CVE sono stati inseriti nel catalogo delle vulnerabilità note sfruttate (KEV) della CISA, risultando collegati anche ad attacchi ransomware condotti da gruppi  sponsorizzati dallo stato cinese. Attualmente sono disponibili diversi kit di exploit proof of concept (PoC) pubblici[1][2][3]. Numerosi CERT nazionali, tra cui CERT-EU [4], Paesi Bassi[5], Nuova Zelanda[6], Canada[7] e Germania [8], hanno emanato specifici avvisi sulle vulnerabilità di SharePoint. Secondo la Shadowserver Foundation, sono stati rilevati oltre 9.000 indirizzi IP SharePoint pubblici potenzialmente esposti a livello globale.

OPENVAS SECURITY INTELLIGENCE di Greenbone integra test di rilevamento della versione[9][10][11][12], un controllo attivo diretto[13] per tutti i CVE ToolShell e il monitoraggio attivo degli indicatori di compromissione (IoC) [14] associati nel nostro ENTERPRISE FEED. I clienti di OPENVAS ENTERPRISE FEED dovrebbero verificare regolarmente che i propri feed siano sempre aggiornati, così da assicurare che i dispositivi includano gli ultimi controlli di vulnerabilità. Di seguito analizziamo nel dettaglio questi insidiosi bug ToolShell.

Una cronologia degli eventi ToolShell

Di seguito una breve panoramica dei principali eventi legati alla campagna ToolShell fino ad oggi:

• 16 maggio 2025: le vulnerabilità sono state svelate per la prima volta durante la seconda giornata del Pwn2Own Berlin 2025 da Dinh Ho Anh Khoa di Viettel Cyber Security.
• 8 luglio 2025: Microsoft rilascia le prime patch tramite l’aggiornamento mensile di luglio, con la pubblicazione dei CVE CVE-2025-49706 e CVE-2025-49704.
• 14 luglio 2025: CODE WHITE GmbH diffonde una riproduzione riuscita dell’exploit, dimostrando la criticità delle falle.
• 18 luglio 2025: Eye Research segnala l’avvio di vere e proprie campagne di exploit e documenta il bypass delle versioni aggiornate.
• 19 luglio 2025: Microsoft riconosce lo sfruttamento attivo delle vulnerabilità, pubblicando misure di mitigazione e due nuovi CVE legati ai bypass: CVE-2025-53770 e CVE-2025-53771.
• 20 luglio 2025: CISA aggiunge CVE‑2025‑53770 al catalogo KEV e specifica l’obbligo di patching immediato.
• 22 luglio 2025: CISA inserisce anche CVE-2025-49706 e CVE-2025-49704 nel catalogo KEV, sottolineando nuovamente l’urgenza della correzione.
• 23 luglio 2025: sia Microsoft che CISA confermano che ToolShell viene attivamente sfruttato in attacchi ransomware attribuiti ad attori sponsorizzati dallo Stato cinese e aggiornano le rispettive linee guida operative.

I CVE ToolShell in Microsoft SharePoint

Quando le falle originali di “ToolShell” (CVE-2025-49706 e CVE-2025-49704)  sono state rese note per la prima volta a maggio 2025, i dettagli tecnici dell’attacco non sono stati resi pubblici. La divulgazione ha però portato al rilascio di patch ufficiali a metà luglio. Tuttavia, i ricercatori di sicurezza hanno rapidamente osservato attacchi in grado di compromettere anche server completamente aggiornati, spingendo così alla pubblicazione di due nuove vulnerabilità: (CVE-2025-53770 e CVE-2025-53771).

Di seguito una sintesi per ciascun CVE ToolShell:

• CVE-2025-49704 (CVSS 8.8): generazione impropria di codice, nota anche come “code injection” [CWE-94], che consente a un attaccante con privilegi autenticati di eseguire codice da remoto. Secondo Cisco Talos, l’attacco può essere condotto da un utente autorizzato con privilegi di membro del sito, mentre Microsoft specifica che sono necessari i privilegi di proprietario del sito. L’exploit risulta semplice da eseguire e presenta un’elevata probabilità di successo.
• CVE-2025-49706 (CVSS 6.3): autenticazione impropria [CWE-287], che permette a un utente non autorizzato di effettuare spoofing sulla rete.
• CVE-2025-53770 (CVSS 9.8): deserializzazione di dati non attendibili [CWE-502] che consente a un utente non autenticato di eseguire codice da remoto [CWE-94]. Questa è una variante più pericolosa e senza requisiti di autenticazione di CVE-2025-49704.
• CVE-2025-53771 (CVSS 6.3): impropria limitazione di percorso, nota anche come “path traversal” [CWE-22], che permette a un utente non autorizzato di eseguire spoofing di rete. È una variante di CVE-2025-49706.

I dettagli dell’attacco ToolShell

L’attacco ToolShell consente l’esecuzione di codice remoto (RCE) non autenticato su server Microsoft SharePoint vulnerabili. Il meccanismo dell’attacco si articola in più fasi:

1. La vulnerabilità CVE-2025-49706 permette di accedere ai servizi interni di SharePoint manipolando l’intestazione Referer: /_layouts/SignOut.aspx per bypassare la logica di convalida. In questo modo, la richiesta risulta autenticata, anche in assenza di sessioni o credenziali valide.
2. Contestualmente, un payload malevolo nel campo __VIEWSTATE viene inviato all’endpoint /_layouts/15/ToolPane.aspx. Questo payload contiene una catena di gadget .NET appositamente creata per sfruttare il difetto di deserializzazione identificato in CVE-2025-53770. I payload VIEWSTATE sono oggetti serializzati ASP.NET usati per mantenere sincronizzato lo stato dell’interfaccia utente tra browser e server SharePoint.
3. La deserializzazione malevola consente così di eseguire comandi exe o PowerShell con i privilegi dell’utente SISTEMA di Windows, garantendo il pieno controllo del sistema compromesso.
4. Sfruttando questo controllo, gli attaccanti hanno installato web shell ASPX dannose, come ad esempio aspx, utilizzate per estrarre la configurazione MachineKey, ovvero le chiavi crittografiche ValidationKey e DecryptionKey, consentendo agli aggressori di ottenere un accesso persistente e autenticato.
5. Con queste chiavi rubate, gli attaccanti possono firmare payload __VIEWSTATE validi tramite lo strumento ysoserial.

Mitigazione degli attacchi ToolShell su Microsoft SharePoint

Le vulnerabilità ToolShell interessano le versioni locali (on-premise) di Microsoft Office SharePoint 2016, 2019, Subscription Edition, oltre alle edizioni ormai obsolete come SharePoint Server 2010 e 2013. Si raccomanda agli utenti di applicare quanto prima gli aggiornamenti di sicurezza più recenti. Va ricordato che, sebbene CVE-2025-49704 e CVE-2025-49706 siano stati corretti con l’aggiornamento di luglio 2025, la successiva scoperta di exploit capaci di bypassare queste patch ha reso necessarie ulteriori correzioni.

• KB5002754 per Microsoft SharePoint Server 2019 Core
• KB5002768 per Microsoft SharePoint Subscription Edition
• KB5002760 per Microsoft SharePoint Enterprise Server 2016
• SharePoint Server 2010 e 2013 sono interessati, ma non saranno patchati a causa del loro stato EOL
• SharePoint Online per Microsoft 365 NON è vulnerabile

La guida di Microsoft consiglia di abilitare l’Antimalware Scan Interface (AMSI) in modalità completa e di utilizzare Microsoft Defender Antivirus per prevenire attacchi contro Microsoft SharePoint. I difensori dovrebbero anche presumere che i loro sistemi siano stati compromessi e cercare IoC identificati nelle campagne osservate. Oltre a identificare e rimuovere qualsiasi infezione da malware, gli utenti dovrebbero mitigare il rischio rappresentato dalle credenziali rubate. Per farlo è necessario aggiornare le chiavi macchina ASP.NET tramite PowerShell (cmdlet Update-SPMachineKey) o eseguire il Machine Key Rotation Job nella Central Administration, quindi riavviare IIS con iisreset.exe per applicare le modifiche.

Riepilogo

La catena di attacchi conosciuta come ToolShell espone gli utenti di Microsoft SharePoint a un rischio molto elevato di esecuzione remota di codice (RCE) senza necessità di autenticazione. L’attacco combina un bypass della logica di autenticazione con un difetto di deserializzazione. Sebbene Microsoft abbia rilasciato le prime patch per CVE-2025-49704 e CVE-2025-49706 a luglio 2025, sono emerse nuove varianti più insidiose, identificate come CVE-2025-53770 e CVE-2025-53771, già attivamente sfruttate a livello globale. Gli utenti devono applicare con tempestività tutti gli aggiornamenti di sicurezza disponibili, eliminare eventuali malware installati dagli aggressori, ruotare le chiavi macchina ASP.NET e verificare la resilienza dell’infrastruttura. Le soluzioni OPENVAS SECURITY INTELLIGENCE di Greenbone offrono una copertura completa e affidabile, in grado di rilevare rapidamente istanze vulnerabili di Microsoft SharePoint tra oltre 180.000 altre vulnerabilità

Greenbone AG si impegna costantemente a fornire dati relativi alle vulnerabilità attraverso canali indipendenti e affidabili. Alla luce delle recenti discussioni sul finanziamento e sulla sostenibilità del programma CVE gestito dall’organizzazione statunitense MITRE, desideriamo informarti sulle misure da noi adottate per assicurare una continua erogazione delle informazioni sulle vulnerabilità.

Dal 1999, il sistema CVE rappresenta la base centrale per l’identificazione e la classificazione univoca delle vulnerabilità IT. Il finanziamento del database centrale CVE è attualmente garantito dal governo degli Stati Uniti fino ad aprile 2026. In questo contesto, Greenbone ha adottato tempestivamente misure strutturali per diventare più indipendente dalle singole fonti di dati.

Con il marchio OPENVAS, Greenbone è tra i principali fornitori open source a livello mondiale nell’ecosistema della sicurezza IT. Contribuiamo attivamente allo sviluppo di infrastrutture decentralizzate e sostenibili per la fornitura di informazioni sulle vulnerabilità e puntiamo su modelli innovativi e sostenibili che proteggono efficacemente i nostri clienti dai rischi per la sicurezza.

Il nostro approccio sovrano ai dati si basa su tre pilastri fondamentali:

• Ampia diversificazione delle fonti: I nostri sistemi e il nostro team di ricerca sulla sicurezza monitorano numerose fonti di informazione internazionali per poter reagire tempestivamente a nuove minacce in modo indipendente dal processo CVE ufficiale.
• Integrazione di database alternativi: per creare una base informativa stabile e geograficamente diversificata, integriamo nei nostri sistemi cataloghi di vulnerabilità indipendenti, come l’European Union Vulnerability Database (EUVD).
• Promozione di standard aperti: sosteniamo attivamente la diffusione dello standard CSAF (Common Security Advisory Framework), che abilita una distribuzione decentralizzata e federata delle informazioni sulle vulnerabilità.

Grazie a queste misure garantiamo ai nostri clienti un accesso illimitato alle informazioni aggiornate sulle vulnerabilità, anche in caso di cambiamenti nell’ecosistema internazionale dei dati. In questo modo, i tuoi sistemi IT resteranno completamente protetti anche in futuro.

Greenbone è sinonimo di acquisizione indipendente, sovrana e a prova di futuro delle informazioni sulle vulnerabilità, anche in un contesto geopolitico in continua evoluzione.

Nonostante l’interruzione del NIST NVD, il sistema di rilevamento di Greenbone mantiene piena operatività, garantendo scansioni affidabili delle vulnerabilità senza dipendere dai dati di arricchimento CVE mancanti.

Dal 1999, il Common Vulnerabilities and Exposures (CVE), gestito dalla MITRE Corporation, fornisce gratuitamente informazioni pubbliche sulle vulnerabilità, pubblicando e aggiornando dati sulle falle del software. Dal 2005, il National Institute of Standards and Technology (NIST) ha arricchito questi rapporti CVE, dando maggiore contesto per migliorare la valutazione del rischio informatico. Tuttavia, all’inizio del 2024, la comunità della sicurezza informatica è stata sorpresa dall’interruzione delle attività del NIST National Vulnerability Database (NVD). A circa un anno di distanza, questa interruzione non è stata ancora completamente risolta [1][2]. Con il numero crescente di CVE segnalati ogni anno, le difficoltà del NIST hanno causato un ritardo significativo nell’assegnazione di contesti fondamentali come il punteggio di gravità (CVSS), gli elenchi di prodotti interessati (CPE) e le classificazioni delle debolezze (CWE).

I cambiamenti politici promossi di recente dall’amministrazione Trump hanno generato notevole incertezza riguardo al futuro della condivisione delle informazioni sulle vulnerabilità, influenzando anche numerosi fornitori di sicurezza che da tali dati dipendono. Parallelamente, il bilancio 2025  della Cybersecurity and Infrastructure Security Agency (CISA), riflette una significativa riduzione delle risorse in aree chiave. In particolare, si registra un taglio di circa 49,8 milioni di dollari destinati ad appalti, costruzioni e miglioramenti e una diminuzione di 4,7 milioni di dollari per attività di ricerca e sviluppo. Questi ridimensionamenti hanno spinto la CISA ad adottare misure di contenimento delle spese, tra cui la revisione dei contratti e l’ottimizzazione delle strategie di approvvigionamento.

Nonostante le recenti preoccupazioni, il programma CVE non ha subito alcuna interruzione: il 16 aprile 2025, la CISA ha esteso all’ultimo minuto il contratto con MITRE, garantendo la continuità dei servizi CVE per altri 11 mesi, proprio poche ore prima della scadenza prevista. Tuttavia, l’evoluzione degli eventi rimane imprevedibile. Il potenziale impatto negativo sulla condivisione dell’intelligence suscita allarme, configurando forse una nuova dimensione geopolitica, paragonabile a una forma di guerra fredda digitale.

Questo articolo fornisce una breve panoramica sul funzionamento del programma CVE e su come le capacità di rilevamento di Greenbone siano rimaste invariate durante l’interruzione del NIST NVD.

Funzionamento del programma CVE: una panoramica

La MITRE Corporation, organizzazione senza scopo di lucro, opera come pilastro strategico per la sicurezza interna statunitense abbracciando ricerca difensiva, protezione delle infrastrutture critiche e cybersecurity. Nella gestione del programma CVE, MITRE ricopre un ruolo centrale come Primary CNA (CVE Numbering Authority), coordinando l’infrastruttura chiave per l’assegnazione degli ID CVE, la pubblicazione dei record e i flussi di comunicazione tra tutti i CNA e gli Authorized Data Publishers (ADP). I dati CVE sono resi pubblici attraverso il sito web del MITRE CVE.org  e il repository cvelistV5 su GitHub, dove i record sono archiviati in formato JSON strutturato. Questo modello ha ottimizzato il reporting delle vulnerabilità, standardizzato i processi e assicurato una condivisione dei dati fluida nell’ecosistema della sicurezza informatica globale.

Quando in passato un CNA inviava una descrizione della vulnerabilità al MITRE, il NIST ha sempre aggiunto informazioni chiave quali:

• CVSS (Common Vulnerability Scoring System): un punteggio di gravità (da 0 a 10) e una stringa vettoriale dettagliata che descrive il rischio associato alla vulnerabilità. Il CVSS valuta fattori come la complessità dell’attacco (Attack Complexity, AC), l’impatto su riservatezza (Confidentiality, C), integrità (Integrity, I) e disponibilità (Availability, A), oltre ad altri parametri.
• CPE (Common Platform Enumeration): una stringa appositamente formattata che identifica in modo univoco i prodotti e le versioni interessate dalla vulnerabilità, includendo nome del prodotto, fornitore e dettagli architetturali.
• CWE (Common Weakness Enumeration): classifica le cause profonde della vulnerabilità in base alla tipologia del difetto software.

ll CVSS consente alle organizzazioni di quantificare il rischio associato a una vulnerabilità attraverso un punteggio standardizzato (0-10), facilitando la prioritizzazione strategica degli interventi di bonifica. Poiché le segnalazioni CVE iniziali includono solo dichiarazioni non standardizzate sui prodotti coinvolti, l’integrazione dei CPE da parte del NIST consente alle piattaforme di sicurezza di utilizzare il matching CPE come metodo rapido, sebbene parzialmente inaffidabile, per identificare la presenza di vulnerabilità nell’infrastruttura di un’organizzazione.

Se desideri approfondire come funziona il procedimento di divulgazione delle vulnerabilità e il ruolo di CSAF 2.0 come alternativa decentralizzata al programma CVE del MITRE, leggi il nostro articolo: Cos’è il Common Security Advisory Framework 2.0 e come automatizza il vulnerability management. Di seguito procediamo ad esaminare le criticità del NIST NVD e identifichiamo gli elementi che garantiscono la capacità di Greenbone di rilevare le vulnerabilità nonostante il malfunzionamento del database federale.

Interruzione NVD del NIST: cos’è successo?

A partire dal 12 febbraio 2024, il NVD ha ridotto drasticamente l’arricchimento delle vulnerabilità CVE con metadati importanti come punteggi CVSS, identificatori CPE e classificazioni CWE. Il problema è emerso inizialmente grazie al vicepresidente della sicurezza di Anchore, che ne ha segnalato l’impatto operativo. A maggio 2024, circa il 93% delle CVE aggiunte dopo il 12 febbraio risultava privo di analisi contestuali. A settembre 2024, il NIST non ha rispettato la scadenza autoimposta per colmare il ritardo: il 72,4% delle CVE e il 46,7% delle KEV (Known Exploited Vulnerabilities) del CISA rimanevano non erano ancora state arricchite [3].

Il rallentamento del processo di arricchimento del National Vulnerability Database (NVD) ha avuto ripercussioni significative per la comunità della sicurezza informatica. Non solo perché i dati arricchiti sono fondamentali per i difensori nel definire con efficacia le priorità delle minacce, ma anche perché numerosi strumenti di scansione delle vulnerabilità si basano su questi metadati per rilevare e valutare le falle di sicurezza.

In qualità di difensore della cybersecurity, è lecito chiedersi se Greenbone sia stato colpito dall’interruzione del NIST NVD. La risposta è no. Continua a leggere per scoprire perché le capacità di rilevamento di Greenbone sono riuscite a far fronte all’interruzione del NIST NVD.

Il rilevamento di Greenbone risulta efficace nonostante l’interruzione NVD

Senza metadati CVE arricchiti, molte soluzioni di sicurezza risultano inefficaci a causa della dipendenza dalla corrispondenza CPE per identificare le vulnerabilità. Tuttavia, Greenbone è riuscito a far fronte all’interruzione del NIST NVD grazie a un approccio indipendente dal CPE: i test di vulnerabilità OpenVAS possono essere sviluppati direttamente dalle descrizioni CVE non arricchite, integrando anche il rilevamento di configurazioni errate e vulnerabilità senza CVE, come i benchmark CIS [4][5]. 

Per sviluppare i test di vulnerabilità (VT), Greenbone si avvale di un team dedicato di ingegneri software specializzati nell’analisi degli aspetti tecnici alla base delle vulnerabilità. Il sistema include uno scanner CVE in grado di eseguire una corrispondenza CPE tradizionale, ma si distingue dalle soluzioni dipendenti esclusivamente dai dati CPE del NIST NVD grazie a tecniche di rilevamento avanzate che superano i limiti del matching di base. Questa architettura ibrida – tra automazione standardizzata e analisi contestuale – garantisce capacità di rilevamento solide anche durante interruzioni critiche come quella recente del NIST NVD.

Per garantire un rilevamento delle vulnerabilità resiliente e all’avanguardia, lo scanner OpenVAS di Greenbone interagisce attivamente con i servizi di rete esposti, costruendo una mappa dettagliata della superficie di attacco di una rete target. Questo comprende l’identificazione dei servizi accessibili tramite connessioni di rete, l’analisi dei prodotti in esecuzione e l’esecuzione di test specifici (VT) per ogni vulnerabilità CVE o non-CVE, verificandone attivamente la presenza. L’Enterprise Vulnerability Feed di Greenbone include oltre 180.000 VT aggiornati quotidianamente, garantendo il rilevamento tempestivo delle ultime vulnerabilità segnalate e un’individuazione rapida delle minacce emergenti.

Oltre alle scansioni attive, Greenbone integra scansioni autenticate agentless che raccolgono dati dettagliati dagli endpoint, analizzando i pacchetti software installati e confrontandoli con i CVE noti. Questo approccio garantisce un rilevamento preciso delle vulnerabilità, bypassando la dipendenza dai dati CPE arricchiti del NVD.

Punti di forza:

• Indipendenza dai dati CVE arricchiti: Greenbone garantisce il rilevamento continuo senza dipendere dai metadati arricchiti del NIST NVD, mantenendo prestazioni stabili anche durante interruzioni del database federale. Una descrizione di base di una vulnerabilità consente agli ingegneri di Greenbone di sviluppare un modulo di rilevamento.
• Rilevamento avanzato oltre il CPE: sebbene Greenbone includa uno scanner CVE con corrispondenza CPE, le sue capacità si estendono ben oltre questo approccio tradizionale, integrando metodi attivi di interazione con i target per un rilevamento più accurato.
• Mappatura della superficie di attacco: lo scanner OpenVAS di Greenbone interagisce attivamente con i servizi esposti per mappare la superficie di attacco della rete, identificando tutti i servizi raggiungibili. Le scansioni autenticate agentless raccolgono dati direttamente dagli endpoint per analizzare i pacchetti software installati, confrontandoli con i CVE noti senza dipendere dai dati CPE arricchiti.
• Resilienza alle interruzioni dell’arricchimento NVD: il rilevamento di Greenbone risulta efficace anche senza dati NVD arricchiti, perché si serve delle descrizioni CVE dei CNA per sviluppare controlli attivi precisi e valutazioni basate sulle versioni software.

L’approccio di Greenbone è pratico, efficace e resistente

Greenbone rappresenta il punto di riferimento in termini di praticità, efficacia e resilienza nel campo della gestione delle vulnerabilità. Le sue soluzioni sono progettate per fornire una protezione proattiva e affidabile contro le minacce informatiche, adattandosi a una vasta gamma di ambienti IT. Utilizzando la mappatura attiva della rete e le scansioni autenticate, le soluzioni Greenbone interagiscono direttamente con l’infrastruttura di destinazione.

Questi standard elevati permettono alle aziende di identificare le vulnerabilità in modo preciso e tempestivo, anche in ambienti complessi e distribuiti. Anche in assenza dell’arricchimento del National Vulnerability Database (NVD), i metodi di rilevamento delle vulnerabilità di Greenbone rimangono efficaci e affidabili. Gli ingegneri di Greenbone possono sviluppare controlli attivi accurati e valutazioni delle vulnerabilità basate sulla versione del prodotto, utilizzando le informazioni disponibili nei rapporti iniziali dei CVE.

Grazie a un approccio intrinsecamente resiliente nel rilevamento delle vulnerabilità, Greenbone assicura una gestione affidabile delle minacce, emergendo come punto di riferimento nel panorama della cybersecurity.

Alternative a NVD / NIST / MITRE

La problematica del MITRE rappresenta un campanello d’allarme per la sovranità digitale europea, ma l’UE ha reagito con tempestività: l’EuVD di ENISA, l’Agenzia dell’Unione per la cybersecurity, è ora operativa. Ne parleremo nel nostro prossimo articolo.

Di recente, nel software MegaRAC BMC (Baseboard Management Controller) di American Megatrends International (AMI) è stata identificata la falla di sicurezza CVE-2024-54085, valutata con il punteggio di rischio CVSS 10, il più elevato possibile. Questa vulnerabilità consente agli aggressori di bypassare i meccanismi di autenticazione e accedere ai sistemi vulnerabili. Considerando il ruolo predominante di AMI nella supply chain delle schede madri, numerosi fornitori hardware di rilievo potrebbero essere coinvolti. Oltre a una dichiarazione tecnica, è disponibile un Proof-of-Concept (PoC) dettagliata, il che indica che la vulnerabilità non è più solo un rischio teorico.

Utilizzando il Proof of Concept (PoC) disponibile, gli aggressori possono creare un account di servizio sulla console di gestione Redfish, ottenendo così accesso non autenticato a tutte le funzionalità remote di BMC. L’exploit è stato verificato su dispositivi come HPE Cray XD670, Asus RS720A-E11-RS24U e ASRockRack. Sebbene questa CVE sia stata pubblicata nel 2025, l’ID (CVE-2024-54085) è stato probabilmente riservato già nel 2024.

La CVE-2024-54085 permette agli aggressori di:

• compromettere il server, assumerne il controllo totale e gestirlo da remoto
• installare software malevolo, inclusi ransomware​
• modificare il firmware
• rendere inutilizzabili componenti della scheda madre (BMC o anche BIOS/UEFI) ​
• causare danni hardware, ad esempio sovratensioni
• indurre il server in cicli di riavvio continui, causando interruzioni prolungate del servizio (DoS).

Greenbone è in grado di individuare un server colpito attraverso test di vulnerabilità remoti che rilevano attivamente BMC esposti.

Impatto potenziale

L’interfaccia Redfish, utilizzata nel MegaRAC BMC di AMI, è una delle numerose soluzioni BMC che supportano la gestione remota dei server. Lo standard Redfish si è affermato nel mercato dei server aziendali come sostituto moderno di interfacce di gestione obsolete come l’IPMI. La vulnerabilità ha un impatto significativo su tutti i prodotti che utilizzano AMI MegaRAC, inclusi dispositivi OT, IoT e IT.  In passato, vulnerabilità simili in MegaRAC hanno interessato prodotti di numerosi produttori, tra cui Asus, Dell, Gigabyte, Hewlett Packard Enterprise (HPE), Lanner, Lenovo, NVIDIA e Tyan. AMI ha rilasciato patch per questa vulnerabilità l’11 marzo 2025. HPE e Lenovo hanno già distribuito aggiornamenti per i loro prodotti interessati.

Aspetti tecnici di CVE-2024-54085

La vulnerabilità CVE-2024-54085 è un difetto critico individuato nello stack firmware SPx (Service Processor) di AMI, componente chiave della soluzione MegaRAC BMC. I BMC (Baseboard Management Controller) sono microcontroller integrati nelle schede madri dei server che permettono la gestione e il monitoraggio remoto, anche quando il sistema è spento o non risponde.

La CVE-2024-54085 è classificata come “bypass dell’autenticazione tramite spoofing” [CWE-290]. Questo tipo di vulnerabilità si verifica quando un sistema utilizza informazioni facilmente falsificabili, come l’indirizzo IP del client, per autenticare le richieste. Sebbene la raccomandazione di AMI fornisca pochi dettagli, i ricercatori di Eclypsium, ai quali è attribuita la scoperta, hanno pubblicato un articolo dettagliato che ne spiega le cause. La vulnerabilità CVE-2024-54085 deriva dall’utilizzo dell’indirizzo IP come metodo di autenticazione. Nello specifico, la logica di controllo degli accessi basata su Lua nell’interfaccia Redfish utilizza le intestazioni HTTP, come X-Server-Addr o Host, per determinare se una richiesta HTTP è interna o esterna; le richieste interne vengono automaticamente considerate autenticate.

Nei sistemi BMC come MegaRAC, “l’interfaccia host” rappresenta la connessione, sia fisica che logica, tra il BMC e il server principale (l’host). Questa connessione può essere paragonata all’interfaccia di loopback (spesso denominata lo), comunemente associata all’indirizzo IP 127.0.0.1 e al nome host localhost. Nel contesto di MegaRAC, all’interfaccia che collega il chip BMC all’host viene assegnato un indirizzo IP dalla gamma Link-Local, specificamente nell’intervallo 169.254.0.0 fino a 169.254.255.255). Inoltre, questo indirizzo IP è incluso in un elenco di indirizzi considerati attendibili durante il processo di autenticazione HTTP di MegaRAC; pertanto, un attaccante che riesca a falsificare questo indirizzo può eludere l’autenticazione. Attraverso reverse engineering del firmware MegaRAC, i ricercatori hanno identificato che l’indirizzo Link-Local 169.254.0.17 viene utilizzato su più chip BMC.

L’errore è dovuto all’implementazione di un’espressione regolare che estrae il testo dall’intestazione HTTP X-Server-Addr fino al primo due punti e verifica se corrisponde agli indirizzi IP attendibili memorizzati in un database Redis. I chip BMC utilizzano Lighttpd come server web incorporato, che aggiunge automaticamente un’intestazione X-Server-Addr con l’indirizzo IP dell’istanza Redfish. Se una richiesta include già l’intestazione fornita dal client, Lighttpd concatena il proprio valore a quello ricevuto. Questo permette a un attaccante di inviare un’intestazione appositamente modificata, manipolando così il valore estratto dall’espressione regolare. Fornendo un valore X-Server-Addr corrispondente all’indirizzo Link-Local del sistema host seguito da due punti (ad esempio, 169.254.0.17:), un malintenzionato può indurre il BMC a interpretare la richiesta come proveniente dall’interfaccia host interna, bypassando completamente l’autenticazione.

Una volta bypassata l’autenticazione, il resto della richiesta HTTP viene elaborato normalmente, consentendo all’attaccante di eseguire qualsiasi azione API disponibile. Ciò include la creazione di account con privilegi elevati, ottenendo il controllo remoto completo del BMC del server e l’accesso alla sua interfaccia web di amministrazione.

Strategie per mitigare la CVE-2024-54085

Le aziende devono monitorare attentamente le indicazioni dei propri fornitori di hardware e applicare tempestivamente gli aggiornamenti firmware non appena resi disponibili. Come misura temporanea, è consigliabile consultare i manuali dei dispositivi per verificare la possibilità di disattivare l’interfaccia Redfish quando non è in uso. Poiché i BMC rimangono operativi anche quando il server principale è spento, i sistemi interessati devono essere considerati permanentemente a rischio fino all’applicazione della patch firmware, a meno che Redfish non venga disabilitato o il sistema sia isolato dalla rete (air-gap). I responsabili di sicurezza possono sviluppare regole specifiche per firewall o sistemi di prevenzione delle intrusioni (IPS) al fine di bloccare tentativi di sfruttare questa vulnerabilità e di proteggere le interfacce di gestione BMC vulnerabili.

Poiché l’errore risiede in un firmware proprietario incorporato, l’applicazione delle patch risulta più complessa rispetto agli aggiornamenti di routine del sistema operativo o delle applicazioni. A differenza del software tradizionale, il firmware BMC risiede su un chip dedicato della scheda madre. Pertanto, l’aggiornamento del firmware BMC richiede l’uso di un’utilità software speciale fornita dal produttore del dispositivo per “flashare” il firmware aggiornato. Questo processo può causare periodi di inattività, poiché gli amministratori potrebbero dover avviare il sistema in un ambiente speciale e riavviarlo al termine dell’aggiornamento del firmware.

Per riassumere

La vulnerabilità CVE-2024-54085 rappresenta un rischio significativo per l’infrastruttura aziendale, poiché consente il controllo remoto non autenticato di server prodotti da importanti fornitori come HPE e Lenovo. Data la diffusione del software MegaRAC di AMI nei data center, lo sfruttamento di questa falla potrebbe causare guasti estesi, hardware inutilizzabile o periodi di inattività prolungati. È quindi essenziale riconoscere immediatamente questa minaccia e applicare le patch firmware fornite dai produttori per tutti i sistemi interessati.

Greenbone è in grado di individuare un server colpito attraverso test di vulnerabilità remoti che rilevano attivamente BMC che possono essere colpiti.

Due nuove vulnerabilità in Apache Camel richiedono l’attenzione immediata degli utenti. Il 9 marzo 2025, Apache ha divulgato la vulnerabilità CVE-2025-27636 (CVSS 5.6) per l’esecuzione di codice remoto. Pochi giorni dopo, l’11 marzo, il Security Intelligence Group (SIG) di Akamai ha identificato una tecnica per aggirare la patch originale, portando alla pubblicazione della vulnerabilità CVE-2025-29891 (CVSS 4.2) il 12 marzo. ​

Sebbene l’Authorized Data Publisher (ADP) della Cybersecurity and Infrastructure Security Agency (CISA) abbia assegnato punteggi CVSS moderati a queste due vulnerabilità, a seconda della configurazione dell’istanza Apache Camel interessata le loro conseguenze possono essere gravi. Entrambe le vulnerabilità derivano da un filtraggio inadeguato delle intestazioni o dei parametri HTTP durante la comunicazione con un’istanza di Apache Camel. In particolare, il problema risiede nella gestione delle maiuscole e minuscole: mentre il filtraggio dei parametri considera la distinzione tra maiuscole e minuscole, l’applicazione degli argomenti non lo fa. Inoltre, la disponibilità pubblica di codice Proof of Concept (PoC) e di descrizioni tecniche dettagliate aumenta il rischio associato a queste vulnerabilità.

Greenbone ha implementato test di vulnerabilità (VT) per individuare sistemi esposti alle CVE-2025-27636 e CVE-2025-29891. Questi test eseguono scansioni attive sugli endpoint HTTP per rilevare potenziali punti deboli. Ma vediamo il tutto nel dettaglio.

Cos’è Apache Camel?

Apache Camel è una libreria Java open source progettata per facilitare l’integrazione di diversi componenti all’interno di architetture di sistema aziendali distribuite, come API o microservizi. Fornisce una piattaforma versatile per il routing e la trasmissione dei dati, basata sul concetto di Enterprise Integration Patterns (EIP), che rappresentano modelli architetturali per l’integrazione dei sistemi aziendali. Camel implementa questi modelli attraverso vari domain-specific Languages (DSL), tra cui Java, XML, Groovy e YAML, consentendo ai programmatori di definire in modo flessibile le regole di routing e mediazione.

Nel 2021, Apache Camel deteneva una quota del 3,03% nel mercato dell’Enterprise Application Integration. Oltre 5.600 aziende (di cui circa la metà con sede negli Stati Uniti) hanno adottato il software. Camel è particolarmente diffuso nei settori della tecnologia e dei servizi IT (33%), del software (12%) e dei servizi finanziari (6%).

Due CVE in Apache Camel consentono l’header injection

Quando un componente HTTP di Apache Camel elabora una richiesta, un filtro predefinito dovrebbe impedire la divulgazione di dati sensibili o l’esecuzione di comandi interni. Tuttavia, a causa di una regola di filtro errata che distingue tra maiuscole e minuscole, vengono filtrate solo le intestazioni corrispondenti al 100%, mentre nella logica del programma queste si applicano senza tenere in considerazione la distinzione maiuscole-minuscole. Questo ha permesso di bypassare il filtro modificando la maiuscola o minuscola del primo carattere del nome dell’intestazione, consentendo a un attaccante di infiltrare qualsiasi intestazione.

La buona notizia è che i componenti camel-bean o camel-exec devono essere attivati in combinazione con un componente basato su HTTP, come camel-http, camel-http4, camel-rest o camel-servlet. Inoltre, lo sfruttamento è limitato ai metodi interni specificati nell’URI della richiesta HTTP. È rassicurante anche sapere che questa vulnerabilità richiede autenticazione per essere sfruttata. Pertanto, se gli sviluppatori hanno implementato meccanismi di autorizzazione per l’API HTTP di Camel, il rischio di sfruttamento da parte di utenti senza le giuste credenziali è significativamente ridotto.

Al vertice della scala di rischio, l’attivazione mirata del componente “Camel Exec” può consentire a un attaccante di eseguire comandi arbitrari sul sistema con i privilegi dell’utente che esegue il processo Camel. Questo è possibile inviando l’header “CamelExecCommandExecutable” per specificare un comando shell che sovrascrive quelli configurati nel back-end. Il rischio è particolarmente elevato quando le API HTTP vulnerabili di Camel risultano accessibili da Internet. Tuttavia, questa vulnerabilità potrebbe essere sfruttata anche da un insider per muoversi lateralmente all’interno della rete o da aggressori che hanno già ottenuto un accesso iniziale alla rete interna di un’organizzazione.

Akamai ha fornito una descrizione tecnica della catena di exploit e del Proof of Concept.

Qual è il punteggio CVSS appropriato?

Sebbene le vulnerabilità CVE-2025-27636 (CVSS 5.6) e CVE-2025-29891 (CVSS 4.2) siano state classificate come moderatamente gravi, il loro impatto può diventare critico se i componenti “camel-bean” o “camel-exec” sono attivati in combinazione con componenti basati su HTTP. Questa situazione mette in evidenza alcune limitazioni del Common Vulnerability Scoring System (CVSS), che fornisce una valutazione standardizzata della gravità delle vulnerabilità, ma non sempre considera il contesto specifico di utilizzo.

I ricercatori di Akamai hanno evidenziato che la CVE-2025-27636 è relativamente semplice da sfruttare e hanno pubblicato un codice Proof of Concept (PoC), contribuendo ad aumentare la consapevolezza del rischio associato. Questo implica che la metrica “Attack Complexity” (AC) del Common Vulnerability Scoring System (CVSS) dovrebbe essere impostata su “Bassa” (AC:L). Tuttavia, il Cybersecurity and Infrastructure Security Agency – Authorized Data Publisher (CISA-ADP) ha valutato la complessità dell’attacco come “Alta” (AC:H). In risposta a questi sviluppi, Red Hat ha rivalutato la vulnerabilità, aumentando il punteggio CVSS per la CVE-2025-27636 a 6,3.

Sebbene inizialmente il CISA-ADP non avesse identificato un impatto significativo sulla riservatezza (confidentiality) di CVE-2025-29891, ulteriori analisi hanno rivelato che questa vulnerabilità potrebbe consentire l’esecuzione remota di codice arbitrario (Remote Code Execution, RCE) su sistemi con una configurazione vulnerabile di Apache Camel. Di conseguenza, è stato ritenuto appropriato rivalutare l’impatto della vulnerabilità, classificandolo come elevato in termini di riservatezza (C), integrità (I) e disponibilità (A). Questo ha portato a un aumento del punteggio CVSS (Common Vulnerability Scoring System) della vulnerabilità a 9.8, indicando una criticità molto elevata.

La Cybersecurity and Infrastructure Security Agency – Authorized Data Publisher (CISA-ADP) ha assegnato alla vulnerabilità CVE-2025-29891 il valore “Nessuno” (N) per le autorizzazioni richieste (PR). Tuttavia, il Proof of Concept (PoC) pubblicato da Akamai dimostra come l’exploit possa avvenire senza l’uso di connessioni HTTPS né autenticazione. È importante ricordare che eseguire un’API non crittografata e non autenticata è altamente rischioso. Apache Camel offre meccanismi di sicurezza come l’API Java Secure Socket Extension (JSSE) per Transport Layer Security (TLS) e l’integrazione con server di autorizzazione Single Sign-On (SSO) come KeyCloak. Le istanze di Camel che implementano l’autenticazione client sono protette da potenziali exploit. Pertanto, nella maggior parte dei casi, il valore PR dovrebbe essere impostato su “Basso” (L) o “Alto” (H), il che ridurrebbe il punteggio CVSS rispettivamente a 7,3 o 8,8.

Inoltre, alle CVE è stato assegnato il valore “Scope Unchanged” (UC). Secondo la specifica CVSS v3.1, “questa metrica indica se una vulnerabilità in un componente ha un impatto su risorse al di fuori del suo ambito di sicurezza.” L’esecuzione di comandi shell arbitrari su un sistema compromesso è generalmente valutata con “Scope Changed” (C). Se il processo Camel è eseguito con privilegi di root su Linux/Unix o come amministratore su Windows, un attaccante potrebbe ottenere un controllo quasi totale sul sistema. Considerando la variabilità delle valutazioni CVSS, le vulnerabilità CVE-2025-27636 e CVE-2025-29891 dovrebbero essere trattate come critiche in configurazioni vulnerabili prive di autenticazione.

Trattamento delle CVE in Apache Camel

Le vulnerabilità CVE-2025-27636 e CVE-2025-29891 interessano Apache Camel nelle seguenti versioni:​ 4.10 fino alla 4.10.1,​ 4.8 fino alla 4.8.4​, 3 fino alla 3.22.3​. Si consiglia agli utenti di aggiornare alle versioni 4.10.2, 4.8.5 o 3.22.4, oppure di implementare un filtro di intestazione personalizzato utilizzando removeHeader o removeHeaders nelle rotte di Camel. È importante notare che le versioni 4.10.0, 4.10.1, dalla 4.8.0 alla 4.8.4 e dalla 3.10.0 alla 3.22.3 rimangono vulnerabili, nonostante siano considerate aggiornamenti di sicurezza che avrebbero dovuto correggere l’errore.

Nelle architetture distribuite, è fondamentale che tutti i terminali HTTP implementino un’autenticazione robusta. Per Apache Camel, sono disponibili diverse opzioni per garantire la sicurezza delle comunicazioni: utilizzo dell’API Java Secure Socket Extension (JSSE) per TLS con componenti Camel o utilizzo di un server di autorizzazione KeyCloak OAuth 2.0 SSO. Per i sistemi legacy deve essere configurata almeno l’autenticazione di base HTTP.

Per riassumere

Si consiglia agli utenti di Apache Camel di effettuare l’aggiornamento immediato alle versioni 4.10.2, 4.8.5 o 3.22.4. In alternativa, è possibile implementare il filtraggio personalizzato delle intestazioni utilizzando removeHeader o removeHeaders nelle rotte Camel. È inoltre fortemente raccomandato l’uso di un’autenticazione robusta su tutti gli endpoint HTTP. Apache Camel supporta l’API JSSE per soluzioni TLS e l’integrazione con Keycloak per OAuth 2.0 SSO. Greenbone è in grado di rilevare sia la CVE-2025-27636 che CVE-2025-29891 attraverso test di vulnerabilità che controllano attivamente gli endpoint HTTP potenzialmente sfruttabili.