* No badgers were harmed in the creation of this blog *

** Not intended to diagnose, treat, cure, or prevent any disease
**

Saturday, January 21, 2023

Capture the Flag: Raven, part 2

First Post (Last Post)

Last time, I left off during Open-Source Intelligence (OSINT), having looked through most of Raven’s website, found their blog, edited my /etc/hosts file to enable their blog to properly load, and finally loaded up their blog in my web browser. There is another page to the website: Contact. This page looks to have been left unchanged from the template used in creating the site, as it includes contact info specific to Bangladesh, including two phone numbers and a physical address. There is also a Google Maps display that didn’t properly load until I had clicked on it a few times, and a form to submit data. Opening up Burp Suite, I discovered that the form submits to the site’s ip on port 80 via POST request. Allowing my submission to go through revealed that there is no obvious outcome from submitting the form.

So far, there are two obvious avenues of attack: the WordPress blog and the outdated server software. Note that Wordpress isn’t inherently unsafe. Rather, it’s often misconfigured in an unsafe manner.

There may be more to find. So far, I’ve limited my nmap scan to ports 80 and 443. Running it against other ports might yield further information and/or confirm what I’ve already found. I’m also allowing BurpSuite to crawl the site, having set guardrails on it to not scan anything outside of my target’s ip. From this, I found the image library. Here I found several flags (i.e. national flags), probably used for setting the user’s language or location. I note that the first flag is Canadian. Perhaps the site was set up in Canada? Bangladesh’s flag is number 7. There are also a series of images of children, which I didn’t find on the site itself and seem incongruous for a security company; and a disturbing image of a child clown doll. I hope it’s a doll. None of the images show any sticky notes in the background, which might contain usernames and/or passwords. There is an image of a firefighter, but their service (e.g. city) is cropped out. Though the image is likely a stock photo, it might have indicated sources of passwords. Similarly, the main background photo contains an officer. Her uniform contains chevrons, suggesting ranks like those of the military (two stripes would be a corporal). Another image appears to be from Dublin, which might be a source of passwords, including their sports teams. In truth, all of the images here are probably stock images, but in a real engagement there might be valuable information among the dross.

There is no robots.txt file. These files direct web crawlers not to explore or index particular pages. This can be done to shield portions of the site from the search engines powered by the web crawler. From an offensive standpoint, this is a bit like saying “ignore the man behind the curtain,” so evaluating the contents of a robots.txt file can be useful OSINT. Robots.txt files can also be used to alert legitimate crawlers of spider traps (see https://en.wikipedia.org/wiki/Spider_trap).

Any web page’s source is visible by right-clocking and choosing ‘view source’ (or similar) form the contextual menu that pops up. Typically, the browser menu also offers a method, and a shortcut key is [CTRL] + [U]. Looking through the source code, at first I only note some spelling errors. There are also irregularities in the capitalization of the rem lines (comments). These suggest a certain amount of sloppiness went into crafting the site, which may have carried over into its security posture.

One of the flags, it turns out, is hidden in the source code. I’ve whited out part of it – if you want the flag, you’ll have to find it yourself.

 

The source of the WordPress page contains about 150 lines of viewboxes and paths in a format I’m unfamiliar with. I’ll note it down, but given that I already have an outdated Apache Install and a WordPress site, hopefully I won’t need to figure this out. The Contact page’s source code reveals nothing of import, though I am again struck that the phone number on the top right of the page does not match the phone number in the Contact area of the page.

I can also run a more complete nmap scan:

sudo nmap 192.168.159.140 -sC -sV -O -Pn -p- -oA raven1

Here, I’ve directed nmap to limit its attention to the target ip, rather than spreading itself over my entire subnet. I’m also scanning with ‘usual’ scripts (-sC), scanning for software versions (-sV), scanning for operating system and version (-O), suppressing ping as before, scanning all ports (-p-) and directing the output to be saved to files with name “raven1”.

I find four open ports:

·         port 22, running OpenSSH 6.7p1 Debian 5+deb8u4 (protocol 2.0)

·         port 80, running Apache 2.4.10

·         port 111, running rpcbind 2-4 (RPC # 100000)

·         port 58053, status 1 (RPC #100024). This port is also mentioned in association with port 111.

Port 111 is a well-known-port for remote procedure calls (RPC). There may be something here, as there are known exploits for the RPC function.

Considering now the Apache Server, the RPC functions, and the WordPress blog as potential avenues, WordPress feels easier.

Wpscan is a scanner for WordPress blogs. For noncommercial use, it is free. Among other things, it can scan for themes and plugins (including any associated vulnerabilities), enumerate usernames, and attempt to brute-force passwords (as described in its user documentation (https://github.com/wpscanteam/wpscan/wiki/WPScan-User-Documentation), it can check for weak passwords by making brute force attacks. Exhaustive brute force attacks require other tools.) Having updated its databases (gem update wpscan) and its metadata (wpscan –update), I’m ready to launch:

wpscan --url 192.168.159.140/wordpress -eu

wpscan addresses the program.

--url tells it I’m feeding in an address to scan; it is followed by a space and then the address of the blog (in this case, the ip address followed by “/wordpress”).

-eu tells it to enumerate users.

Note that without additional flags, wpscan will run somewhat aggressively (noisily)

Perhaps a second later, wpscan returns two users, “michael” and “steven”. It also gives me the WordPress version, and notes that this version is outdated.

First Post (Last Post)

No comments: