This updates the packet header so that the encryption byte flag is now
32 bits. This also updates the powershell and python extensions so that
both of the bindings work correctly as a result of the TLV packet header
changes.
Make the XOR key an array of bytes as a start to normalise the way the
XOR happens across the board. Given that we're going to be adding
encryption to the packet level and adding more stuff to the packet
header, now is the time to fix this up once and for all.
Crypto context stuff appears to have only ever been supported in
Meterpreter on Windows. The only thing it allowed for is XOR, which is
redundant given that we have packet level XOR in place. Also, it would
appear that MSF didn't have support for it anyway!
With the move torwards packet-level encryption, this is unnecessary so
it needs to go bye bye.
The last issue we had in removing the OpenSSL library from Windows
meterp is making it so that reconnects would behave. With a staged
listener, the first thing that gets sent down the wire is metsrv.dll. As
a result, when a fully staged connect comes in (whether it be from
a stageless payload, from a transport switch or from a sleeping session
waking up), Meterpreter needs to handle the case that the data coming
down the wire is no actually a TLV packet, and hence ignore it.
This "hack" abuses the properties of the XOR key for the packet,
relying on the fact that the XOR key will never contain NULl bytes and
that the first 4 bytes from a staged listener starts with the length of
the metsrv DLL, which is small enough to result in a NULL byte in the
MSB position.
If we see a NULL byte in that position, we assume it's the metsrv header
coming in, and we just ignore it and move on. If the XOR key looks
legit, we assume it's a valid TLV packet.
Dirty, but it's quick and it works!
This commit fixes the case where we incorrectly assume that the URIs
used in the transport don't make use of the LURI setting in MSF.
The bug was that the code iterated through the URI string in reverse,
looking for a slash and then using that as the point to patch the new
URI over the existing. This meant that with the LURI parameter used, the
actual LURI field was missed, and the patch would result in the LURI
value appearing again.
The fix put in iterates from the start of the string and looks for the
third instance of the slash. This means that the LURI field is patched
as well as the UUID section.
Fixes#197
As part of b50955a92476e797256158db783ba9684db2a902 important code that
sent UUIDs along with each request was accidentally removed. This PR
re-includes it so that the UUIDs are in fact sent when they should be
sent.
This fixes issues where UUID commands don't work, and fixes migration in
a bunch of scenarios.
This commit will result in SSL cert failures causing failovers to other
transports, even to itself, instead of shutting the session down. This
will result in repeated calls back to the endpoint, every "retry wait"
seconds, and will continue to do so until the session expires, or the
SSL verification works.
Be warned, this can be noisy in your console if you haven't configured
things properly. The result is a lot of callbacks over the life of the
session.
We are currently inconsistently handling errors in recv() when flushing data from a TCP socket. In one case, we handle the graceful close, but not the error case. In the other, we handle exactly the opposite.
Both of these loops may spin indefinitely depending on the recv value from the remote server. In one, if the TCP connection is abruptly closed in stageless meterpreter or on a transport switch, the flush function may loop. In the other, if the remote server does a socket shutdown, but not a close, we will also loop.
