Des chercheurs de la société chinoise Chaitin Tech ont identifié () Dans , une implémentation open source des technologies Java Servlet, JavaServer Pages, Java Expression Language et Java WebSocket. La vulnérabilité a reçu le nom de code Ghostcat et un niveau de gravité critique (9.8 CVSS). Le problème permet, dans la configuration par défaut, en envoyant une requête au port réseau 8009, de lire le contenu de tous les fichiers du répertoire de l'application Web, y compris les fichiers avec les paramètres et les codes sources de l'application.
La vulnérabilité permet également d'importer d'autres fichiers dans le code de l'application, ce qui permet d'organiser l'exécution du code sur le serveur si l'application autorise l'upload de fichiers sur le serveur (par exemple, un attaquant peut uploader un script JSP sous couvert d'un image via le formulaire de téléchargement d'image). Une attaque peut être effectuée en envoyant une requête à un port réseau avec un gestionnaire AJP. Selon des données préliminaires, en ligne plus de 1.2 million d'hôtes acceptant les requêtes via le protocole AJP.
La vulnérabilité existe dans le protocole AJP, et erreur de réalisation. En plus d'accepter les connexions via HTTP (port 8080), Apache Tomcat permet par défaut l'accès à une application web via le protocole AJP (, port 8009), qui est un équivalent binaire optimisé pour les performances de HTTP, couramment utilisé lors de la création d'un cluster de serveurs Tomcat ou pour accélérer la communication avec Tomcat sur un proxy inverse ou un équilibreur de charge.
AJP fournit une fonction standard d'accès aux fichiers sur le serveur, qui peut être utilisée, notamment pour obtenir des fichiers qui ne sont pas soumis à divulgation. AJP est censé n'être accessible qu'aux serveurs de confiance, mais en fait, la configuration par défaut de Tomcat était d'exécuter le gestionnaire sur toutes les interfaces réseau et d'accepter les requêtes sans authentification. L'accès est possible à tous les fichiers d'application Web, y compris le contenu de WEB-INF, META-INF et tout autre répertoire donné via l'appel ServletContext.getResourceAsStream(). AJP vous permet également d'utiliser n'importe quel fichier dans les répertoires accessibles de l'application Web en tant que script JSP.
Le problème se manifeste depuis la sortie de la branche de Tomcat 13.x il y a 6 ans. Sauf directement problème Tomcat et les produits qui l'utilisent, tels que Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), ainsi que les applications Web autonomes qui utilisent . Vulnérabilité similaire (CVE-2020-1745) dans le serveur Web utilisé dans le serveur d'application Wildfly. Dans JBoss et Wildfly, le protocole AJP est uniquement activé par défaut dans les profils standalone-full-ha.xml, standalone-ha.xml et ha/full-ha dans domain.xml. Dans Spring Boot, la prise en charge AJP est désactivée par défaut. Plus d'une douzaine d'exemples de travail d'exploits ont été préparés par différents groupes (
,
,
,
,
,
,
,
,
,
,
).
Vulnérabilité corrigée dans les versions de Tomcat , и (branche maintenance 6.x ). Vous pouvez suivre l'apparition des mises à jour dans les distributions sur ces pages : , , , , , . Pour contourner le problème, vous pouvez désactiver le service Tomcat AJP Connector (lier le socket d'écoute à localhost ou commenter la ligne avec Connector port = "8009") s'il n'est pas nécessaire, ou accès authentifié à l'aide des attributs "secret" et "address", si le service est utilisé pour interagir avec d'autres serveurs et proxies basés sur mod_jk et mod_proxy_ajp (mod_cluster ne prend pas en charge l'authentification).
Source: opennet.ru