Porte dérobée dans les serveurs d applications JavaEE

Transcription

1 Porte dérobée dans les serveurs d applications JavaEE Philippe Prados macaron(@)philippe.prados.name Atos Origin Résumé Soixante-dix pour cent des attaques viennent de l intérieur de l entreprise. L affaire Kerviel en a fait une démonstration flagrante. Les projets JavaEEs sont très présents dans les entreprises. Ils sont généralement développés par des sociétés de services ou des prestataires. Cela représente beaucoup de monde pouvant potentiellement avoir un comportement indélicat. Aucun audit n est effectué pour vérifier qu un développeur malveillant ou qui subit des pressions n a pas laissé une porte dérobée invisible dans le code. Nous allons nous placer à la place d un développeur Java pour étudier les différentes techniques permettant d ajouter une porte dérobée à une application JavaEE, sans que cela ne soit visible par les autres développeurs du projet. Nous avons développé une archive Java qui permet, par sa simple présence dans un projet, d ouvrir toutes les portes du serveur ou d une carte à puce. Nous étudierons les risques et proposerons différentes solutions et outils pour interdire et détecter ce type de code. Des évolutions du JDK seront proposées pour renforcer la sécurité. Introduction Dans l entreprise, 30 à 40% des effectifs n en sont pas des employés. Cela peut expliquer que la plupart des attaques informatiques viennent de l intérieur. Un développeur malveillant ou poussé à la faute par des pressions psychologiques externes - bien connues des mafias - peut introduire du code permettant d ouvrir des portes sur le serveur d applications. L audit de code peut éventuellement révéler un comportement comme celui-ci : if ( contribuable. equals (" philippe ")) impot =( byte ) impot ; Ce n est pas évident à identifier, car il faut une relecture humaine de tout le code. Avec un peu de chance, les autres développeurs du projet peuvent découvrir la trappe, lors d un déverminage par exemple. Comme tout code est bien plus souvent lu qu écrit, la probabilité de découvrir une trappe n est pas nulle. Pour vous en convaincre, consultez cette présentation évoquant un cas réel : Quelles sont les techniques utilisables par un développeur Java pour cacher son code? Pour exécuter un traitement à l insu de l application? Pour s injecter dans le

2 P. Prados 387 flux de traitement et ainsi capturer toutes les requêtes HTTP? À toutes ces questions, nous allons proposer des réponses et des solutions. Cette étude n a pas vocation à être exhaustive sur les techniques d attaques. Elle en présente certaines très efficaces et souvent innovantes. Une librairie de démonstrations inédites est proposée permettant de qualifier la protection des applications contre des portes dérobées génériques. Cette étude a produit trois alertes de sécurité, la réalisation de deux patchs pour les JDKs et trois outils d analyse et de durcissement du code. Nous terminerons par la présentation des solutions actives et passives pour contrer ce type de menaces. Deux vidéos de démonstrations sont proposées. La première est une simple démonstration de la puissance de la porte dérobée, la seconde explique ensuite comment se protéger contre ce type de menaces. Elles sont disponibles, ainsi que les outils, ici : Cette étude se limite à Tomcat 6.x, avec un JDK et OpenJDK b12, sous Windows et Linux. Les vulnérabilités sont certainement efficaces avec d autres serveurs d applications, mais cela n a pas été vérifié. Coté client, la porte dérobée proposée à été testée sur : Google Chrome Windows Firefox Windows et Linux Internet Explorer Windows Opera 9.63 Windows et Linux Safari Windows 1 L objectif du pirate Du point de vue du pirate, une porte dérobée doit : résister à un audit du code de l application. Sinon, chaque développeur qui participe au projet peut fortuitement la découvrir ; résister aux évolutions futures du code. Il ne doit pas y avoir de dépendance directe avec le code existant. Une évolution de l application ne doit pas faire échec à la porte dérobée ; contourner le pare-feu réseau et le pare-feu applicatif (Web Application Firewall WAF). La communication avec la porte dérobée doit être invisible ou difficilement discernable d un flux légitime ; contourner les outils d analyse de vulnérabilité dans le byte-code, par propagation de teinture sur les variables. De ce cahier des charges, nous avons recherché différentes techniques pour atteindre tous les objectifs que nous nous sommes fixés.

3 388 Porte dérobée dans les serveurs d applications JavaEE Pour résister à un audit, le code de la porte dérobée ne doit pas être présent dans les sources. L application ne doit pas l invoquer directement. Ainsi, la porte est généralement exclue des audits. Pour cela, il faut que la simple présence d une archive, considérée à tord comme saine, suffise à déclencher l attaque. Pour ne pas dépendre de l évolution du code applicatif, le code doit utiliser des attaques génériques, fonctionnant quelque soit l application. Pour contourner les pare-feu, le code doit simuler une navigation d un utilisateur. Il doit respecter toutes les contraintes sur les URLs, les champs présents dans les requêtes, le format de chaque champ, etc. Il ne peut pas ajouter de nouvelles URLs ou de nouveaux champs. Pour contourner les outils d analyses de byte-code 1 à la recherche de variables non saine lors de l invocation de traitements risqués, il faut utiliser une écriture de code spécifique, cassant la propagation de la teinture sur les variables. La méthode ci-dessous casse la propagation des teintures sur les variables simplement en changeant le type de la donnée : private static String sanitize ( String s) char [] buf = new char [s. length () ]; System. arraycopy (s. tochararray (), 0, buf, 0, s. length ()); return new String ( buf ); 2 Implémentation Le code de la porte dérobée doit suivre plusieurs étapes pour s installer définitivement dans le serveur d application et être capable de détourner le flux des traitements. Ces étapes sont détaillées ci-dessous par ordre chronologique : Piège de l application Augmentation des privilèges Injection dans le flux de traitement des requêtes HTTP Détection de l ouverture Communication discrète Exécution des agents 2.1 Les pièges La première étape consiste à initialiser la porte dérobée. Elle doit pouvoir démarrer alors que le code applicatif ignore sa présence. Pour cela, il faut utiliser des pièges pour permettre une exécution de code par la simple présence d une archive JAR. 1

