
PoC de contournement de sécurité Apache Tomcat

Récemment, Apache a publié un bulletin de sécurité indiquant que plusieurs versions d'Apache Tomcat 7, 8 et 9 présentent une vulnérabilité de contournement de sécurité. Un attaquant peut exploiter ce problème pour contourner certaines restrictions de sécurité et exécuter des opérations non autorisées, ce qui pourrait faciliter une attaque ultérieure.
Les contraintes de sécurité définies par les annotations de servlet Apache Tomcat ne sont appliquées qu'une seule fois, après le chargement du servlet. Étant donné que les contraintes de sécurité définies de cette manière s'appliquent au modèle d'URL ainsi qu'à toute URL située sous ce point, leur application dépend très probablement de l'ordre de chargement des servlets, ce qui peut exposer des ressources à des utilisateurs non autorisés à y accéder.
CVE-2018-1305
Apache Tomcat < 9.0.5
Apache Tomcat < 8.5.28
Apache Tomcat < 8.0.50
Apache Tomcat < 7.0.85
Moyen
Java EE fournit l'annotation ServletSecurity, similaire à un contrôle d'autorisation de type ACL, qui permet de décorer un servlet et de le protéger. S'il existe deux servlets, Servlet1, dont le chemin d'accès est « /servlet1/* » et qui est annoté avec ServletSecurity, et Servlet2, dont le chemin d'accès est « /servlet1/servlet2/* » mais sans annotation ServletSecurity, lors du premier accès à servlet1/servlet2, l'annotation ServletSecurity de servlet1 ne prend pas effet et ne peut pas protéger le chemin « /servlet1/servlet2 », ce qui peut entraîner un accès non autorisé.
Si « /servlet1 » a été consulté avant « /servlet1/servlet2 », Tomcat charge l'ACL et active la protection de « /servlet1/servlet2 » ; dans ce cas, la vulnérabilité ne se déclenche pas.

Ajoutez l'annotation ServletSecurity à Servlet1 ; Servlet2 n'en possède pas.

Après avoir modifié le modèle d'URL (url-pattern) correspondant au servlet dans le fichier web.xml comme indiqué dans la figure ci-dessous.

Exécutez le projet. Lors du premier accès à l'URL de servlet2, on constate qu'un accès non autorisé est possible ; l'ACL de servlet1 n'a pas pris effet.

Lors de la deuxième visite de l'URL de servlet1, l'accès est interdit ; l'ACL prend alors effet.

En accédant de nouveau à l'URL de servlet2, on constate que l'accès est interdit. Pour que l'ACL s'applique à servlet2, servlet1 doit avoir été consulté au préalable.


Par conséquent, la reproduction de la vulnérabilité est limitée au cas où, après le démarrage de Tomcat, la page « /servlet1/servlet2/* » est consultée avant « /servlet1/* ». Si quelqu'un a déjà consulté la page « /servlet1/* » auparavant, la vulnérabilité ne se déclenche pas. La vulnérabilité est très dangereuse, mais difficile à exploiter ; son impact est donc limité.