This is my write-up for TryHackMe’s Binex Room
Using nmap, we see that SSH and SMB are running on the target.
The hint showed that the longest username in RID range 1000–1003 has an insecure password. We then run enum4linux to enumerate the users.
Using hydra, we can get the password.
Connecting via SSH using the credentials we found, we can run find to search for files with SUID bit set.
From the results, we see that the /usr/bin/find has its SUID bit set.
From gtfobins, we can use find to escalate privilege.
We find ourselves running as user des! Looking at the home directory, we see flag.txt and an executable bof and its corresponding bof.c source code. Also, we find that bof actually belongs to user kel and that its SUID bit is set. We can use this to pivot to become kel.
I find it easier copying bof onto my attack machine rather than running gdb on the target (Just a matter of preference and also because I have gdb-peda installed on my system). Let’s see what happens when we send too much data to it.
It turns out it is susceptible to buffer overflow exploitation!
Through trial and error, we find that the program crashes with an input of 700 characters.
However, RIP is not overwritten here.
If we take a look at the registers, we find RSP is pointing to the user buffer.
We can use RBP to compute for the offset to the RIP for this case here.
The above means that the offset to RIP overwrite is 608 + 8 bytes. We can test this by:
Using gdb, we can send eip.txt to bof.
RIP is not overwritten as we hoped. However, RBP is overwritten as expected though.
We find bof wants to return to the RSP (“CCCCCCCCCC”).
The reason why RIP is not 0x4343434343434343 is because most of the addresses are 6-bytes and not 8. Let’s try reducing the number of “C”s.
So now we know that RIP can be overwritten! We also know that prior to the return, the RSP is 0x7fffffffe1b8. We can have a very large NOP sled at the start of the buffer. Let’s try with the following script:
We then test this out as follows:
As shown above, execution breaks at the int 3 instruction!
Using the provided shellcode and tweaking the original script a little, we get:
And running this on the target, we get:
Looking at /home/kel directory, we find a file named “exe”. Looking at the source code, we see that exe calls “ps”. We can manipulate the PATH variable such that it calls a file we own.