Upload d'une backdoor jsp depuis la console JMX de JBoss

Il arrive parfois de rencontrer des serveurs JBoss dont la console JMX traine nonchalamment sur le réseau derrière un port 8080.

En accédant à l'url suivante http://url_jboss:8080/jmx-console vous pouvez accéder à cette console fort pratique, et au travers du Mbean service=BSHDeployer sous jboss.deployer, vous pouvez créer à loisir un script BeanShell. Et ce n'est pas les exemples qui manquent sur internet (Google est votre ami :) ).

Grâce au Beanshell vous pourrez créer et copier une JSP au bon endroit (ex: le répertoire de la console JMX) et ainsi exécuter des commandes sur le serveur au travers de la JSP !!!

Cependant la taille est limitée...

Voici quelques liens si vous souhaitez explorer plus en détail les diverses techniques associées à la console JMX :

http://www.nruns.com/_downloads/Whitepaper-Hacking-jBoss-using-a-Browser.pdf
http://www.notsosecure.com/folder2/2009/10/27/hacking-jboss-with-jmx-console/
http://carnal0wnage.blogspot.com/2009/11/hacking-unprotected-jboss-jmx-console.html

Happy hacking !!!

Sécurité des applications FLEX/AMF

Les applications riches (RIA) posent de nouveaux problèmes aux pen-testeurs, car on se retrouve face à un client lourd, dont le code source n'est pas aussi accessible que peut l'être le Javascript (modulo l'obfuscation ;) ).

Le client lourd en environnement WEB à un premier effet pervers sur le développeur : l'impression de contrôler les actions du client, ce qui s'accompagne d'un relâchement des contrôles coté serveur.

Et là, c'est le drame !!!

Car le flash peut être décompilé et analysé à l'aide d'outils comme SWFScan d'HP.
les requêtes flex (au dessus d'HTTP) peuvent être analysées à l'aide de Burp,
et bien sur, il est possible d'interagir avec la partie serveur à l'aide de librairies AMF comme pyAMF :D

Happy Hacking !

OpenVPN sous Debian Lenny

En environnement professionnel on a souvent besoin d'accéder au réseau de l'entreprise de manière directe... Nous avions déjà parlé de SSL-Explorer qui permet via un client "léger" (une applet JAVA) d'accéder a des services situé dans le réseau interne d'une entreprise. Cependant les VPNs SSL malgré leur forte augmentation doivent répondre a des contraintes assez importantes notamment pour la connexion vers le S.I. de l'entreprise. En effet le VPN SSL a besoin comme point d'entrée la plupart du temps une connexion sécurisée sur le port 443. Ce qui n'est pas forcément facile si l'entreprise possède qu'une seule IP d'entrée et des services déjà disponibles sur ce port.

C'est ce type de contrainte qui me fait préférer le déploiement "ultra-rapide" d'un VPN SSL "lourd". Aujourd'hui dans l'esprit de la plupart des personnes VPN SSL est synonyme de VPN léger accessible depuis un navigateur. Mais ce n'est pas forcément vrai... et OpenVPN est la pour le prouver. La contrainte essentielle d'OpenVPN est qu'il nécessite un client et qu'il ne s'adapte pas à toutes les typologies de réseau : un certain port doit être ouvert, et non les ports les plus couramment utilisés comme 80, 443...

La commande clé :

aptitude install openvpn

Le reste (la configuration) est suffisamment bien décrit ici (exemple sur Etch mais fonctionne sur Lenny) : Coagul.

Il faut garder à l'esprit que la machine OpenVPN va devenir "un routeur" de l'extérieur vers le réseau interne. Il est nécessaire de bien filtrer les flux depuis et vers cette machine. Il très recommandé d'installer un filtrage IPTables sur la machine. Le firewall Shorewall me semble tout indiqué pour ce type de filtrage rapide.