Remote Exploit. Shellcode without Sockets

Clever. Is something like that possible on windows?

1 Like

AFAIK there is no direct equivalence to this on Windows. I’m pretty sure it should be possible to reuse the existing connection but I bet the process would probably be pretty different… but I do not know how. Maybe some of the windows guy can provide some details.

Woah, this is so clever! Awesome tutorial once again, might use this for the Ret2libc tut ^^

2 Likes

Thank you @py! This is a very good read. I do have some questions though.

system = 0x8048380
exit = 0x80483a0
system_arg = 0x80485b5 

He obtains these addresses by doing a hex dump of the binary. The only way he could do this would be if he already had shell access? This would never work for a remote exploit? Or would it?

I’m really interested in this but I need to grasp memory concepts a little more. May give your dynamic linker post another read through, I could do with going through Pico’s wannabe tutorials as well just to reinforce the basics.

1 Like

@pry0cc: The link is indeed not aimed at a scenario like the one @0x00pf presented. I linked it to you so you can get a general idea on how some of the modern exploit mitigations can be bypassed. The funny thing is that IoT/embedded devices barely manage to implement any of the aforementioned mitigations.

As for the dynamic linking stuff, I’ll try to write a few more posts on it from an exploit dev perspective once my exams are over.

3 Likes

Well, you need to have a local version of the program to exploit. I do not think you can write a exploit against a service without having access to the service itself and some details of the system. You have to get the program somehow (using some other flaw or getting it from other server with lower security) or use your recon phase to gather enough information (OS version, service version, compiler, etc…) to rebuild a “close-enough” version of the service to develop the exploit whenever the service is publicly available (open source project for instance).

I’m not 100% sure but I do not think you can develop a remote exploit without some kind of access to the binary. If anybody know about any technique to achieve that I’m interested in knowing more :slight_smile:

4 Likes

Ohhhhhhhh! I didn’t realise the addresses were the same in every binary. That’s dope. Okay thanks.

1 Like

Your sentence is a bit stronger that what I suggested.

I meant that, as far as the system configuration is the same (OS version, libc version, compiler version…) in two different machines. Compiling the same source will produce the same binary. I do not know if what you said is true… never checked it.

2 Likes

Right. So if you could obtain the same binary as them, then it will be the same?

1 Like

I would say so for most of the cases. Somebody can rebuild the binary with special linker flags that mesh up the memory.

Check the last section to see an example on how to relocate the text segment via linker flags. In that case you also need the Makefile, however I do not believe that happens very often.

2 Likes

Hi there. When I wrote this trick I had in mind it was not theorically valid, which led me not to propose an implementation for Metasploit for example. Hence, as an exploit coding fan, I suggest to rather use this shellcode for challenges and ROP your way for concrete and accurate socket-reuse exploits.

Also, if I may add something, the interests of such attacks are 1/ obviously that it’s stealthier regarding potential monitoring, and 2/ that as it uses an established channel initiated as in a classic client-server case, so coupling it with TOR seems easy as hell :wink:

8 Likes

Hi @zadyree,

Thanks for passing by our site and for that great trick. I was really amaze when I read your code in shell-storm!. Actually it took me a while to realise what it was doing :sweat:

Haven’t thought about TOR. That is a very good point.

6 Likes

Hi @0x00pf!

I think I found a small typo.

I found your shell command to generate shellcode didn’t work, it just produced a tonne of binary jibberish, this is the revised version that worked for me (I just escaped the first \ on the echo -n).

for i in $(objdump -d rsh.o -M intel |grep "^ " |cut -f2); do echo -n '\\x'$i; done;echo

Hi @pry0cc

It may be due to your shell. According to man page for echo

    (...)
    \xHH   byte with hexadecimal value HH (1 to 2 digits)

   NOTE: your shell may have its own version of echo, which usually supersedes the version described here.  Please refer to your shell's docu‐
   mentation for details about the options it supports.
   (...)

In may system with bash I get two slashes with your version. But it is very good you spotted as other people may have had that problem as well

4 Likes

Man this article has a lot of viwss

I wonder why, pry0cc :wink:

Hi there! I’m new around here. I tried to follow this tutorial and it sort of worked out. It generates the shell but immediately after it finishes the child process (which is /bin/dash), why is that?

Thanks!

Hi @p3rla,

Thanks for following the tutorial and for your feedback.I have seen that happening some time ago. As far as I remember it happens when you mix up 32bits and 64bits code. In those cases you need to do some extra work to invoke the system call. I’m not sure if I took notes from those tests but I’ll let you know if I found them.

I have running it with dash (my /bin/sh is a link to /bin/dash) and it was working fine.

To know more about how the mixing on 32bits and 64bits code works I recommend the two following brilliant articles. Specially part 2 explains how this mix is managed by Linux.

Hope this helps

Thank you very much for you response! You are actually right, I’m mixing 32bit and 64bit.
I’ll take a look at these articles :slight_smile:

1 Like

This topic was automatically closed after 30 days. New replies are no longer allowed.