Vaccine (Tier 2)
Last updated
Was this helpful?
Last updated
Was this helpful?
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
With this and a little research, I answered the first questions
Answer: ftp
Answer: anonymous
Then I did an exhaustive scan to learn more about the services running on the open ports
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
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
With this and a little research, I answered the next questions
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
I saw it worked successfully recovering the password 741852963 and after trying again I could decompress the file and extract its content
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
With this and a little research, I answered the next questions
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
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
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
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
With this and the previously found user flag, I answered the next questions
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
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
With this, I got the root flag and pwned the machine
Answer: dd6e058e814260bc70e9bbdef2715849
I started doing an initial port scan using
To learn more about the HTTP protocol you can go
To learn more about the FTP protocol you can go
So I tried cracking the password helping me with the 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
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 and fortunately gave me the value of qwerty789 for the password
To learn more about MD5 and other hashing methods you can go
To learn more about Cross-site Scripting (XSS) technique you can go
To learn more about SQL Injection (SQLi) you can go .
So to make faster the process for abusing this vulnerability, I used 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
To make sure, I tried looking at the petition sent when I used the search engine, using and . 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
As the shell given by sqlmap is limited, I tried gaining a Reverse Shell to my machine through the os-shell, setting a 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
To learn more about how to create a script for a Reverse Shell you can go , and to learn about the sanitization process you can go
To learn more about the SSH protocol you can go
To learn more about the sudo abuse for privilege escalation you can go
