Step 1: Analyze the Network Traffic

Jumping into the unknown by associating to the WLAN without thoroughly analyzing its traffic is not wise. There is a wealth of information one can gather by putting a card into RFMON mode and analyzing the flowing packets in real time with Ethereal. Even better is dumping them into a pcap-format file for the period of time you consider to be sufficient and analyze the dump in calm lab conditions rather than on the client's site (bear in mind dumping data is illegal in some countries). An IT security consultant, wired or wireless, should be familiar with the various network protocols to the extent that allows her or him to find network design structure and security flaws from a first glance at the traffic dump. The Wireless Penetration Testing Procedure Outline in the template checklist given in Appendix G has it all (or nearly all). In this section we only clarify the points made in the template.

802.11 Frames

Do they contain any specific information? A default ESSID indicates that other AP settings are probably left at default as well, administrative passwords, SNMP communities, and IP addresses included. A list of wireless access point default settings is included in Appendix H for you to verify if this is the case. Being able to log in to the access point or wireless bridge and change its settings impresses the client, and you can only imagine what a cracker with such an access level can do with the WLAN. Use AP-tools and Net-SNMP utilities such as snmpwalk, snmpget, and snmpset to gather information about the targeted access point and alter its settings.

Are there any particular 802.11-related details you should know before associating to the network? Do you need to change the frame size and fragmentation threshold to get a proper link? Is the RTS/CTS feature enabled? If it is enabled, the network must have a problem such as a hidden node. Enable RTS/CTS yourself when associating to such a WLAN, otherwise you might have serious connectivity problems.

Plaintext Data Transmission and Authentication Protocols

It is a very common misconception to think that "If I am behind the firewall I can safely use telnet." This is not the case. The most common and well-known protocols transmitting data and user credentials in plaintext include POP, IMAP, HTTP, FTP, IRC, and instant messengers such as AOL Instant Messenger and ICQ. SNMP also transmits the community names and a variety of useful information in the MIB traps cleartext. More specific protocols such as Cisco Discovery Protocol (CDP) can provide a wealth of data about the supporting device's capabilities and configuration. There are some cases when plaintext data transmission is overlooked or unavoidable. For example, a sensible system administrator can implement an SSH/FTPS only policy and use HTTPS only to access a sensitive corporate site and force users to employ PGP for e-mail encryption. At the same time, networked printers will still receive plaintext documents and there isn't much that can be done about it unless the printer or the printing system supports SSL.

What if the network is not based on TCP/IP? Even if the protocol analyzer employed cannot decode IPX, AppleTalk, or DecNet traffic properly (rarely the case), cleartext is still cleartext, and data can be easily grepped. Also, there are many cases when a networked device can only be administered via an insecure protocol such as telnet. This applies to switches, routers, wireless access points, bridges, various WAN terminating devices, and even some low-end firewalls. If security was not taken into consideration in the early network design stages, it is likely that the network will have such devices plugged in and running.

Some "fun" things to do with data transmitted in the clear include these:

