Symposium sur la sécurité des technologies de l'information et des communications

Les tests d'intrusion réalisés ces dernières années par HSC qu'ils soient internes ou externes montrent que la technologie J2EE occupe une place de plus en plus importante au sein du domaine applicatif. Sa portabilité, sa sécurité et ses nombreuses API sont les éléments principaux à l'origine de son succès. Le « boom » du J2EE a particulièrement impacté le monde du web que ce soit pour les applications web elles-mêmes ou bien la mise en place d'infrastructures beaucoup plus complexes comme des plate-formes de web services. De nombreux sites gouvernementaux, banques et grands organismes utilisent notamment cette technologie et cela ne va pas en régressant.

Bien entendu, les infrastructures web ont dû s'adapter à cette nouvelle technologie et de nouveaux serveurs ont dû être mis en place. Cependant, les bannières que l'on peut rencontrer sur la toile et sur les réseaux internes des entreprises ne sont pas si diversifiées. Pour les conteneurs web, il s'agit principalement de serveurs Tomcat utilisés généralement pour l'hébergement des applications web (JSP et Servlets notamment). Par ailleurs, ces dernières années, avec l'apparition des architectures N-tiers, la logique métier des applications a été modularisée nécessitant l'apparition de nouveaux serveurs dits « d'application ». De la même manière, le marché est principalement dominé par une seule bannière: JBoss Application Server.

Ce succès au sein des entreprises peut être justifié premièrement par sa portabilité, tant qu'une machine virtuelle Java (JVM) est disponible, il n'y a aucun problème. Puis, deuxièmement, par sa grande modularité qui permet d'utiliser JBoss pour à peu près tout et n'importe quoi, du simple hébergement d'applications web basiques (JBoss embarque un serveur Tomcat) à la mise en place d'une véritable plate-forme de web services complète mettant à profit tous les avantages des architectures distribuées.

Cependant, malgré ce succès, les mécanismes de sécurisation des serveurs JBoss ne semblent pas encore correctement maîtrisés par les administrateurs. Le retour d'expérience HSC montrent notamment que de plus en plus d'intrusions internes ou externes débutent par la compromission d'un serveur JBoss.

Cette constatation s'appuie principalement sur le manque de protection mis en place, par défaut, sur les nombreuses interfaces d'administration de ces serveurs. Contrairement aux serveurs Tomcat où cette vulnérabilité est maintenant connue et reconnue pour le Tomcat Manager, pour les serveurs JBoss cela est loin d'être le cas d'où l'intérêt de plus en plus prononcé des pirates pour ces serveurs. Là où le problème des comptes par défaut a été corrigé pour Tomcat dans les versions récentes, pour JBoss les interfaces d'administration ne sont même pas protégées par défaut. Lorsqu'elles le sont, le compte trivial admin/admin est créé pour peu que les administrateurs n'aient pas pensé à le modifier.

L'impact serait minime si les possibilités offertes par ces interfaces étaient limitées mais malheureusement c'est généralement loin d'être le cas. Un attaquant ayant accès à l'une de ces interfaces peut récupérer de nombreuses informations concernant le serveur, modifier la configuration « à chaud » voir même déployer ses propres applications web sur le serveur (webshells) lui permettant d'asservir totalement le serveur (y compris le système d'exploitation) à ses besoins. Une fois cet objectif atteint, libre à l'attaquant de rebondir sur d'autres systèmes...