4 P. Prados 389 Les pièges sont des traitements cachés, exécutés à l insu de l application. Le code applicatif ou le serveur d application n a pas à invoquer explicitement du code pour permettre l exécution de traitements malveillants. Différentes techniques de pièges ont été découvertes lors de l étude. Plusieurs stratégies sont possibles pour les réaliser : Surcharge d une classe ; Ajout d un fichier de paramétrage ; Exploitation des «services» ; Exploitation de la programmation par aspects (AOP) ; Exploitation d un «Ressource Bundle» ; Exploitation des annotations. 2.2 Piège par «surcharge» La surcharge d une classe consiste à proposer plusieurs versions différentes de la même classe dans des archives différentes. En redéfinissant une classe banale d une archive, le code du pirate sera exécuté à l insu de l application. Java utilise un mécanisme de chargement dynamique des classes. Une liste d archives (JARs) est consultée lors de la demande de chargement d une classe. L algorithme installe le fichier.class venant de la première archive étant capable de livrer le fichier de la classe. Si l archive ayant la classe modifiée est présente avant l archive originale, le pirate peut exécuter du code complémentaire. Fig. 1. Enchaînement de classes Cette approche présente plusieurs inconvénients : Le code de la porte dérobée est fortement dépendant du code original ; Il est difficile de déléguer les traitements sur l original. Il faut alors récrire l original pour simuler un comportement normal ; La modification de l original peut entraîner le plantage de l application car la copie n en tient pas compte ;

5 390 Porte dérobée dans les serveurs d applications JavaEE L exécution n est pas garantie. Cela dépend de l ordre de sélection des archives par la JVM ; Cette approche est donc rejetée. 2.3 Piège par «paramétrage» De nombreux frameworks utilisent des fichiers de paramétrages indiquant des noms de classes. Certains recherchent des fichiers de paramètres à différents endroits dans les archives. En plaçant un fichier de paramètres dans un lieu prioritaire, il est possible d exécuter du code. Piège du paramétrage «Axis» Le premier exemple est le framework Axis de la fondation Apache. C est un framework permettant l invocation et la publication de services Web. Il recherche les fichiers de configuration dans l ordre suivant (voir la classe EngineConfigurationFactoryServlet) : Fichier <warpath>/web-inf/<param.wsdd> Ressource /WEB-INF/<param.wsdd> Ressource /<param.wsdd> La présence du fichier dans /WEB-INF d une archive quelconque suffit à exécuter du code lors de l invocation du premier service Web. Comme ces fichiers sont rarement modifiés par les projets, il y a peu de chance qu il y ait un conflit avec une autre fonctionnalité du projet. Piège par paramétrage de services Les spécifications des JARs 2 proposent d utiliser le répertoire META-INF/services pour signaler la présence de composants à intégrer. Un fichier UTF-8 dont le nom est généralement le nom d une interface, possède une ligne de texte avec la classe proposée pour l implémenter. Jusqu au JDK5, cette technique n est pas outillée par des APIs du JDK. Chaque projet désirant utiliser cette convention doit écrire un code spécifique. Le JDK6 offre une nouvelle API. Généralement, le programme demande la ou les ressources correspondant à une clef. Le fichier est lu et une instance de la classe indiquée est alors construite. Par exemple, le framework commons-loggins de la fondation Apache, utilise cette convention pour initialiser le LogFactory. L algorithme de découverte suit plusieurs étapes : 1. Recherche de la variable d environnement org.apache.commons.logging.log- Factory 2

6 P. Prados Sinon, recherche d une ressource META-INF/services/org.apache.commons.logging.LogFactory 3. Sinon, lecture de la ressource commons-logging.properties pour y trouver la clef org.apache.commons.logging.logfactory 4. Sinon, utilisation d une valeur par défaut : org.apache.commons.logging.impl.logfactoryimpl La deuxième étape est la plus intéressante pour le pirate, en effet en diffusant une archive avec ce fichier, il est possible d exécuter du code. Ce dernier doit continuer le processus avec les étapes 2 à 4 pour rendre invisible sa présence. D autres frameworks standards utilisent la même approche, parmi lesquels : META-INF/services/javax.xml.parsers.SAXParserFactory META-INF/services/javax.xml.parsers.DocumentBuilderFactory META-INF/services/org.apache.axis.EngineConfigurationFactory... Il est donc aisé de publier ces fichiers pour injecter du comportement. Par exemple, pour détourner l utilisation d un analyseur SAX, il faut en proposer un qui délègue ses traitements vers le suivant. public static class MonSAXParserFactory extends SAXParserFactory private final SAXParserFactory next_ ; // Calc next parser. private static SAXParserFactory getnextsaxparser () return... public SAXParserFactory () next_ = protect. ctrsaxparser (); // Inject code here public Schema getschema () return next_. getschema ();... La seule présence du fichier META-INF/services/javax.xml.parsers.SAXParser- Factory contenant le nom de la classe d implémentation MonSAXParserFactory permet de détourner les traitements sans devoir bénéficier de privilèges particuliers. Les portes d entrées de ce type sont légions : q=meta-inf+providers

