Exploitation Java RMI Registry
De la reconnaissance au shell root
Write-up pédagogique complet : reconnaissance réseau, énumération de services, exploitation d'une désérialisation Java RMI non authentifiée, établissement d'un canal C2 avec Metasploit, et post-exploitation via Meterpreter. Chaque terme technique est défini au fil du texte.
- 00Contexte & environnement de lab
- 01Fondamentaux théoriques
- 02Reconnaissance réseau (ping sweep)
- 03Énumération des services (scan de ports)
- 04Metasploit Framework & sélection du module
- 05Configuration & lancement de l'exploit
- 06Architecture C2 & session Meterpreter
- 07Post-exploitation
- 08Recommandations de sécurité
Contexte & Environnement de Lab
Ce write-up documente l'exploitation d'une machine Metasploitable 2, une distribution Linux volontairement vulnérable développée par Rapid7 à des fins pédagogiques. Elle est largement utilisée en formation pentest pour s'entraîner légalement sur des vulnérabilités réelles, sans risque juridique.
L'environnement est constitué de deux machines virtuelles sur un réseau interne isolé
(192.168.30.0/24) :
192.168.30.0/24
La commande ifconfig affiche la configuration des interfaces réseau de la machine.
On y confirme l'adresse IPv4 attribuée à l'interface eth0 :
192.168.30.135. Cette IP servira de point de référence pour tout le reste
de l'exploitation — notamment comme adresse d'écoute du canal de contrôle à distance (C2).
Fondamentaux Théoriques
Avant de plonger dans l'exploitation, il est essentiel de comprendre les concepts qui structurent toute intrusion méthodique. Un test d'intrusion (pentest) suit généralement une méthodologie en phases : reconnaissance, énumération, exploitation, post-exploitation, et reporting.
Qu'est-ce que Java RMI ?
Le problème de sécurité exploité ici (CVE-2011-3556) vient du fait que, par défaut, le RMI Registry accepte des appels non authentifiés qui permettent de charger et d'exécuter du code Java arbitraire fourni par le client — sans aucune vérification d'identité. Un attaquant peut donc envoyer un objet malveillant que le service exécutera avec ses propres privilèges.
Le Metasploit Framework
exploit (code d'attaque), payload (charge utile post-exploitation),
auxiliary (scanners, fuzzers), post (modules post-exploitation),
encoder (obfuscation) et nop (générateurs de NOP sled).
L'interface interactive s'appelle msfconsole.
Ce framework élimine le besoin d'écrire un exploit à la main pour chaque vulnérabilité connue : il suffit de sélectionner le bon module, de le configurer, et de l'exécuter.
Reconnaissance Réseau — Ping Sweep
La toute première étape d'un test d'intrusion réseau consiste à identifier les machines actives sur le segment ciblé. On utilise pour cela un ping sweep — un balayage qui envoie une requête à chaque adresse IP possible d'une plage réseau pour détecter les hôtes qui répondent.
-sn désactive le scan de ports et effectue uniquement une détection
de présence (ping scan) — rapide et discret.
nmap -sn 192.168.30.0/24
Le scan révèle 5 machines actives sur le réseau, dont l'adresse 192.168.30.141 —
une IP qui ne correspond ni à la passerelle (.1), ni à notre propre machine
(.135), ni aux adresses d'infrastructure habituelles. C'est notre cible potentielle.
Énumération des Services — Scan de Versions
Une fois la cible identifiée, l'étape suivante consiste à cartographier sa surface d'attaque : quels ports sont ouverts, quels services y écoutent, et surtout quelle version exacte de chaque service est déployée — l'information clé pour rechercher des vulnérabilités connues.
-sV de nmap va au-delà de la simple détection de port ouvert : elle
envoie des sondes spécifiques à chaque service pour identifier précisément le logiciel et
sa version (ex. OpenSSH 4.7p1, vsftpd 2.3.4). Cette granularité
est indispensable pour cibler un exploit adapté.
sudo nmap -sV 192.168.30.141
Le résultat est extrêmement riche : la machine expose 23 services, dont plusieurs sont historiquement associés à des vulnérabilités critiques bien documentées. Voici les entrées les plus significatives pour notre analyse :
| Port | Service | Version | Intérêt offensif |
|---|---|---|---|
| 21/tcp | ftp | vsftpd 2.3.4 | Backdoor connu (CVE-2011-2523) |
| 22/tcp | ssh | OpenSSH 4.7p1 | Version ancienne, peu d'intérêt direct ici |
| 139/445/tcp | samba | Samba 3.X–4.X | Vulnérabilités SMB historiques |
| 1099/tcp | java-rmi | GNU Classpath grmiregistry | RMI Registry non authentifié → RCE (ciblé ici) |
| 1524/tcp | bindshell | Metasploitable root shell | Backdoor déjà ouvert (root direct) |
| 3306/tcp | mysql | MySQL 5.0.51a | Version vulnérable aux injections/bypass |
| 6667/tcp | irc | UnrealIRCd | Backdoor connu (CVE-2010-2075) |
| 8180/tcp | http | Apache Tomcat/Coyote JSP 1.1 | Credentials par défaut, upload WAR malveillant |
Cette diversité de services vulnérables est caractéristique de Metasploitable 2, conçue pour offrir de multiples chemins d'exploitation pédagogiques. Nous choisissons ici de cibler le port 1099 (java-rmi), car il permet une exploitation directe menant généralement à un accès avec les privilèges root — le service RMI de Metasploitable tourne en effet sous cet utilisateur.
Metasploit Framework — Recherche du Module
On lance msfconsole, l'interface en ligne de commande interactive du Metasploit Framework. Elle centralise tous les modules disponibles et fournit des commandes pour les rechercher, les configurer et les exécuter.
La bannière confirme le chargement de la base de modules. On recherche ensuite un exploit
lié au service RMI identifié, avec la commande search et le mot-clé
rmiregistry.
msf6 > search rmiregistry
Le module exploit/multi/misc/java_rmi_server apparaît, avec un
Rank ("classement de fiabilité") noté excellent — le niveau le
plus élevé attribué par Metasploit, signifiant que l'exploit est stable et ne devrait pas
faire planter le service ciblé.
On sélectionne le module avec la commande use, en utilisant soit son index
numérique (use 0) soit son chemin complet.
Configuration & Lancement de l'Exploit
Chaque module Metasploit expose un ensemble d'options configurables. La commande
show options affiche les paramètres requis, leur valeur actuelle et leur
description.
On observe deux blocs distincts : les Module options (paramètres de l'exploit lui-même) et les Payload options (paramètres de la charge utile qui sera livrée après exploitation réussie).
| Paramètre | Rôle |
|---|---|
RHOSTS | Remote Host(s) — l'adresse IP de la machine cible à attaquer |
RPORT | Remote Port — le port du service ciblé (1099 pour RMI, valeur par défaut correcte) |
SRVHOST / SRVPORT | Adresse et port du serveur HTTP temporaire que Metasploit monte pour livrer le payload Java |
LHOST | Listen Host — l'adresse IP de l'attaquant, où la cible devra se reconnecter |
LPORT | Listen Port — le port d'écoute sur la machine attaquante (4444 par défaut) |
On configure la cible avec set RHOSTS, en indiquant l'adresse IP découverte
lors du scan.
msf exploit(multi/misc/java_rmi_server) > set RHOSTS 192.168.30.141
Toutes les options requises sont renseignées. On lance l'attaque avec la commande
exploit.
Architecture C2 & Établissement de la Session Meterpreter
Comprendre l'architecture C2 (Command & Control)
Le payload utilisé ici — java/meterpreter/reverse_tcp — illustre un choix
architectural central dans la conception d'un canal C2 : la direction de la connexion.
initiée par la cible
vers le port 4444
Concrètement, l'exploit RMI livre un petit stager Java à la cible, qui se connecte ensuite
vers le handler (gestionnaire de connexion) démarré automatiquement par
Metasploit sur LHOST:LPORT. Une fois la connexion établie, le stage complet
(Meterpreter) est transféré, et une session interactive s'ouvre.
Le journal d'exécution retrace précisément le protocole d'exploitation :
Une fois la session ouverte, la commande help liste l'ensemble des
Core Commands disponibles — l'interface de contrôle du canal C2 côté
attaquant.
Post-exploitation
Une fois l'accès obtenu, la phase de post-exploitation consiste à explorer le système compromis, confirmer le niveau de privilège obtenu, et éventuellement pivoter vers d'autres ressources internes.
Bascule vers un shell système
La commande shell de Meterpreter fait basculer la session vers un
shell système natif (sh/bash sur Linux) — utile pour exécuter des commandes
Unix classiques directement.
meterpreter > shell
La commande ifconfig, exécutée cette fois depuis l'intérieur de la cible,
confirme l'adresse 192.168.30.141 — preuve que le shell obtenu s'exécute bien
sur la machine Metasploitable, et non localement.
Exploration du système de fichiers
On explore ensuite l'arborescence pour repérer d'éventuelles applications ou données
sensibles, en particulier le répertoire personnel de l'utilisateur par défaut de
Metasploitable, msfadmin.
ls cd home ls cd msfadmin ls cd vulnerable ls
Cette exploration révèle que Metasploitable héberge, sous
/home/msfadmin/vulnerable/, plusieurs autres applications volontairement
vulnérables (TikiWiki, TWiki, configurations Samba et MySQL faibles) — autant de vecteurs
d'attaque supplémentaires pour poursuivre l'entraînement.
Capacités étendues de Meterpreter
Au-delà du shell basique, Meterpreter expose une bibliothèque de commandes stdapi (Standard API) qui illustre bien l'étendue d'un canal C2 mature — bien plus qu'un simple accès en ligne de commande.
| Commande | Fonction |
|---|---|
execute | Exécute un programme arbitraire sur la cible |
getuid | Affiche l'utilisateur sous lequel s'exécute la session (souvent root ici) |
sysinfo | Récupère les informations système (OS, architecture, nom d'hôte) |
screenshot | Capture l'écran de la session utilisateur active (Windows/desktop) |
record_mic | Enregistre l'audio du microphone par défaut pendant X secondes |
keyevent / mouse | Simule des entrées clavier/souris à distance |
Ces commandes illustrent pourquoi Meterpreter est qualifié de payload "avancé" : il ne s'agit plus d'un simple accès shell, mais d'une véritable plateforme de contrôle à distance couvrant surveillance, exécution et manipulation du système compromis — l'essence même d'une architecture C2 opérationnelle.
Recommandations de Sécurité
Cette exploitation illustre les conséquences d'un service d'infrastructure exposé sans authentification. Voici les mesures correctives à appliquer dans un environnement réel.
-
01
Ne jamais exposer le RMI Registry sur un réseau non fiable. Le port 1099 ne devrait être accessible que depuis des hôtes explicitement autorisés, via un pare-feu ou une liste de contrôle d'accès stricte.
-
02
Mettre à jour vers une version de Java corrigée. Le correctif de CVE-2011-3556 introduit un filtrage des classes chargées via RMI — appliqué depuis les versions Java patchées post-2011.
-
03
Ne jamais faire tourner un service réseau en tant que root. L'impact de cette faille est démultiplié par le fait que le service RMI de Metasploitable s'exécute avec les privilèges maximaux — un principe du moindre privilège aurait limité les dégâts à un compte non privilégié.
-
04
Segmenter le réseau et limiter la surface d'attaque exposée. 23 services ouverts sur une seule machine est un cas extrême (volontaire ici), mais rappelle l'importance de désactiver tout service non strictement nécessaire.
-
05
Déployer une détection réseau (IDS/IPS). Un trafic RMI inhabituel suivi d'une connexion sortante vers un port arbitraire (comme 4444) est un indicateur de compromission détectable par des règles de corrélation réseau basiques.