Vulnérabilité dans Apache Tomcat, permettant l'injection de code JSP et l'accès aux fichiers des applications web

Des chercheurs de la société chinoise Chaitin Tech ont identifié CVE-2020-10174 (CVE-2020-1938) dans Apache Tomcat, une implémentation open source des technologies Java Servlet, JavaServer Pages, Java Expression Language et Java WebSocket. La vulnérabilité a été nommée Ghostcat et classée avec un niveau de dangerosité critique (9.8 CVSS). Le problème permet, par défaut, de lire le contenu de n'importe quel fichier du répertoire de l'application web en envoyant une requête sur le port réseau 8009, y compris les fichiers de configuration et le code source de l'application.

La vulnérabilité permet également d'importer d'autres fichiers dans le code de l'application, ce qui permet l'exécution de code sur le serveur si l'application autorise le téléchargement de fichiers sur le serveur (par exemple, un attaquant peut télécharger un script JSP déguisé en image via un formulaire de téléchargement). L'attaque peut être réalisée si une requête peut être envoyée au port réseau avec un traitement AJP. Selon les données préliminaires, il y a dans le réseau trouvé plus de 1,2 million d'hôtes acceptant des requêtes via le protocole AJP.

La vulnérabilité est présente dans le protocole AJP, et n'est pas causée par une erreur d'implémentation. En plus d'accepter des connexions HTTP (port 8080), Apache Tomcat autorise par défaut l'accès à l'application web via le protocole AJP (Apache Jserv Protocol, port 8009), qui est un équivalent binaire optimisé pour une performance supérieure à HTTP, généralement utilisé lors de la création de clusters de serveurs Tomcat ou pour accélérer l'interaction avec Tomcat sur un proxy inverse ou un équilibreur de charge.

AJP offre une fonctionnalité intégrée pour accéder aux fichiers sur le serveur, qui peut également être utilisée pour récupérer des fichiers qui ne devraient pas être divulgués. Il est supposé que l'accès à AJP est ouvert uniquement aux serveurs de confiance, mais en réalité, dans la configuration par défaut de Tomcat, le traitement était exécuté sur toutes les interfaces réseau et les requêtes étaient acceptées sans authentification. L'accès est possible à n'importe quel fichier de l'application web, y compris le contenu de WEB-INF, META-INF et d'autres répertoires, accessibles via l'appel ServletContext.getResourceAsStream(). AJP permet également d'utiliser n'importe quel fichier dans les répertoires accessibles à l'application web comme un script JSP.

Le problème apparaît à partir de la branche Tomcat 6.x publiée il y a 13 ans. En plus de Tomcat lui-même, le problème touche et les produits qui l'utilisent, tels que Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), ainsi que des applications web autonomes utilisant Spring Boot. Une vulnérabilité similaire (CVE-2020-1745) est présent dans le serveur web Undertow, utilisé dans le serveur d'applications Wildfly. Dans JBoss et Wildfly, le protocole AJP est activé par défaut uniquement dans les profils standalone-full-ha.xml, standalone-ha.xml et ha/full-ha dans domain.xml. Dans Spring Boot, le support AJP est désactivé par défaut. Actuellement, plus d'une dizaine d'exemples exploitables ont été préparés par différents groupes (
1,
2,
3,
4,
5,
6,
7,
8,
9,
10,
11).

La vulnérabilité a été corrigée dans les versions de Tomcat 9.0.31, 8.5.51 et 7.0.100 (soutien de la branche 6.x interrompu). Pour suivre l'apparition de la mise à jour dans les distributions, vous pouvez consulter ces pages : Debian, Ubuntu, RHEL, Fedora, SUSE, FreeBSD. Comme mesure de protection, vous pouvez désactiver le service Tomcat AJP Connector (lier le socket d'écoute à localhost ou commenter la ligne avec Connector port = «8009»), si ce n'est pas nécessaire, ou configurer l'accès authentifié à l'aide des attributs «secret» et «address», si le service est utilisé pour interagir avec d'autres serveurs et des proxies basés sur mod_jk et mod_proxy_ajp (mod_cluster ne prend pas en charge l'authentification).

Source : opennet.ru