Endpoint Protection

 View Only

Wireless Attacks and Penetration Testing (part 2 of 3) 

Jun 14, 2004 02:00 AM

by Jonathan Hassell

There are several techniques to performing penetration testing on your wireless network, the objective of all of them being to improve the security and integrity of the network itself. What wireless lacks in the security of the physical layer and medium must be compensated for in protections on other layers of the stack. As you'll recall from Part I of this article, there are many different attacks that a nefarious individual can carry out on your wireless network.

In this installment, I'd like to focus more on a cracker attempting to penetrate your network and hack one of the servers held therein. The three phases of this hypothetical, but entirely realistic attack, consist of:

 

  1. gaining access to the wireless network, even though it is protected by WEP2. finding available servers on the network
  2. determining the services on those servers available for connection (and exploit)
  3. taking advantage of a well-known vulnerability to gain unauthorized access to a machine

Let's begin.

Phase 1: WEP key cracking

Our first task is to figure out how to gain access to the WEP-protected wireless network. Using AirSnort, named after the venerable intrusion detection system Snort, you can passively monitor transmissions across a wireless network and, from that monitoring, derive the encryption key for a WEP-protected network once you have an adequate base of packets. The number of packets required is somewhere between 5 and 10 million packets, but once this foundation of packets for reference has been gathered, it takes less than one second to identify the key. It's important to note that all 802.11b networks with 40/128 bit WEP encryption are vulnerable. Further, since using AirSnort constitutes a passive attack, nothing can be done to detect the program being run, either.

AirSnort is a Linux-based application and requires two things of your network card:

  • it must support RF monitor mode, and
  • it must have the ability to pass these RF-monitor mode packets to the PF_PACKAGE interface.

Note: there is some movement toward a Windows release of AirSnort. From the latest information on the porting effort, it appears to require considerable experience from developers in order to get it working on Windows, however.

Having a wireless card that operates in monitor mode allows the card to capture packets without associating with an access point or ad-hoc network. This way, you can sniff packets from a specific channel without ever needing to transmit any packets. In monitor mode, you can also discover access points that might not otherwise be available to you and attempt to crack the WEP key associated with that AP that way.

AirSnort also allows you to use promiscuous mode, which is similar to monitor mode but requires you to associate with a nearby access point-meaning you can effectively only sniff networks that trust you. If you are in promiscuous mode, you will not be able to sniff packets until after you have associated with an AP.

The suggested cards from the developers of the product include Cisco Aironet cards, any Prism-based cards using wlan-ng drivers, and Orinoco-based cards using the newer, patched set of orinoco_cs drivers. You will also need an up-to-date version of libpcap and gtk+-2.2 and gtk+-devel, since the AirSnort interface runs inside a graphical user interface (GUI).

Once all of the prerequisites have been filled, download the latest version of AirSnort and then, from a command line, execute the following:

 

tar -xzf airsnort-0.2.3a.tar.gz cd airsnort-0.2.3a ./autogen.sh make

Once those commands have completed, AirSnort is installed on your machine. Run AirSnort within your favorite GUI environment on Linux, and then you'll see the figure presented in Figure 1.

 


Figure 1: Sniffing packets with AirSnort

Once you have your wireless card active, press Start and begin collecting packets. The most common question now is, how long should you wait Here's how AirSnort cracks a WEP key. A weak IV, as discussed in Part I of this article, can assist in exposing only one key byte. AirSnort collects these weak IVs and sorts them according to which key byte each assists in exposing. When a sufficient number of weak IVs have been gathered for a particular key byte, AirSnort computes the probable value for that key byte using some advanced statistical methods. Once these probable values have been generated, AirSnort makes a guess at the key based on the highest ranking values found in the statistical analysis. Typically, there is approximately a 95% chance that a weak IV will reveal nothing at all about a key byte. It may require only a few packets before a key byte is revealed, or it may require many times more. Thus, some keys will be generated and tried fairly quickly, whereas others will crack much more slowly. Regardless, after a while, AirSnort will calculate the key and present it to you. At that point, associate with the wireless network, and you're now effectively connected to that LAN as if you were plugged in via a standard wire port.

