search

rapid7 / mettle

This is an implementation of a native-code Meterpreter, designed for portability, embeddability, and low resource utilization.
422 stars 122 forks source link

I use mbedtls to compile curl files by default to support multiple tls encryptions including ECDH #229

Open archieKern opened 2 years ago

archieKern commented 2 years ago

I use mbedtls to compile curl files by default to support multiple tls encryptions including ECDH.

Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02e) Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 (0xc026)

Only 6 tls encryption methods are supported when performing mettle and ECDH is not supported.

Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)

timwr commented 2 years ago

https://github.com/rapid7/mettle/blob/master/deps/mbedtls-config.h#L23

Can you provide a bit more information about what you're trying to achieve?

archieKern commented 2 years ago

https ECDHE algorithm does not work, suggest a fix

archieKern commented 2 years ago

https://github.com/archieKern/mettle/blob/master/make/Makefile.mbedtls

timwr commented 2 years ago

How are you reproducing this? I assume we include a minimal mbedtls configuration to reduce the size. Why do you need the ECDHE algorithm? HTTPS Domain Fronting?

clapbr commented 2 years ago

FWIW I've been proxying my listeners with redacted commercial WAF/CDN solution and stumbled upon this problem with mettle specifically. Python and Java meterpreter work fine under this setup, but of course, they're relying on interpreter TLS implementation.

As it is, Mettle fails at SSL handshake due to lack of a matching algorithm. Not sure if there are other use cases not specific to the proxy solution I'm using but I'd blindly guess other proxy set-ups might encounter similar issues.

edit: as OP suggested, enabling all algorithms on mbedtls fix this but additional overhead on payload size might be undesirable as timwr said. In the case I tested the file size difference was negligible, but it's just my single use case.

Another possible solution is to find a compromise and enable some but not all TLS algorithms. Current algorithm choice is very limited AND unusual for nowadays, which makes it prone to easier fingerprinting with it's SSL supported ciphers and thus easier detection by border IPS/IDS. Just like some WAFs detect you're using Burp if you don't change default ciphers.

smcintyre-r7 commented 2 years ago

If it's the size of the stage, a large increase in size would be fine. Stages / stageless payloads are supposed to be arbitrarily sized. If it's the stager though, that'd affect compatibility with a bunch of exploits.

clapbr commented 2 years ago

If it's the size of the stage, a large increase in size would be fine. Stages / stageless payloads are supposed to be arbitrarily sized. If it's the stager though, that'd affect compatibility with a bunch of exploits.

In the case of linux/x64/meterpreter_reverse_https there is no staged alternative AFAIK, only reverse_tcp has a staged version.

My final elf file went from 1037272 bytes to 1106168, so a ~68Kb difference.