Comprehensively refactor Windows reverse_http stagers

[hdm]

The reverse_http* stagers for Windows are inconsistent and need to be refactored to keep things sane.

• windows/reverse_http: This stager supports up to 5 byte URIs, but doesn't support specific proxies, pstore-based authentication, or SSL.
• windows/reverse_https: This stager supports up to 5 byte URIs and SSL (with invalid certificates) but doesn't support specific proxies or pstore-based authentication.
• windows/reverse_https_proxy: This stager supports up to 5 byte URIs and SSL (with invalid certificates) and specific proxies, but not pstore-based authentication.
• windows/reverse_http_proxy_pstore: This stager supports up to 5 byte URIs and pstore-based authentication, but not specification of the proxy server, nor SSL.
• windows/x64/reverse_https: This stager supports up to 5 byte URIs, but doesn't support specific proxies, or pstore-based authentication

In addition to the existing stagers, we have also have two pending PRs that are related: #4716 (reverse hop) and #4608 (winhttp).

In the current model, there is a startup penalty for using Metasm to generate payloads. Additionally, payloads must always return a static size, or it can break exploit matching. These currently make it optimal to create a new stager per feature and to always use static blobs instead of dynamic generation.

Fixing this requires two small changes to the framework:

1. Land PR Implement payload size caching, speeding up framework loads #4894, which removes the startup penalty of dynamic payload generation, and speeds up loading times.
2. Land PR Tell payloads and encoders how much space they have to work with #4876, which allows payloads to support optional features depending on how much space is available. In the exploit use case, only those features that can fit within the available size will be available, but when generating external payloads (such as EXEs), those limits go away and the full feature set should be available.

Once these two PRs are landed (both backwards-compatible), the refactoring work can start.

Prerequisites:

• Land PR Implement payload size caching, speeding up framework loads #4894 (payload size caching)
• Land PR Tell payloads and encoders how much space they have to work with #4876 (size-aware payloads and encoders)

WinInet rework (Windows/x86):

• WinInet Refactor: Port all existing HTTP(S) features into a mixin that can selectively enable features based on configuration parameters and return Metasm-compatible assembler.
• Refactor reverse_https to be size-aware, use the new mixin, and expose options to enable specific features.
• Refactor reverse_http using reverse_https as a base and without SSL support.
• Land PR Refactor x86 Windows reverse_http and reverse_https stagers #4904 (refactored reverse_http(s) stagers)
• Implement reverse_http(s)_proxy features in the new payloads. PR Adds proxy (with authentication) support to reverse_http(s) #4934
• Implement reverse_http(s)_proxy_pstore features in the new payloads
• Remove duplicate stagers reverse_https_proxy and reverse_https_proxy_pstore
• Rework PR Add new reverse_hop_https stager #4716 to use the new Metasm stagers as a base
• Implement control over User-Agent and other settings

WinHTTP implementations (Windows/x86):

• WinHTTP Refactor: Use HTTP stager based on WinHttp #4608 as a starting point to create a new set of mixins that use WinHTTP as the backend API (versus WinInet). Leverage existing code blocks from the WinInet payloads to add features where possible.
• Add the reverse_winhttp and reverse_winhttps stagers.
• Land PR HTTP and HTTPS stagers based on WinHttp #4914
• Implement and land SSL verification for WinHTTP. PR SSL certificate verification for reverse_winhttps stager #4930
• Implement proxy and proxy_pstore() functionality
• Implement control over User-Agent and other settings

Add 64-bit versions of the x86 stagers:

• Implement x86_64 payloads for WinInet reverse_http(s)
• Implement x86_64 payloads for WinHTTP reverse_http(s)

[pyrohaz4good]

Thanks for adding on "Implement control over User-Agent and other settings"

[hdm]

This is still alive, just waiting on a PR from @OJ for 64-bit support before I pick up the ball again.

[OJ]

Definitely me dragging the chain here but I'm close!

[hdm]

Recap on status; everything is complete, except for:

• pstore() support is not implemented in the new reverse_http(s) payloads, these are out of scope for now, but can be ported over in the future.
• reverse_hop payloads are broken in master, these may need a redo from scratch, but are out of scope for now.
• user-agent control is almost done, just waiting on Added ECHOUA URI request type to reflect victim UA string #4984

[OJ]

Damn, I thought we'd handled the user-agent stuff in the stagers already, but clearly we haven't. Crap. I had intended to do this while working on the stagers earlier this year.

I'm happy to work on pulling this in, and making sure the wiring of MeterpreterUserAgent is complete in both reverse_http and reverse_winhttp. If an agent isn't give, we can fallback to the shortest to keep the payload size down. Want me to take that bit?

[hdm]

@OJ Go for it! The big missing piece is stage2 either doing one of the following based on option:

• Use the UA sent in the first request (default)
• Pick a UA at random from the set
• Use a specified UA

[fsacer]

@OJ @wvu-r7 can you check what's missing from this, if nothing this should get closed

[OJ]

The UA stuff still hasn't made it into HTTPS stagers.

[xkill]

Some IPS/Proxy blocked content when it cannot detect the type of content in responses, so it will be great to add a specific encoder to send the responses with a "content-type" header (for example text/plain) and content encoded in base64, or as image, include the first X bytes of a real image (to bypass magic numbers).