Fix#6658.
When there is no service pack, the
Msf::Exploit::Remote::SMB#smb_fingerprint_windows_sp method returns
an empty string. But in the MS08-067 exploit, instead of check an
empty string, it checks for "No Service Pack", which causes it to
never detect the right target for Windows Server 2003 SP0.
Powerhell provides direct interface to WMI, allowing users in UAC
or otherwise restricted context to attain privileged resources via
impersonation. Moreover, WMI allows for execution remotely, on any
endpoint attainable via DCOM. In practice, this allows foothold on
a single domain host to immediately infect every machine accessible
via DCOM either from the currently held privileged context (such as
a domain administrator) or from a new context generated by entering
acquired credentials.
Payloads, remote commands, and collection activities can be invoked
without direct IP connectivity on a remote host, and output can
be collected the same way.
Of particular note when implementing this technique is that admin
contexts resulting from this form of execution are not encapsulated
in UAC, allowing for immediate privesc to system if creating a new
session.
Old notes show that loopback exec is not stable or usable, though
this merits further research as it seems the native way to avoid
UAC altogether without any exploitation.
As with all the other powershell vectors, this mechanism provides
in-memory execution, and in all our testing walks right through the
AV currently out there since it has no service executable, on-disk
footprint, or even error log from the improper service exit that
psexec causes. Sandboxes dont cover powershell - too much runtime
entropy and some quite legitimate use of sockets and unmanaged
memory marshalling to get a good "guess" of what the code is trying
to do.
Makes for a great gift left behind in GPO startup scripts or other
latent backdoor approaches. Since a script is produced, those with
the need and craft can alter the resulting scripts to dynamically
enumerate domain hosts meeting their needs for exploitation at
runtime, as opposed to the "brute-force" approach used here.
-----
Testing:
The internal module has been in use for over three years in our
fork. Its been instrumental in showing several clients what it
means to be "pwned" in 30s flat. This particular version has been
slightly altered for upstream consumption and should be tested
again by community and developers alike in the upstream branch.
Note:
Word to the wise on target selection - choose carefully, it is
possible to generate more sessions than an L3 pivoted handler can
comfortably address, and having a thousand reverse_tcp sessions
going past the edge is sure to raise an eyebrow at the SOC.
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.
504137480