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]
Tested in the following configurations:
* WinXP SP0 x86 - reverse_http, reverse_tcp, ms08-067, ms03-026
* Win7 x64 fully patched - reverse_https, reverse_tcp, x64/reverse_tcp
Tested with all public extensions. Behaviour matches that of the currently released MSF.
x64 binaries no longer show up in auto-complete for x86.
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.
In IE8 standards mode, it's possible to cause a use-after-free condition by first
creating an illogical table tree, where a CPhraseElement comes after CTableRow,
with the final node being a sub table element. When the CPhraseElement's outer
content is reset by using either outerText or outerHTML through an event handler,
this triggers a free of its child element (in this case, a CAnchorElement, but
some other objects apply too), but a reference is still kept in function
SRunPointer::SpanQualifier. This function will then pass on the invalid reference
to the next functions, eventually used in mshtml!CElement::Doc when it's trying to
make a call to the object's SecurityContext virtual function at offset +0x70, which
results a crash. An attacker can take advantage of this by first creating an
CAnchorElement object, let it free, and then replace the freed memory with another
fake object. Successfully doing so may allow arbitrary code execution under the
context of the user.
This bug is specific to Internet Explorer 8 only. It was originally discovered by
Orange Tsai at Hitcon 2013, but was silently patched in the July 2013 update, so
no CVE as of now.
If the date and time preference pane is locked, effects are:
1. systemsetup takes 30 seconds to return
added a 30-second timeout to cmd_exec
2. Unable to change system date and time settings
added additional check to see if date change was successful
jvazquez-r7
Tod Beardsley
dummys
xistence
Rick Flores (nanotechz9l)
Meatballs
OJ
James Lee
Brandon Turner
Ryan Wincey
sinn3r
Joe Vennix
MosDefAssassin
HD Moore
Tyler Krpata