Capture the Flag: Raven. Part 1

Raven is a Capture the Flag (CTF) that runs as a virtual machine. The benefits of this are first, that as you hack Raven, you don’t have to worry about accidentally shutting something down – it’s a virtual machine with no other software on it; and second, you actually have to find the machine on your network, giving you some practice in network assessment.  I ran Raven on VMWare, attacking from a Kali Linux box, also on VMWare.

Finding the target:

Since I didn’t have an ip for Raven, my first step was a quick network scan.   I turned to nmap for this.  Since I knew that Raven includes a website, it seemed reasonable to scan for any machines with ports 80 (http) and/or 443 (https) open:

sudo nmap 192.168.159.0/24 -p80,443 -Pn

In this case, I didn’t need to use sudo, which runs nmap with administrator privileges, but nmap does require sudo for some of its scan types and I slipped up and added it.  No harm done.

nmap, of course, runs nmap, the network mapper, and this is followed by the CIDR range of my home network.

The p flag (option)n tells namp to only look at ports 80 and 443.  By default, nmap looks at 100 ports on each host; trimming the list to two ports sped things up.  If I had remembered whether Raven hosted its website on http or https, I could have eliminated one of those ports and sped things further, but with a small network (and no intrusion detection system (IDS)) the benefits would have been minimal.

Pn tells nmap to skip pinging hosts to see if they’re live.  In practice, hosts can be told not to respond to pings, meaning that lack of response to a ping doesn’t prove the lack of a host at that address.  A flurry of pings can also set off an IDS.  Suppressing pings causes nmap to proceed as if it successfully received a ping from every host on the network – i.e. it fully scans every address, whether there’s evidence of a host at that address or not.  Depending on the complexity of the scan and the size of the network, this can greatly add to the work nmap has to do, and thus the time it take nmap to complete, which the program warns you of when you use this flag.  Here, I had a small network and a simple scan, so the time burden was minimal.

Nmap returned five hosts. One was the ip for my attack box (the machine I was attacking from).  It is possible to tell nmap to skip the attack ip, but the extra keystrokes would have taken more time than it would have saved.  Of the other four, only one had an open port 80 or 443.  As a bonus, the MAC address is noted as VMWare, though MAC addresses can be spoofed.

Since port 80 was the open port, simply dropping that ip into my web browser of choice proved that this was indeed my target, as the Raven website popped up.

Assessing the Target:

Now that I had a website, let’s take a look at it.   Much of the site isn’t actually fleshed out – the links lead nowhere.  At the bottom of the home page, however, there is a list of blog posts which lead to a different nowhere.  Instead of leading right back to the page they start on (a # link), clicking on a blog entry yields an error:

Apache 2.4.10, huh?  Pretty outdated.  There should be some good exploits available here.

Adding this to my notebook, I kept going.  The bottom of the page contains a live link to colorlib, which provides website templates and WordPress themes  Perhaps there are known flaws in some of their products.?

Also at the bottom of the page there is a text entry field for visitors to enter their email addresses to stay abreast on Raven’s latest news.  A quick entry of a single quote yielded no peculiar results, but there could be something here on further investigation.

The About Us, Service, and Team pages yielded nothing of note, but the blog page liked out to a Wordpress blog. This page took about a minute to load, and came up as a mess.  Either someone did a really bad job coding here, or (more likely) the page isn’t loading properly.

Viewing the source code reveals the answer. There are three dns prefetches. Two look to be sites on the web, but the third (the first, actually, line 10, to raven.local) looks like an address stored on the same server as the web page.

A quick Google search tells me that dns prefetches are hints to a web browser that resources will be requested form a particular location, so making a connection with that server now will save time when the resource is actually requested.  Searching the web page’s source code shows 27 times where resources are requested from raven.local (not shown).  This looks to be the problem: the browser can’t find the resources that are stashed at raven.local.  No DNS lookup can provide this address; I need to tell the browser that these resources are located locally.

Doing so is via the /etc/hosts file.  Here, I’ve added Raven’s ip and the text ‘raven.local.’  When the computer wants to access a domain, it will first look here to resolve the domain name to its ip address; adding this line tells the computer where raven local is.  At the same time, I could add a line stating that 129.168.159.140 is “target”, so that I could substitute “target” for the ip for the rest of this engagement.

Note that /etc/hosts is rewritten every time the computer reboots, so changes here aren’t permanent.  I edited the file using nano – note that this file is write-restricted – I needed to edit with root privilege to be able to change the file (sudo nano /etc/hosts).

Saving my updated /etc/hosts file and reloading the blog generated a clean, properly loaded site, and enabled me to easily find the login page.

NOTE: In this write-up, I have included images of the Raven website. This website is copyright protected. However, I believe that the use of low-resolution images, used for the purposes of educating users about the site, is acceptable "fair use" of this material. If the copyright holder wishes me to remove these images, please comment on this post, including a method for replying.

Next Post