tunneling a meterpreter session

[gelim]

Hi guys,

I understand it's a project that has not moved since a long time, but maybe you still will read this. I'm trying to tunnel a meterpreter session through reDuh.

The stage1 that need to load the big meterpreter blob is listenning locally on the server under control to port 4444. I use reDuh to connect my local meterpreter control machine to this server's local socket, the blob seems sent properly but after the upload nothing is happening.

Log of reDuhClient is the following:

[...]
[Info]Localhost ====> 127.0.0.1:4444:1 (2500 bytes read from local socket)
[Info]Localhost ====> 127.0.0.1:4444:1 (2500 bytes read from local socket)
[Info]Localhost ====> 127.0.0.1:4444:1 (2500 bytes read from local socket)
[Info]Localhost ====> 127.0.0.1:4444:1 (2500 bytes read from local socket)
[Info]Localhost ====> 127.0.0.1:4444:1 (2500 bytes read from local socket)
[Info]Localhost ====> 127.0.0.1:4444:1 (2410 bytes read from local socket)
[Info]Localhost ====> 127.0.0.1:4444:1 (77 bytes read from local socket)
[Info]Caught data with sequenceNumber 1
[Info]Caught data with sequenceNumber 2
[Info]Caught data with sequenceNumber 3
[Info]Caught data with sequenceNumber 4
[Info]Caught data with sequenceNumber 5
[Info]Caught data with sequenceNumber 6
[Info]Caught data with sequenceNumber 7
[Info]Caught data with sequenceNumber 8
[Info]Caught data with sequenceNumber 9
[Info]Caught data with sequenceNumber 10
[Info]Caught data with sequenceNumber 11
[... skip this infinite incrementing...]

Maybe you have an idea about the root of the problem, or where to look at? Cheers,

-- Mathieu

[staaldraad]

Hi Mathieu

I don't have too much experience with reDuh, could I suggest you try reGeorg - it's the successor to reDuh and is actively maintained.

The usage would be more or less the same, except you would set a proxy in Metasploit:

set Proxies socks4:127.0.0.1:8888

cheers, Etienne

[gelim]

Hi Etienne, actually coming from reGeorg had the problem, as you mentionned tested with set Proxies msf command, and as well with proxychains ./msfconsole. Same behavior with a different log, but basically as long as it's not a simple socket exchange (like doing a proxychains curl or proxychains nc to check open port) there is this socket problem. I will try to debug the code a bit more... I'm still unsure what msf is doing in the background with the socket.

[staaldraad]

Was worried you might say that :) Was worth a shot getting around the issue with reGeorg.

I'll have to setup a test instance of reDuh to play with, in the meantime I'll mention a few things that have worked with reGeorg in the past. Although I'm pretty sure these are things you've already tried.

1) meterpreter bind shell 2) enable stage encoding

I know there were a few other tricks used in the past, I'll have to try find my notes

[gelim]

Yeah using linux/x64/meterpreter/bind_tcp. I feel there is something cheesy during the recvfrom(size=mettle_size) made by the stage1.

About stage encoding I'm not sure it has something to do with the problem. I tried out of interest x64/zutto_dekiru but doesn't change anything.

(without JSP socks, that's working like a charm)

[gelim]

So after some debugging the problem is arising after the first read(sockfd, *newmmaped_rwx_mem, 0x7e) (0x7e is the size of the stage1 that will bootstrap Mettle via an mmap + rcvfrom + jmp *%rsi).

After the syscall for read(), the shellcode jumps to the new mmaped location where should be our stage1 with 0x79 bytes. The problem is that there is a SEGFAULT at %rsi + 1 (beginning of stage1) and from the debug info I can see %rax == 0x3. So we read only 3 bytes on the stage1 and jmp to it.... The client (msfconsole) is properly sending the data unmangled.

I don't know why with reDuh the shellcode can read only 3 bytes when asking for 0x7e.