L'objectif de cet article sera donc de montrer d'une part les possibilités offertes à un attaquant face à un serveur JBoss mal protégé puis d'autres part les dispositifs de sécurisation existants afin de se protéger de ce type d'attaques qui peuvent se révéler désastreuses pour une entreprise (vol de données clients, compromission d'une multitude d'équipements via le JBoss, rebond sur un système étranger mettant en cause la responsabilité de l'entreprise...).

Cependant, avant toute chose, il est important de bien comprendre l'architecture interne des serveurs JBoss et plus particulièrement ce que l'on appelle le Java Management Extensions (JMX) qui correspond à la partie la plus intéressante pour un attaquant puisqu'il permet la gestion de l'ensemble des ressources (services, applications...) du serveur. Ainsi, la maîtrise de cet élément permet la maîtrise totale du serveur.

L'article décrira donc l'architecture de cet élément critique au sein d'un serveur JBoss et notamment sa structure en couche:

• Les Mbeans (instrumentation level) qui sont des objets représentant les ressources à proprement dites. Chaque Mbean propose, comme tout objet Java qui se respecte, des méthodes permettant de contrôler la ressource associée.

• Le Mbean Server (agent level) qui fournit aux interfaces d'administration les méthodes des différents Mbeans disponibles. Toute interaction avec un MBean passe par le MBean Server.

Les Mbeans à privilégier lors d'une attaque dépendent des motivations de l'attaquant. Les possibilités sont multiples et l'article final décrira plus précisément les MBeans les plus intéressants du point de vue d'un attaquant. Il existe notamment des MBeans permettant de gérer les mécanismes d'authentification des applications hébergées. Il est donc assez facile d'imaginer, qu'une fois l'accès à ces MBeans possible, le contournement des mécanismes d'authentification devient facile. D'autres permettent le déploiement d'application au format .war, .jar ou .sar par exemple, offrant la possibilité d'insérer des portes dérobées au sein du serveur. Puis finalement, certains permettent l'exécution de scripts BSH (BeanShell), c'est-à-dire du java à la volée, et autant dire que la seule limite sera l'imagination de l'attaquant dans ce cas.

La cible privilégiée des attaquants reste bien sûr le MBean Server qui permet de gérer toutes les ressources (MBeans) disponibles. Une fois la communication avec le MBean Server établie, un attaquant peut mener à bien la compromission du serveur.

Pour communiquer avec le MBean Server, JBoss propose plusieurs interfaces d'administration, ces fameuses interfaces encore trop peu souvent protégées. Ici, l'article fera un inventaire des différentes interfaces d'administration proposées par JBoss. JBoss en dénombre 4 et sont autant de points d'entrée pour un attaquant:

• La JMX console, la plus connue et la cible privilégiée des pirates puisqu'elle permet d'interagir graphiquement avec le Mbean Server et donc l'ensemble des MBeans.

• La web console qui permet, théoriquement, de n'obtenir que des informations concernant la configuration du serveur.

• L'admin console, disponible depuis JBoss 5, qui réunit les fonctionnalités principales de la JMX console et la web console. Elle est très utile notamment pour le déploiement d'applications à distance sur le serveur.

• Le port 4444 qui permet d'interagir par RMI avec le MBean Server.

L'article rentrera ensuite dans le vif du sujet en décrivant, par un exemple simple, comment un attaquant pourra profiter de ces interfaces pour compromettre le serveur. L'article prendra notamment l'exemple du déploiement d'une application à distance sur le serveur JBoss et décrira précisément chacune des nombreuses techniques d'attaque permettant d'atteindre notre but, dont voici un aperçu.

Dans un premier temps, la solution la plus simple sera abordée c'est-à-dire celle de la JMX console. Si l'attaquant a accès à cette interface, le déploiement d'une application ne peut pas être plus simple. La simple utilisation du MBean offrant ce service via l'interface web de la JMX console permet de réaliser l'opération voulue. Il est à noter que le serveur JBoss doit être autorisé à établir une connexion vers l'hôte hébergeant l'application à déployer.

Lorsque cela n'est pas possible, JBoss propose l'exécution de Java à la volée (scripts BSH) via un MBean particulier. Cette technique peu connue par les administrateurs permet facilement de déployer à distance une nouvelle application sans avoir à initier une connexion vers un hôte distant. Cette technique sera décrite précisement par l'article final.

Lorsque la JMX console n'est pas disponible à cause d'un filtrage ou tout simplement lorsque les mécanismes d'authentification ont été mis en place et que le compte par défaut a été supprimé, que pouvons nous faire? Pas de panique, l'ensemble des MBeans peuvent être manipulés via RMI, à condition que le serveur JBoss est activé les composants RMI (activés par défaut à l'installation). Le port par défaut en écoute est le port 4444. Pour communiquer avec ce port la suite JBoss propose un outil appelé Twiddle réalisant les appels RMI pour nous. Il ne nous reste plus qu'à savoir utiliser l'outil pour appeler les méthodes des MBeans cibles. Cependant, l'outil Twiddle étant incomplet, un outil a été développé en interne par HSC, que décrira l'article final, comblant certaines lacunes.

Il arrive également régulièrement que le port 4444 soit filtré par un pare-feu intermédiaire, notamment lors d'une intrusion externe mais tout n'est pas perdu pour autant. Il existe également d'autres méthodes beaucoup moins officielles permettant d'atteindre notre objectif que décrira plus en détail l'article final.

Dans un premier temps, l'attaquant peut utiliser l'interface web console. Cette interface prévue à l'origine pour réaliser de la simple consultation d'information peut en réalité être mise à profit par un attaquant lorsqu'il y a accès. Pour fournir les informations disponibles sur son interface, la web console utilise une servlet particulière. Elle permet d'invoquer des MBeans et cela ne se limite pas aux seuls MBeans que la web console a besoin. Un attaquant ayant accès à cette interface peut communiquer avec cette servlet pour invoquer n'importe quel MBean. Pour cela, il est nécessaire de générer des requêtes HTTP particulières. Un outil a été développé en interne par HSC pour réaliser cette opération est sera décrit ici.

Finalement, si la web console a été sécurisée par un mot de passe par exemple, il reste une ultime solution qui vise à utiliser une servlet installée par défaut sur les serveurs JBoss: JMXInvokerServlet. De la même manière, l'invocation de cette servlet permet d'interagir avec les MBeans à travers le protocole HTTP. Cette dernière méthode est particulièrement utile lors des intrusions externes où seul l'accès HTTP est généralement autorisé. HSC a également développé un outil en interne qui sera décrit ici.

L'article fera un détour sur les serveurs d'application JBoss 5 et 6 qui corrige un certain nombre de vulnérabilités en améliorant sa configuration par défaut rendant certaines attaques difficiles à mettre en oeuvre. Nous nous intéresserons plus particulièrement à l'interface admin console, la nouvelle interface d'administration, et aux techniques permettant de contourner l'authentification de cette interface (mise en place par défaut).

Après avoir décrit les différents angles d'attaque sur un serveur JBoss, l'article décrira les différents moyens de sécurisation qui peuvent être mis en place pour parer ces attaques et plus particulièrement concernant la configuration du serveur JBoss. Les vulnérabilités présentes au sein d'un serveur JBoss sont souvent le résultat d'une configuration trop laxiste et qui est malheureusement celle par défaut.