Détection et atténuation des vulnérabilités Apache Camel
Synthèse
Le 9 mars 2025, Apache Camel a signalé la vulnérabilité CVE-2025–27636, qui résulte d'un filtrage incorrect des en-têtes de demande pouvant conduire à l'exécution de code à distance.
Comme cette vulnérabilité se trouve dans une bibliothèque, cela crée une dépendance à la fois directe et indirecte qui complique la détection et l'atténuation.
Dans cet article de blog, les chercheurs d'Akamai fournissent des informations détaillées sur la vulnérabilité, les techniques d'exploitation et les stratégies de détection.
Une règle rapide Adaptive Security Engine d'Akamai fournit automatiquement une protection aux clients d'Akamai App & API Protector.
Nous fournissons également une requête Akamai Guardicore Segmentation Insight pour la détection.
- Les clients d'Akamai Hunt concernés ont déjà reçu un mappage détaillé des ressources vulnérables.
- MISE À JOUR : Le 11 mars 2025, le groupe Security Intelligence (SIG) d'Akamai a signalé un contournement à l'équipe de sécurité Apache Camel. Le 12 mars 2025, Apache a publié une nouvelle CVE : CVE-2025-29891.
Introduction
Le 9 mars 2025, une vulnérabilité a été corrigée dans Apache Camel, bibliothèque Java largement utilisée. La vulnérabilité a été résolue par Apache. Elle est corrigée dans les versions 4.10.2, 4.8.5 et 3.22.4. Bien que les premiers rapports aient classé la vulnérabilité comme pouvant avoir un impact critique, l'équipe de développeurs lui a attribué un niveau de gravité modéré.
Il est toutefois fortement recommandé de mettre en place des correctifs le plus rapidement possible si votre environnement utilise les versions corrigées. Cependant, les applications qui exécutent les versions 4.10.0, 4.10.1, 4.8.0 à 4.8.4 et 3.10.0 à 3.22.3 peuvent toujours être affectées.
Pour être exploitée, l'application vulnérable doit répondre à certaines conditions préalables spécifiques (que nous allons explorer plus loin dans cet article). Il n'est reste pas moins que l'impact pourrait encore être significatif. Cette vulnérabilité est extrêmement facile à exploiter et pourrait entraîner des conséquences dévastatrices, notamment l'exécution de code à distance.
L'omniprésence de Camel, ainsi que la nature intégrée des vulnérabilités dans les bibliothèques, font écho à la gravité de cette découverte. Ce billet de blog a pour objectif d'aider les entreprises dans leur processus de réponse.
Nous examinerons la vulnérabilité et expliquerons ses conséquences potentielles sur les applications, analyserons son exploitation pour instaurer des détections et nous nous attaquerons à ce qui est peut-être le défi le plus difficile à relever avec cette vulnérabilité et d'autres qui se cachent dans les bibliothèques, c'est-à-dire l'identification des applications vulnérables.
Qu'est-ce qu'Apache Camel ?
Apache Camel est un cadre d'intégration open source largement utilisé qui permet un échange de données fluide entre différents systèmes, applications et services cloud. Il simplifie le routage, la transformation et la connectivité des messages dans divers environnements d'entreprise. De nombreuses entreprises font confiance à Camel pour leurs workflows métiers critiques, leurs intégrations d'API et l'orchestration de leurs microservices.
Analyse de CVE-2025-27636
Apache Camel utilise DefaultHeaderFilterStrategy.java pour bloquer la transmission des en-têtes internes vers l'extérieur. Cela empêche les en-têtes de divulguer des informations de routage sensibles qui pourraient être exploitées par des attaquants. Voici quelques exemples de ces en-têtes :
- CamelHttpResponseCode
- CamelHttpUri
- CamelContextId
- org.apache.camel.SomeInternalHeader
Ce filtrage est appliqué lorsque des composants HTTP traitent des demandes, telles que :
- camel-http et camel-http4 (traitement HTTP standard)
- camel-rest (gestion de REST DSL)
- camel-cxf (services Web Apache CXF)
La vulnérabilité provient du filtrage incorrect des en-têtes de demande de Camel. Avant le correctif, Apache Camel utilisait une règle de filtrage sensible à la casse (Figure 1).
Fig. 1: Vulnerable filtering logic in Apache Camel DefaultHeaderFilterStrategy.java
Cette logique ne correspondait qu'aux en-têtes qui commençaient par Camel ou org.apache.camel (exactement comme illustré). Si un attaquant modifiait la casse et utilisait CAmelHttpUri ou cAMELHttpResponseCode, par exemple, l'en-tête n'était pas filtré.
Cela signifie qu'un attaquant pourrait injecter des en-têtes arbitraires dans nos requêtes et faire en sorte que Camel les transmette à des composants internes. Il est important de noter, comme le mentionne Apache dans ses conseils, que la vulnérabilité ne permet pas d'accéder à des méthodes internes arbitraires, mais seulement à celles qui se trouvent dans le même bean que celui déclaré dans l'URI du bean. Il s'agit de l'une des conditions préalables spécifiques à l'exploitation, ce qui signifie que l'exécution d'une version vulnérable d'Apache Camel ne rend pas automatiquement une application vulnérable.
Test de la menace
Pour démontrer cette vulnérabilité, nous avons créé un exemple d'application vulnérable qui pourrait être exploitée à distance. L'application écoute sur le port HTTP 80 et, lorsqu'elle reçoit une demande, utilise le composant Camel « Exec » pour exécuter la commande whoami et faire écho du résultat au client.
Lorsque l'on invoque une requête simple à l'aide de curl, cela renvoie le résultat attendu, à savoir être exposé à la vulnérabilité (Figure 2).
Fig. 2: Normal application operation that returns the result of the whoami command
Comme nous pouvons le voir dans le code, la commande whoami est définie de manière statique, ce qui rend le code relativement sûr. Les problèmes surviennent lorsque nous inspectons les potentiels en-têtes de messages internes pris en charge par Exec. Lorsque nous examinons l'en-tête CamelExecCommandExecutable , nous constatons qu'il remplace l'exécutable défini dans l'URI statique du code (Figure 3).
Fig. 3: Apache Camel Exec component documentation
Apache Camel filtrerait les en-têtes internes correspondant à la casse, comme CamelExecCommandExecutable. Cependant, CVE-2025–27636 permettrait de contourner le filtre en saisissant CAmelExecCommandExecutable (ou toute autre casse différente) et exécuterait des commandes arbitraires sur le serveur (Figure 4).
Fig. 4: Exploiting CVE-2025-27636 by including the CAmelExecCommandExecutable header
De la même manière, nous pouvons également spécifier CAmelExecCommandArgs pour fournir des paramètres à la commande exécutée (Figure 5).
Fig. 5: Using the CAmelExecCommandArgs header to specify command-line arguments
Cet exemple simple montre à quoi pourrait ressembler l'exploitation de cette vulnérabilité. La possibilité d'injecter des en-têtes internes arbitraires peut permettre aux attaquants de compromettre une variété d'applications, en fonction des composants Camel utilisés par le serveur.
Comment Apache Camel a-t-il répondu à CVE-2025-27636 ?
Le problème a été résolu en imposant l'uniformisation de la casse des lettres. Il n'est donc plus possible pour un acteur malveillant de manipuler la casse des lettres pour contourner le filtre. Par exemple, CAmelHttpUri se transforme en camelhttpuri, ce qui correspond maintenant au filtre et serait donc détecté.
Présentation de .toLowerCase()
L'enregistrement GitHub a mis à jour la logique de filtrage d'en-tête dans DefaultHeaderFilterStrategy.java pour inclure toLowerCase(Locale.ENGLISH) afin de s'assurer que tous les noms d'en-têtes sont convertis en minuscules avant d'appliquer le filtre (Figure 6).
Fig. 6: The fix to CVE-2025-27636, implementing case-insensitive filtering
En plus de la protection contre l'injection, la solution maintient également son efficacité grâce à un contrôle optimisé. Le premier contrôle traite rapidement les cas normaux « Camel » et « camel ». La vérification .toLowerCase() ne s'exécute que si nécessaire, afin d'éviter des coûts de performances inutiles.
Détection des applications vulnérables
Il peut s'avérer difficile d'identifier chaque instance vulnérable d'Apache Camel sur un réseau. Les équipes de sécurité doivent évaluer un large éventail d'actifs, car Apache Camel est intégré à de nombreux endroits. Il peut s'agir d'applications dans lesquelles les bibliothèques sont utilisées sans que les gardiens de la sécurité n'en aient connaissance.
La bibliothèque peut être présente comme une dépendance indirecte, ce qui signifie qu'elle n'est pas explicitement incluse dans le code source, mais qu'elle est introduite via un autre package logiciel. Cela ajoute une couche de complexité à la détection et, bien sûr, à l'atténuation.
Apache Camel peut souvent être identifié dans les applications Java en analysant récursivement les répertoires à la recherche de fichiers JAR dont le nom contient « camel ». Une fois qu'un fichier JAR associé à Camel est localisé, son fichier manifeste peut être examiné pour déterminer la version utilisée.
Avec la version extraite, les équipes de sécurité peuvent la comparer à l' avis de sécurité d'Apache pour évaluer les vulnérabilités potentielles. Les versions suivantes sont concernées :
- 4.10.0 — vulnérable avant 4.10.2
- 4.8.0 — vulnérable avant 4.8.5
- 3.10.0 — vulnérable avant 3.22.4
Automatisation de la détection
Pour faciliter l'identification des applications vulnérables, nous avons développé des scripts PowerShell et Bash qui analysent récursivement les répertoires, détectent les fichiers JAR d'Apache Camel et produisent les applications potentiellement vulnérables. Nous avons inclus des options pour Windows et Linux. Les clients Akamai Hunt concernés ont déjà reçu une cartographie détaillée de leurs actifs vulnérables.
Détection avec Akamai Guardicore Segmentation
Pour les clients Akamai Guardicore Segmentation , nous avons conçu une requête Insight qui permet d'identifier les actifs vulnérables. Si le résultat de la requête pour la version du fichier est « Version non trouvée », le hachage retourné peut être vérifié soit sur VirusTotal soit à travers le fichier manifeste à l'intérieur du jar pour obtenir la bonne version.
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
Atténuation avec Akamai App et API Protector
Le vendredi 7 mars 2025, l'équipe de recherche sur les menaces d'Akamai a déployé une règle rapide d'Adaptive Security Engine pour les clients App & API Protector :
3000911 v2 – attaque Apache Camel (CVE-2025-27636) détectée – action par défaut : Refuser
Les clients pour lesquels les règles rapides sont activées avec l'action par défaut définie sur « géré par Akamai » sont automatiquement protégés contre cette menace. Ceux qui utilisent des règles rapides dont l'action par défaut est réglée sur « Alerte » doivent évaluer tous les déclencheurs de règles et définir l'action de la règle sur « Refuser ».
La règle rapide 3000911 est conçue pour se déclencher sur des en-têtes qui auraient autrement échappé à la logique de filtrage interne de Camel (Figure 7). La règle ne se déclenche pas sur les en-têtes Camel normaux afin d'éviter toute répercussion sur les opérations légitimes des clients.
Fig. 7: Rapid Rule 3000911 triggering on attack payload
Trafic d'attaques observé
Les charges utiles d'attaque actuelles observées par le Groupe Security Intelligence d'Akamai tentent uniquement de confirmer la vulnérabilité plutôt que de l'exploiter. La majorité des charges utiles observées utilisent deux stratégies différentes pour confirmer la vulnérabilité.
Tout d'abord, nous avons vu l'utilisation du nom d'en-tête CAmELDestinationOverrideUrl lorsque la charge utile est un domaine de balisage hors bande (OOB). Ce trafic provient d'un fournisseur commercial d'analyse de vulnérabilités et l'URL de la charge utile renvoie à son domaine (Figure 8).
Fig. 8: Rapid Rule 3000911 blocking payload attempting to perform server-side request forgery
Deuxièmement, nous avons vu que des charges utiles utilisent l'en-tête CAmelHttpResponseCode dans le but de provoquer un code d'état de réponse HTTP spécifique de la part du serveur (Figure 9). Si la charge utile a été correctement exécutée, le code d'état de réponse HTTP renvoyé par le serveur correspond au code d'état fourni dans la charge utile.
Fig. 9: Rapid Rule 3000911 blocking payload attempting to override HTTP response status code
Enfin, nous avons vu les deux charges utiles susmentionnées tenter d'échapper à la détection en utilisant un codage URL simple tel que ca%4d%45%6cHttpResponseCode (Figure 10). Cependant, ces tentatives sont toujours détectées et bloquées par Adaptive Security Engine.
Fig. 10: Rapid Rule 3000911 blocking obfuscated payload
MISE À JOUR : CVE-2025-29891
Le groupe Security Intelligence (SIG) d'Akamai, en collaboration avec Citi Cyber Security Operations, a identifié un vecteur d'exploitation supplémentaire qui découle du même problème de filtrage ayant causé la vulnérabilité CVE-2025-27636. Lors du test de notre application vulnérable, nous avons constaté qu'en plus des en-têtes de demande, la chaîne de requête et les paramètres du corps de la requête fournissaient également une voie d'attaque valide.
Dans la Figure 11, nous constatons que la spécification du paramètre de la requête CAmelExecCommandExecutable conduit à une exécution de commande arbitraire, tout comme le vecteur d'en-tête d'origine.
Fig. 11: Command injection in either a header or a parameter using CAmelExecCommandExecutable
Le groupe Security Intelligence (SIG) d'Akamai ayant signalé le contournement à l'équipe de sécurité d'Apache Camel, les résultats ont été validés et une nouvelle CVE a été créée : CVE-2025-29891. Les correctifs codés dans Apache Camel à partir de la vulnérabilité CVE-2025-27636 corrigent également ce contournement, mais Akamai a dû publier une règle rapide 3000911 v3 d'App & API Protector le 12 mars 2025, pour remédier à l'écart.
Le correctif original de la vulnérabilité CVE-2025-27636 résout également ce problème, de sorte que les applications qui utilisent des versions à jour d'Apache Camel ne sont pas vulnérables à ce vecteur d'exploitation.
Nous avons mis à jour notre référentiel GitHub, qui contient désormais également des détails sur la vulnérabilité CVE-2025-29891 et son exploitation.
Bien que l'exploitation de la vulnérabilité précédente puisse être détectée en inspectant les en-têtes de demande, ce problème nécessite également le filtrage des paramètres de requête.
Synthèse
Les vulnérabilités au sein des bibliothèques ont non seulement des conséquences directes sur les applications, mais peuvent également se cacher dans des endroits inconnus, ce qui rend leur détection et leur atténuation extrêmement difficiles. Apache Camel est non seulement largement utilisé, mais un attaquant disposant des bons outils peut également l'exploiter pour exécuter du code à distance, ce qui ajoute à la gravité de la situation. Il est recommandé de suivre les mesures suggérées par Apache et d'appliquer le correctif aussi rapidement que possible pour votre environnement.
Le groupe Security Intelligence d'Akamai continuera de surveiller, générer des rapports et créer des mesures d'atténuation des menaces telles que celles-ci pour nos clients et la communauté de sécurité dans son ensemble. Pour rester au fait des dernières actualités du groupe Security Intelligence d'Akamai, consultez notre page d'accueil de recherche et suivez-nous sur les réseaux sociaux.