Rilevamento e mitigazione delle vulnerabilità di Apache Camel
Analisi riassuntiva
Il 9 marzo 2025, Apache Camel ha divulgato la vulnerabilità CVE-2025–27636, che deriva da un errato filtraggio delle intestazioni delle richieste e potrebbe condurre all'esecuzione di codice remoto.
Questa vulnerabilità risiede in una libreria, il che crea una dipendenza diretta e una indiretta, oltre a complicare le operazioni di rilevamento e mitigazione.
In questo blog, i ricercatori di Akamai forniscono dettagli approfonditi sulla vulnerabilità, sulle tecniche di sfruttamento e sulle strategie di rilevamento.
La soluzione Akamai Adaptive Security Engine Rapid Rule fornisce una protezione automatica ai clienti di Akamai App & API Protector,
mentre per le operazioni di rilevamento viene fornita una query Insight di Akamai Guardicore Segmentatione
- i clienti di Akamai Hunt che sono stati interessati hanno già ricevuto una mappatura dettagliata delle risorse vulnerabili.
- AGGIORNAMENTO: l'11 marzo 2025, l'Akamai Security Intelligence Group (SIG) ha comunicato al team addetto alla sicurezza di Apache Camel un metodo per bypassare la vulnerabilità. Il 12 marzo 2025, Apache ha pubblicato una nuova vulnerabilità, a cui è stato assegnato il codice CVE-2025-29891.
Introduzione
Il 9 marzo 2025, è stata corretta una vulnerabilità in Apache Camel, che è una libreria Java ampiamente usata. La vulnerabilità è stata divulgata da Apache ed è stata corretta nelle versioni 4.10.2, 4.8.5 e 3.22.4. Anche se dai rapporti iniziali sembrava che la vulnerabilità potesse avere un impatto critico, il team addetto allo sviluppo l'ha classificata con un livello di moderata gravità.
Ciò nonostante, vi consigliamo vivamente di applicare una patch il prima possibile se nel vostro ambiente vengono eseguite versioni che sono state corrette. Tuttavia, potrebbero comunque essere ancora interessate le applicazioni con 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.
Per essere sfruttata, l'applicazione vulnerabile deve soddisfare alcuni specifici prerequisiti (che andremo ad esaminare più avanti in questo post). Ciò nonostante, l'impatto potrebbe risultare significativo. Queste vulnerabilità sono semplici da sfruttare e potrebbero condurre a risultati devastanti, inclusa l'esecuzione di codice remoto.
L'ubiquità di Camel, insieme alla natura delle vulnerabilità incorporate nella libreria, fa capire l'importanza di questa scoperta. Questo blog si propone di aiutare le organizzazioni con il loro processo di risposta.
Esamineremo le vulnerabilità e spiegheremo il loro potenziale impatto sulle applicazioni, analizzeremo la loro capacità di essere sfruttate in modo da poter creare appositi sistemi di rilevamento e gestiremo ciò che, forse, è la sfida maggiore legata a questa vulnerabilità e ad altre vulnerabilità che si nascondono nelle librerie, ossia, identificare le applicazioni vulnerabili.
Che cos'è Apache Camel?
Apache Camel è un sistema di integrazione open source ampiamente usato, che consente di scambiare facilmente i dati desiderati tra diversi sistemi, applicazioni e servizi cloud. Inoltre, semplifica l'instradamento dei messaggi, la trasformazione e la connettività in diversi ambienti aziendali. Molte organizzazioni si affidano a Camel per i loro workflow business-critical, l'integrazione delle API e il coordinamento dei microservizi.
Analisi della vulnerabilità CVE-2025-27636
Apache Camel utilizza DefaultHeaderFilterStrategy.java per bloccare l'inoltro delle intestazioni interne all'esterno. In tal modo, si impedisce la fuga di informazioni sensibili sull'instradamento, che potrebbero essere violate dai criminali, da parte delle intestazioni, che includono:
- CamelHttpResponseCode
- CamelHttpUri
- CamelContextId
- org.apache.camel.SomeInternalHeader
Questo filtraggio viene applicato quando i componenti basati sull'HTTP elaborano le richieste, come:
- camel-http and camel-http4 (elaborazione HTTP standard)
- camel-rest (gestione REST DSL)
- camel-cxf (servizi web di Apache CXF)
La vulnerabilità deriva dal filtraggio errato delle intestazioni delle richieste in Camel. Prima della correzione, Apache Camel ha usato una regola di filtraggio sensibile alla distinzione tra maiuscole e minuscole (Figura 1).
Fig. 1: Vulnerable filtering logic in Apache Camel DefaultHeaderFilterStrategy.java
Questa logica ha associato solo le intestazioni che iniziavano con Camel o org.apache.camel (esattamente nel modo mostrato). Se un criminale ha cambiato il carattere da maiuscolo a minuscolo o viceversa, usando CAmelHttpUri o cAMELHttpResponseCode, ad esempio, l'intestazione non sarà stata filtrata.
In tal caso, quindi, un criminale potrebbe iniettare intestazioni arbitrarie nelle nostre richieste per forzare Camel ad inoltrarle ai componenti interni. È importante notare che, come menzionato da Apache nel suo avviso, la vulnerabilità non consente l'accesso a metodi interni di tipo arbitrario, ma piuttosto solo a quelli che si trovano nello stesso bean all'interno del relativo URI. Si tratta di uno dei prerequisiti specifici che consentono di sfruttare una vulnerabilità a indicare che la semplice esecuzione di una versione vulnerabile di Apache Camel non rende automaticamente vulnerabile un'applicazione.
I test delle minacce
Per dimostrare la vulnerabilità, abbiamo creato un'applicazione campione vulnerabile da poter sfruttare in remoto. L'applicazione è in ascolto sulla porta HTTP 80 e, alla ricezione di una richiesta, utilizza il componente "Exec" di Camel per eseguire il comando whoami e inviare il risultato al client.
Richiamare una semplice richiesta utilizzando il comando cURL restituisce il risultato previsto: la possibilità di sfruttare la vulnerabilità (Figura 2).
Fig. 2: Normal application operation that returns the result of the whoami command
Come possiamo vedere nel codice, il comando whoami è definito in modo statico, il che lo rende relativamente sicuro. I problemi insorgono quando verifichiamo le possibili intestazioni dei messaggi interni supportati da Exec. Esaminando l'intestazione CamelExecCommandExecutable , vediamo che sovrascrive l'eseguibile definito nell'URI statico all'interno del codice (Figura 3).
Fig. 3: Apache Camel Exec component documentation
Apache Camel rimuove le intestazioni interne corrispondenti al carattere maiuscolo o minuscolo, come CamelExecCommandExecutable. Tuttavia, la vulnerabilità CVE-2025–27636 consente di bypassare il filtro inserendo la stringa CAmelExecCommandExecutable (o con diverse lettere maiuscole o minuscole) per eseguire comandi arbitrari sul server (Figura 4).
Fig. 4: Exploiting CVE-2025-27636 by including the CAmelExecCommandExecutable header
Analogamente, possiamo specificare la stringa CAmelExecCommandArgs per fornire i parametri necessari al comando eseguito (Figura 5).
Fig. 5: Using the CAmelExecCommandArgs header to specify command-line arguments
Questo semplice esempio dimostra come si presenta lo sfruttamento di questa vulnerabilità. La capacità di iniettare intestazioni interne può consentire ai criminali di compromettere una serie di applicazioni, a seconda dei componenti di Camel utilizzati dal server.
In che modo Apache Camel ha gestito la vulnerabilità CVE-2025-27636?
Il problema è stato risolto forzando l'uniformità dei caratteri maiuscoli o minuscoli per impedire ad un criminale di manipolarli allo scopo di bypassare il filtro. Ad esempio, CAmelHttpUri diventa camelhttpuri, che, quindi, ora corrisponde al filtro e, pertanto, può essere rilevato.
Presentazione di .toLowerCase()
Il commit GitHub ha aggiornato la logica di filtraggio dell'intestazione in DefaultHeaderFilterStrategy.java per includere toLowerCase(Locale.ENGLISH) allo scopo di garantire che tutti i nomi delle intestazioni vengano convertiti in minuscolo prima di applicare il filtro (Figura 6).
Fig. 6: The fix to CVE-2025-27636, implementing case-insensitive filtering
Oltre alla protezione dagli attacchi injection, la correzione si mantiene, inoltre, efficiente con un controllo ottimizzato. Il primo controllo gestisce rapidamente i normali caratteri in maiuscolo ("Camel") e in minuscolo ("camel"). Il controllo .toLowerCase() viene eseguito solo se necessario per evitare di sostenere inutili costi in termini di performance.
Rilevamento delle applicazioni vulnerabili
L'identificazione di ogni istanza vulnerabile di Apache Camel in una rete può risultare difficoltosa. I team addetti alla sicurezza devono valutare un'ampia gamma di risorse perché Apache Camel è integrato in molti posti, incluse le applicazioni in cui vengono usate le librerie di cui gli addetti alla sicurezza sono consapevoli.
La libreria può essere presente come dipendenza indiretta a indicare che non è esplicitamente inclusa nel codice sorgente, ma, invece, viene introdotta tramite un altro pacchetto software. Tutto ciò aggiunge un livello di complessità che ostacola il rilevamento e, ovviamente, la mitigazione.
Apache Camel, spesso, può essere identificato all'interno delle applicazioni Java eseguendo la scansione delle directory in modo ricorsivo per i file JAR che contengono "camel" nel nome. Una volta individuato un file JAR correlato a Camel, è possibile esaminare il relativo file manifest per stabilire la versione in uso.
Con la versione estratta, i team addetti alla sicurezza possono effettuare riferimenti incrociati rispetto all' avviso sulla sicurezza di Apache per valutare le potenziali vulnerabilità. Sono interessate le seguenti versioni:
- 4.10.0 : vulnerabile prima della 4.10.2
- 4.8.0 : vulnerabile prima della 4.8.5
- 3.10.0 : vulnerabile prima della 3.22.4
Automazione del rilevamento
Per facilitare l'identificazione delle applicazioni vulnerabili, abbiamo sviluppato gli script PowerShell e Bash, che eseguono la scansione delle directory in modo ricorsivo, rilevano i file JAR di Apache Camel e individuano le applicazioni potenzialmente vulnerabili. Abbiamo incluso opzioni sia per Windows che per Linux. I clienti delle versioni di Akamai Hunt interessate hanno già ricevuto una mappatura dettagliata delle loro risorse vulnerabili..
Rilevamento con Akamai Guardicore Segmentation
Per i clienti di Akamai Guardicore Segmentation , abbiamo creato una query Insight che è in grado di identificare le risorse vulnerabili. Nei casi in cui dai risultati della query per la versione del file emerge che non è possibile individuare la versione, l'hash restituito può essere controllato in VirusTotal o tramite il file manifest all'interno del jar per trovare la versione corretta.
Windows
WITH relevant_cwds as (
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
mmap.path AS mmap_path
FROM process_memory_map AS mmap
LEFT JOIN processes AS proc USING(pid)
WHERE mmap_path LIKE "%jvm%"
UNION
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
proc.path AS placeholder_path
FROM processes AS proc
WHERE proc.name IN ("java", "javaw", "java.exe", "javaw.exe")
),
RELEVANT_JAR_PATHS AS (
SELECT file.path as lib_path, cwd, cwd || '..\%\%\camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
UNION
SELECT file.path as lib_path, cwd, cwd || '..\%\camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
UNION
SELECT file.path as lib_path, cwd, cwd || '%\%\camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
)
SELECT lib_path, relevant_cwds.path as proc_path,
CASE WHEN lib_path LIKE '%camel-core-2%' OR lib_path LIKE '%camel-core-3%' OR lib_path LIKE '%camel-core-4%' THEN SUBSTR(lib_path, INSTR(lib_path, 'camel-core-') + 11, INSTR(lib_path, '.jar') - (INSTR(lib_path, 'camel-core-') + 11))
WHEN lib_path like '%camel-core.jar' THEN 'Version not found' ELSE NULL END as version, cmdline, sha256 FROM RELEVANT_JAR_PATHS
INNER JOIN relevant_cwds ON relevant_cwds.cwd = RELEVANT_JAR_PATHS.cwd
WHERE
version is not null
Linux
WITH relevant_cwds as (
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
mmap.path AS mmap_path
FROM process_memory_map AS mmap
LEFT JOIN processes AS proc USING(pid)
WHERE mmap_path LIKE "%jvm%"
UNION
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
proc.path AS placeholder_path
FROM processes AS proc
WHERE proc.name IN ("java", "javaw", "java.exe", "javaw.exe")
),
RELEVANT_JAR_PATHS AS (
SELECT file.path as lib_path, cwd, cwd || '/../%/%/camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
UNION
SELECT file.path as lib_path, cwd, cwd || '/../%/camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
UNION
SELECT file.path as lib_path, cwd, cwd || '/%/%/camel-core%.jar' AS jar_path, sha256
FROM file INNER JOIN relevant_cwds ON file.path LIKE jar_path
INNER JOIN hash on file.path = hash.path
)
SELECT lib_path, relevant_cwds.path as proc_path,
CASE WHEN lib_path LIKE '%camel-core-2%' OR lib_path LIKE '%camel-core-3%' OR lib_path LIKE '%camel-core-4%' THEN SUBSTR(lib_path, INSTR(lib_path, 'camel-core-') + 11, INSTR(lib_path, '.jar') - (INSTR(lib_path, 'camel-core-') + 11))
WHEN lib_path like '%camel-core.jar' THEN 'Version not found' ELSE NULL END as version, cmdline, sha256 FROM RELEVANT_JAR_PATHS
INNER JOIN relevant_cwds ON relevant_cwds.cwd = RELEVANT_JAR_PATHS.cwd
WHERE
version is not null
Mitigazione con Akamai App & API Protector
Venerdì 7 marzo 2025, il team Akamai Threat Research ha implementato una soluzione Adaptive Security Engine Rapid Rule per i clienti di App & API Protector :
3000911 v2 - Apache Camel (CVE-2025-27636), che, nel caso in cui venga rilevato un attacco, l'azione viene rifiutata per impostazione predefinita.
I clienti che dispongono di regole rapide abilitate con l'azione predefinita impostata sulla gestione di Akamai sono automaticamente protette da questa minaccia. I clienti che dispongono di regole rapide con l'azione predefinita impostata sulla generazione di avvisi devono valutare l'attivazione delle regole e impostare la regola in modo che venga rifiutata.
La regola rapida 3000911 è progettata per attivare le intestazioni che sarebbero riuscite altrimenti ad eludere la logica del filtraggio interno di Camel (Figura 7). La regola non si attiva sulle intestazioni normali di Camel per impedire di influire minimamente sulle operazioni dei clienti legittimi.
Fig. 7: Rapid Rule 3000911 triggering on attack payload
Traffico degli attacchi osservato
Gli attuali payload degli attacchi osservati dall' Akamai Security Intelligence Group tentano soltanto di verificare la vulnerabilità anziché di sfruttarla. La maggior parte dei payload osservati utilizza due diverse strategie per verificare la vulnerabilità.
Innanzitutto, abbiamo osservato l'uso del nome dell'intestazione CAmELDestinationOverrideUrl , in cui il payload è un dominio di beaconing OOB (Out-Of-Bounds). Questo traffico si origina da un vendor di soluzioni commerciali per la scansione delle vulnerabilità e l'URL del payload esegue nuovamente il beaconing sul suo dominio (Figura 8).
Fig. 8: Rapid Rule 3000911 blocking payload attempting to perform server-side request forgery
In secondo luogo, abbiamo visto i payload utilizzare l'intestazione CAmelHttpResponseCode nel tentativo di suscitare uno specifico codice di stato della risposta HTTP dal server (Figura 9). Se il payload è riuscito, il codice di stato della risposta HTTP che viene restituito dal server corrisponde a quello fornito nel payload.
Fig. 9: Rapid Rule 3000911 blocking payload attempting to override HTTP response status code
Infine, abbiamo visto entrambi i tentativi di payload qui sopra eludere il rilevamento utilizzando una semplice codifica URL, come ca%4d%45%6cHttpResponseCode (Figura 10). Tuttavia, questi tentativi vengono comunque rilevati e bloccati dall'Adaptive Security Engine.
Fig. 10: Rapid Rule 3000911 blocking obfuscated payload
AGGIORNAMENTO: CVE-2025-29891
L'Akamai SIG, in collaborazione con il Citi Cyber Security Operations, ha identificato un ulteriore vettore di sfruttamento originato dallo stesso problema di filtraggio che ha causato la vulnerabilità CVE-2025-27636. Durante l'esecuzione di test sulla nostra applicazione vulnerabile, abbiamo scoperto che, oltre alle intestazioni della richiesta, anche la stringa della query e i parametri del corpo POST possono fornire un valido percorso di attacco.
Nella Figura 11, vediamo che, se si specifica il parametro della query CAmelExecCommandExecutable , si arriva all'esecuzione di un comando arbitrario, proprio come il vettore dell'intestazione originale.
Fig. 11: Command injection in either a header or a parameter using CAmelExecCommandExecutable
L'Akamai SIG ha segnalato al team addetto alla sicurezza di Apache Camel un metodo per bypassare la vulnerabilità, verificando i risultati e creando una nuova CVE: CVE-2025-29891. Le modifiche apportate al codice in Apache Camel per la CVE-2025-27636 correggono anche questo bypass, tuttavia Akamai ha dovuto rilasciare una nuova regola rapida 3000911 v3 per App & API Protector il 12 marzo 2025 per colmare la falla nella vulnerabilità.
Anche la patch che è stata creata originariamente per correggere la CVE-2025-27636 risolve questo problema, pertanto le applicazioni che utilizzano versioni aggiornate di Apache Camel non sono vulnerabili a questo vettore di sfruttamento.
Abbiamo aggiornato il nostro archivio GitHub, che ora contiene anche informazioni dettagliate sulla CVE-2025-29891 e sulla sua possibilità di sfruttamento.
Benché sia possibile rilevare lo sfruttamento della vulnerabilità precedente esaminando le intestazioni delle richieste, anche questo problema richiede un filtraggio dei parametri della richiesta.
Riepilogo
Le vulnerabilità presenti all'interno delle librerie non solo influiscono direttamente sulle applicazioni, ma si possono nascondere anche in posti sconosciuti, il che rende estremamente difficile eseguire le relative operazioni di rilevamento e mitigazione. Non solo Apache Camel è un sistema ampiamente usato, ma un criminale che dispone degli strumenti corretti può anche sfruttarlo per eseguire il codice in remoto, aggiungendo un ulteriore livello di pericolosità. Vi consigliamo, pertanto, di seguire la procedura suggerita da Apache e di applicare la patch il prima possibile nel vostro ambiente.
L'Akamai Security Intelligence Group continuerà a monitorare, segnalare e creare mitigazioni per minacce come queste per i clienti dell'azienda e per la più vasta comunità della sicurezza. Per tenervi aggiornati sulle ultime novità dell'Akamai Security Intelligence Group, potete consultare la nostra home page sulle ricerche e seguirci sui social media.