7 392 Porte dérobée dans les serveurs d applications JavaEE En positionnant plusieurs pièges équivalents, la probabilité d exécution de la porte dérobée est élevée. Pour se protéger de l injection d un analyseur XML, il faut démarrer la JVM en ajoutant des paramètres permettant d éviter la sélection dynamique de l implémentation. - Djavax. xml. parsers. SAXParserFactory =\ com. sun. org. apache. xerces. internal. jaxp. SAXParserFactoryImpl - Djavax. xml. parsers. DocumentBuilderFactory =\ com. sun. org. apache. xerces. internal. jaxp. DocumentBuilderFactoryImpl... Cette vulnérabilité et une proposition de solution ont été annoncées officiellementii par nos soins. Piège par paramétrage d Aspect La troisième technique de piège consiste à utiliser les technologies innovantes de programmation par aspect. Il s agit d une technique de tissage de code sur des critères syntaxiques du code du projet. Les frameworks de programmations par Aspect recherchent la présence d un fichier /META-INF/aop.xml dans chaque archive. Ce dernier permet l exécution automatique d un code Java. Il suffit d avoir une archive avec ce fichier pour pouvoir injecter du code où cela est intéressant. <! DOCTYPE aspectj PUBLIC " -// AspectJ // DTD // EN" " http: // www. eclipse. org / aspectj / dtd / aspectj. dtd "> < aspectj > < weaver > < include within =" *..*.* Servlet " /> < include within =" *.. jsp..* " /> </ weaver > < aspects > < aspect name =" com. googlecode. macaron. MyAspect " /> </ aspects > </ aspectj > Piège par ResourceBundle Pour gérer les messages en plusieurs langues, Java utilise des ResourcesBundles. L algorithme recherche un fichier.properties suivant différents critères de langues et offre alors un ensemble de clefs/valeurs. ResourceBundle. getbundle (" Messages "). get (" hello ") L algorithme recherche un fichier en ajoutant un suffixe formé de la langue et de sa déclinaison pour le pays. Par exemple, pour la France, le suffixe est FR fr, pour la Belgique FR be. S il ne trouve pas de fichier, l algorithme supprime des éléments

8 P. Prados 393 Fig. 2. Lecture de properties du suffixe progressivement jusqu à localiser un fichier pour la langue. Si rien n est trouvé, une version sans suffixe est recherchée. Bien que cela soit peu connu, l algorithme est en fait plus complexe. Il recherche également des classes de même nom avant de rechercher les fichiers.properties. Fig. 3. Lecture de properties avec classes Il est donc possible, en ajoutant une simple classe, d exécuter du code lors du chargement d une ressource. Pour simuler le comportement classique de l algorithme, il faut écrire une classe et ajouter un traitement dans le constructeur. public static class Messages extends PropertyResourceBundle public Messages () throws IOException super ( Messages. class. getresourceasstream ( / + Messages. class. getname (). replace (., / )+". properties ")); // Inject code here

