JBoss Application Serveur (JBoss AS) est un serveur d’application Java EE open-source. JBoss AS a été développé par JBoss, c’est désormais une division de Red Hat. Fin 2012, JBoss AS a pris le nom de WildFly.

Une poussée de l’exploitation d’une faille des serveurs web fonctionnant grâce au JBoss AS a récemment été détectée par le centre de recherche ADC (Application Defense Center) d’Imperva, probablement due à la divulgation publique d’un code d’exploitation d’une vulnérabilité. Par Barry Shteiman, Directeur de la Stratégie de Sécurité chez Imperva

Cette faille permet à un hacker d’accéder à l’interface de gestion JBoss AS afin de déployer des fonctionnalités additionnelles sur le serveur web.

Dès l’instant où le hacker déploie cette fonctionnalité additionnelle, il prend le contrôle de l’infrastructure exploitée en JBoss et, par conséquent, du site fonctionnant grâce au serveur d’application.

Bien que cette faille ne soit pas une nouveauté (elle est connue depuis au moins deux ans), il est surprenant de constater que durant ces années, sa surface d’attaque ne faiblit pas, mais qu’au contraire, elle croît, en termes de nombre d’applications web vulnérables.

Historique de l’incident

En 2011, une faille JBoss AS avait été révélée lors de conventions de Sécurité. Des chercheurs ont montré que JBoss AS était vulnérable lorsqu’une commande à distance était effectuée via le service ‘HTTP Invoker’ (qui fournit l’accès Remote Method Invocation (RMI)/HTTP à l’Enterprise Java Beans (EJB)).

En septembre 2013, le NIST (National Institute for Standards and Technology) avait assigné un code d’exploitation profitant d’une faille dans certains produits HP qui utilisaient JBoss AS avec un “Common Vulnerability Enumeration” (CVE-2013-4810).

Le 4 octobre 2013, un chercheur en sécurité a rendu le code d’exploitation publiquement disponible. Immédiatement après, nous avions constaté une poussée soudaine ayant pour objectif de hacker JBoss AS. Cela s’est manifesté par un trafic malveillant provenant des serveurs infectés et observé par les « honey pots » d’Imperva.

L’analyse technique du code d’exploitation

JBoss AS est vulnérable lorsqu’une commande à distance est effectuée via le service ‘HTTP Invoker’ qui fournit l’accès Remote Method Invocation (RMI)/HTTP à l’Enterprise Java Beans (EJB).

Les Java Beans sont des composants réutilisables pour Java et sont identifiés comme un Objet Java en série. MBean, qui signifie Managed Bean, est un type de Java Bean. javax.management.ObjectName correspond au nom d’objet d’un MBean.  Les MBeans sont souvent utilisés au sein de la technologie Java Management Extensions (JMX). Java Management Extensions (JMX) est une technologie Java qui fournit des outils pour gérer et surveiller des applications, des objets système, des appareils et services réseau. Ces ressources sont représentées par des MBeans.

JMX utilise une architecture à trois niveaux :

• Le niveau Probe qui contient MBeans
• Le niveau Agent, ou MBeanServer, est le coeur de JMX. Il agit comme un intermédiaire entre le MBean et les applications.
• Le niveau Remote Management permet aux applications à distance d’accéder au MBeanServer au travers de connecteurs et d’adaptateurs. Un connecteur fournit un accès total à distance au MBeanServer API tandis que l’adaptateur traduit les requêtes entre un protocole donné (i.e. HTTP, RMI) et une fonctionnalité spécifique JMX. L’Invoker fait appel au service MBean correspondant basé sur la requête JMX existante.

Figure 1 Architecture JMX

Le Detached Invoker permet aux services MBean d’exposer des interfaces fonctionnelles via des protocoles arbitraires pour permettre aux clients d’y accéder à distance. Le service HTTP Invoker , incluant EJBInvoker et JMXInvoker, comprend une servlet qui traite des posts d’objets rassemblés (en série) org.jboss.invocation.Invocation. Ces objets représentent des invocations qui devraient être dispatchées sur le MBeanServer. En réalité, cela permet d’accéder aux MBeans qui soutiennent l’opération du Detached Invoker via les requêtes HTTP POST.

La faille est constituée d’un accès public HTTP aux servlets EJBInvokerServlet ou JMXInvokerServlet, représentées respectivement sous la forme d’URL /invoker/EJBInvokerServlet et /invoker/JMXInvokerServlet, et invocation du MainDeployer MBean. Le MainDeployer MBean est responsable du déploiement d’un WAR à partir d’un emplacement à distance.

Le code d'exploitation récemment publié, s’introduit dans l’invoker/EJBInvokerServlet afin de déployer un code web shell qui permet au hacker d’exécuter des commandes arbitraires du système d’exploitation sur le système du serveur de la victime.

Figure 2 Code d’exploitation

Le code d’exploitation se décompose en deux étapes :

Lors de la première étape, le code d’exploitation s’introduit à travers l’EJBInvokerServlet afin de déployer l’application web malveillante ARchive (WAR) depuis l’URL à distance http://retrogod.altervista.org/a.war qui inclut le code shell ”a/pwn.jsp”.

Figure 3 Une capture réseau de l’injection web shell malveillante comme reproduite dans le laboratoire d’Imperva

Lors de la seconde étape, le code d’exploitation envoie une commande de système d’exploitation au web shell injecté.

Figure 4 Une capture réseau des commandes envoyées à l’injection web shell malveillante comme reproduite dans le laboratoire d’Imperva

Au coeur du code d’exploitation

Bien que ce problème particulier de sécurité JBoss AS soit connu de la communauté des professionnels de la sécurité depuis plusieurs années, il est surprenant de constater que durant ces années la surface d’attaque n’avait pas faibli, mais s’était en fait étendue en termes de nombre d’applications web vulnérables.

Le nombre de serveurs exposant leurs interfaces de gestion JBoss avait plus que triplé (7000 à 23000) depuis que la faille a été découverte en 2011.

Figure 5 Interfaces de management JBoss exposées - Octobre 2013 (Google Dork ici)

Figure 6 Interfaces de gestion JBoss exposées – 2011

La liste des sites exposés comprend des sites gouvernementaux et éducatifs. Nous avions identifié certains d’entre eux comme étant vraisemblablement infectés avec un code web shell.

De nombreux web shell déployés utilisent le shell code original pwn.jsp qui a été présenté avec le code d’exploitation original, comme on peut le voir sur un billet de blog  posté par l’une des victimes des attaques.

Dans d’autres cas, un web shell plus puissant a été déployé. Dans ces circonstances, les hackers avaient utilisés le web shell JspSpy qui inclut une interface utilisateur plus riche, permettant aux hackers de naviguer facilement au travers des fichiers et des bases de données infectés, de se connecter à l’aide d’une commande à distance et de contrôler les serveurs pour déployer les logiciels malveillants de pointe.

Figure 7 Interface utilisateur JspSpy

Recommandations et Atténuation

• Les utilisateurs de JBoss devraient renforcer leur application web selon le manuel JBoss
• Les clients d’Imperva ont été informés par le biais d’une signature de quelle façon ils pouvaient empêcher l’accès indésirable à la faille servlet JBoss AS via les mises à jour régulières de contenu.

Barry Shteiman, Directeur de la Stratégie de Sécurité chez Imperva