Another tool much like AirSnort is WEPCrack, a utility that simply cracks 802.11 WEP encryption keys via much the same method as AirSnort. WEPCrack, however, requires a lot more manual intervention, sniffing packets out of the air and then logging them to a file in a specific format so that a Perl script can be run to glean weak IVs from the packets. Another Perl script is then run to generate the WEP key from that list of IVs. AirSnort has quite a bit more polish, and allows you to complete all of the tasks associated with the key breaking process from within one application. I recommend AirSnort over WEPCrack; however, if you are working in a forced text-only environment with no GUI, then give WEPCrack a look.

Phase II: port scanning

Next, let's discover some of the things running within our newly-cracked network. Port scanning continues to be an effective and simple way to detect anomalies and openings from your internal network to the outside world. Using the Linux-based NMAP utility, which is the gold standard of port scanning software, helps you to determine both the operating system and version of a system detected through the firewall, but also what ports are open and what usual applications are behind those open ports. The port scanning process essentially knocks on the doors of your computer, asking who is there and why.

NMAP and port scanning is a good place to start when beginning your penetration testing process. It provides an overview of your networks, with pointers into where to look for weaknesses. There are plenty of resources on NMAP already on SecurityFocus, so be sure to examine the archives here for in-depth coverage of NMAP's capabilities and operation.

Phases III and IV: identifying vulnerable applications and exploiting them

The next step, once you've gained access to the wireless network and discovered open ports on systems connected to the network therein, is to probe the applications behind those ports, determine their identities and any possible vulnerabilities. Again on Linux, there are a couple of tools you can use to try to bring down applications and target their weaknesses.

The first application is NetCat, which is a multipurpose tool for the TCP/IP protocol-it's been dubbed the "swiss army knife" of network administrators everywhere. It is a simple Unix utility which reads and writes data across network connections, using the TCP or UDP protocols. It is designed to be a reliable "back-end" tool that can be used directly, or easily driven by other programs and scripts. At the same time, it is a feature-rich network debugging and exploration tool, able to create almost any kind of connection imaginable with several built-in features.

Some of the activities you can perform with NetCat include:

 

  • Create outbound or inbound connections, TCP or UDP, to or from any ports
  • Implement full DNS forward/reverse checking, with appropriate warnings
  • Use any local source port
  • Use any locally-configured network source address
  • Use integrated port-scanning capabilities, with randomizer
  • Use integrated loose source-routing capability
  • Read command line arguments from standard input
  • Use Slow-send mode, one line every N seconds
  • Create a hex dump of transmitted and received data
  • Let another program service established connections
  • Use the optional telnet-options responder

One of the primary uses a hacker would have with NetCat is to send improperly crafted, illegitimate, or handily cloaked TCP/IP packets to a certain host and port and watch the reaction of the application behind that port. For example, one can construct a packet with enough HTTP code to request the web server at port 80 to identify itself and its platform. But we'll start a bit earlier than that. To conduct a simple port scan with NetCat -- for instance, of the server at 192.168.0.2 using ports 1-500, we'd execute and receive in return the following:

 

linux:~ # netcat -v -w2 -z 192.168.0.2 1-500 mercury.hasselltech.local [192.168.0.2] 464 (kpasswd) open mercury.hasselltech.local [192.168.0.2] 445 (microsoft-ds) open mercury.hasselltech.local [192.168.0.2] 444 (snpp) open mercury.hasselltech.local [192.168.0.2] 443 (https) open mercury.hasselltech.local [192.168.0.2] 389 (ldap) open mercury.hasselltech.local [192.168.0.2] 139 (netbios-ssn) open mercury.hasselltech.local [192.168.0.2] 135 (epmap) open mercury.hasselltech.local [192.168.0.2] 88 (kerberos) open mercury.hasselltech.local [192.168.0.2] 82 (xfer) open mercury.hasselltech.local [192.168.0.2] 80 (http) open mercury.hasselltech.local [192.168.0.2] 53 (domain) open mercury.hasselltech.local [192.168.0.2] 42 (name) open mercury.hasselltech.local [192.168.0.2] 25 (smtp) open

