VulnHub: Lampião: 1
Difficulty: Easy

This lab was a little bit more difficult than the last one but still relatively easy. I did end up using two non-default Kali scripts. There are probably tools prebuilt into Kali that achieve the same function, but was still able to get root on this machine.

As with any labs, first step is to run the good ol’ trusty nmap to see what ports we have that are open and potentially usable to gain access and actually find the target on my network. In doing this it was found that SSH, HTTP and a random port 1898 was open.

On port 80 was a simple HTML page, a nikto scan revealed nothing of worth. Port 1898 was also a webserver, this how ever had a nice little Drupal install.

Running the non-Kali standard CMSmap script, Drupal was outdated and vulnerable to Drupalgeddon 2 and 3, Drupalgeddon 2 in its own is own is enough to give us a shell on the server.

So setup metasploit to use this and gained access to a shell under the www-data user.

Next we were able to see there was a user ‘tiago’ by running cat on /etc/passwd.

There didn’t appear to be any easy way to gain access to this user (no nice little password files :() but checking uname -a and running the string through the non-kali default linux-exploit-suggester shows us it was susceptible to the dirty cow exploit.

Now that we know we have a way to set the password of the root user, we use searchsploit to find the source code of the exploit and check the first few lines after copying the source to a temporary directory (this tells us the recommended way to compile and run the exploit on the target machine).

Now, we exit out of the shell we previously had and back to the meterpreter command line to upload the source file to the server. Then we can jump back into a shell to compile and run the code.

The error is fine because we don’t have a standard shell. So far we have changed the root password, but now we need to see if we can access ssh with the user root.

Sadly, SSH is set to deny root as a login. Looking at the source code for the exploit how ever, we should be able to modify source code #define ROOTID “root:” to be tiago instead of root. With the change made, the new source uploaded and run in the www-data shell, we were present with exactly the same output. This time how ever we can SSH to  the server as tiago.

As we now know the root password from the first run of the exploit, all that was needed to get access to root and the flag was a simple su – command.