So after making changes for MSIE modules (see #3161), I decided to
take a look at all MS modules, and then I ended up changing all of
them. Reason is the same: if you list modules in an ordered list
, this is a little bit easier to see for your eyes.
since the IO redirection hangs our original process
we have the moudle wait for the session then kills
the spawning process and delete the exe we dropped
Stacks of modules were using `extract_path` where it wasn't really semantically correct
because this was the only way to expand environment variables. This commit fixes that
up a bit.
Also, I changed the existing `getenv` function in `stdapi` to `getenvs`, and had it
support the splat operator. I added a `getenv` function which is used just for a
single variable and uses `getenvs` behind the scenes.
The meterpreter console `getenv` command now uses `getenvs`
Now broken into two modules, one for loading RDI DLLs off disk and
finding the loader function offset, and another for doing the process
specific stuff of loading into the target.
MSF was starting to see more modules using RDI to load binaries into
remote processes, so it made sense to create a mixin which contained
the functionality that was being used in various locations.
This commit contains the new mixin, and adjustments to all the existing
exploits and modules which use RDI.
I had inteded to add the `WfsDelay` as Meatballs suggested, but for locl
exploits this doesn't appear to work as expected. After speaking to HDM
we've decided to leave the sleep in there and figure out the `WsfDelay`
thing later.
This also includes a slight refactor which puts the payload and the
exploit in the same chunk of allocated memory. Minor optimisation, but
worth it.
This commit contains a few changes for the ppr_flatten_rec local windows
exploit. First, the exploit binary itself:
* Updated to use the RDI submodule.
* Updated to build with VS2013.
* Updated to generate a binary called `ppr_flatten_rc.x86.dll`.
* Invocation of the exploit requires address of the payload to run.
Second, the module in MSF behaved a little strange. I expected it to create
a new session with system privs and leave the existing session alone. This
wasn't the case. It used to create an instance of notepad, migrate the
_existing_ session to it, and run the exploit from there. This behaviour
didn't seem to be consistent with other local exploits. The changes
include:
* Existing session is now left alone, only used as a proxy.
* New notepad instance has exploit reflectively loaded.
* New notepad instance has payload directly injected.
* Exploit invocation takes the payload address as a parameter.
* A wait is added as the exploit is slow to run (nature of the exploit).
* Payloads are executed on successful exploit.
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.
This will give the option to drop an exe or use psh if uac is turned
off. The lib can be used for post exploitation to drop an exe or use
powershell and then execute it with the runas command. I have used the
lib for both bypassuac and ask.
The method checks to see if the user is a part of the admin group. If
the user is the exploit continues, if not the exploit stops because it
will prompt the user for a password instead of just clicking ok.
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
Added fail_with instead of just print_error
figured a way to execute the cmd_psh_payload with out using gsub
added case statment for datastore['TECHNIQUE']
Gives you the ability to use powershell to 'ask' for admin rights if the
user has them. Using powershell makes the pop up blue instead of orange
and states that the company is Microsoft, it also doesn't drop an exe
on the system. Looks like 32 bit https works but if you migrate out you
loose priv and if you run cachedump the session hangs.
Meatballs
William Vu
kaospunk
RageLtMan
Tod Beardsley
sinn3r
OJ
kyuzo
David Maloney
jvazquez-r7
Spencer McIntyre
b00stfr3ak
James Lee
jvazquez-r7
MrXors