Tweak the SSL implemention so that for https meterpreters the SSL certificate is validated against a hash that is specified in the payload. If the hash isn't specified, then certificate validation isn't attempted.
metsrv now makes use of the METERRPETER_URL for stageless payloads. This value is checked when Meterpreter starts to determine what should be done with communications. If the URL indicates that the payload is stageless, it then establishes communications appropriately, depending on the configuration.
This commit contains a bunch of code tidying (formatting, spaces, naming, etc) as well as new exports for each of the modules so that the extension can be identified. The plan is for the loader to know which modules are loaded so that when stageless meterpreter fires up MSF can query the existing extensions and load the appropriate functionality on the client side.
By making this a static _inline, it is not necessary to guard it, since
an inline is only instantiated if it is used. This also allows adding
one-off debug message for use during debugging sessions, without turning
on DEBUGTRACE all over the place.
Convert a few of the extensions to also do this as well, making them perhaps
slightly smaller.
I am curious why Windows builds define debug this way, vs posix that
just includes it in common.c. Could I just do that instead, assuming
there's no historical reason.
Finally, correct the docs in the posix version of real_dprintf.
- try to share some bits between different makefiles, make modifying
global compiler flags not such a huge pain.
- directly specify we should be using the gold rather than bpf linker
- make compiler output largely quiet except where we care - allow
warnings to actually be visible
- don't delete downloaded tarballs with --really-clean
- add missing dependencies between libraries
(--no-add-needed/--no-copy-dt-needed-entries causes lots of trouble)
- update readme to show what to install to build
I made minimal changes to the loader makefile - it breaks easily.
-Os prevents if from being able to load libc, for instance
source/common/arch/win/i386/base_dispatch.c was referring to:
see '/msf3/external/source/shellcode/x86/migrate/migrate.asm'
which was updated to:
see '/msf3/external/source/shellcode/windows/x86/src/migrate/migrate.asm'
and see '/msf3/external/source/shellcode/x64/migrate/migrate.asm'
was updated to:
see '/msf3/external/source/shellcode/windows/x64/src/migrate/migrate.asm'
In some cases this extension would crash. This was due to the code using the
incorrect "length" variable when dumping LSA data. This commit includes addition
of some debug output, removal of other debug output, and changing of the
kiwi-specific debug definition.
Another packet function was added to aid in construction of this fix, and the
group packet function was added to one of the calls.
The create thread functionality would work in all cases except where
the thread was being created in an x64 process from an x86 process.
This commit adds support for this by reusing the wow64 injection code
in this case.
A group packet is a special packet that is to be used as a group of TLVs that
will live under another packet. Using this functionality means that we can
easily nest groupings of data to arbitrary depths, which wasn't something we
were able to do before easily.
The MSF side is easily capable of handling this scenario, but this side had
always been lacking.
The clipboard dump code has been updated to show how this can be used.
Previous commits removed the stack size parameter from the remote thread
creation function call. This caused issues in systems prior to Vista/2k8.
This fix puts that value back in and now everything is honky dory.
Tested on 2k/XP/2k3/Vista/7/2k8
In a previous commit, I rejigged the way commands were overloaded,
and added what appeared to be a micro-optimisation to prevent
the thread from being imperonsated twice. Ultimately it wouldn't
make any differnce, so why I put it in there I really don't know.
The optimisation actually resulted in a breakage in the case where
base commands weren't present but extension commands were. As a
result all extended commands didn't get impersonated unless they
were overloading. This is not a good thing at all.
This fix removed that total stupidity and restores some level of
sanity.
Apologies for my idiocy.
This is a seprate extension because the old Mimikatz supports more
operating systems, while the new Mimikatz has more features for
less operating systems.
A few minor issues around formatting collisions, nothing huge.
.gitignore fixes too
Conflicts:
source/common/base_dispatch_common.c
source/extensions/stdapi/server/stdapi.c
I felt into the C progrmmer's trap of accidentally using `=` instead of `==`. This is
not good. Good catch @jlee-r7.
This commit fixes this, swaps the values around and tidies up code a bit.
The work that was done a while back to fix up command dispatching allowed
inline commands to run so that the server could be told to shutdown. Those
commands that want the server to terminate (such as migrate and shutdown)
should have returned `FALSE` instead of `TRUE` to tell the server thread to
stop.
I have no idea why those values were incorrect, but it's my work so it's
definitely my fault. I will have to sick back and lick my wounds for a while.
I hate it when I'm stupid.
Thanks to Kevin Mitnick for the bug, and @todb-r7 for the investigating the
history.
Redmine: [FixRM #8696]
In previous work done during the command refactor the mechanism for overriding
commands changed such that it wasn't invoking commands if they were overriden
by an extension. This, it would appear, broke some stuff. Badly.
This commit fixes this issue by reinstating the way things were done before.
If a base command exists, it is always executed. If an extension also exists
which overrides this command then the base command result is ignored, the
extension command is executed, and the result of that command is returned.
