This commit includes a new module that allows for payloads to be
uploaded and executed from disk while bypassing AppLocker in the
process. This module is useful for when you're attempting to generate
new shells on the target once you've already got a session. It is also
a handy way of switching between 32 and 64 bit sessions (in the case of
the InstallUtil technique).
The code is taken from Casey Smith's AppLocker bypass research (added in
the references), and includes just one technique at this point. This
technique uses the InstallUtil feature that comes with .NET. Other
techiques can be added at any time.
The code creates a C# file and uploads it to the target. The csc.exe
compiler is used to create a .NET assembly that contains an uninstaller
that gets invoked by InstallUtil behind the scenes. This function is
what contains the payload.
This was tested on Windows 7 x64. It supports running of both 32 and 64
bit payloads out of the box, and checks to make sure that .NET is
installed on the target as well as having a payload that is valid for
the machine (ie. don't run x64 on x86 OSes).
This appears to work fine with both staged and stageless payloads.
This patch updates the ie_unsafe_scripting exploit to use the
BrowserExploitServer mixin in order to implement a JavaScript check.
The JS check allows the exploit to determine whether or not it is
in the poorly configured zone before firing.
It also adds another datastore option to carefully avoid IEs that
come with Protected Mode enabled by default. This is even though
IE allows unsafe ActiveX, PM could still block the malicious VBS or
Powershell execution by showing a security prompt. This is not ideal
during BrowserAutopwn.
And finally, since BAP2 can automatically load this exploit, we
bump the MaxExploitCount to 22 to continue favoring the
adobe_flash_uncompress_zlib_uninitialized module to be on the
default list.
Resolves#6341 for the purpose of better user experience.
This commit fixes issues with specifying "rhost:rport",
replacing them instead with "peer". Also, a couple of
"Unknown" errors were replaced with "UnexpectedReply".
This module takes advantage of an authenticated HTTP RCE
vulnerability to start telnet on a random port. The module
then connects to that telnet session and returns a shell.
This vulnerability is present in version 2.01 of the firmware
and resolved by version 2.12.