From this list, we see that port 80, the usual web server port, is open. We can use NetCat to identify the banner of the service, a fairly accurate way to determine the software used for that service. (Clever administrators can change this, but most don't bother unless they're creating honeypot systems.) Using NetCat:

 

linux:~ # netcat -v -n 192.168.0.2 80 (UNKNOWN) [192.168.0.2] 80 (?) open GET HTTP HTTP/1.1 400 Bad Request Server: Microsoft-IIS/5.0 Date: Tue, 01 Jun 2004 22:56:11 GMT Content-Type: text/html Content-Length: 87 Connection: close Content-Length: 34 <html><head><title>Error</title></head><body>The parameter? </html>

The banner indicates to us that we've found what is probably a Windows 2000 server running IIS 5.0. Clever hackers will then research valid exploits on unpatched Windows 2000 servers and try them. For instance, issuing the GET statement above with an address http://192.168.1.90/scripts/..%255c../winnt/system32/cmd.exe?/c+dir+c: to an unpatched IIS 5 server will result in a listing of the contents of the root directory in C: in your NetCat window. That's a problem for the administrator, but you just accomplish the hacker's objective -- finding a way into your system -- using NetCat.

NetCat can also run as a backdoor once installed on a machine, listening on a specific port and waiting for connections. Most hackers would use NetCat on both ends of a connection for a full-featured communications session. For instance, on a remote machine at IP address 192.168.0.2, running nc -L -p 7896 -d -e cmd.exe would instruct NetCat to stay open listening for a connection (-L), listen on port 7896 (-p), run cmd.exe upon connection (-e), and detach itself from that process (-d). Then, on a local machine, run nc -v -n 192.168.0.2 7890 and watch as NetCat connects to the remote machine and a shell on the remote machine opens, ready for your commands. It's a powerful tool for penetrating networks.

Note that NetCat is also available for Windows NT-based machines; this version can also be found at the same location as the Unix version.

If web server exploitation particularly concerns you, you might want to have a look at Whisker. It's another Linux tool that uses documented vulnerabilities in web server software to test running instances of those programs. Take, for instance, the machine in our earlier example detected by NMAP and NetCat to be running Microsoft Internet Information Services (IIS). Whisker takes common vectors of attacks-buffer overflows, FrontPage extensions, IIS password administration, and Unicode URL attacks that have been well documented-and uses them against a running instance of IIS. It's a great way to tell if a system is hardened. Whisker can be found directly from the SecurityFocus tools archive.

Conclusion

In this installment of the series, you've discovered how to find wireless networks, gain access to them even if they're using WEP encryption, find vulnerable systems and ports, and use various utilities to assist you in those endeavors. This is mostly what a hacker would do to gain access to your systems. By "knowing thine enemy," you can then successfully implement strategies to circumvent these methods-which is the topic of Part III, the final installment, which will appear in a few weeks. Until then.
 
References

Jonathan Hassell is an author and consultant specializing in Windows administration and security. He is the author of Managing Windows Server 2003 and RADIUS, both published by O'Reilly & Associates, and Hardening Windows, published by Apress. He also holds periodic public seminars; see www.hardeningwin.com for details. He has written for Windows & .NET Magazine and WindowsITSecurity.COM and is a contributor to PC Pro, a leading computer magazine in the United Kingdom.

View more articles by Jonathan Hassell on SecurityFocus.

This article originally appeared on SecurityFocus.com -- reproduction in whole or in part is not allowed without expressed written consent.

Statistics
0 Favorited
0 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Related Entries and Links

No Related Resource entered.