Networking

Penetration testing finds more holes in wireless network

Finding out exactly where your network is most vulnerable--penetration testing--can give you an honest look at your vulnerabilities. One consultant describes what he found when he performed penetration testing for his client.


Following the theft of its key customer contact lists; NCTPTI, Inc. (Name Changed To Protect The Innocent) hired our company to perform a security assessment. We found the client’s wireless local area network (WLAN) unsecured and accessible from any area within 500+ feet of its office building. As we continued our security assessment, we conducted WLAN penetration testing to determine the vulnerabilities posed by the unsecured WLAN.

I’ll outline the tools we used and what we found.

Second in a series
Our first article on CQUR IT’s network security audit of a client’s WLAN detailed how the consultancy determined how thieves could have stolen clients’ customer contact lists. The next article in this series will explain how CQUR IT presented the findings to the client’s senior management team and how it began the process of securing the WLAN.

Penetration testing
As part of a broader vulnerability assessment, we performed some specific penetration testing (attempting to exploit the client’s network as a “hacker”) to gauge the vulnerability level of the client’s network. It is valuable, but penetration testing also presents some risks to the client (for example, disruption of critical services, exposure of security weaknesses to external party, “hacker” education of internal staff) and the consultant (scope of testing, securing the data obtained, liability associated with disruption of critical client services). Accordingly, it’s usually best to conduct security assessments with reputable, experienced firms that are provided enough information to minimize the potential of catastrophic disruption of business-critical services. Generally, our penetration testing (PT) involves the following steps.

Footprinting: Port scanning with Nmap
Penetration testing is a lot like the children’s game twenty questions: The key is to start broad and then systematically and logically reduce the scope of your probing until you find what you’re looking for.

Sitting on the shoulder of an interstate behind NCTPTI, we switched to a Linux-based notebook, connected to the client’s WLAN, and asked our typical first question, “What can we see on your network?” with Nmap.

Nmap is an advanced network-scanning tool used by security professionals and hackers alike to map unknown networks and provide information about all identifiable systems. In addition to identifying computer systems and their operating systems, Nmap also detects ports on a system that are open, and perhaps vulnerable, to exploit.

Table A


At the operating system level, active applications (also referred to as services, processes, or daemons) are assigned a port to listen on. When an information request/response (for example, a Web page request on port 80) is received at a computer system, the request/response is passed to the application listening on that port. So, like an unlocked door to a cat burglar, an open port is an invitation to look further to determine whether a vulnerable application may be listening on that port. Some commonly used ports are shown in Table A.

From the Nmap screenshot (see Figure A), we identified a Windows NT system that appeared to be a Web server (ports 80/HTTP & 443/SSL open) as a good candidate for further exploration. Improperly secured Windows NT systems, especially those running Microsoft’s Internet Information Server (IIS) as a Web server, are highly vulnerable due to IIS’s wide deployment, Microsoft’s emphasis of functionality over security, and its ease of deployment, which allows less security-conscious administrators to easily implement the system without properly hardening it.

Figure A


NetCat and Whisker identify vulnerable applications
After footprinting the network with Nmap, we asked our next question: “What can we discover about what we see on your network?”

To determine whether a vulnerable application was listening on any of the ports identified by Nmap, we used an application called NetCat, “the Swiss army knife of TCP/IP,” to send improperly crafted packets to the listening ports. The packets contained incorrect information, tricking the listening applications into responding with a message that allowed them to be identified (see Figure B).

Figure B


The duped applications allowed us to identify IIS on port 80 and MDaemon 4.0.2 on ports 25 and 110 (see Figure C).

Figure C


Because there are a large number of documented flaws for improperly secured versions of these two applications, we knew we had a good target.

Our systematic approach continued with a third question: “Is the IIS server on port 80 vulnerable to any well-known attacks?” To answer this question, we used Whisker, a Web server vulnerability scanner. The server proved to be susceptible to numerous attack methodologies, including buffer overflows, FrontPage extensions, IIS password administration, and Unicode URL attacks.

The attack begins: Quest for the Holy Grail (root/administrator access)
Our questioning was getting increasingly specific: “Which attack can we use to gain the privileges we require to access the data we desire?”

We selected a simple Unicode URL attack to run first due to its high likelihood of success. Unicode provides a mechanism to uniquely express any character, no matter what the platform, no matter what the program, no matter what the language.Unfortunately, Unicode can be used to disguise malicious code and launch a variety of attacks. When successful, these attacks often allow the attacker to escape the Web root and run any DOS command with IIS (IUSR account) privileges.

We confirmed success by accessing the contents of the WINNT directory. At this point, we decided to load NetCat on an open port to expedite our penetration testing rather than continuing to use the more cumbersome URL approach.

We had to be careful because port selection is critical. For example, had we chosen to use port 80, NetCat would have replaced IIS on port 80, taken the intranet down, and virtually ensured detection of our activities. We were also hesitant to open a new port because astute administrators often monitor open ports.

We decided to use port 53 (which was already open). Using Samba, we temporarily mapped our Linux notebook as a network drive and transferred NetCat to the system. Shortly thereafter, we successfully created an Administrator account of our own.

We “compromise” confidential client information
With full control of the system, the only remaining question was, “Where could we locate a file with content equivalent to the data that was compromised in the original security incident?”

We navigated to the Active Server Pages source code that controlled intranet access to key client information. Inherent in the code were references to the underlying data source, a Microsoft Access database. We copied the database to our system and later verified that we had retrieved the targeted content by moving it to our Windows notebook and opening the database in Access. Our “hacking” had retrieved a critical file containing key customer contact information. If used maliciously, this information could significantly compromise NCTPTI’s future revenue streams and reputation.

Removing some of our fingerprints
Mission accomplished, we decided to gauge the client’s detection and incident response capabilities by leaving remnants of our attack. We left NetCat listening on port 53 (a shrewd hacker would have disguised the file and moved it to a less detectable port) and used WinZapper to remove enough log entries to noticeably reduce log file sizes. A log file that gets smaller should quickly catch the attention of a diligent administrator.

Unfortunately, our attack went undetected for two days. At that point, we connected to the WLAN and removed NetCat and our Administrator’s password without the client being aware of our activities.

Final thought: It takes a thief…
Penetration testing is extremely beneficial to both the client and the consulting firm. From the client’s perspective, they gain the ability to learn where their network is vulnerable and the steps necessary to detect and respond to an incident with the luxury of a safety net. Inherently, penetration testing by a consulting firm involves exposing security flaws to an external organization. Accordingly, the proper selection of a trustworthy consulting firm is critical to the security of the client’s organization.

From the consulting firm’s perspective, penetration testing allows consultants to assume the “mouse’s” role in the ever-changing cat and mouse game of securing a client’s network. This is invaluable because it keeps the consultant’s “Black Hat” knowledge current, ensuring the ability to provide clients with the level of security they require. As the saying goes, “It takes a thief….”

Editor's Picks