15 avril 2020

Retour sur la vulnérabilité Ghostcat (CVE-2020-1938) affectant Apache Tomcat

Logo

La vulnérabilité Ghostcat référencée CVE-2020-1938 est une faille qui vise les serveurs web Apache Tomcat qui a été publiée sur NVD (Nationnal Vulnerability Database) le 24/02/2020 et a été considérée comme une faille critique avec une gravité de 9,8 sur 10 pour la version 3.1 et de 7,5 sur 10 pour la version 2. Notre équipe Pentest s'est penchée sur le sujet.

vulnérabilité Ghostcat

Pourquoi, c’est intéressant ?

  • Environ 118 843 des sites web utilisent le serveur Apache Tomcat dans le monde.
  • Un attaquant peut lire des fichiers sur le serveur.
  • Un attaquant peut potentiellement exécuter des commandes sur le serveur à travers cette faille si et seulement si :
    • Le port AJP est ouvert.
    • Il peut envoyer des fichiers au serveur à travers une fonctionnalité de l’application.
    • Ces fichiers sont enregistrés dans la racine du serveur.

Présentation de Apache Tomcat et le protocole AJP

Tomcat :

Tomcat est un serveur web open source, sous licence Apache, il permet d’exécuter des applications Web développées avec les technologies Java (Servlets, JSP…).

Protocole AJP :

AJP (Apache JServ Protocol) est un protocole qui garantit la communication entre un serveur web et un serveur d’applications, son utilisation est similaire à celle d’un proxy HTTP.

AJP utilise le port TCP/8009 par défaut.

vulnérabilité Ghostcat 1

La vulnérabilité Ghostcat et son code d’exploitation

Tomcat considère toutes les requêtes provenant de AJP comme requêtes légitimes.

En effet, AJP possède un champ nommé URI (Uniform Resource Identifier) qui représente une chaîne de caractères permettant de préciser l’extension du fichier entré par l’utilisateur.

Ce champ n’est pas contrôlé, un attaquant peut le modifier afin de lire ou d’exécuter des fichiers déjà présents sur le serveur.

vulnérabilité Ghostcat 2

Exploitation :

Pour exploiter cette vulnérabilité, le port 8009 d’AJP doit être ouvert.

vulnérabilité Ghostcat 3

Nous avons développé le script exploit.py permettant d’exploiter cette faille.

L’idée est de modifier le champ URI :

  • Si le champ URI contient “toto.jsp”, le serveur va considérer le fichier entré par l’utilisateur comme un fichier jsp donc il va l’exécuter, sinon il va le lire.

Pour faire le test, nous avons créé un fichier sur le serveur nommé “test.txt”.

vulnérabilité Ghostcat 4

Pour lire le fichier “test.txt”, nous avons mis le champ URI à “toto.toto”, le serveur va le considérer comme fichier d’extension différente de .jsp , dans ce cas, il sera lu.

Pour exécuter le même fichier, nous avons modifié le champ URI à “toto.jsp”, nous remarquons qu’il est cette fois interprété par le moteur JSP.

La liste des versions d’Apache Tomcat vulnérables :

  • Tomcat v9.0.x < 9.0.31
  • Tomcat v8.5.x < 8.5.51
  • Tomcat v7.x < 7.0.100

Protection

Pour se protéger :

  • Désactiver le port de protocole AJP.
  • Mettre à jour les serveurs Apache Tomcat vers les versions suivantes :
    • V7.0.100
    • V8.5.51
    • V9.0.31

Conclusion

La sécurité informatique se focalise souvent sur les failles d’applications. Toutefois les failles systèmes, de fréquence assez rare, ne peuvent être négligées compte tenu des impacts qui en induisent. Elles peuvent constituer un point d’entrée pour un attaquant. Or, de nombreux serveurs accessibles sur Internet sont rarement mis à jour, rendant ces attaques possibles.

Dans ce contexte, la vulnérabilité Ghostcat soit CVE-2020-1938 est une faille système critique, qui ne demande pas beaucoup de compétences techniques pour être exploitée. En effet, des connaissances sur le fonctionnement du protocole AJP suffisent.

Le serveur Apache Tomcat, quant à lui, est devenu de plus en plus vulnérable. Entre 5 et 25 vulnérabilités sont trouvées chaque année. Pour cette raison, l’utilisation de pares-feux est fortement recommandée afin de protéger les serveurs applicatifs de l’extérieur et ainsi, éviter ces problèmes.

Il ne faut, toutefois, pas oublier de faire ses mises à jour régulièrement.

Références :
https://www.similartech.com/technologies/apache-tomcat
https://github.com/hypn0s/AJPy

Blog

Nos derniers articles

Cybersécurité

Cyber Resilience Act : quelles obligations pour les éditeurs et les fabricants ?

Le Cyber Resilience Act est entré en vigueur le 10 décembre 2024, mais rien ne vous était encore demandé. Cela change le 11 septembre 2026 : à cette date, la plateforme européenne de signalement ouvre, et les fabricants doivent y déclarer leurs vulnérabilités activement exploitées. Restait une inconnue que le règlement laissait à chaque État membre : qui contrôle, et qui sanctionne. La foire aux questions publiée par l’ANSSI vient de la lever.

28 août 2026

Cybersécurité

Tester la sécurité de son site web : ce que voient les outils gratuits

Le contrôle d'accès défaillant occupe la première place du Top 10 de l'OWASP depuis l'édition 2021, devant les défauts cryptographiques et les injections. C'est aussi la famille de failles qu'un scanner automatique détecte le plus mal, parce qu'elle suppose de comparer les droits de deux comptes distincts et de comprendre qui a le droit de voir quoi. Un outil qui lit des en-têtes HTTP ne raisonne pas comme cela. Vouloir tester la sécurité de son site web reste une démarche saine, et les scanners publics ont leur utilité. Ils répondent simplement à une question plus étroite que celle que se pose un dirigeant.

18 août 2026

Cybersécurité

Analyse de risque EBIOS : ce que les cinq ateliers produisent vraiment

L'ANSSI a publié EBIOS Risk Manager en 2018, en rupture avec la logique d'inventaire qui dominait jusque-là les analyses de risque. Huit ans plus tard, la méthode est devenue la référence française, citée dans les dossiers NIS 2, réclamée par les auditeurs, inscrite dans les cahiers des charges. Elle est aussi, souvent, mal employée. Beaucoup d'analyses se terminent par un classeur de trois cents lignes que personne ne rouvre, faute d'avoir été construit pour décider quoi que ce soit. Chez Digitemis, nous animons ces ateliers pour des organisations qui doivent à la fois se protéger, se conformer et continuer à produire. Une analyse utile répond à une question courte : sur quels verrous investir pour que l'activité ne s'arrête pas.

18 août 2026

informations

Contactez-nous

Une question ou un projet en tête ? Remplissez le formulaire, nous reviendrons vers vous rapidement pour un premier échange.

    *Informations obligatoires

    Les informations recueillies à partir de ce formulaire sont traitées par Digitemis pour donner suite à votre demande de contact. Pour connaître et/ou exercer vos droits, référez-vous à la politique de Digitemis sur la protection des données, cliquez ici.

    Index