• Setting your browser to automatically surf the Web sites a selected host (the company CEO's machine?) is surfing. This can be accomplished using Dsniff's webspy (webspy -i wlan0 <IP of the victim>) or pdump (perl pdump.pl -B <hostname>). You can also do it to all hosts on a LAN with a -b switch, although you can imagine how your Netscape will behave when many users are browsing. Surprisingly, you have to be associated and properly inserted into the WLAN to do that.

• Grepping the data on the fly for a certain string using ngrep -w, Super Sniffer's ss – k, or pdump (there are many expression-filtering pdump options; check the README file).

• Pulling .jpeg and .gif images and .mpeg video/audio files from the passing network traffic using driftnet:

  
  

  
  arhontus:~# ./driftnet -h
  
  driftnet, version 0.1.6
  
  Capture images from network traffic and display them in an X window.
  
  
  
  Synopsis: driftnet [options] [filter code]
  
  
  
  Options:
  
  
  
    -h              Display this help message.
  
    -v              Verbose operation.
  
    -i interface    Select the interface on which to listen
  
                    (default: all interfaces).
  
    -p              Do not put the listening interface into
  
                    promiscuous mode.
  
    -a              Adjunct mode: do not display images on screen,
  
                    but save them to a temporary directory and
  
                    announce their names on standard output.
  
    -m number       Maximum number of images to keep in temporary
  
                    directory in adjunct mode.
  
    -d directory    Use the named temporary directory.
  
    -x prefix       Prefix to use when saving images.
  
    -s              Attempt to extract streamed audio data from the
  
                    network, in addition to images. At present this
  
                   supports MPEG data only.
  
    -S              Extract streamed audio but not images.
  
    -M command      Use the given command to play MPEG audio data
  
                    extracted with the -s option; this should
  
                   process MPEG frames supplied on standard input.
  
                    Default: 'mpg123 -'.
  
  

  
  

Filter code can be specified after any options in the manner of tcpdump. The filter code will be evaluated as 'TCP and (user filter code).' You can easily save images to the current directory by clicking them. Adjunct mode is designed for use by other programs that want to use driftnet to gather images from the network. With the -m option, driftnet silently drops images if more than the specified number of images is saved in its temporary directory. It is assumed that some other process is collecting and deleting the image files.

• Intercepting Voice over IP (VOIP) traffic with vomit:

  
  

  
  arhontus:~# ./vomit -h
  
  ./vomit: [-h] [-d <dev>] [-p <wav>] [-r <file>] [filter]
  
  
  
       -d <dev>  use <dev> for sniffing
  
       -p <wav>  read this wav file for later insertion
  
       -r <file> use content of <file> for sniffing
  
       -h        help
  
  

  
  

Note that you can insert a .wav file into the ongoing phone conversation on the network and use your imagination to think of all prank and social engineering avenues opened.

Other less obvious types of cleartext traffic interesting to a potential attacker include UNIX X Window server cookies and NFS file handles. The X uses a "magic cookie" to authenticate connecting clients. Sniffing the cookie out and inserting it into the .Xauthority file in the attacker's home directory lets the cracker connect to the X Window server used by the client whose cookie was intercepted. Sniffing the NFS handle allows attackers to contact the nfsd daemon on a server and gain access to the resources the handle describes. The best tool to sniff out NFS handles is Super Sniffer (ss -n flag).

Network Protocols with Known Insecurities

Examples of such protocols include SSHv1 (vulnerable to a man-in-the-middle attack using Dsniff's sshmitm) and LM/NTLMv1 Windows authentication hashes. The most common way of cracking LM/NTLMv1 hashes is using L0phtcrack, but on the UNIX side of the fence you can use readsmb <output file> to collect the hashes and apply John the Ripper (john -format:LM) or Mdcrack (mdcrack -M NTLM1) against the obtained file for password cracking.

DHCP, Routing, and Gateway Resilience Protocols

DHCP lease negotiation traffic provides a lot of information to the network eavesdropper, including present routers, DNS servers, and NetBIOS servers and node types. Tools such as Kismet use DHCP to find the IP range of wireless networks detected, and Aphunter and Apradar can automatically associate hosts with the found WLANs and obtain IP addresses by running DHCP. A bandwidth-stealing attacker who wants to roam between several WLANs in the area can use AP Hopper to stay connected. AP Hopper is a utility that automatically hops between access points of different wireless networks. It checks for the DHCP packets' presence and uses DHCP if the traffic is detected. In addition, AP Hopper looks for the gateway to the outside networks and can be run in a daemon mode with a -D flag.

DHCP is not a protocol designed with security in mind, and there are a variety of attacks that exploit DHCP. Check out the DHCP Gobbler tool (http://www.networkpenetration.com/downloads.html) if you want to implement several DHCP attacks in your LAN security audit practice.

By analyzing the routing protocol data transmitted over an insecure link, a knowledgeable attacker can reconstruct the logical map of a whole network and determine gateways and external network connections. He or she can also plan future traffic redirection attacks involving routing protocols enabled on the targeted WLAN or, more likely, leaking onto the WLAN from the wired side due to improper network separation. RIPv1 does not possess any authentication means, and other routing protocols such as RIPv2, IGRP, EIGRP, or OSPF rarely have authentication enabled. Even if the router administrator was sensible enough to enable the routing protocol authentication, it would be a plaintext password or an MD5 hash susceptible to a dictionary or brute-forcing attack. If your MDcrack has failed, you can always replay the same MD5 hash when generating a "rogue" routing update packet in a course of the route injection attack, using an advanced custom packet-building tool such as Nemesis or IRPAS.

Another issue an attacker observing wireless traffic might spot immediately is if ICMP type 9 and 10 (ICMP router discovery protocol, router advertisement and solicitation) packets are present. The ICMP router discovery protocol is really insecure and allows malicious LAN traffic redirection. We briefly review such attacks later in this chapter.

Finally, always pay attention to the gateway resilience protocols such as Cisco Hot Standby Router Protocol (HSRP) and Virtual Router Resilience Protocol (VRRP). HSRP is "protected" by a cleartext password (default "cisco") and there are a variety of attacks, including DoS and gateway hijacking attacks, committed against the HSRP-supporting Cisco routers. These attacks can be launched using the hsrp utility from the IRPAS toolkit:

arhontus:~# ./hsrp

./hsrp -i <interface> -v <virtual IP> -d <router ip> -a <authword>

     -g <group> [-S <source>]

For example:

while (true);

  do (./hsrp -d 224.0.0.2 -v 192.168.1.22 -a cisco -g 1 -i eth0 ; sleep 3);

done

VRRP (the IETF standard) implements three main authentication methods: No authentication, plaintext passwords, or IPSec Authentication Header (AH). We have seen VRRP running over wireless networks on a couple of occasions and in no case was the AH used! If you want to experiment with VRRP security on Linux, get the vrrpd source code from http://www.gen-i.co.nz/. VRRP implementations for other platforms also exist.

Syslog and NTP Traffic

An attacker can determine if remote logging is present before associating with the network. If logging is present, the cracker will know which hosts participate in the process and can plan attacks against the centralized log server. These attacks can range from trying to gain access to the log server (should be well-protected) to using syslog-specific DoS attacks (do a search at http://www.packetstormsecurity.org) or inserting the cracker's host between the attacked peer and the centralized log server employing a wireless-specific man-in-the-middle attack. In the latter case, log traffic can be modified on the fly with packet injection and other tools to make a future incident response procedure extremely difficult. To make it even more difficult, similar attacks can be launched against the NTP server if NTP traffic is spotted. If there are no correct timestamps, there is no reliable legal proof against the cracker. To fake NTP packets and see if the time server can be tricked, use the SendIP utility with the -p ntp flag, which loads up the custom NTP packet-creation module.

Protocols That Shouldn't Be There

We have frequently found that completely unused STP, NetBIOS, IPX, or SNMP traffic freely flows across the wireless link. Although this might not be a security issue, unused protocols consume resources and can be used by crackers to enumerate broadcasting hosts and even launch possible buffer overflow attacks if corresponding holes are found. Your responsibility as a network auditor is to advise the client to disable such protocols.