This is a fix for crap and stupid stuff that I did half way through the
packet pivot code. I was working on some priv stuff at the same time,
and when I realised that the work I was doing was not sensible as part
of the packet pivot PR, I failed to revert my changes properly.
As a result I broke `getprivs` and `getsystem`. I am sorry. And I'm
ashamed.
This commit adds MSF-side support for listing currently loaded drivers
on the machine that Meterpreter is running on. It doesn't add a UI-level
command at this point, as I didn't see the need for it. It is, however,
possible to enumerate drivers on the target using the client API.
Also, the capcom exploit is updated so that it no longer checks for the
existence of the capcom.sys file in a fixed location on disk. Instead,
it enumerates the currently loaded drivers using the new driver listing
function, and if found it checks to make sure the MD5 of the target file
is the same as the one that is expected. The has is used instead of file
version information because the capcom driver doesn't have any version
information in it.
There has been Meterpreter work done as well to support this. But this
commit allows for a new 'getsid' command which tells you the sid of the
current process/thread. This can be used for things like determining
whether the current process is running as system. It could also be used
for golden ticket creation, among other things.
The call to `getenv` failed when `%` or `$` were used because of the
differences between Meterpreter handling and MSF handling.
Meterpreter effectively ignores (ie. strips out) the platform-specific
characters which are used for environment variables. In the `getenv`
call, MSF was invoking `getenvs` and getting a full hash of values, then
attempting to index into the hash using a string which may be "polluted"
with those platform-specific characters. This meant that there was a
discrepency between what was returned and what was used to index and
as a result, the value would come out as `nil`.
For example, calling `getenv('%FOO%')` would result in a hash with
`{'FOO'=>'bar'}`, so looking for '%FOO%' in this result would yield
nothing.
This commit changes this so that the name is ignored and the first
value is returned.
The getenv call in sys/config was renamed to getenvs and now uses
the splat operator so that arrays don't have to be passed in. A
new function called getenv was added which takes a single argument
and returns a single value back (for ease of use).
This command will allow the attacker to grab environment variables from the
target, if they exist. Calling this function allows for one or more values
to be passed in, which should match the name of the variable required. If
the variable is found, it is returned. If it is not found, the variable
is not returned (ie. it's not present in the resulting hash).
Note 1: POSIX environment vars are case-senstive, whereas Windows is not.
Note 2: POSIX doesn't seem to cough up user environment vars, it only returns
system vars. I'm not sure why this is, but it could be because of the way
we do linking on POSIX.
Spencer McIntyre