OverTheWire.org - Behemoth - Level 5 Writeup

We start by running the code

behemoth5@behemoth:~$  /behemoth/behemoth5
behemoth5@behemoth:~$ 

Nothing happens.
Retry with ltrace:

behemoth5@behemoth:~$ ltrace  /behemoth/behemoth5
__libc_start_main(0x804872b, 1, 0xffffd784, 0x8048920 <unfinished ...>
fopen("/etc/behemoth_pass/behemoth6", "r")                                                       = 0
perror("fopen"fopen: Permission denied
)                                                                                  = <void>
exit(1 <no return ...>
+++ exited (status 1) +++

Mmmmh. It exits due to permission denied reading the password file!
Reason being the fact that ltrace drops privileges

 Let's disassemble with gdb (cutting out non interesting parts while keeping only the sequence of function calls)

behemoth5@behemoth:~$ gdb /behemoth/behemoth5
...
(gdb) disassemble main
Dump of assembler code for function main:
   0x0804872b <+0>:     lea    0x4(%esp),%ecx
...
   0x08048750 <+37>:    call   0x80485b0 <fopen@plt>
 ..
   0x08048785 <+90>:    call   0x8048540 <fseek@plt>
...
   0x08048793 <+104>:   call   0x80485a0 <ftell@plt>
... 
   0x080487a8 <+125>:   call   0x8048520 <rewind@plt>
...
   0x080487ce <+163>:   call   0x8048500 <fgets@plt>
 ...
   0x080487f4 <+201>:   call   0x8048510 <fclose@plt>
   0x080487f9 <+206>:   add    $0x10,%esp
 ...
   0x08048804 <+217>:   call   0x8048600 <gethostbyname@plt>
 ...
   0x08048838 <+269>:   call   0x80485f0 <socket@plt>
....
   0x080488d1 <+422>:   call   0x80485d0 <sendto@plt>
...

We have no way to get to interesting code running it in gdb because it fails with permission denied.

But from the sequence of function calls it seems that it

1. opens the password file
2. moves inside it (fseek), 
3. retrieve position (ftell),
4.  goes back to its beginning (rewind), 
5. reads from file (fgets) 
6. get an host IP address from name (probably localhost ?)
7. open a socket 
8. sends some data to the socke
9. we are not able to execute but we can use strings on the executable:

behemoth5@behemoth:~$ strings  /behemoth/behemoth5
..
/etc/behemoth_pass/behemoth6
fopen
localhost
gethostbyname
socket
1337
...

Note that 1337 number just after socket string: maybe it's a port that it sends data to...
Let's open another session and use netcat to listen on port 1337

behemoth5@behemoth:~$ nc -l   -p 1337 127.0.0.1

Nothing! Let's try using UDP instead of TCP

behemoth5@behemoth:~$ nc -l -u  -p 1337 127.0.0.1
m*******e

And, yes, we got it!