Retour sur la vulnérabilité Ghostcat (CVE-2020-1938) affectant Apache Tomcat
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.
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.
Par ailleurs, les serveurs applicatifs sont toujours des cibles intéressantes pour les attaquants, car elle permettent souvent de déposer des applications malveillantes. Lors de tests d’intrusion l’identification rapide des serveurs Apache Tomcat et des services AJP est souvent la première étape des scénarios d’intrusion identifiés.
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.
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.
Exploitation :
Pour exploiter cette vulnérabilité, le port 8009 d’AJP doit être ouvert.
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”.
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
Je partage
Derniers articles
Renforcer la sécurité WordPress, du développement des plugins à la configuration serveur
Il y a peu, dans le cadre de recherches sur des plugins WordPress, notre pentester Vincent Fourcade a découvert une injection de code, côté client, dans un module du célèbre CMS. Celle-ci fut vérifiée et validée par les équipes de WPScan. Aujourd’hui, une CVE lui a été attribuée. L’occasion de revenir aujourd’hui sur la sécurité, au sens large, dans le CMS WordPress, que ce soit au niveau de la couche applicative, de la configuration du serveur ou du bureau. C’est parti !
Analyse des Métriques XSS : comprendre l’Impact des injections de code côté client
Lors des tests d’intrusion, l’injection de code côté client est généralement plus aisée à découvrir qu’une injection côté serveur. Le nombre de paramètres dynamiques transitant du back au front, la difficulté d’échapper correctement à l’entrée et à la sortie et la multitude d’encodage liés à l’affichage peuvent être des vrais casse-têtes pour qui souhaite faire la chasse à la XSS. Le JavaScript malveillant semble ainsi avoir de beaux jours devant lui. Cependant, il n’est pas rare qu’à l’issu de l’audit, la criticité d’une telle injection découle directement de la configuration des cookies présents sur l’application. En effet, l’absence de l’attribut HttpOnly majore irrémédiablement les risques liés à ce type d’attaque. Néanmoins, cela signifie-t-il que la présence de cet attribut doive absolument amenuiser la criticité d’une injection ?