| I l@ve RuBoard | |
During one engagement, we were asked to perform external penetration testing from the Internet against a company that had an Internet Web server, an FTP server, and a firewall. When we began the engagement, we did not know what the client had attached to the Internet; we knew only the name of the company. (We call the company “xyz.org” in this discussion.) Using Sam Spade, we performed a whois search for the name of the organization and quickly located the domain name. Next, we performed a whois query on the actual domain name of the company and discovered the name server's name, IP address, contact information, and other useful pieces of information. Using the company's name server, we performed a zone transfer with Sam Spade and discovered the IP address of the Web server, a system called “fire1,” and another server called “ftp1.xyz.org.”
Now that we had IP addresses for servers, we quickly used Sam Spade to determine the entire IP address block that held these servers. Sam Spade revealed that the entire Class C address belonged to the organization we were targeting. Using Pinger, we performed a ping sweep of the Class C address to identify any systems we may have missed. The ping sweep identified only the systems we had already discovered from the zone transfer. Next, we performed a TCP ping using Nmap on port 80.
# nmap -sP -PT80 10.10.10.1-254
Nmap found only the hosts that Pinger had reported. Next we used Nmap to perform a stealth (SYN) port scan of selected ports against the target systems and used operating system identification.
# Nmap -sS -O -v -p 7,9,21,23,53, . . . 10.10.10.2,5,10
We scanned for the ports we highlighted in Chapter 13. The results of the port scan appear in Table CS-1
These results showed some interesting findings. First, fire1 appeared to be a Check Point firewall since port 256 is used for Check Point firewall management.
| Host | Port | Description | Comment |
|---|---|---|---|
| webserver, 10.10.10.10 | 23 | telnet | |
| 80 | HTTP | ||
| 135 | MS RPC service | ||
| 139 | NetBIOS | ||
| fire1, 10.10.10.2 | 256 | Check Point management | |
| ftp1, 10.10.10.5 | 21 | FTP | |
| 135 | MS RPC service | ||
| 139 | NetBIOS |
Secondly, we suspected that webserver and ftp1 were located on the same segment as fire1 and were not protected by the firewall due to the number of ports open on the systems. We performed traceroutes to the targets and the paths were identical, confirming our suspicion. The fact that the Web and FTP servers were not protected by a firewall or filtering router was a weakness in the site's architecture. The Web and FTP servers should be located on a DMZ segment on a separate interface of the firewall. This way, only essential ports such as 80 would be open to traffic from the Internet.
Since ports 135 and 139 appeared to be open, we attempted to establish a null session to the Web server.
C:\>Net use \\10.10.10.10\ipc$ "" /user:""
The null session was successful. We then used DumpSec to gather user information from the host. The RestrictAnonymous registry key was not in use, and DumpSec was able to obtain all the user information from the system. Here we learned the user IDs of the administrator accounts and the fact that the accounts were neither disabled nor locked out and that the passwords had not been changed in some time. We looked through the comments for any password hints but found none. Next, we performed the same process against ftp1 and found nearly the same account information with only a few different accounts. This seemed to indicate that the same administrator probably configured both of these systems.
Next we used telnet to connect to webserver and confirmed that we were able to obtain a login prompt. Using What's Running, we grabbed the banner and saved it. We then performed an FTP to ftp1, confirmed that we were able to obtain a login prompt, and grabbed the banner. We also attempted to log in to ftp1 using “anonymous” as the user name and a blank password. We were successful. We then perused all the directories to which we had access but did not find any useful information.
We now had several options for attempting to gain unauthorized access to the systems. First, to be thorough in our information gathering, we looked through the Web site for information and clues that might help us during the testing. We did not find any useful information on the site that would aid us.
Our plan was to attempt to gain access to either webserver or ftp1 and to use this system to attack the other systems and hopefully find a way into the internal network through the firewall. We were hoping that one of the systems would either be dual-homed (have a second network interface card that connected to the internal network) to the internal network or have a rule in the firewall that allowed it to connect to the internal network.
We chose webserver as our first target. We started by employing limited password guessing against the administrator account. The local administrator account sometimes has a weak password since multiple people may need to remember it, and it is not often changed for the same reason. First, we had to delete our previous null connection and close DumpSec to ensure our credentials did not conflict while attempting password guessing.
C:\>net use * /d
First we tried “password” as the password, and unbelievably, it worked.
C:\>net use \\10.10.10.10\ipc$ password /user:administrator
You would be surprised how many times we have encountered weak passwords such as these. If “password” had not worked, we would have attempted five guesses, checked the account lockout status with DumpSec, and then tried five more attempts before checking the lockout status a final time. If the account was not locked out after ten attempts, account lockout was probably not enabled and brute force could be used. Since the password was so weak, we did not need to perform these additional steps.
Now that we had administrator rights to the system, we were able to use L0phtCrack to extract the SAM file. We then set L0phtCrack to work on the SAM file so we would have accounts and passwords that may work on other systems. We also started to look through the files and directories for information and to perform NET commands that would give us more information.
We had administrator access but still had not penetrated the internal network. We needed to use this exploited system as our foothold for breaking through or around the firewall. To do this we needed to get our tool kit onto webserver. Using NetBIOS and the administrator account, we were able to map a drive to the C drive on the Web server.
C:\>net use * \\10.10.10.10\c$ password /user:administrator
We then copied a tool kit consisting of Netcat, Nmap, NAT, DumpSec, Remote, AuditPol, SC, and other NT resource kit utilities to the share. We put the kit in Winnt/system32 and hid the files using the attrib command (attrib +h filename). Next, we created a batch file, getin.bat, to launch Remote and give us a command prompt. The batch file contained:
remote /s "cmd" backdoor
Since NetBIOS was open to the server, we were able to access the NT scheduler service. If NetBIOS were not open to the server, we would have needed to find another way for our script to be executed. Some options for getting a script executed include copying it into startup or creating a Trojan horse program with a common name that a user may execute by accident, thereby launching the script. Since we could access the server via NetBIOS, we started the schedule service on webserver using the following command:
C:\>SC \\webserver start schedule
We then checked the time using NET TIME.
C:\>net time \\webserver
Then we used the schedule service to launch our batch file, which would open our back door using remote.
C:\>at \\webserver 16:00 "c:\\winnt\system32\getin.bat"
This would launch our batch file at 16:00 or 4:00 p.m. To view the job we used the AT command:
C:\>at \\webserver
After the time passed for the job to have executed, we again issued the AT command and verified the job had completed (it was no longer listed). Using Remote we were able to obtain a command prompt:
C:\>remote /c webserver backdoor
Now we had command line access to webserver. We then installed VNC and were able to use a GUI and command line interface. We checked the status of auditing using AuditPol and saw it was not enabled.
C:\>auditpol \\webserver
If auditing were enabled we would have disabled it and then restarted it when we had completed our testing.
Next, we started discovery once again from our new position. We found that we were able to view and ping internal systems from the Web server since rules must have existed in the firewall allowing webserver to communicate with the internal systems. We were able to repeat the steps listed above and obtain access to internal systems. Here again we saw a poor network architecture. The firewall should have restricted the Web server to communicating with internal systems only over necessary ports. For instance, NetBIOS connections between the Web server and the internal network should not have been allowed. Only port 80 for HTTP and ports necessary for the Web server to communicate with the application server should have been permitted to pass through the firewall. Since these restrictions were not in place, we were able to probe and exploit the internal systems just as if we were on the internal network.
This was a relatively easy penetration test for several reasons. First, the Web server and FTP server were not protected by a firewall. Because of this, many services and ports that should not have been accessible from the Internet were open. NetBIOS should never be accessible from the Internet. Since it was accessible, we were able to establish null connections, perform NET USE, and copy files. In addition, poor passwords were being used, account lockout was not in place, auditing was turned off, and RestrictAnonymous was not set. FTP and telnet should not have been open to the Internet. If we were unable to use NetBIOS to access the systems, we could have attempted to use telnet and FTP. As we stated earlier, the Web server and FTP server should have been located on a secure DMZ segment. In addition, the Web server and FTP server should not have been allowed to communicate with internal systems. If anything, the internal systems should have been allowed to connect to the DMZ systems, but connections from the DMZ to internal should have been denied. Had the DMZ systems not been able to initiate connections internally, our job would have been harder but not impossible. We could have installed sniffers, keyboard loggers, and other devices that would have eventually given us information that would have enabled us to penetrate the perimeter defenses.
| I l@ve RuBoard | |