Détection et atténuation de la vulnérabilité CVE-2025-24813 dans Apache Tomcat
Synthèse
Le 10 mars 2025, une vulnérabilité d'équivalence de chemin dans Apache Tomcat (désignée par CVE-2025-24813) a été divulguée publiquement, accompagnée d'un correctif.
Bien que cette vulnérabilité puisse permettre une RCE, Apache considère qu'il s'agit d'une vulnérabilité de gravité modérée, car elle nécessite des conditions préalables spécifiques non définies par défaut pour être exploitable.
Peu après la publication de la vulnérabilité, Akamai a commencé à observer les premières tentatives d'exploitation visant à identifier cette vulnérabilité sur des serveurs potentiels.
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 Akamai Adaptive Security Engine 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.
Qu'est-ce que la CVE-2025-24813 ?
Le 10 mars 2025, une vulnérabilité d'équivalence de chemin au sein d'Apache Tomcat, un serveur Web open source populaire et un conteneur de servlet Java couramment utilisé pour héberger des applications Java (CVE-2025-24813), a été signalée, accompagnée d'un correctif. Ce défaut affecte spécifiquement la façon dont le serveur traite les chemins d'accès aux fichiers en interne. Quelques jours seulement après la publication d'une démonstration de faisabilité publique, des attaquants ont tenté de l'exploiter à grande échelle, en suivant une tendance inquiétante que nous avons récemment observée : un délai d'exploitation de plus en plus court.
Apache a désigné la vulnérabilité CVE-2025-24813 comme étant de gravité modérée en raison des exigences d'exploitation. Un serveur vulnérable doit répondre à un ensemble spécifique de conditions préalables, ce problème est donc moins susceptible d'être exploitable. Toutefois, quelles que soient ces conditions préalables, il est important de corriger immédiatement cette vulnérabilité car elle peut entraîner une exécution de code à distance (RCE) non authentifiée si elle est exploitée.
La vulnérabilité a été corrigée dans les versions 11.0.3, 10.1.35 et 9.0.99 d'Apache Tomcat, mais les serveurs exécutant les versions 11.0.0-M1 à 11.0.2, 10.1.0-M1 à 10.1.34 et 9.0.0-M1 à 9.0.98 restent toujours à risque.
Qu'est-ce que la CVE-2025-24813 ?
Lorsque le servlet par défaut d'Apache Tomcat est configuré pour activer la fonctionnalité d'écriture, qui est désactivée par défaut, un pirate peut avoir un impact considérable en utilisant la CVE-2025-24813. Lorsque cette fonctionnalité est associée au comportement par défaut autorisant des requêtes PUT partielles, un pirate peut importer un fichier de session sérialisé spécialement conçu, dans un répertoire accessible en écriture par exemple. Une fois que ce fichier a été importé, une demande HTTP ultérieure oblige le servlet Tomcat à désérialiser son contenu, ce qui déclenche l'exécution de la charge intégrée.
L'exploitation peut entraîner une RCE, une fuite d'informations grave ou l'injection de contenu malveillant qui peut également corrompre des fichiers de configuration essentiels du serveur. Les versions d'Apache Tomcat concernées incluent : 11.0.0‑M1 à 11.0.2, 10.1.0‑M1 à 10.1.34 et 9.0.0‑M1 à 9.0.98.
Exploitation de la CVE-2025-24813
Le résultat final de l'exploitation est assez grave, mais parvenir à une RCE par le biais de cette vulnérabilité nécessite un ensemble de prérequis solides :
Le servlet par défaut doit disposer de la capacité d'écriture explicite
Les requêtes PUT partielles doivent être autorisées
L'application Web doit utiliser une persistance de session basée sur des fichiers avec un emplacement de stockage par défaut (fournissant un répertoire cible accessible à l'écriture pour la charge utile sérialisée malveillante)
Une bibliothèque vulnérable à la désérialisation doit être présente ou utilisée par l'application (permettant l'exécution de la charge utile via une attaque de désérialisation)
En outre, un attaquant doit connaître les conventions de dénomination de fichiers internes utilisées par l'application et la structure de répertoires du système de fichiers cible
Bien que la plupart des conditions préalables soient en place, la plus critique (la capacité d'écriture du servlet par défaut) est désactivée par défaut.
Trafic d'attaques observé
Le groupe Security Intelligence (SIG) d'Akamai a identifié le trafic d'attaques très peu de temps après la divulgation de la vulnérabilité. La plupart des charges utiles d'attaque observées sont des tests de vulnérabilité conçus pour aider les pirates à déterminer si le serveur cible est vulnérable. Une variante courante de l'attaque cible spécifiquement les chemins d'accès aux fichiers .session, qui suivent un schéma de dénomination aléatoire, avec une base de six caractères ajoutée à l'extension de fichier .session (Figure 1).
Fig. 1: Examples of .session attack variant
La charge utile la plus populaire comprenait un fichier .session dans le corps de la requête, qui consistait en des objets Java sérialisés malveillants. Dans la plupart des cas, l'objet malveillant utilise l'objet java.net.URL pour « communiquer avec sa source » une fois que ce fichier de session importé est désérialisé par Apache Tomcat (Figure 2).
Fig. 2: Attempted .session payload in request body
Détection des applications vulnérables
Il peut s'avérer difficile d'identifier chaque instance vulnérable d'Apache Tomcat sur un réseau. Les équipes de sécurité doivent évaluer un large éventail de ressources, car Apache Tomcat est intégré à de nombreuses applications, y compris des applications dans lesquelles des bibliothèques sont utilisées à l'insu des spécialistes de la sécurité.
Comme dans le cas de la récente vulnérabilité d'Apache Camel , cette 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 Tomcat peut être installé indépendamment sous Windows et Linux, ou être intégré aux applications Kava. Il peut être détecté en analysant de manière récursive les répertoires à la recherche de fichiers d'archives Java (JAR) appelés tomcat-api.jar. Une fois qu'un fichier JAR associé à Tomcat 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 :
- Apache Tomcat 11.0.0-M1 à 11.0.2
- Apache Tomcat 10.1.0-M1 à 10.1.34
- Apache Tomcat 9.0.0.-M1 à 9.0.98
Automatisation de la détection
Pour les clients Akamai Guardicore Segmentation , nous avons conçu une requête Insight qui permet d'identifier les actifs vulnérables. La requête renvoie tous les chemins et hachages disponibles pour tomcat-api.jar. Le fichier JAR renvoyé peut être vérifié dans VirusTotal par hachage ou via le fichier manifeste dans le fichier JAR pour obtenir la bonne version.
Windows : Apache Tomcat au sein des applications
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")
UNION
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
proc.path AS placeholder_path
FROM processes AS proc
WHERE LOWER(proc.name) LIKE "%tomcat%"
),
RELEVANT_JAR_PATHS AS (
SELECT file.path as lib_path, cwd, cwd || '..\%\%\tomcat-api.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 || '..\%\tomcat-api.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 || '%\%\tomcat-api.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 DISTINCT lib_path, cwd, jar_path, sha256
FROM RELEVANT_JAR_PATHS
Linux : Apache Tomcat au sein des applications
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")
UNION
SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
proc.path AS placeholder_path
FROM processes AS proc
WHERE LOWER(proc.name) LIKE "%tomcat%"
),
RELEVANT_JAR_PATHS AS (
SELECT file.path as lib_path, cwd, cwd || '../%/%/tomcat-api.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 || '../%/tomcat-api.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 || '%/%/tomcat-api.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 DISTINCT lib_path, cwd, jar_path, sha256
FROM RELEVANT_JAR_PATHS
Windows : Apache Tomcat installé
SELECT name, version
FROM programs
WHERE name LIKE '%tomcat%'
AND ((version >= '11.0.0' AND version <= '11.0.2') OR (version >= '10.1.0' AND version <= '10.1.34') OR (version >= '9.0.0' AND version <= '9.0.98'))
Linux : Apache Tomcat installé
SELECT name, version
FROM deb_packages
WHERE name LIKE '%tomcat%'
AND ((version >= '11.0.0' AND version <= '11.0.2') OR (version >= '10.1.0' AND version <= '10.1.34') OR (version >= '9.0.0' AND version <= '9.0.98'))
UNION
SELECT name, version
FROM rpm_packages
WHERE name LIKE '%tomcat%'
AND ((version >= '11.0.0' AND version <= '11.0.2') OR (version >= '10.1.0' AND version <= '10.1.34') OR (version >= '9.0.0' AND version <= '9.0.98'))
Atténuation avec Akamai App & API Protector
De nombreuses tentatives d'exploitation sont atténuées par les règles Adaptive Security Engine existantes, notamment celles qui détectent les tentatives de désérialisation Java (Figure 3).
3000072 — Attaque de désérialisation détectée
Fig. 3: Adaptive Security Engine rule 3000072 detecting CVE-2025-24813 exploit attempt
Le 19 mars 2025, l'équipe de recherche sur les menaces d'Akamai a également déployé une règle rapide d'Adaptive Security Engine pour les clients App & API Protector , afin de fournir une couverture complète (Figure 4).
3000957 — Attaque par exécution de code à distance Apache Tomcat détectée (CVE-2025-24813)
Fig. 4: Adaptive Security Engine Rapid Rule provides full coverage
L'action par défaut de la version 1 de la règle rapide est définie sur Alerte. Pour bloquer les tentatives d'attaque, il est conseillé aux clients de définir l'action de règle sur Refuser après avoir examiné les déclencheurs afin d'éliminer tout faux positif.
Synthèse
Le groupe Security Intelligence (SIG) 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.