dimanche 7 décembre 2008

[PENTESTING] JBoss hacking

Avec l'expansion des serveurs J2EE, il y a de bonnes chances d'en rencontrer un pendant un test d'intrusion d'application WEB. Après avoir vu Jonas dans un post précédent, nous allons aujourd'hui nous attaquer à JBoss, 2e plateforme J2EE open source répandue. Pour cela, nous allons nous baser sur la présentation qui a eu lieu lors de la conférence Hack.lu 2008 avec les démonstrations qui vont bien.


1 - Reconnaissance de la cible

Pour savoir si nous avons à faire à une plateforme JBoss, le scan de la cible devrait nous aider. En l'occurrence, les ports 8080 et 4444 devraient être ouverts en TCP :


2 - Les attaques

Entrons directement dans le coeur du sujet. Il existe plusieurs pistes d'attaque que nous allons voir toute de suite.

2.1 - Attaque via la console JMX

On obtient l'interface WEB de JBoss facilement en tapant sur la port 8080 de la cible. Puis cliquer sur le lien "JMX console" pour atteindre notre but :

Dans la nouvelle page, lancer une recherche sur le mot "deployment" et cliquer sur le premier lien ("deploymentScanner") :

Dans cette troisième page :
  • rechercher la fonction void addURL() et dont le ParamType est java.lang.String ;
  • entrer l'adresse où se trouve votre .WAR malicieux dans le champ prévu (ici pentest.war);
  • cliquer sur le bouton "Invoke".
Si tout s'est bien passé, la page suivante devrait s'afficher :

Entrer maintenant l'URL suivante (avec ici nom_commande = cmd.jsp) :
http://<adresse_cible>:8080/pentest/<nom_commande>


La fenêtre qui s'affiche permet de lancer n'importe quelle commande. Il existe aussi d'autres scripts dans le .WAR malicieux qui peuvent permettre la compromission du serveur. Et 1 - 0 ! :)

L'attaque peut ne pas être possible si la console JMX est protégée par un mot de passe. Cependant, n'oubliez pas d'essayer les mots de passe triviaux avant d'abandonner ;)

2.2 - Attaque via le programme twiddle


Nous tentons donc de passer par l'interface RMI qui est présente ici. Pour cela, nous avons besoin du programme twiddle qui fait partie de l'exécutable de JBoss.
twiddle.bat -s hostname_cible invoke "jboss.system:service" deploy "pentest.war"


NB : Ici, pentest.war est dans le répertoire bin de l'attaquant. Sinon, ajouter le chemin.
NB : Vous pouvez aussi utiliser twiddle.sh ou twiddle.jar.

Les résultats obtenus sont les mêmes que pour la première attaque : et 2 - 0 !


2.3 - Attaque via le BSH Deployer

Nous sommes dans le cas où nous ne sommes pas autorisé à initier un flux sortant contrairement à la première attaque (contrôle pare-feu). Ici, nous utilisons un *.WAR malicieux allégé nommé pentest_light.war. Vous allez comprendre très vite pourquoi ...

Tout d'abord, nous allons devoir écrire un petit programme JAVA. Avant cela, il nous faut juste encoder notre .WAR malicieux en base64. Pour effectuer cette opération, il existe des programmes (base64 file > encoded_file.txt sur la backtrack) ou des sites en lignes [exemple ou exemple2].

Nous plaçons le code obtenu dans le programme qui suit. Je précise que je ne suis pas l'auteur de ce code ;) Ce sont les Red Team les boss !

import java.io.FileOutputStream;
import sun.misc.BASE64Decoder;

String val = "<.war malicieux en base64 ici>";

BASE64Decoder decoder = new BASE64Decoder();
byte[] byteval = decoder.decodeBuffer(val);
FileOutputStream fstream = new FileOutputStream("/tmp/pentest_light.war");
fstream.write(byteval);
fstream.close();

1/ Nous devons accéder à la console jmx et rechercher le BSHDeployer :


2/ Nous utilisons la méthode CreateScriptDeployment() avec les paramètres suivants :
  • le script lui-même (attention, supprimer les sauts de ligne) ;
  • le nom de notre script BSH sans l'extension (qui sera concaténée automatiquement).
3/ Une fois que vous avez cliqué sur le bouton "Invoke", le script est présent sur le serveur et a été interprété automatiquement. Notre module pentest_light.war est donc présent sur le serveur. Il ne nous reste plus qu'à le déployer avec une adresse locale :


2.4 - Attaque via la WEB console

Maintenant, nous nous trouvons dans le cas de figure où nous n'avons accès ni à la console JMX (attaques 1 et 3), ni à l'interface RMI (attaque 2).



A suivre ...



Conclusion

JBoss ouvre donc plusieurs voies d'attaque lorsqu'on l'installe par défaut. Il existe plusieurs mesures permettant de renforcer la sécurité de la plateforme J2EE. Elles devront toutes être mises en place pour parer à l'ensemble des menaces :
  • Mise en place d'un mot de passe sur l'interface JMX ;
  • Filtrage au niveau du pare-feu ;
  • Contrôle d'accès (sources) ;
  • Fermeture des ports non utilisés sur le système (ex : interface RMI).
  • Etc.

1 commentaire:

Patrick Hof a dit…

Hi, I'm glad to see you liked the talk we held at hack.lu 08 :). If you want to link to the original slides, they are available at RedTeam Pentesting's Publications website.

Locations of visitors to this page