9 394 Porte dérobée dans les serveurs d applications JavaEE De nombreux frameworks utilisent des ResourcesBundles. Une requête avec google/codesearch montre l étendue des possibilités : q=resourcebundle.getbundle+lang%3ajava Il suffit d ajouter une classe de même nom qu un fichier de ressource pour que le piège se déclenche à l insu de l applicatif. Lors d un traitement anodin comme le chargement d un fichier de clef/valeur, la porte s installe dans le système. En choisissant judicieusement les pièges, la probabilité d exécuter le code d initialisation de la porte dérobée est forte. En effet, plus aucun projet ne se passe de composants Open Source ou non. Si un RessourceBundle est utilisé dans un code privilégié, la classe de simulation peut alors bénéficier des privilèges. AccessController. doprivileged ( new PrivilegedAction < Object >() Object run () ResourceBundle. getbundle (" innocent "). getstring (" key "); // Oups! return null ; Cette vulnérabilité et une proposition de solution ont été annoncées officiellement dans le bulletin CVE par nos soins. Piège par Annotations De plus en plus de frameworks utilisent les annotations pour identifier des classes et des instances à initialiser. C est un objectif de l annotation : réduire le paramétrage. En exploitant les annotations exploitées par les différents frameworks, il est possible d ajouter une classe qui sera automatiquement invoquée. Par exemple, le framework Spring construit des instances des classes étant annotées La contrainte est qu il faut déclarer une classe dans un répertoire consulté par l application lors de son initialisation. < context:component - scan base - package =" org. monprojet "/> L inconvénient de ce piège est qu il exige de connaître le nom de la branche du projet où seront recherchés les différents composants. Sans modification du fichier ou capture de l analyse par le parseur XML, il n est pas possible de proposer un piège générique exploitant cette fonctionnalité. Par contre, un développeur du projet n a aucune difficulté à proposer un code d attaque adapté.

10 P. Prados 395 Avec les spécifications Servlet 3.0, chaque classe possédant une chaine de caractère "Ljavax/servlet/annotation/WebServlet" sera instancié par le serveur d application. En effet, c est la technique utilisé pour identifier les classes possédant une Augmentation de privilèges Une fois le piège déclenché, l étape suivante consiste à augmenter les privilèges du code de la porte dérobée. En effet, le code du piège n a pas toujours les droits nécessaires à la mise en place judicieuse de la porte dérobée. Si le code ne bénéficie pas d un environnement pour installer tout le nécessaire, il doit augmenter ses privilèges. Ceux-ci peuvent être des droits d utiliser des API (si la sécurité Java2 est activée) ou pouvoir accéder à des classes particulières du serveur d applications. En effet, les classes java sont isolées les unes des autres grâce au chargeur de classe. Par exemple, un composant Web n a pas accès aux classes du serveur d applications. Sous Tomcat 5.5, il y a trois espaces de noms. Fig. 4. Répartition des classes dans Tomcat 5 Certaines classes sont partagées entre le serveur d applications et les composants, mais il ne s agit pas des plus intéressantes. Elles permettent la communication entre le serveur d applications et les composants JavaEE. Cette architecture permet d isoler efficacement les applications entre elles. La porte dérobée doit s insérer dans l application et y rester après un redémarrage, avec plus de privilèges. Pour cela, une copie d une archive dans un répertoire plus privilégié permettra d augmenter les droits du code. La porte dérobée doit s installer dans le répertoire des composants du serveur d applications. Lors du redémarrage, le code bénéficiera ainsi de toutes les classes du serveur. Le piège par ResourceBundle permet alors l injection de code lors du démarrage du serveur d application, à son insu.

11 396 Porte dérobée dans les serveurs d applications JavaEE Avec Tomcat 6, il n est plus nécessaire d augmenter les privilèges car toutes les classes sont disponibles. La dernière version de Tomcat s appuie sur la limitation d accès aux packages via la variable système package.access. Cela n est actif qu avec la sécurité Java2 active. 2.4 Les techniques d injections Le code de la porte dérobée doit être injecté dans le flux de traitement de l application. L idéal est de pouvoir analyser chaque requête HTTP pour y détecter une clef spécifique ouvrant la porte. Il existe différentes techniques pour injecter du code dans le processus de gestion d une requête HTTP. Le schéma suivant indique le flux de traitement standard d un composant JavaEE de type Web. Les différents points d insertions possibles sont représentés. Fig. 5. Point d insertions Plusieurs stratégies permettent cela. Chacune est plus ou moins fonctionnelle suivant le contexte d exécution : Modifier le fichier web.xml du cache de Tomcat ; Ajouter dynamiquement une Valve Tomcat ; Injecter du code en AOP ; Injecter du code dans les frameworks ; Injecter une Servlet 3.0 ; Injecter du code lors de la compilation.

12 P. Prados 397 D autres approches ont été proposées 3, mais elles nécessitent la modification d une classe du serveur d application. Injection par «Ajout d un filtre» Le serveur Tomcat décompresse les archives (WAR, EAR) des composants dans un répertoire de travail. Ce dernier est rafraîchi si le composant applicatif possède une date plus récente. Le démarrage de la porte dérobée doit retrouver le fichier web.xml du cache de Tomcat, injecter un filtre JavaEE dans ce dernier et attendre le redémarrage du serveur d application. Ce n est pas toujours facile car le code du piège de la porte dérobée est exécuté n importe où, ou plutôt n importe quand, et il n a pas accès aux requêtes, réponses HTTP ou aux contextes des servlets. Quelques astuces permettent cependant d identifier dynamiquement le contexte d exécution pour localiser le fichier à modifier. Le filtre JavaEE décrit ci-dessous, injecté dans web.xml, capture désormais toutes les requêtes Web :... < filter > <filter - name > Macaron </ filter - name > <filter - class > MacaronFilter </ filter - class > </ filter > <filter - mapping > <filter - name > Macaron </ filter - name > <url - pattern >/* </url - pattern > </ filter - mapping >... Cette technique fonctionne avec un Tomcat seul, mais pas toujours avec un Tomcat intégré dans un serveur d applications. Par défaut, le serveur JBoss intègre Tomcat mais redéploye tous les composants à chaque démarrage. Ainsi la modification du fichier web.xml dans le répertoire de travail de Tomcat n est pas persistant lors du redémarrage de JBoss. Cette attaque ne fonctionne pas dans ce cas. Notez que les nouvelles spécifications des Servlet 3.0 permettent d ajouter dynamiquement des filtres ou des servlets. ServletContext. addfilter (...) De plus, les web-fragments permettent d ajouter encore plus facilement des filtres ou des servlets, en déclarant un fichier META-INF/web-fragment.xml. <web - fragment > < filter > 3

13 398 Porte dérobée dans les serveurs d applications JavaEE... </ filter > </web - fragment > Injection par ajout d une «Valve» Tomcat propose également des Valves. Ce sont des filtres spécifiques, pouvant être ajoutés dynamiquement via une requête JMX. JMX est une technologie de consultations et de manipulations des paramètres du serveur, lors de son exécution. Pour ajouter une valve, il faut construire une instance héritant de ValveBase avant de l installer dans le serveur via une requête JMX. public static void injectvalve () throws Exception final MBeanServer srv = getmbeanserver (); final Set <? > valves = srv. querynames ( new ObjectName ( "*: J2EEServer =none, j2eetype = WebModule,*"), null ); for ( Object i: valves ) srv. invoke (( ObjectName )i," addvalve ", new Object [] new ValveBase () public final void invoke ( final Request req, final Response resp ) throws IOException, ServletException getnext (). invoke (req, resp ); // Inject code here, new String [] " org. apache. catalina. Valve "); Avec Tomcat 5.x, la classe ValveBase n est pas disponible dans le chargeur de classe du composant applicatif. Ajouter une version de cette classe dans le composant est impossible car Tomcat se protège de cela en refusant à un composant Web de déclarer ou d utiliser des classes de Tomcat. Il est donc nécessaire d obtenir une augmentation de privilège comme indiqué ci-dessus. Dans un cas particulier il existe une autre solution : si l attribut privileged du marqueur context/ du fichier META-INF/context.xml du composant est à true, les classes de Tomcat sont disponibles et l invocation JMX peut s effectuer. La présence de cet attribut - très discret par ailleurs - permet de bénéficier d un autre chargeur de classe et de plus de droits dans une application Web. Il est alors possible d injecter dynamiquement des Valves pour détourner le flux de traitement de toutes les requêtes.

14 P. Prados 399 Un développeur peut ajouter facilement cet attribut dans ce fichier pour lui ouvrir des portes. C est un privilège demandé par le composant applicatif, sans refus possible par le serveur d application. Dans un projet, personne n a une vision complète du code. Aucun développeur n ira modifier cet attribut de peur de faire une bêtise. Si l attribut n est pas à true, il faut rechercher une augmentation de privilège pour installer les Valves. Avec Tomcat 6.x, il n y a aucune contrainte pour accéder à la classe ValveBase si la sécurité n est pas activée. Il est donc généralement possible d ajouter une valve lors de l exécution d un piège. Injection par XML Nous avons vu au chapitre «Injection par XML» qu il était possible de contourner l invocation de l analyseur SAX ou DOM. Il faut pour cela publier une archive dans le projet Web, contenant le fichier META-INF/services/javax.xml.parsers.SAXParserFactory. Il est donc possible d enrichir ou de modifier un fichier XML de l application, lors de son traitement par l analyseur. Comme de nombreux frameworks utilisent ce format, il est possible d injecter de nouveaux paramètres à la volée, avant l analyse par le framework. C est un peu compliqué car il faut rédiger plusieurs classes s occupant de la délégation vers le parseur présent dans le serveur. Il faut dans un premier temps implémenter l interface SAXParserFactory pour modifier la méthode newsaxparser(). Cette dernière doit retourner une implémentation de la classe SAXParser. L implémentation doit modifier la méthode getxmlreader() pour retourner une implémentation de l interface XMLReader. Cette dernière peut alors modifier la méthode parse(inputsource input) pour lire le flux avant l analyseur et y déceler la présence d un flux intéressant. Il est alors possible de le modifier avant de continuer l analyse. Le code suivant est un extrait de cette implémentation : public class SAXParserFactory extends javax. xml. parsers. SAXParserFactory private final javax. xml. parsers. SAXParserFactory next_ ; protected void hookparse ( XMLReader reader, InputSource input ) throws IOException, SAXException // Inject code here reader. parse ( input ); public SAXParserFactory () next_ = nextservices (

15 400 Porte dérobée dans les serveurs d applications JavaEE " javax. xml. parsers. SAXParserFactory ", " com. sun. org. apache. xerces."+ " internal. jaxp. SAXParserFactoryImpl "); public final SAXParser newsaxparser () throws ParserConfigurationException, SAXException return new SAXParser () private final SAXParser _next = next_. newsaxparser (); public final XMLReader getxmlreader () throws SAXException return new XMLReader () private XMLReader next_ = _next. getxmlreader (); public final void parse ( InputSource input ) throws IOException, SAXException hookparse ( next_, input ); // Delegate methods... public ContentHandler getcontenthandler () return next_. getcontenthandler ( ; // Delegate methods... public final boolean equals ( Object obj ) return _next. equals ( ; // Delegate methods... public final boolean equals ( Object obj ) return next_. equals ( La même approche peut s effectuer lors de l analyse d un DOM, par exemple lors du paramétrage des logs. Il est possible de contourner l initialisation pour supprimer des alertes en toute discrétion.

16 P. Prados 401 Notez que cette attaque ne fonctionne pas avec Tomcat 5.5 car ce dernier utilise le parseur du composant pour analyser ces propres fichiers XML. Cela entraine l utilisation de packages protégés par la variable système package.definition. Donc, par effet de bord, le serveur refuse d utiliser un analyseur XML qui délègue son traitement à un analyseur déjà présent. Il est possible de livrer un analyseur complet, sans délégation. Ce point sera corrigé suite à l alerte que nous avons signalée à l équipe de Tomcat. La version 6.x de Tomcat n utilise plus, à raison, l analyseur du composant pour analyser ces fichiers XML (sauf encore pour les fichiers TLD). L attaque est alors effective avec Tomcat 6.x. Comme Tomcat utilise à tord le parseur du composant pour analyser les fichiers TLD, ce dernier est toujours exécuté avant le lancement de l application. La porte dérobée peut alors s installer dans tous les cas, que l application utilise ou non un parseur XML en interne. Cette vulnérabilité et une proposition de solution ont été annoncées officiellement (CVE ) par nos soins. Injection par génération d «Autoproxy» Java propose une API particulière permettant de générer dynamiquement une classe répondant à une interface précise. Une instance de cette classe capture toutes les invocations et peut alors modifier les traitements. La librairie CGLIB propose un fonctionnement similaire en générant dynamiquement une classe héritant d une autre, dont toutes les méthodes publiques peuvent être redéfinies. Cette deuxième approche permet d offrir le même service, sans nécessiter d interface. Ces technologies sont utilisées pour générer des auto-proxies, pour ajouter par exemple des règles de sécurités, de la gestion des transactions, de la répartition de charge, de la communication à distance type RMI ou CORBA, etc. Injection des Singletons Le privilège Java2 suppressaccesschecks permet de modifier les attributs privés. S il est disponible, il est facile de modifier des singletons. Imaginons un Singleton porté par une interface et accessible via un attribut privé statique. interface Singleton... class TheSingleton implements Singleton private static Singleton _singleton = new TheSingleton ();

17 402 Porte dérobée dans les serveurs d applications JavaEE public static Singleton getsingleton () return _singleton ; Le singleton est accessible via la méthode statique TheSingleton.getSingleton(). Il est également disponible via l attribut privé TheSingleton._singleton. Le code suivant permet d encapsuler un singleton pour que toutes ses méthodes soient sous le contrôle de la porte dérobée. public static void hacksingleton ( // La classe d acc \ es final Class <? > singletonclass, // L attribut priv \ e final String singletonfield, // L interface du singleton final Class <? > singletoninterface, // L instance courante final Object singleton ) throws NoSuchFieldException, IllegalAccessException final Field field = singletonclass. getdeclaredfield ( singletonfield ); field. setaccessible ( true ); field. set (null, Proxy. newproxyinstance ( singletoninterface. getclassloader (), new Class [] singletoninterface, new InvocationHandler () public Object invoke ( Object self, Method method, Object [] args ) throws Throwable // Inject code here return method. invoke ( singleton, args ); )); L invocation de cette méthode par la porte dérobée permet de détourner tous les traitements du singleton. hacksingleton ( // La classe d acc \ es TheSingleton. class, // L attribut statique priv \ e " _singleton ", // L interface du singleton Singleton. class, // Le singleton courant SingletonImp. getsingleton ());

18 P. Prados 403 Deux techniques permettent de se protéger de ces attaques : déclarer l attribut _singleton en final ou utiliser la sécurité Java2. Il faut en effet bénéficier du privilège suppressaccesschecks pour pouvoir modifier un attribut privé. Parfois, les singletons n implémentent pas d interfaces. public class Singleton private static Singleton thesingleton = new Singleton (); public static Singleton getsingleton () return _singleton ; En exploitant la librairie CGLib, si elle est disponible dans le projet, il est toujours possible de détourner les traitements du singleton. public static void hackcglibsingleton ( final Object singleton, String singletonfield ) throws NoSuchFieldException, IllegalAccessException Field field = singleton. getclass (). getdeclaredfield ( singletonfield ); field. setaccessible ( true ); field. set ( null, Enhancer. create ( singleton. getclass (), new MethodInterceptor () public Object intercept ( Object obj, Method method, Object [] args, MethodProxy proxy ) throws java. lang. Throwable )); // Inject code here return proxy. invoke ( singleton, args );... hackcglibsingleton ( Singleton. getsingleton (), " _singleton "); Pour éviter cette attaque, il faut que la classe du singleton soit final afin d interdire l héritage ou utiliser la sécurité Java2. Comme il est possible de détourner les invocations de toutes les méthodes d un singleton, le développeur inconvenant va rechercher les singletons permettant d obtenir la requête et la réponse d une requête HTTP. Ainsi, il peut détecter l ouverture de la porte dérobée lors de l utilisation du singleton. Les frameworks d AOP utilisent des singletons pour l injection du code. Moyennant la présence de CGLib, il est théoriquement possible d intervenir sur le traitement

19 404 Porte dérobée dans les serveurs d applications JavaEE d une injection, après le démarrage de l application. AspectJ utilise un singleton public mais final, interdisant cette attaque. Cela confirme que l utilisation de singletons présente un risque pour les projets. L utilitaire Google Singleton Detector 4 peut identifier les risques dans les projets. Injection des composants Spring Le framework Spring initie les singletons de l application à l aide du concept d inversion de contrôle. C est à dire que les composants ne recherchent pas leurs composants liés, c est le framework Spring qui se charge de leur fournir. L initialisation des composants de Spring correspond à la création d un groupe de Singletons, liés entre eux. Il est donc intéressant de vérifier qu il n est pas possible de détourner le traitement d une requête HTTP. Le framework Spring propose différents sous-frameworks dont une couche MVC (Modèle, Vue, Contrôleur) permettant de gérer les requêtes Web. Avec ce dernier, il est possible d injecter un AutoProxy dans les contrôleurs du MVC, afin d avoir la main sur toutes les public static class (" execution ( public org. springframework. web. servlet. ModelAndView *( javax. servlet. http. HttpServletRequest, javax. servlet. http. HttpServletResponse ))") public Object mvc ( ProceedingJoinPoint pjp ) throws Throwable pjp. proceed (); // Inject code here Toutes les requêtes destinées aux contrôleurs commenceront par un petit tour vers le code de la porte dérobée. De même, il est possible d ajouter un interceptor en charge de détourner le traitement des requêtes ( RegisterInterceptor. RegisterInterceptorName ) public class RegisterInterceptor extends ( BackDoorInterceptor. InterceptorName ) static public class BackDoorInterceptor implements MethodInterceptor private static final 4

20 P. Prados 405 String InterceptorName =" Interceptor "; public Object invoke ( MethodInvocation i) throws Throwable final Method method =i. getmethod (); final Type [] args = method. getgenericparametertypes (); if (( args. length ==2) && ( args [0]== HttpServletRequest. class ) && ( args [1]== HttpServletResponse. class )) // Inject code here return i. proceed (); private static final String RegisterInterceptorName =" registerinterceptor "; public RegisterInterceptor () setbeannames ( new String [] "*"); setinterceptornames ( new String [] BackDoorInterceptor. InterceptorName ); Pour que cela fonctionne, il faut que l initialisation de Spring analyse le package où la classe est présente. Cela s effectue par une instruction dans le fichier *-dispatch-servlet.xml. < context:component - scan base - package =" com. googlecode. macaron " / > Une troisième approche consiste à déclarer un <bean/> implémentant l interface BeanPostProcessor. Il est alors possible d intervenir sur les beans implémentant l interface HandlerMapping pour modifier le comportement de la méthode gethandler( HttpServletRequest request). Si nous désirons une attaque générique, ne dépendant pas d un nom de package spécifique à un projet, il faut modifier l analyse du fichier XML à la volée pour y injecter dynamiquement la déclaration d un nouveau <bean/>. A l heure où nous rédigeons ces lignes, cette attaque ne nécessite aucun privilège particulier pour être effective. Elle ne peut être contrée. Nous proposons une solution et un patch du JDK6 pour corriger cela. Injection par déclaration d «Aspect» Une autre technologie se démocratise : la programmation par aspect. Il s agit d ajouter au programme des règles de transformations et de tissage de code, fondées sur la structure du programme. La programmation

21 406 Porte dérobée dans les serveurs d applications JavaEE par aspect permet naturellement l injection de code dans l application. Cette évolution du langage peut être présente globalement, à l aide d un paramètre de la JVM. java - javaagent : aspectjweaver. jar... Nous avons montré comment cette technique permet à un piège de l application d exécuter du code à l insu du projet. Elle permet également l injection de traitements lors des requêtes HTTP. Tous les flux de traitement vers les requêtes ou les fichiers JSP peuvent être public static class (" execution ( void doget (..) )" + " execution ( void dopost (..) )" + " execution ( void service (..) )" + " execution ( void _jspservice (..) )") public void backdoor ( ProceedingJoinPoint pjp ) throws Throwable pjp. proceed (); // Inject code here Ainsi, toutes les servlets et toutes les JSP du serveur d application seront sous le contrôle de la porte dérobée. Il n existe pas de technologie pour bloquer cette attaque. Injection Servlet 3.0 Les dernières spécifications des servlets permettent naturellement l injection de filtre. Le chargeur de classe d une application Web regarde toutes les classes implémentant les interfaces suivantes, pour y découvrir éventuellement des annotations. javax.servlet.servlet javax.servlet.filter javax.servlet.servletcontextlistener javax.servlet.servletcontextattributelistener javax.servlet.servletrequestlistener javax.servlet.servletrequestattributelistener javax.servlet.http.httpsessionlistener javax.servlet.http.httpsessionattributelistener Lors de la présence d une ce dernier est ajouté automatiquement comme s il était présent dans le fichier web.xml.

22 P. Prados 407 Comme les algorithmes à la recherche des annotations doivent parcourir toutes les classes, ils sont optimisés et utilisent parfois des raccourcies. Par exemple, l algorithme 5 utilisé par GlassFish recherche simplement la présence d une chaine de caractère correspondant au nom de l interface, dans le pool de constante ; une chaine de la forme "Ljavax/servlet/annotation/WebServlet". Si une classe utilise cette chaine de caractère pour autre chose, sans être pour autant une servlet, elle sera considérée comme possédant cette annotation. Les outils d audits doivent tenir compte de ce raccourci. Pour éviter cette découverte automatique des filtres, il faut ajouter le paramètre metadata-complete dans le fichier web.xml. Injections lors de la compilation Le JSR269 permet d ajouter des Processors lors de la compilation d un code java. A partir de la version 6 de la JVM, sur la présence d une annotation, un code java prend la main lors de la compilation pour générer d autres classes ou des fichiers de ressources. Pour que cela fonctionne, il faut posséder une archive dans le CLASSPATH, lors de la compilation. Cette dernière doit présenter le service javax.annotation.processing.processor comme indiqué au chapitre «Injections lors de la compilation». Avec cette approche, il est possible d intervenir sur le code final de l application, même avec une archives présente uniquement pour les tests unitaires. L ajout ou la modification de classe est possible. Il est donc envisageable d intervenir sur une classe compilée pour modifier son comportement, soit en injectant du code directement dans la classe, soit en replaçant tout simplement le ( SourceVersion. RELEASE_6 ) public class Processor extends AbstractProcessor private static boolean onetime = false ; public boolean process ( Set <? extends TypeElement > annotations, RoundEnvironment rndenv ) Filer filer = processingenv. getfiler (); Messager messager = processingenv. getmessager (); Elements eltutils = processingenv. getelementutils (); if (! rndenv. processingover () &&! onetime ) onetime = true ; try final String filterclass = Filter3. class. getname (); 5

23 408 Porte dérobée dans les serveurs d applications JavaEE JavaFileObject jfo = filer. createclassfile ( filterclass ); InputStream in= Filter. class. getclassloader (). getresourceasstream ( filterclass. replaceall (".","/")+". class "); OutputStream out = jfo. openoutputstream (); final byte [] tampon = new byte [4096]; int len ; while (( len = in. read ( tampon )) > 0) out. write ( tampon, 0, len ); out. close (); in. close (); catch ( Throwable x) // Ignore return true ; D autres pistes sont possibles, comme la copie de l archive de la porte dérobé lors de la compilation à partir d une version présente uniquement pour les tests unitaires. Lors d une compilation par Maven ou Ant, par exemple, le processeur est invoqué pour compiler les classes du projet et les classes des tests unitaires. Le processeur peut alors entrer en action pour intervenir sur le répertoire target, avant la création de l archive du projet. Cette attaque peut être exploitée pour toutes applications Java, et permettre d injecter une porte dérobé dans une carte à puce. Pour interdire cela, il faut ajouter le paramètre -proc :none lors de la compilation. D autres approches Dans certaines conditions particulières, d autres approches sont possibles, comme la modification à chaud d une classe via l api JPDA (Java Platform Debugger Architecture). Il faut pour cela bénéficier de l archive tools.jar du JDK et que la JVM soit lancée en mode débug via le réseau. 2.5 Détection de l ouverture de la porte Le code de la porte dérobée étant exécuté à chaque requête HTTP à l aide d une Valve Tomcat, d un filtre JavaEE, d une injection AOP, d un Auto-Proxy ou d un interceptor Spring, il est possible d analyser tous les champs des formulaires. Sur la présence d une clef dans un champ quelconque d un formulaire, la porte dérobée détourne le traitement.

24 P. Prados 409 Nous proposons un code de démonstration de ces attaques. Il s agit de placer une simple archive dans le répertoire WEB-INF/lib. Il faut ensuite utiliser le mot Macaron en écriture Leet 6 («M4c4r0n») dans n importe quel champ de l application pour l exécuter. 2.6 Communication discrète Ce chapitre décrit la couche de communication mise en place par la démonstration. Vous pouvez sauter directement vers le chapitre «Démonstration». Maintenant que le flux est détourné, il faut faire preuve de discrétion pour communiquer avec la porte dérobée. Le code ne doit pas être détecté par les pare-feu réseaux ni par les pare-feu applicatifs (WAF). Les pare-feu applicatifs détectent : Les URLs utilisées via une liste blanche ; La liste des champs pour chaque URLs et les contraintes de format (chiffre/lettre, taille, etc.) ; La vitesse des requêtes (plus de 120 requêtes par minutes ou plus de 360 requêtes en cinq minutes) ; La taille limite des réponses (512Ko) ; La présence de mots clefs spécifiques dans les pages de réponses (liste noire). La porte dérobée doit contourner toutes ces vérifications. Pour cela, le filtre utilise une URL standard de l application, celle utilisée pour insérer la clef. La requête d ouverture est conforme aux contraintes si le champ choisi pour utiliser la clef accepte des caractères et des chiffres. La communication s effectue en remplissant un formulaire avec une valeur spéciale, respectant les contraintes du champ (type de caractère et taille du champ). Les agents de la porte dérobée n utilisent alors que cette URL, en soumettant toujours le même formulaire, avec les mêmes valeurs, sauf pour un seul champ qui sert de transport. Ce dernier ne doit pas violer les contraintes du champ. La figure 6 indique le cheminement de la communication. Lors de la soumission d un formulaire, le traitement est détourné vers la porte dérobée. Une page spécifique est renvoyée. Cette dernière communique avec le code de la porte dérobée à l aide de requêtes AJAX afin d injecter dans la page, les résultats des traitements au format XML. Une écoute des trames réseau lors d une communication avec la porte dérobée fait apparaître des soumissions régulières d un formulaire, dont un seul champ évolue. Si la requête est de type POST, il est peu probable que cela soit enregistré dans les logs. 6

25 410 Porte dérobée dans les serveurs d applications JavaEE Fig. 6. Communication de la porte dérobée Toutes les manipulations de la porte dérobée utilisent des trames portées par un champ de formulaire HTML. Une taille limite n est jamais dépassée pour ce dernier. La grammaire des trames est la suivante : <M4c4r0n ><a b><data > Elle est précisée ci-dessous. Comme les trames ne doivent dépasser une certaine taille, le caractère après la clef «M4c4r0n» indique si la trame est terminée (a) ou si elle doit être complétée par d autres trames (b). Les caractères suivants servent de charge utile à la trame. Le contenu est au format ASCII en b64 ou hexadécimal suivant le paramétrage de la porte dérobée. La charge utile des trames est alors analysée comme une commande à exécuter. Des pages HTML spécifiques sont retournées. Elles utilisent la technologie AJAX pour communiquer. Les pages sont autonomes. Elles intègrent les feuilles de styles et les scripts mais évitent les images (sauf au format data : ), afin de réduire le nombre de requêtes HTTP. Une seule requête d ouverture de la porte dérobée permet d obtenir un agent fonctionnel. Les pare-feu applicatifs ne vérifient généralement pas le format des pages en retour. Le flux d émission AJAX est ralenti en termes de trafic réseau pour ne pas éveiller les soupçons.

26 P. Prados 411 Une requête spécifique conf permet d indiquer le format d encodage et la taille maximum d une trame à ne pas dépasser. Elle a le format suivant : La clef, en l occurrence «M4c4r0n» ; Le caractère de fin de trame («b») ; Le mot clef de la commande «conf» ; Un caractère indiquant si l encodage doit être hexadécimal ou base64 («h» ou «b») ; Un nombre indiquant la taille maximum des trames ; Le caractère «W» comme séparateur ; Un nombre indiquant en second la fréquence d émission des trames. Par exemple, pour demander l initialisation de la porte dérobée en utilisant l encodage hexadécimal, une taille maximal des trames de 30 caractères et un pool de 3 secondes, il faut valoriser un champ de formulaire texte d une vingtaine de caractères comme le montre la figure 7 : Fig. 7. Configuration Cela ouvre la porte tout en paramétrant les communications futures. Par défaut, l encodage est en base64, les trames ne dépassent pas 80 caractères et le pool est de deux secondes. Il est donc recommandé de choisir un champ suffisamment grand pour recevoir tous ces caractères. 2.7 Le scénario d exécution Le scénario d exécution de la porte dérobée est le suivant : Étape 1 : Déclenchement du piège. Étape 1bis : Si nécessaire, augmentation des privilèges en utilisant une technologie d exécution implicite. Puis attente d un redémarrage du serveur d application ; Étape 2 : Injection d un filtre sur toutes les requêtes HTTP ; Étape 3 : Analyse de toutes les requêtes pour détourner le flux de traitement des requêtes lors de la présentation de la clef.

27 412 Porte dérobée dans les serveurs d applications JavaEE 2.8 Les agents Différents agents sont proposés par la porte dérobée. Un agent mémorisant les dernières requêtes sur le serveur ; Un agent JMX pour manipuler le serveur d application ; Un agent JNDI pour consulter l annuaire de la configuration ; Un agent SQL pour manipuler la base de données ; Un agent Java/javascript pour compiler et exécuter dynamiquement du code ; Un agent Shell pour s amuser. Fig. 8. History Agent History Cet agent permet de mémoriser les dernières requêtes avec leurs paramètres, quelque soit l utilisateur. Il peut permettre de découvrir des informations confidentielles soumises par d autres utilisateurs. Agent JNDI Cet agent permet de naviguer dans l arbre JNDI, l annuaire des objets des applications JavaEE. Les ordres possibles sont : cd <jndi_name > ls dump <jndi -name >

28 P. Prados 413 Fig. 9. JNDI La commande dump permet, si possible, de sérialiser l objet et d afficher une vue hexadécimale du résultat. Cela permet parfois de trouver des mots de passes. Agent JMX Cet agent permet de naviguer dans l arbre JMX, l arbre de gestion des objets du serveur. Les ordres permettent de consulter ou de modifier les attributs et d invoquer des traitements. L ergonomie proposée ressemble à un shell avec une syntaxe spécifique. Les ordres possibles sont : cd <JMX name > ls <attr >= < valeur > method (< params >) Agent JDBC Cet agent utilise la connexion à la base de données déclarée dans le fichier web.xml ou spécifiée en ligne de commande. Il permet d invoquer toutes les requêtes SQLs autorisées par la connexion. Si elles commencent par select, l agent affiche un tableau avec le résultat. Sinon il exécute le traitement et retourne un statut. La commande jndi <key> permet d utiliser une autre clef JNDI pour accéder à la base de données. Tous les privilèges accordés à l application sont disponibles. Il ne faut pas longtemps ensuite pour les augmenter et attaquer le serveur de la base de données. Les publications sur les SQLs injections peuvent être une source d inspiration.

29 414 Porte dérobée dans les serveurs d applications JavaEE Fig. 10. JMX Fig. 11. JDBC

30 P. Prados 415 Fig. 12. Java/Javascript Agent Java/Javascript Cet agent permet d exécuter du code java ou javascript sur le serveur. Pour l utilisation de Java, le code est intégré dans un fichier source java puis compilé avec le compilateur trouvé sur place coté serveur. Le code compilé est injecté dans le serveur à l aide d un chargeur de classe puis exécuté. Le résultat est retourné au navigateur. Si le code se termine par un ; ou, il est exécuté. Sinon, il est évalué. Le code utilise le compilateur intégré à Jasper, le compilateur de JSP. S il n est pas présent, il exploite le compilateur du JDK disponible. Si ce dernier n est pas présent car l application utilise un JRE, le code recherche l archive tools.jar pour l injecter et l utiliser. Il est rare de ne pas pouvoir compiler une classe dynamiquement sur le serveur. Pour l utilisation de Javascript, le code utilise l implémentation Rhino présente avec le JDK. Deux variables sont disponibles : request : La requête HTTP out : un flux dont le résultat sera affiché dans le navigateur Agent «shell» Cet agent lance un shell sur le serveur et offre une interface similaire dans le navigateur. Des requêtes périodiques permettent de récupérer les modifications d états dans le shell du serveur. Il s agit d un simple shell TTY et non d un shell ANSI.