Four modules updated for the weekly release with minor cosmetic fixes.
- [ ] See all affected modules still load.
- [ ] See all affected modules have expected `info`
Note that there are some cases of host-endian left, these
are intentional because they operate on host-local memory
or services.
When in doubt, please use:
```
ri pack
```
This reverts commit 9b35b0e13a.
This should not land on master until the Metasploit Pro folks (@trosen-r7
and friends) get their Meterpreter path specifications working the
same way as Framework's does.
When initializing the db:
/opt/metasploit-framework/modules/payloads/singles/cmd/windows/reverse_powershell.rb:34:in `initialize': uninitialized constant Msf::Handler::ReverseTcp (NameError)
from /opt/metasploit-framework/lib/msf/core/payload_set.rb:198:in `new'
from /opt/metasploit-framework/lib/msf/core/payload_set.rb:198:in `add_module'
from /opt/metasploit-framework/lib/msf/core/module_manager/loading.rb:72:in `on_module_load'
from /opt/metasploit-framework/lib/msf/core/modules/loader/base.rb:207:in `load_module'
from /opt/metasploit-framework/lib/msf/core/modules/loader/base.rb:271:in `block in load_modules'
from /opt/metasploit-framework/lib/msf/core/modules/loader/directory.rb:58:in `block (2 levels) in each_module_reference_name'
from /opt/metasploit-framework/lib/rex/file.rb:127:in `block in find'
from /opt/metasploit-framework/lib/rex/file.rb:126:in `catch'
from /opt/metasploit-framework/lib/rex/file.rb:126:in `find'
from /opt/metasploit-framework/lib/msf/core/modules/loader/directory.rb:45:in `block in each_module_reference_name'
from /opt/metasploit-framework/lib/msf/core/modules/loader/directory.rb:29:in `foreach'
from /opt/metasploit-framework/lib/msf/core/modules/loader/directory.rb:29:in `each_module_reference_name'
from /opt/metasploit-framework/lib/msf/core/modules/loader/base.rb:264:in `load_modules'
from /opt/metasploit-framework/lib/msf/core/module_manager/loading.rb:118:in `block in load_modules'
from /opt/metasploit-framework/lib/msf/core/module_manager/loading.rb:116:in `each'
from /opt/metasploit-framework/lib/msf/core/module_manager/loading.rb:116:in `load_modules'
from /opt/metasploit-framework/lib/msf/core/module_manager/module_paths.rb:56:in `block in add_module_path'
from /opt/metasploit-framework/lib/msf/core/module_manager/module_paths.rb:55:in `each'
from /opt/metasploit-framework/lib/msf/core/module_manager/module_paths.rb:55:in `add_module_path'
from /opt/metasploit-framework/lib/msf/base/simple/framework/module_paths.rb:14:in `init_module_paths'
from /opt/metasploit-framework/lib/msf/ui/console/driver.rb:228:in `initialize'
from /opt/metasploit-framework/msfconsole:148:in `new'
from /opt/metasploit-framework/msfconsole:148:in `<main>'
This stager looks for proxy credentials in windows protected storage. If it finds proxy credentials, it will use them to connect back. If it does not find credentials, it will do the same as stager_reverse_http.
Works on:
- Windows Server 2003
- Windows XP
- Internet Explorer versions 4 to 6
This will make copy-pasta less painful in the future. There's still the
problem of reverse_https_proxy being very similar, but the logic in how
it gets generated in the module is more than i want to tackle right now
This avoids zalgo. Also optionally checks the return value
of the compiled Function in XSS to allow you to use send()
or an explicit return, which is maybe more natural for
synchronous xss payloads.
* Project system updated to VS 2013.
* Clean builds, had to remove a bunch of warnings.
* `make.bat` for building from the command line.
* Removed RDI stuff that shouldn't be there any more.
* Renamed the x86 DLL to include the platform name.
* Moved shortlink to a reference.
* Reformat e-mail address.
* Fixed whitespace
* Use multiline quote per most other module descriptions
Still need to resplat the modules, but it's no big thang to do that
after landing. Also, References do not seem to appear for post modules
in the normal msfconsole. This is a bug in the UI, not for these modules
-- many payloads would benefit from being explicit on their references,
so may as well start with these.
This change updates the proxy handler code, which for some reason was
ommitted in the orginal commits. This now uses the same mechanism as
the new code. It removes `HIDDENHOST` and `HIDDENPORT`, and instead
uses `ReverseListenerBindHost` and `ReverseListenerBindAddress`.
According to the Ruby style guide, %w{} collections for arrays of single
words are preferred. They're easier to type, and if you want a quick
grep, they're easier to search.
This change converts all Payloads to this format if there is more than
one payload to choose from.
It also alphabetizes the payloads, so the order can be more predictable,
and for long sets, easier to scan with eyeballs.
See:
https://github.com/bbatsov/ruby-style-guide#collections
It appears that testing of the original submit was performed
on VMWare which worked. On a non virtualized machine the
payload would crash.
[Closes#2373] [FixRm #8271]
This makes x86 more consistent with x64.
Also replaces a bunch of instances of:
File.join(Msf::Config.install_root, 'data', ...)
with the simpler
File.join(Msf::Config.data_directory, ...)
[See rapid7/meterpreter#19]
Meterpreter Error: Uninitialized Constant Error Prevents a 32bit Meterpreter session from migrating to a 64bit process.
Discovered: September 9th 2013
Fixed: September 11th 2013 By MosDefAssassin
Contact:ara1212@gmail.com
Tested on Windows 2008 R2 SP1 Running as a Domain Controller
Issue:
An issue has been discovered when you have created a simple 32bit windows/meterpreter/reverse_tcp payload and have launched the payload on the victim to obtain a remote meterpreter session. While in this session you attempt to migrate your 32bit process over to a 64bit process in order to take advantage of tools like hashdump or mimikatz or obtain system level access under a 64bit process that runs as system such as dns.exe. However when you attempt to migrate to a 64bit process you receive the following error:
Error running command migrate: NameError uninitialized constant Msf::Payload::Windows::ReflectiveDllInject_x64
Cause and Resolution:
This issue occurs because the meterpreter.rb file that is being called from within
“/opt/metasploit/apps/pro/msf3/modules/payloads/stages/windows/” folder
does not contain the following classes:
require 'msf/core/payload/windows/x64/reflectivedllinject'
require 'msf/base/sessions/meterpreter_x64_win'
Once you add these two classes to the meterpreter.rb file, you will be able to migrate to 64bit processes from a basic msfpayload generated 32bit meterpreter payload.
AnwarMohamed
Tod Beardsley
HD Moore
Chris Doughty
Christian Mehlmauer
sinn3r
jvazquez-r7
Meatballs
joev
William Vu
Spencer McIntyre
Tom Sellers
Tim Wright
Michael Messner
James Lee
Daniel Miller
root
somename11111
OJ
Sagi Shahar
scriptjunkie
Niel Nielsen
Geyslan G. Bem
jvazquez-r7
Joe Vennix
xistence
Ryan Wincey
RageLtMan
MosDefAssassin
Tab Assassin