hasegawatadamitsu/cve-2014-0094-test-program-for-struts1Programme de test de la CVE-2014-0094 pour struts1
Ce document résume l'impact de CVE-2014-0094 sur Struts 1. Sauf indication contraire, chaque version a été vérifiée avec java 1.7.0_02,struts 1.3.10, apache-tomcat-6.0.39, FreeBSD 8.2.
Veuillez noter qu'en aucun cas le contenu des sources et des documents n'est garanti. Je ne suis impliqué dans aucun événement, quel qu'il soit. En particulier, en cas d'utilisation abusive de ce contenu, je ne suis aucunement impliqué. (Cela dit, il n'y a rien de bien nouveau ici.)
Pour ce document, j'ai présenté des exemples concrets de solutions en m'appuyant sur divers sites Web. Sauf pour les faits déjà connus, les URL de référence sont indiquées dans les sources. Je remercie celles et ceux qui ont rendu ces informations publiques.
J'ai rédigé ce document en évitant autant que possible le jargon technique, avec des termes simples, même si cela peut manquer de précision.
La vulnérabilité de Struts 1 concernée ici est désignée par plusieurs noms, semble-t-il, comme CVE-2014-0094, S2-020, je ne sais trop, mais pour l'instant, je l'appellerai CVE-2014-0094.
Inutile de le rappeler, CVE-2014-0094 pose un problème très grave.
http://www.nta.go.jp/sonota/sonota/osirase/service.htm
« e-Taxソフト（WEB版） », « 確定申告書等作成コーナー », « NISA（日本版ISA）コー\ナー » : avis d'interruption de service (important) du 25 avril 2014 Selon cet avis, le service Web de l'Agence nationale des impôts utilise Struts 1, et le service a été interrompu le jour même de la découverte.
L'interruption a vraisemblablement été décidée en urgence afin de limiter les dégâts au minimum.
De notre côté, lors des tests de démonstration, nous avons constaté que le simple fait d'accéder à une URL suffisait à interrompre le service et à provoquer la fuite de fichiers arbitraires.
Comme il suffit d'accéder à une URL, envoyer depuis une adresse e-mail anonyme un message contenant l'URL à une liste de diffusion rend difficile l'identification de l'auteur, et permet d'interrompre facilement un service.
Voilà à quel point ce problème est simple à exploiter.
C'est le point le plus important. Lorsqu'un organisme tiers a annoncé qu'il existe au moins un risque d'impact, la démarche normale consiste d'abord à arrêter le système afin d'empêcher l'aggravation des dégâts. Même si une enquête ultérieure révèle qu'il n'y a pas eu d'impact, les informations divulguées ne peuvent pas être récupérées. Bien entendu, un jugement politique est nécessaire. Pour une entreprise, cela engage son éthique, sa conscience quotidienne des problèmes, sa gestion des risques, etc.
Ce problème provient du fait que certaines valeurs de configuration détenues par le système peuvent être réécrites. Il faut déterminer quelles valeurs de configuration peuvent être réécrites. C'est selon ces valeurs que l'on peut juger quelles attaques sont possibles.
Ces valeurs de configuration diffèrent selon le conteneur de servlets. Avec Tomcat 6, l'exécution de code arbitraire semble probablement impossible, mais avec Tomcat 8, l'exécution arbitraire est possible. Par ailleurs, selon l'environnement utilisé, comme Jetty, WebSphere Application Server, etc., il est nécessaire de vérifier quelles valeurs de configuration existent.
Avec Tomcat 6, 23 de ces paramètres seraient modifiables ; class.classLoader.resources.dirContext.docBase si l'on modifie cette valeur, le fonctionnement normal du système devient impossible. De plus, au lieu d'afficher une JSP, il est possible de spécifier un fichier situé sur le serveur, ce qui permet d'obtenir (de faire fuiter) n'importe quel fichier.
Avec Tomcat 8, l'exécution de code arbitraire est possible, car davantage de valeurs peuvent être configurées par rapport à Tomcat 6. Si cette valeur de configuration n'existe pas dans le conteneur de servlets utilisé, le problème est pour l'instant considéré comme limité.
Cette modification de paramètres peut être réalisée en incluant la chaîne dans l'URL, mais aussi comme champ caché d'une requête normale ; il est également possible d'inclure la valeur dans un cookie.
Lorsqu'elle est placée dans un champ caché, elle est indétectable dans les journaux d'accès.
Il arrive souvent qu'un redémarrage soit effectué tard dans la nuit de dimanche. Si la réécriture de docBase et l'extraction de fichiers sont réalisées un peu avant, comme le redémarrage du système a ensuite lieu, il est difficile, pour l'administrateur système, de remarquer une anomalie. Si des statuts 404, 500, etc. se multiplient pendant cette fenêtre, il est fort probable que des fichiers aient fuité.
Struts 1 n'est plus pris en charge (laissons de côté la question « qu'est-ce que le support d'un logiciel open source ? »), aucun correctif de sécurité n'est publié. Il faut donc résoudre le problème par ses propres moyens.
L'origine du problème se trouve dans BeanUtil ; il est nécessaire de l'implémenter de manière à ignorer les chaînes inappropriées qui lui parviennent. BeanUtil est un outil qui modifie les valeurs de configuration des objets (c'est une description assez approximative).
Quant à l'exemple d'implémentation,
com.haselab.struts.filter
web.xml
le voici.
Pour expliquer simplement : au démarrage du système, web.xml appelle un programme qui modifie le comportement de BeanUtil. SafeResolverListener.java est appelé, et BeanUtil utilisera désormais SafeResolver.java. Dans SafeResolver.java, si la chaîne analysée est 'classLoader' (en ignorant la casse), "" est renvoyé. Autrement dit, il devient impossible de définir une valeur arbitraire pour classLoader. Pour ce comportement, je me suis appuyé sur https://gist.github.com/nakamura-to/11347570 Je m'y suis référé (le programme étant court, je l'ai repris tel quel).
Si l'application doit modifier un paramètre nommé classLoader, cette méthode l'en empêche, elle ne convient donc pas. Mais en général, il ne devrait pas exister de paramètre portant un nom tel que classLoader, il n'y a donc normalement pas de problème. En cas de doute, sur l'ensemble des sources de l'application, grep -r -i classLoader * permet par exemple de vérifier qu'aucune occurrence n'existe.
J'ai testé la réécriture de docBase. Après le déploiement avec mvn, ouvrez le répertoire struts dans un navigateur. À chaque clic sur le bouton, la réécriture de docBase et l'affichage du fichier /etc/passwd sont effectués.