Chapter 6. Wireless: Network Forensics Unplugged
“You are only coming through in waves . . .”
—Pink Floyd1
1. R. Waters and D. Gilmour, “Comfortably Numb,” The Wall (EMI, 1979).
Wireless networks are everywhere. They exist in enterprises, homes, subways, buses, cafes, anywhere people go. For an investigator, wireless networks can be a boon or a wretched headache. In the best scenarios, wireless networks provide easy access to client traffic, a convenient entry point into the network, and extensive access logs.
On the other hand, many wireless devices and access points do not retain access logs, especially when deployed with default configurations. Client systems tend to be connected transiently, and their physical locations are often unknown or difficult to pinpoint. Employees or attackers can set up rogue wireless networks, unbeknownst to central IT staff, for the purposes of convenience or covert data exfiltration. Wireless devices in the enterprise can pose a major challenge for forensic investigators—especially since these same devices are often accessible from the parking lot of a facility and can represent a major loophole in organizational security defenses.
Wireless devices have exploded in popularity during the past decade. It is impossible to enumerate all the wireless devices that exist in even a single person’s house, let alone a large corporate environment. Individuals often walk around carrying multiple wireless devices, such as cell phones, iPads, laptops, Bluetooth headsets, and GPS tracking devices.
Common types of wireless devices and networks include:
• AM/FM radios
• Cordless phones
• Cell phones
• Bluetooth headsets
• Infrared devices, such as TV remotes
• Zigbee devices, such as HVAC, thermostat, lighting, and electrical controls
• Wi-Fi (802.11)—LAN networking over RF
• WiMAX (802.16)—“last-mile” broadband2
2. Ian Mansfield, “WiMAX Companies Receive $504 Million in Funding for Last Mile Broadband Projects,” Cellular-News, October 20, 2010, http://www.cellular-news.com/story/45995.php.
Why investigate wireless networks? Here are some examples of cases involving wireless networks:
• Recover a stolen laptop by tracking it on the wireless network.
• Identify rogue wireless access points that have been installed by insiders for convenience or to bypass enterprise security.
• Investigate malicious or inappropriate activity that occurred via a wireless network.
• Investigate attacks on the wireless network itself, including denial-of-service, encryption-cracking, and authentication bypass attacks.
In addition, you may find yourself capturing wireless packets, investigating wireless routers and switches, or conducting a forensic analysis relating to any other topic in this book where the physical layer happens to be air rather than a cable or fiber.
Wireless networks, particularly those based on IEEE 802.11 (“Wi-Fi”) standards, have proliferated in the last decade. These days almost no enterprise is without them. As a result, every network forensic investigator should be prepared to handle wireless evidence.
With computing devices getting smaller and more mobile, we are increasingly reliant upon wireless connectivity. The proliferation of mobile devices is putting pressure on government and enterprises alike to expand the availability of network access. In the United States, the Federal Communications Commission (FCC) has been instructed to facilitate ubiquitous broadband access.
If you calculate the expense of a network deployment versus the number of potential endpoints that can be supported, wireless networks are clearly the economical option. In general, it is cheaper to deploy a wireless network than run all the cables necessary for a wired infrastructure. This is especially important in sparsely populated areas where cables might have to be run long distances or over rough terrain, and also in high-density areas where older buildings were not designed with modern wiring needs in mind. As a result, wireless networks are being deployed in nearly every type of environment, often replacing or expanding existing network access.
In this chapter, we focus our attention on 802.11 “Wi-Fi” networks specifically. This is because Wi-Fi networks are extremely common both in the enterprise and at home, and we can leverage many of our previously discussed forensic techniques on 802.11 Wi-Fi networks. Many of the concepts we cover in this chapter are also applicable to other types of wireless devices and networks.
6.1 The IEEE Layer 2 Protocol Series
As previously discussed in Chapter 3, “Evidence Acquisition,” the IEEE has published a series of international standards (“802.11”) for Wireless Local Area Network (WLAN) communication. These standards specify protocols for WLAN traffic in the 2.4, 3.7, and 5 GHz frequency ranges. The term “Wi-Fi” is used to refer to certain types of RF traffic, which include the IEEE 802.11 standards. For more details about passive evidence acquisition of 802.11 traffic, please see Section 3.1.2, “Radio Frequency” in Chapter 3.
As analysts of network traffic, it is easy to get in the habit of assuming that all of the protocols that we care about are described in an IETF RFC. It is worth remembering that not all standards are sponsored by the IETF (see discussions in Chapter 4). Many of the core network protocols, especially at Layer 2, were instead proposed and published by IEEE standards groups—particularly the 802 series, which covers Ethernet (802.3), trunking (802.1q), LAN-based authentication (802.1X), and various aspects of Wi-Fi (802.11) including both WEP- and WPA-based encryption standards.
6.1.1 Why So Many Layer 2 Protocols?
You may be wondering why we need so many different protocols for Layer 2 functionality. Often, network forensic students ask, “Why didn’t we just use existing Ethernet standards over RF just like we did over copper?” Radio frequency and copper simply don’t have the same physical characteristics, and so signals sent across them don’t behave the same way! In order to insulate Layer 3 protocols (chiefly IP) from those differences in physical properties, we need intermediary protocols to allow a uniform interface to the network layer, regardless of the physical media.
We’ve been talking about how a wireless access point is essentially just a Layer 2 hub, but it’s a little bit more complicated than that. A physical copper hub can be relied upon to deliver signals from each station to every other station.
For forensic investigators, it is important to realize that if you are capturing traffic from a wireless network, there may well be stations actively participating in the network that you cannot overhear from your vantage point, due to signal strength (unlike on wired media, where voltages propagate much more reliably through copper or fiber cables). This simple fact has far-reaching effects on both data link–layer protocols themselves and forensic analysis of the wireless evidence.
While Ethernet (802.3) is designed to use the “carrier sense multiple access with collision detection” (CSMA/CD) method, the 802.11 wireless protocols we discuss use “carrier sense multiple access with collision avoidance” (CSMA/CA). We briefly review these concepts in the next sections.
6.1.1.1 CSMA/CD
Ethernet, designed for wired networks, is a protocol based on CSMA/CD. What this means is that all stations on the network share the same medium—typically a star-shaped but essentially physically contiguous piece of copper. A single conductor can only transmit one single signal at a time, by raising the voltage on the line (a “one”) or reducing the voltage on the line (“a zero”). In other words, only one station can be using the “multiple access” medium at the same time. (There may be other more sophisticated and multiplexing ways to encode signals with electrons on copper, but that’s how Ethernet does it.) Meanwhile, it must be all stations’ responsibility to make sure that the wire is live and in use (the “carrier sense” part of CSMA) and to detect if any two stations are trying to use it at the same time (the “collision detection” part).
This isn’t always easy, as electrons don’t propagate down copper instantaneously, so two stations on the farthest ends of the circuit could commence sending at roughly the same time without realizing that someone else down the wire was trying to talk too. The specified result is that the first station that detects overlapping signals should send out a special “jamming” signal to all stations, essentially informing everyone that they need to stop talking and try again, but only after selecting at random a time increment to wait (so that they don’t all try at once again).
6.1.1.2 CSMA/CA
In wireless LANs, collisions cannot be reliably detected by the sender. On a wire, the high and low voltages will eventually propogate to every station, so long as they remain physically connected. In contrast, on a wireless network, it is entirely common to have multiple stations sharing the same frequency and channel, even if each station is not necessarily capable of detecting all signals from its peers. As long as a station can reliably send and receive signals to and from the access point, it can participate in the network. A station that can communicate with the access point but not other stations is referred to as a “hidden node.”
Since collisions cannot be reliably detected over radio frequency, 802.11 wireless networks are designed to use collision avoidance techniques by decreasing the likelihood that two stations will attempt to communicate at the same time. As described in the IEEE 802.11-2007 standard, before transmission, a station on the wireless network listens to determine if the transmission medium is idle. If it is busy, the station waits until the end of the current transmission, and then it waits an additional random amount of time before attempting to send traffic. This helps to reduce the likelihood that all stations will transmit at once. In addition, stations can also exchange control frames of message type “request-to-send” and “clear-to-send” to help avoid collisions, as described further in Section 6.1.2.1, “802.11 Frame Types.”3
3. IEEE, “IEEE Standard for Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications” (June 12, 2007): 251, http://standards.ieee.org/getieee802/download/802.11-2007.pdf (accessed December 31, 2011).
6.1.2 The 802.11 Protocol Suite
The IEEE developed the 802.11 protocol suite as a standard for data link–layer transmission over wireless physical media, including the radio and infrared frequency spectra. 802.11 is designed to incorporate CSMA/CA, in keeping with the needs of the wireless physical medium.
6.1.2.1 802.11 Frame Types
The 802.11 protocol suite defines different types of frames. For forensic investigators, different types of frames contain different types of evidence, as we will see.
There are three types of 802.11 frames:
• Management Frames—Govern communications between stations, except flow control;
• Control Frames—Support flow control over a variably available medium (such as RF);
• Data Frames—Encapsulate the Layer 3+ data that moves between stations actively engaged in communication on a wireless network.
802.11 is a complicated Layer 2 protocol in many respects. Figure 6-1 is a chart that shows the 802.11 frame’s data structure. You’d be forgiven for looking at the chart in Figure 6-1 and wondering to yourself what the fields meant—especially since there are several 6-byte locations for frame addresses. The purpose of each “address” field is dependent upon the frame’s type and subtype.4
4. IEEE, “IEEE Standard for Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications” (June 12, 2007): 59–87.
Figure 6-1 The 802.11 frame’s data structure, which includes four fields for 6-byte MAC addresses per frame. How each is used is dependent upon the frame’s type and subtype.
Management Frames
Management frames (type 0) are designed to coordinate communication on any wireless LAN, from infrastructure networks to individual stations sending out probe requests. These frames are the glue that keeps the stations together through a single access point, or on an extended series of bridged access points. Management frame subtypes include Association Requests, Association Responses, Probes, Beacons, and others.
For forensic investigators, management frames are important for several reasons. First and foremost, they are not encrypted. As a result, these clear-text frames provide a wealth of information as to which stations are trying to communicate, in which ways, and with whom. At a minimum, type 0 frames are interesting because their subtypes indicate basic associative activities. In addition, with a bit of statistical analysis (as we’ll soon see), they can provide a treasure trove of forensic data. From the information in a management frame, you can enumerate station MAC addresses, infer likely manufacturers, identify access point Basic Service Set Identification (BSSID) and Service Set Identifiers (SSIDs), investigate successful and failed authentication attempts, and more.
Management frames are often the target of manipulation or the vector of attacks against an access point. As we will see, common attacks such as WEP cracking and Evil Twin attacks are often facilitated through manipulation of management frames, or simply careful attention to the details broadcast within them.5
5. IEEE, “IEEE Standard for Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications,” 79–87.
Management frame subtypes include:
• 0x0 — Association Request
• 0x1 — Association Response
– Status Code: 0x0000 — Successful
• 0x2 — Reassociation Request
• 0x3 — Reassociation Response
• 0x4 — Probe Request
• 0x5 — Probe Response
• 0x6 — Reserved
• 0x7 — Reserved
• 0x8 — Beacon frame
• 0x9 — Announcement Traffic Indication Map (ATIM)
• 0xA — Disassociation
• 0xB — Authentication
• 0xC — Deauthentication
• 0xD — Action
• 0xE — Reserved
• 0xF — Reserved
Control Frames
Control frames (type 1) are designed to manage the flow of traffic across a wireless network. One of the main challenges wireless protocol designers faced is the “hidden node” problem. Recall that while on a wired medium, it can be presumed that every station will eventually be able to see all nodes (as voltages propagate to all stations). With RF, it is entirely possible that some stations cannot “see” each other, while still being networked using the same notional physical media (since they can each “see” the WAP). One way of addressing this problem is to have individual stations send “request-to-send” control frames, and for all stations to watch for corresponding “clear-to-send” and “acknowledgment” frames. That way availability of transmission and reception can be tested prior to the establishment of data circuits.
There are three control frame subtypes (as displayed by Wireshark, with the high-order nibble set to “1” for the “Control” type):
• 0x1B—Request-to-send (RTS)
• 0x1C—Clear-to-send (CTS)
• 0x1D—Acknowledgment
Control frames are relatively sparse, but can provide an investigator with information about timing and station MAC addresses.
Data Frames
Data frames (type 2) contain the actual data transmitted across the wireless network, including encapsulated higher-layer protocols. For instance, every IP packet that flows across the wireless 802.11 network is part of the payload of an 802.11 data frame.
There are many different data frame subtypes, including the Null function (subtype 4), indicating no data. However, the most interesting is likely to be those where the subtype is 0 (Data).6
6. IEEE, “IEEE Standard for Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications,” 77–79.
As a forensic investigator, if the wireless network is not encrypted, or if you have access to the encryption key and can gain access to unencrypted data frames, then you can capture and analyze the wireless traffic at Layer 3 and above. Even encrypted data frames can still be analyzed using statistical flow analysis techniques to reveal volumes and directionality of traffic and stations involved.
6.1.2.2 802.11 Frame Analysis
When you analyze captured network traffic, how do you know which bits correspond with which protocol fields? This may seem like a trivial question at first, but stations can be configured to transmit the bits in different orders, depending on the data link–layer protocol used. As long as the sending and receiving station are both synchronized to interpret and reassemble the bits according to the same protocol, that is all that matters.
The order that bits are transmitted in the 802.11 protocol suite is not straightforward. This can cause forensic analysts to produce incorrect results if you are not careful. To fully understand how the bits we capture correspond with protocol charts and field descriptions, let’s first explore the concept of “endianness.”
Endianness
The term “endianness” emerged from the tale Gulliver’s Travels, in which Gulliver encounters two groups of people: the Lilliput and the Blefuscu. The Lilliput people insist on cracking open their eggs at the little end (and hence, are “little-endian”), whereas the Blefuscu are convinced that everyone should crack their eggs open at the big end (“big-endian”).7
7. Jonathan Swift, Gulliver’s Travels (London: Penguin, 2010).
This idea was eventually applied to the field of computer science. Both humans and computers can be programmed to read, write, and transmit numbers in different orders. We refer to this distinction as “endianness.” When the most-significant digit is ordered first, the system is called “big-endian.” When the least-significant digit is ordered first, the system is called “little-endian.”
As trivial as it may seem, the concept of “endianness” is deeply important for the purposes of computer science and network implementation. While it doesn’t really matter which order we choose to transmit bits, it is important that we agree on standards so that bits can be transmitted and properly interpreted at the other end.
Most of the time when we refer to “big-endian” we mean that the most significant byte is represented, stored, or transmitted first (though we can use other data boundaries than bytes—commonly including 16-bit or 32-bit words). When we refer to “little-endian” we usually mean that the least significant byte is represented, stored, or transmitted first (though again we could be referring to byte order within a 16- or 32-bit word, or the word order itself).8
8. IEEE, “IEEE Standard for Information Technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 6: Medium Access Control (MAC) Security Enhancements” (July 23, 2004), http://standards.ieee.org/getieee802/download/802.11i-2004.pdf.
Figure 6-2 shows an example of how the concept of “endianness” applies in the familiar example of Hindu-Arabic numerals using base-10 math. “Base 10” means that we use 10 different characters (in this case, 0 through 9) to represent any arbitrary numerical value. In Figure 6-2, the left-most digit represents the number of thousands, the next digit to the right represents the number of hundreds, the next digit to the right represents the number of tens, and finally the right-most digit represents the number of ones. As a result, we can refer to the right-most digit as “least significant” (its value is the smallest) and the left-most digit as “most significant” (its value is the largest).
Figure 6-2 Base10: From left to right, 1000s, 100s, 10s, 1s. Since we normally read Hindu-Arabic numerals from left to right, beginning with the “most significant bit,” this numbering system is “big-endian.”
In English, we read Hindu-Arabic numerals from left to right. That means that we have been trained to read the number in Figure 6-2 beginning with the “most significant digit” on the left. Hence, Hindu-Arabic numerals read by English-speakers are considered “big-endian.”
6.1.2.3 Network-Byte Order (TCP/IP, but NOT 802.11)
Network forensic analysts are used to viewing captured bits in big-endian form. The IP protocol specifies the order the bits are transmitted across the network as big-endian.9 This is often referred to as “network-byte order.”
9. Jon Postel, “RFC 791—Internet Protocol, Darpa Internet Program Protocol Specification,” Information Sciences Institute, University of Southern California, September 1981, http://rfc-editor.org/rfc/rfc791.txt.
As described in RFC 791, “Internet Protocol—Appendix B: Data Transmission Order”:
The order of transmission of the header and data described in this
document is resolved to the octet level. Whenever a diagram shows a
group of octets, the order of transmission of those octets is the normal
order in which they are read in English. For example, in the following
diagram the octets are transmitted in the order they are numbered.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 | 3 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 6 | 7 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 10 | 11 | 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Transmission Order of Bytes [IP Protocol]
...
Whenever an octet represents a numeric quantity the left most bit in the
diagram is the high order or most significant bit. That is, the bit
labeled 0 is the most significant bit. For example, the following
diagram represents the value 170 (decimal).
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+-+-+-+-+-+-+-+-+
Significance of Bits [IP Protocol}
...
Similarly, whenever a multi-octet field represents a numeric quantity
the left most bit of the whole field is the most significant bit. When
a multi-octet quantity is transmitted the most significant octet is
transmitted first.
6.1.2.4 802.11 Endianness
The IEEE 802.11 specification transmits bits in a different order from the TCP/IP protocol suite, which most network forensic analysts are familiar with. Hence, the need for this discussion!
Mixed-endian?
802.11 is neither big-endian nor little-endian, but is best described as “mixed-endian.” While the bit ordering within each individual data field is big-endian, the fields themselves are transmitted in reverse order, within the byte-boundaries.
The top diagram in Figure 6-3 shows the written protocol specification for the first two bytes of a typical 802.11 Data Frame (type 2, subtype 0). You can see that the payload is encrypted—note that the privacy bit, marked with a “W,” is set to 1 (the “W” originally meant “WEP-protected,” though now it could be protected with TKIP or AES-CCMP instead). The bit ordering depicted in the top diagram shows what we would expect to capture if the 802.11 frame were transmitted in network-byte order like IP, which it most certainly is not.
Figure 6-3 802.11 traffic: Comparison of field orders within the byte-boundaries. The top diagram represents the protocol specification, whereas the bottom diagram represents the order of bits captured via libpcap.
When the first byte of the frame is actually transmitted, the least significant field (“Sub-type”) is sent first! The Type goes second, and the protocol version goes third. When libpcap receives the bytes, they arrive bit-for-bit as shown in the lower chart in Figure 6-3. Notice that in the second byte, all seven fields were sent in reverse order, though the bit ordering within the 2-bit DS field remains intact. Similarly, the bit ordering within the Version, Type and Subtype fields remains intact.
This has an immediate impact on the values you see displayed in libpcap-based tools such as Wireshark and tcpdump.
Binary sequences (series of 1s and 0s) can be encoded easily in hexadecimal to facilitate reading and interpretation by human analysts. For example, Wireshark displays each frame’s data in the order received, in the “Packet Bytes” frame at the bottom of its window.
The bits are displayed, nibble by nibble, in hexadecimal representation. When interpreting the data, libpcap treats the bit received first as the most significant bit in the nibble. As a result, the hexadecimal representation of a byte in the Packet Bytes window may differ from the protocol-aware interpretation of the meaning of the bits.
Figure 6-4 shows an example of an 802.11 data frame in Wireshark. As you can see, in Wireshark’s Packet Details panel, Wireshark has correctly interpreted the first byte of the 802.11 frame (“Version/Type/Subtype”) as 0x20 (0b00100000). However, when you view the raw traffic in the Packet Bytes panel below, it appears as 0x08, since the bits were actually received in that order (0b00001000).
Figure 6-4 In the Packet Details panel, Wireshark interprets the 802.11 frame correctly. In the Packet Bytes panel below, you can see the order that the bits were actually transmitted across the wire (shown as hexadecimal). The 802.11 transmission was mixed-endian.
Let’s look at the second byte of the 802.11 frame, the “Flags.” This contains six single-bit frame control flags and the 2-bit DS field. These are transmitted in reverse order, from least to most significant, field-by-field! Again, while Wireshark correctly interpreted the flags in the second byte (as seen in the Packet Details panel), due to the order in which the bits were received, the Packet Bytes panel displays 0x41 (0b01000001), and not 0x42 (0b01000010). See Figure 6-3 for details.
This can get a bit confusing to say the least!
6.1.2.5 Wired Equivalent Privacy (WEP)
Wired Equivalent Privacy (WEP) is part of the 802.11 standards, published by the IEEE. It was proposed as a way to enable a WAP to provide a “private” network, similar to the environment that a wired hub could provide due to natural limitations of the physical media.
To gain access to a WEP-encrypted wireless network, users need knowledge of a “shared secret” key to gain access to the wireless hub’s service at Layer 2. (Recall that the WAP’s physical layer—radio frequencies—is by definition a physically broadcast medium. Any station with a suitable antenna in range and tuned to the appropriate frequency and channel may observe and transmit data over the Layer 1 shared physical medium.)
Problems in WEP-land
The WEP protocol has a couple of significant problems, which has led to its being deprecated in favor of newer wireless privacy protocols such as WPA2. Most importantly, the WEP protocol has a commonly known flaw that allows any eavesdropper (any station with sufficient RF gain) to harvest unprotected key material, which can then be used to expedite a brute-force attack and recover the shared encryption key. Widely published tools such as “aircrack-ng” make it easy even for beginners to crack WEP keys and access “protected” wireless networks. We discuss this vulnerability in greater detail in Section 6.4.4, “WEP Cracking.”
WEP (and other protocols used with shared secret keys) also pose a logistical Layer 8 (human) problem. The most obvious is that a “shared secret” is not really a secret at all. If the network administrator has to give the WEP key to many people, Layer 8 failures should be anticipated, expected, and compensated for. Adding to that problem is the logistical difficulty in changing the shared secret, which means that even compromised shared secrets often remain unchanged for long periods of time.
Forensic investigators should assume that WEP-protected segments are at high risk of compromise, and may be a likely vector for unauthorized network intrusions. On the plus side, investigators who are (legally) conducting covert investigations without the knowledge of local IT staff may find that WEP-protected networks are a convenient point of covert entry to the network.
If WEP is so broken, why are we still studying it?
Although WEP has widely known flaws, it is also still widely implemented. Happily, most commodity Wi-Fi hardware now supports WPA2 (see below). However, forensic investigators still often encounter WEP in use today, for a variety of reasons, such as:
• Legacy equipment—Sometimes WAPs are deployed and forgotten, or never maintained, or passwords are never rotated. Lack of resources may prevent equipment upgrades.
• Modern equipment deployed to support legacy equipment—Modern WAPs may be deployed in an environment where other legacy devices persist, and therefore must be configured to support the lowest common denominator with respect to key length and cryptosystem.
Often, if a WAP is working, system administrators simply never touch it. Unfortunately, the model “if it ain’t broke, don’t fix it” doesn’t really apply when a device’s functionality continues, even as the security model completely breaks down.
How can you tell if a packet capture or stream is encrypted?
802.11 management frames have a “Privacy” subfield that is set to “1” when “data confidentiality is required for all data type frames exchanged within the BSS.”10 In other words, when the access point is configured to use WEP, WPA, or WPA2, the “Privacy” subfield in WAP management frames is set to 1.
10. IEEE, “IEEE Standard for Information Technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 6: Medium Access Control (MAC) Security Enhancements,” (July 23, 2004), http://standards.ieee.org/getieee802/download/802.11i-2004.pdf.
802.11 data frames include a “Protected” bit within the first byte offset of the 802.11 MAC framing, which indicates whether encryption is in use. (Remember, when specifying offsets, we begin counting from zero!) The “Protected” bit is set to “1” when WEP, WPA, or WPA2 is enabled. This bit-sized field was previously labeled the “WEP” field, but this name was changed when the 802.11i standard was updated in 2004.11
11. Ibid.
6.1.2.6 TKIP, AES, WPA, and WPA2
Clearly, WEP did not provide the level of protection that its designers had intended. The 802.11 working group had to come up with something better to replace it, but they were also constrained because the replacement protocol had to be compatible with existing networking hardware.
In response, the IEEE 802.11 working group came up with a new protocol that the Wi-Fi Alliance dubbed “Wi-Fi Protected Access” (WPA). WPA was a stop-gap measure designed to deal with some of the weaknesses of WEP, such as key rotation. This was done through the introduction of the Temporal Key Integrity Protocol (TKIP). In 2008 flaws were discovered in TKIP as well, and as a result there are widely available tools that exist to crack WPA pre-shared keys (PSKs).
Happily, the working group also drafted specifications for the use of the “Counter Mode with CBC-MAC Procotol” (CCMP) mode of the Advanced Encryption Standard (AES). This is at the core of the improvements that the Wi-Fi Alliance has termed “WPA2,” which is far more secure (although it requires equipment upgrades over the original equipment). Properly implemented, WPA2 is not known to be broken.
In order for stations to communicate their ability to conform to the new specifications, a new category of functionality was created called robust security networks (RSNs). Stations configured to support RSN associations (RSNAs) such as WPA and WPA2 include RSN information within the tagged parameters of management frames, including Beacons, Association Request, Reassociation Request, and Probe Response. Figure 6-5 shows RSN information displayed in an 802.11 management frame. Forensic investigators can therefore filter traffic to isolate packets that employ specific types of encryption algorithms, or none at all.12
12. Ibid.
Figure 6-5 An 802.11 packet capture displayed in Wireshark. Having filtered down to only management frames, a probe response is selected. The Packet Details panel shows the RSN Information within the tagged parameters, indicating that AES-CCMP is used as the cipher. Note that this is a clear indication that WPA2 is used, and not WPA, since WPA doesn’t support AES-CCMP.
In summary:
• WPA is:
– Designed to work with legacy 802.11 hardware.
– Intended to compensate for keying weaknesses (using TKIP).
– Already broken.
• WPA2 is:
– Required next generation hardware.
– Built to utilize AES-CCMP (real crypto!).
– Currently considered secure when used with strong preshared keys or in combination with strong 802.1X authentication mechanisms.
6.1.3 802.1X
802.1X was designed to provide a modular, extensible authentication framework for LANs (regardless of physical medium). It can be used over wired or wireless networks, and it is designed to control access to the LAN. Forensic investigators should be aware of 802.1X when it is used in the environment under investigation because it limits access to the network and requires a back-end authentication system, that typically stores access logs.
802.1X is the IEEE’s standard for implementing the IETF’s Extensible Authentication Protocol (EAP) over LANs.13 EAP was intended as an improvement to the Point-to-Point Protocol (PPP) methods for authentication. Though initially deployed predominantly as a data link–layer protocol over asynchronous dial-up links, the abandonment of the 56kbps modulator-demodulator (modem) hasn’t spelled the end for PPP. In its many incarnations it remains perhaps the most widely used WAN protocol. PPP over Ethernet (PPPoE)14 is commonly used for DSL circuits. The Evolution-Data Optimized (EV-DO) wireless network—used widely for both smartphones and laptops in the United States—uses PPP over its wireless links as well. As a component of PPP, the Challenge Handshake Authentication Protocol (CHAP) is still widely deployed, as is—regrettably—the Password Authentication Protocol (PAP), which transmits passwords in cleartext.
13. B. Aboba, “RFC 3748—Extensible Authentication Protocol (EAP),” IETF, June 2004, http://rfc-editor.org/rfc/rfc3748.txt.
14. L. Mamakos, “RFC 2516—A Method for Transmitting PPP Over Ethernet (PPPoE),” IETF, February 1999, http://rfc-editor.org/rfc/rfc2516.txt.
RFC 3748 and the IEEE’s 802.1X standards provide a better framework for low-layer authentication. Support for EAP by any Layer 2 device (physically switched or wireless) allows for authentication not by knowledge of a “shared secret” but rather based on a central authentication store. This can be performed over a dial-up link, 802.3 Ethernet, or 802.11 Wi-Fi, among others. The authentication is abstracted, and 802.1X can therefore support a wide range of back-end authentication methods, including “EAP-Transport Layer Security” (EAP-TLS), the “Protected Extensible Authentication Protocol” (PEAP), and the “Lightweight Extensible Authentication Procotol” (LEAP).
6.1.3.1 Impact on Wireless Networks
EAP was not widely used until the weakness of WEP became well known, and there was a scramble to deploy stronger access control mechanisms. Some enterprises responded by deploying 802.1X with Cisco’s LEAP protocol on their wireless networks (and sometimes wired networks as well). LEAP was based on Microsoft’s version of CHAP (MS-CHAP), which does not send authentication credentials in the clear, but which has flaws that allow passwords to be trivially brute-forced.15 Josh Wright’s “asleap”16 tool makes breaking LEAP passwords an academic exercise.
15. B. Schneier and D. Wagner, “Cryptanalysis of Microsoft’s PPTP Authentication Extensions (MSCHAPv2),” Secure Networking—CQRE [Secure]’99 (1999): 782782.
16. Joshua Wright, “asleap—exploiting cisco leap,” May 2, 2009, http://www.willhackforsushi.com/Asleap.html.
PEAP, another proprietary protocol cooperatively designed by Cisco, Microsoft, and RSA Security, tunnels EAP traffic via TLS in order to provide server-to-client authentication, confidentiality, and integrity.
6.1.3.2 Implications for the Investigator
When you encounter an 802.1X implementation, the back-end authentication system in use—whether a RADIUS system or an Active Directory/LDAP server—is much more likely to be producing an audit trail than a stand-alone WAP with a static key shared by all. However, if LEAP is being used for authentication, network compromise due to use of a weak authentication mechanism should be considered a very real possibility.
6.2 Wireless Access Points (WAPs)
A wireless access point (WAP) is a Layer 2 device that aggregates endpoint stations into a LAN. Instead of voltages across a wire, the physical medium is RF through air (or buildings, trees, etc). For WAPs, the physical layer is a shared medium, and as a result all stations have access to all signals traveling across the LAN. This facilitates traffic sniffing in much the same way as with wired hubs. Anyone within range to receive the RF signal can intercept the traffic.
Unlike simple hubs, WAPs have a wide range of configuration options and logging capabilities. Hubs are dumb devices; all they do is replicate traffic. WAPs perform the same function, but are much smarter devices.
Configuration and logging capabilities vary widely across brands and models. Even low-end WAPs generally have built-in web management interfaces, basic logging capabilities, MAC address filtering, and DHCP servers. Higher-end models also function as routers and support syslog and SNMP.
In the enterprise, you will often find a centrally managed wireless network with many distributed WAPs. These systems typically include corresponding software that aggregates logs from all WAPs, which can allow you to gather the connection history for a given MAC address and sometimes view the physical location of the connections on a map. In some cases, you can even reconstruct the route that a wireless client (such as a tablet) took through a building or campus.
On the one hand, we must treat WAPs as a class of hubs whose physical access is nearly unlimited. This makes them a special case. On the other hand, unlike standard hubs, most WAPs bundle functionality that transcends Layer 2. This can include Layer 3 routing, DHCP functionality, Layer 4 NATing, and various sophisticated management capabilities. To complicate matters, WAPs employ a range of different standards for encryption and authentication. Some devices are even based on draft standards that have not yet been finalized (such as 802.11aa).
6.2.1 Why Investigate Wireless Access Points?
Wireless access points are typically involved in forensic investigations for one of a few reasons:
• Wireless access points may contain locally stored logs of connection attempts, authentication successes and failures, and other local WAP activity.
• WAP logs can help you track the physical movements of a wireless client throughout a building or campus.
• The WAP configuration may provide insight regarding how an attacker gained access to the network.
• The WAP configuration may have been modified by an unauthorized party as part of an attack.
• The WAP itself may be compromised.
6.2.2 Types of Wireless Access Points
There are a wide variety of wireless access points available, each with different interfaces and functionality. The sheer variety of WAPs make them challenging for investigators to assess and examine. Remember, any device with an 802.11 card can potentially be made to function as a WAP, and so investigators must be familiar with a wide variety of platforms. General classes of WAPs include enterprise and consumer devices.
6.2.2.1 Enterprise
Enterprise facilities typically span a much wider geographic range than home offices or small businesses. Wireless networks are commonly set up to provide seamless, ubiquitous coverage throughout the environment. Since enterprise IT staff usually deploy many wireless access points, centralized management and integration are important. In the enterprise environment, wireless networks are commonly set up to use central authentication systems. They also include central management consoles that can be used to monitor network state, user activity, or even track wireless clients throughout the physical environment.
Common features of enterprise-class WAPs include:
• Support for IEEE 802.11a/b/g/n
• Physical media is RF waves
• Layer 3+ functionality, including:
– Support for routing protocols
– DHCP
– Network address translation
– Packet filtering
• Centralized authentication
• Auditable access logs (local and central)
• Station location tracking
• Performance monitoring capabilities
• Power over Ethernet (PoE)
• Indoor and outdoor options
The interface options for enterprise-class wireless access points frequently include:17,18
17. “Cisco Aironet 1250 Series Access Point Data Sheet [Cisco Aironet 1250 Series],” Cisco Systems, 2011, http://www.cisco.com/en/US/prod/collateral/wireless/ps5678/ps6973/ps8382/product_data_sheet0900aecd806b7c5c.html.
18. “Products | Aruba Networks,” 2011, http://www.arubanetworks.com/products/.
• Console (command-line interface (CLI))
• Remote console (SSH/Telnet)
• Web interface
• Proprietary interface
• Central management interface
Examples of enterprise wireless access points include the Cisco 3600 AP and Aruba’s AP-135 WAPs for high-density environments.
6.2.2.2 Consumer
Small businesses and home users often deploy consumer-class WAPs in their home and office environments. These devices are inexpensive and easy to configure for simple use.
There are two different kinds of consumer-class wireless access points that an investigator might encounter and need to be concerned with. First, consumers may purchase their own WAPs (or routers with built-in wireless capabilities) from retail stores. These low-end WAPs typically have all the features that you need to easily build a home network or small office to extend or replace wired infrastructure.
Second, WAP functionality is commonly built into DSL modems and cable modems leased from an ISP. In these cases, you may not have legal or technical access to the device without support from the local ISP. Furthermore, it is improtant to keep in mind that these devices are often deployed by ISPs with trivial or default passwords.
Features of consumer-class wireless access points typically include:
• Support for IEEE 802.11a/b/g/n
• Physical media is RF waves
• Often contain Layer 3+ functionality, including:
– Limited routing
– DHCP service
– NATing
– Limited filtering
• Logging (locally and sometimes remotely)
The configuration interface options for consumer-class WAPs are typically limited to a web interface or proprietary application. Examples of consumer-class WAPs are the ubiquitous Linksys WRT54G and the Apple Airport.
Apple Airport Express
Now let’s look at the higher-layer functionality bundled in common consumer WAPs. The first example will be an Apple Airport Express. This is not merely an access point; it also includes DHCP and NAT technology, as well as sophisticated traffic statistics and management capabilities. It may not be the most widely deployed device, but it is a good example of a proprietary interface with many common features.
Figure 6-6 is a screenshot that displays local logs from an Apple Airport Express. (This is from a real production device, so the client addresses have been partially blocked out.)
Figure 6-6 Log entries saved locally on an Apple Airport, accessed through the native, proprietary Airport Utility. These logs can also be exported via Syslog or SNMP.
Linksys WRT54G
The Linksys WRT54G series WAP (Figure 6-7) is one of the most commonly deployed low-cost COTS WAPs, retailing at less than US$60. It is a fairly full-featured router/switch/WAP with a web-based configuration interface that addresses basic setup, wireless setup (including security settings), HTTP URL blocking ability, port-based restrictions, and the ability to backup configurations to a local file.
Figure 6-7 This is one of the second-generation WRT54G wireless routers from Linksys (now Cisco of course). This device is an extremely common sight in homes and small offices, though its slim lines and low profile make it relatively inconspicuous.
However, the web-based interface is not terribly intuitive for laymen, and all the security features that are most critical are disabled by default (hence the proliferation of “linksys” SSIDs with no authentication or encryption enabled). Furthermore, the logging ability of the native firmware is extremely limited in that no remote logging is possible.
One of the things that has made this particular make and its various models so popular is that the firmware is easily flashable. This has opened the devices up to be reprogrammable, and many projects exist that offer replacement software systems for the relatively cheap and capable hardware. Many of these are based on Linux, and so offer much of the capabilities that such distributions have natively, including syslog, packet capturing, robust filtering, and network intrusion detection systems (NIDS).
6.2.3 WAP Evidence
Wireless access points contain both volatile and nonvolatile evidence, although due to their persistent storage capabilities tend to be very limited. WAPs can also send logs over the network to a remote repository.
6.2.3.1 Volatile
As with switches and routers, most of the evidence on WAPs tends to be quite volatile. Enterprise-class WAPs tend to include the same functionality and range of evidence as wired routers, with the addition of wireless-specific capabilities. Evidence that you may find on wireless access points includes:
• History of connections by MAC address
• List of IPs associated with MACs
• Historical logs of wireless events (access requests, key rotation, etc.)
• History of client signal strength (can help identify geographic location)
• Routing tables
• Stored packets before they are forwarded
• Packet counts and statistics
• ARP table (MAC address to IP address mappings)
• DHCP lease assignments
• Access control lists
• I/O memory
• Running configuration
• Processor memory
• Flow data and related statistics
6.2.3.2 Persistent
Again, like wired routers and switches, WAPs are not designed to include much local persistent storage space. The WAP operating system and startup configuration files are maintained in persistent storage by necessity. Persistent evidence you may find on a WAP includes:
• Operating system image
• Boot loader
• Startup configuration files
6.2.3.3 Off-System
Wireless access points can be configured to send event logs to remote systems for off-site aggregation and storage. Syslog and SNMP are commonly supported. Enterprise-class devices may include other options, often proprietary. Check the documentation for the model you are investigating and review local configuration to locate devices that may contain off-system WAP logs.
6.3 Wireless Traffic Capture and Analysis
Capturing and analyzing wireless traffic often provides valuable evidence in an investigation, for the same reasons we discussed in Chapter 3. However, there are some additional complexities involved in capturing wireless traffic, as opposed to sniffing traffic on the wire. In this section, we review some important notes for capturing and analyzing wireless traffic. For further discussion of passive evidence acquisition and analysis, please see Chapter 3, “Evidence Acquisition.”
6.3.1 Spectrum Analysis
There are, literally, an infinite number of frequencies over which data can be transmitted through the air. Sometimes the most challenging part of an investigator’s job is simply identifying the wireless traffic in the first place.
For Wi-Fi traffic, the IEEE utilizes three frequency ranges:
• 2.4 GHz (802.11b/g/n)19
19. IEEE, “IEEE Standard for Information Technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 5: Enhancements for Higher Throughput” (October 29, 2009): Annex J, http://standards.ieee.org/getieee802/download/802.11n-2009.pdf (accessed December 31, 2011).
• 3.6 GHz (802.11y)20
20. IEEE, “IEEE Standard for Information Technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 3: 3650-3700 MHz Operation in USA” (November 6, 2008): Annex J, http://standards.ieee.org/getieee802/download/802.11y-2009.pdf (accessed December 31, 2011).
• 5 GHz (802.11a/h/j/n)21
21. IEEE, “IEEE Standard for Information Technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 5: Enhancements for Higher Throughput” (October 29, 2009): Annex J, http://standards.ieee.org/getieee802/download/802.11n-2009.pdf (accessed December 31, 2011).
Each of these frequency ranges is divided into distinct channels, which are smaller frequency bands (for example, the IEEE has specified 14 channels in the 2.4 GHz range). Although the IEEE has set globally recognized frequency boundaries for 802.11 protocols, individual countries typically allow only a subset of these frequency ranges.
The precise frequencies in use vary by country. For example, the United States only allows WiFi devices to communicate over channels 1–11 in the 2.4 GHz range, while Japan allows transmission over all 14 channels. As a result, WiFi equipment manufactured for use in the United States is generally not capable of transmitting or receiving traffic on all of the channels used in Japan. This has important consequences for forensic investigators. For example, an attacker can purchase a Japanese WAP that supports Channel 14 and plug it into a corporate network in the United States, and U.S. wireless clients will not “see” the access point.
Wireless security researcher Joshua Wright has also published articles about the use of 802.11n in “Greenfield” (GF) mode. 802.11n devices operating in Greenfield mode are not visible to 802.11a/b/g devices. As a result, investigators scanning for wireless devices using 802.11a/b/g cards will not detect the 802.11n network. Please see Section 6.4.2, “Rogue Wireless Access Points,” for more details.
When monitoring for the presence of wireless traffic, make sure that you fully understand the capabilities of your monitoring device, as well as the potential for devices that operate outside your range of detection.
Spectrum analyzers are designed to monitor RF frequencies and report on usage. They can be very helpful for identifying stealthy rogue wireless devices and WiFi channels in use. MetaGeek’s Wi-Spy product line supports the 2.4 GHz and 5 GHz frequency bands (as well as 900 MHz), and range in price from $100 to $1,000. AirMagnet (owned by Fluke Networks) also produces a popular wireless spectrum analyzer that can “identify, name and find: Bluetooth devices, 2.4G cordless phones, microwave ovens, RF Jammers, analog video cameras, etc.”22
22. “WLAN Design, Security and Analysis,” Fluke Networks, 2011, http://www.airmagnet.com/products/spectrum_analyzer/.
6.3.2 Wireless Passive Evidence Acquisition
In order to capture wireless traffic, investigators need an 802.11 wireless card capable of running in Monitor mode. Many wireless cards do not support this capability. Furthermore, in order to ensure totally passive monitoring, it is preferable to use a special-purpose WiFi monitoring card that can be configured to operate completely passively.
Riverbed Technology offers the AirPcap USB adapters, that are designed for exactly this task. The AirPcap USB adapter plugs into a USB port and can monitor Layer 2 WiFi traffic (one channel at a time). AirPcap software runs on Windows, integrates with Wireshark, and can be configured to automatically decrypt WEP-encrypted frames. The AirPcap “Classic” and “Tx” models support the 2.4 GHz 802.11b/g band, while the “Nx” model additionally supports 802.11n. The “Nx” model also includes an external antenna connector.23 Figure 6-8 shows an example of the AirPcap USB dongle.
23. “Riverbed Technology—AirPcap,” 2011, http://www.cacetech.com/products/airpcap.html.
Figure 6-8 The AirPcap USB adapter from Riverbed Technology (previously CACE Technologies).
For Linux users, the AirPcap USB adapter can be used via a modified driver (although the AirPcap software is still Windows-only). Josh Wright provides a patch for the zd1211rw wireless driver, which supports sniffing using the AirPcap dongle.24
24. http://www.willhackforsushi.com/code/zd1211rw-airpcap-linux-2.6.31.diff. (Accessed Jan. 6, 2012.)
Once you have the ability to monitor Layer 2 802.11 traffic, you can use standard tools such as tcpdump, Wireshark, and tshark to capture and analyze it.
Regardless of whether or not a WAP’s traffic is encrypted, investigators can gain a great deal of information by capturing and analyzing 802.11 management traffic. This information commonly includes:
• Broadcast SSIDs (and sometimes even nonbroadcast ones)
• WAP MAC addresses
• Supported encryption/authentication algorithms
• Associated client MAC addresses
Even when the WAP traffic is encrypted, there is a single shared key for all stations. This means that anyone who gains access to the encryption key can listen to all traffic relating to all stations (as with physical hubs). For investigators, this is helpful because local IT staff can provide authentication credentials, which facilitate monitoring of all WAP traffic. Furthermore, there are well-known flaws in common WAP encryption algorithms such as WEP, which can allow investigators to circumvent or crack unknown encryption keys.
Once an investigator has gained full access to unencrypted 802.11 traffic contents, this data can be analyzed in the same manner as any other unencrypted network traffic.
6.3.3 Analyzing 802.11 Efficiently
So, you have some 802.11 frames. During the course of an investigation, you may search for the answers to questions such as:
• Are there any beacons in the wireless traffic?
• Are there any probe responses?
• Can you find all the BSSIDs/SSIDs from authenticated/associated traffic?
• Can you find malicious traffic? What does that look like?
• Is the captured traffic encrypted using WEP/WPA? Is anyone trying to break the encryption?
6.3.3.1 tcpdump and tshark
It’s certainly true that you could use Wireshark to sort out the endianness problem for you, and you could use the graphical interface to try to zero in on the answers to any of the above questions. However, for large packet captures in particular, tcpdump and tshark tend to be more efficient and scalable.
With nothing but a powerful filtering language and an understanding of how 802.11 is structured—and how it transmits the bits—you can very quickly hone in on important wireless traffic. The following discussion presents useful BPF filters and display filters that can be used to filter 802.11 traffic.
Find the WAPs
Finding Beacon frames with tcpdump and BPF filters is straightforward, as shown below. Recall from Section 6.1.2.1 that Beacon frames are a type of management frame (type 0) with subtype 0x08. With a “Version” field of 0b00, the 0-byte offset of the 802.11 frame header (referred to as “wlan[0]”) is 0b00001000. In order of transmission (remember that 802.11 is “mixed-endian”) that becomes 0b10000000, or 0x80.
'wlan[0] = 0x80'
The 802.11 specification includes a 1-bit field called “ESS capabilities,” which has a Wireshark field name of “wlan_mgt.fixed.capabilities.ess.” According to the IEEE’s 802.11 specification, “WAPs set the ESS subfield to 1 and the IBSS subfield to 0 within transmitted Beacon or Probe Response management frames.”25 Let’s use tshark to search for Beacon or Probe Response frames where the ESS subfield is set to 1 and the IBSS subfield is set to 0, as shown below:
25. IEEE, “IEEE Standard for Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications” (June 12, 2007): 251, http://standards.ieee.org/getieee802/download/802.11-2007.pdf. (accessed December 31, 2011).
$ tshark -nn -r wlan.pcap -R '((wlan.fc.type_subtype == 0x08 || wlan.fc.
type_subtype == 0x05) && (wlan_mgt.fixed.capabilities.ess == 1) && (
wlan_mgt.fixed.capabilities.ibss == 0))'
1 0.000000 00:23:69:61:00:d0 -> ff:ff:ff:ff:ff:ff 802.11 105 Beacon frame
, SN=3583, FN=0, Flags=........, BI=100, SSID=Ment0rNet
265 20.409086 00:23:69:61:00:d0 -> 00:11:22:33:44:55 802.11 211 Probe
Response, SN=3801, FN=0, Flags=........, BI=100, SSID=Ment0rNet
270 20.597504 00:23:69:61:00:d0 -> 00:11:22:33:44:55 802.11 211 Probe
Response, SN=3804, FN=0, Flags=........, BI=100, SSID=Ment0rNet
335 23.318463 00:23:69:61:00:d0 -> 00:11:22:33:44:55 802.11 211 Probe
Response, SN=3837, FN=0, Flags=........, BI=100, SSID=Ment0rNet
412 26.317951 00:23:69:61:00:d0 -> 00:11:22:33:44:55 802.11 211 Probe
Response, SN=3873, FN=0, Flags=........, BI=100, SSID=Ment0rNet
[...]
Find the Encrypted Data Frames
Similarly, how can we filter quickly down to encrypted data frames? Just for fun, let’s use a BPF filter to accomplish this. 802.11 data frames are version 0, type 2, subtype 0 (in binary 0b00100000). In order of transmission, the first byte (“wlan[0]”) is 0b00001000, which in hexadecimal is 0x08.
As discussed earlier, the “Protected” bit indicates whether the frame is encrypted using WEP, TKIP, or AES-CCMP. The Protected bit is located at bit 6 of the 1-byte offset of the 802.11 frame (refer to Figures 6-1 and 6-3). With fields reversed within the byte for transmission, the Protected bit is the second bit received in the 1-byte offset (“wlan[1]”). Consequently, we have to construct a bitmask of 0b01000000 (0x40 in hexadecimal) to test whether the Protected bit is set.
The combination of the two tests, shown below, produces all of the encrypted data packets in a given capture!26
26. IEEE, “IEEE Standard for Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications” (June 12, 2007): 60–64.
'wlan[0] = 0x08 and wlan[1] & 0x40 = 0x40'
6.4 Common Attacks
Often, investigators suspect that a wireless network has been or is currently under attack. Common attacks on wireless networks include:
• Sniffing An attacker eavesdrops on the network
• Rogue Wireless Access Points Unauthorized wireless devices that extend the local network, often for an end-user’s convenience
• The Evil Twin Attack An attacker sets up a WAP with the same SSID as a legitimate WLAN
• WEP Cracking An attacker attempts to recover the WEP encryption key to gain unauthorized access to a WEP-encrypted network.
It is important for network forensic investigators to recognize the signs of common attacks. We discuss each of these in detail below.
6.4.1 Sniffing
Eavesdropping on wireless traffic is extremely common, in part because it is so easy to do! From script kiddies in coffeeshops to professional surveillance teams, wireless traffic monitoring is, frankly, popular. Even where it is completely illegal, the risk of detection is exceptionally low, and the information gained can be very valuable. Both forensic investigators and attackers alike know how to passively monitor wireless traffic and use this technique to their advantage.
Wireless LANs, by virtue of their physical medium, can be accessed over great distances. Although WLANs can be designed to serve a specific geographic range, it is challenging for network administrators to limit the signal to that area and prevent leakage.
The FCC stipulates rules that govern the effective range of 802.11 transmissions. Based on these rules, theoretically the distance from which a station can interact with a wireless access point is limited to roughly 200 feet or 61 meters.27 However, directional antennae can be constructed from off-the-shelf components that can dramatically increase the effective ranges. (As we discussed in Section 3.1.2, one research team claimed a successful data transfer of 3Mbps over a distance of 238 miles!28)
27. “Title 47 CFR Part 15: Low Power Broadcast Radio Stations, Audio Division (FCC) USA,” 2011, http://www.fcc.gov/mb/audio/lowpwr.html.
28. Michael Kanellos, “Ermanno Pietrosemoli has set a new record for the longest communication WiFi link,” Historia de Internet en Amrica Latina y el Caribe, June 2007, http://interred.wordpress.com/2007/06/18/ermanno-pietrosemoli-has-set-a-new-record-for-the-longest-communication-wi-fi-link/.
Eavesdropping on telecommunications (including those transmitted over RF) is a violation of wiretap statutes in many jurisdictions. Remember that even stations that are not associated with a wireless network can capture and analyze WAP traffic. Forensic investigators should be aware that an attacker may have access to the network via a WAP, and that they may be able to monitor local traffic or communicate on the LAN from a location far outside what is considered normal range, a great distance away.
6.4.2 Rogue Wireless Access Points
For $40, anyone can purchase a cheap WAP and plug it into the company network. Often, employees do this simply for the sake of convenience, not realizing that it opens the company to attack. Criminals also deliberately plant wireless access points that allow them to bypass the pesky firewall and remotely access the network later on. These days, disgruntled employees can easily hide a WAP behind the file cabinet before cleaning out their desks and then access the company network months later from the parking lot.
Many companies conduct regular “war-walking” scans to detect rogue access points (i.e, using Kismet or NetStumbler) or invest in commercial wireless intrusion detection systems (WIDSs). However, there are sneaky ways to bypass traditional war-walking and WIDSs.
Forensic investigators should be aware of the methods that attackers can use to place rogue access points and evade detection. Rogue access points can be used to covertly extend the range of an internal network, facilitating access from far outside the physical bounds that network administrators might expect. Rogue access points may also allow for untracked LAN access, and act as a pivot point for attacks.
Conversely, in certain situations a forensic investigator may be charged with monitoring a network in which the network administrators are hostile or unaware of the investigation. In these circumstances, where law and ethics allow, it may be the forensic investigator employing these same techniques for the purposes of covert monitoring and evidence acquisition.
6.4.2.1 Changing the Channel
In the United States, the FCC has licensed 11 channels for 802.11b/g/n, which have center frequencies between 2.412 GHz to 2.462 GHz. However, most of Europe allows 13 channels (up to 2.472 GHz) and Japan allows 802.11b all the way up to channel 14, or 2.484 GHz.29
29. “List of WLAN channels—Wikipedia, the free encyclopedia.”
Cards manufactured for the United States often don’t support channel 14, since it’s illegal to transmit on that frequency. There’s overlap between the channels, but at 2.484 GHz, channel 14 is far enough away from channel 11 that network cards are unlikely to pick up much signal on channel 11. If an attacker were to configure a WAP to illegally transmit on channel 14 and export data at 2.484 GHz, security teams monitoring U.S. channels would probably never detect it.
Similar tactics are effective in other countries, when attackers use frequencies outside the bounds of normal wireless device operation.
6.4.2.2 802.11n Greenfield Mode
The IEEE’s 802.11n (“MIMO”-based) specification is designed to allow much greater throughput than 802.11a/b/g (100Mbps or more).30 The 802.11n standard specifies two modes:31
30. Joshua Wright, “Wireless Ethical Hacking, Penetration Testing, and Defense: Wireless Architecture & Analysis,” The SANS Institute, 2008.
31. IEEE, “IEEE Standard for Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, Amendment 5: Enhancements for Higher Throughput” (October 29, 2009), http://standards.ieee.org/getieee802/download/802.11n-2009.pdf (accessed December 31, 2011).
• “Mixed mode,” which allows it to work with legacy 802.11a/b/g networks,
• “Greenfield” (GF) or “high-throughput-only” mode, which takes full advantage of the enhanced throughput but is not visible to 802.11a/b/g devices. Older devices will see GF-mode traffic only as noise.
Not visible to 802.11a/b/g devices? That means if you’re war-walking with an 802.11a/b/g card, you can’t see 802.11n devices operating in Greenfield (GF) mode. Even before the specification was finalized, 802.11n devices were already available for as little as $50—easy to buy, easy to plug into the company’s network. However, many companies have not yet purchased 802.11n-compatible equipment and hence cannot detect GF-mode 802.11n rogue WAPs.
Josh Wright submitted a vulnerability report explaining this, in which he wrote: “With the inability to decode GF mode traffic, an attacker can position a malicious rogue WAP on a victim network using the GF mode preamble. This would allow an attacker to evade wireless intrusion detection systems (WIDS) based on non-HT devices. This includes all WIDS devices based on 802.11a/b/g wireless cards.”32
32. Joshua Wright, “GF Mode WIDS Rogue AP Evasion,” Wireless Vulnerabilities and Exploits, November 13, 2006, http://www.wirelessve.org/entries/show/WVE-2008-0005.
6.4.2.3 Bluetooth Access Point
When you think about Bluetooth, you probably envision your tiny little headset that crackles and hisses every time you walk too far away from your phone. That’s because your Bluetooth headset is designed for a Class 2 Bluetooth network, which is fairly low-power (2.5mW) and has a maximum range of about 9m.33
33. Karen Scarfone and John Padgette, “Guide to Bluetooth Security: Recommendations of the National Institute of Standards and Technology,” Special Publication 800-121, National Institute of Standards and Technology, September 2008, http://csrc.nist.gov/publications/nistpubs/800-121/SP800-121.pdf (accessed December 31, 2011).
However, there’s more to Bluetooth than your rinky-dink headset. Bluetooth Class 1 devices are much more powerful, with ranges similar to 802.11b WAPs. A Bluetooth Class 1 device can transmit up to 100mW, with a typical range of up to about 91m (or possibly miles, if the receiver has a directional antenna). You can buy a Class 1 Bluetooth WAP for $100–$200.34
34. Ibid.
Can you discover Bluetooth WAPs while war-walking? Not if you’re just using an 802.11 card. Even if you’re using a spectrum analyzer like WiSpy, you may not notice it. Bluetooth uses Frequency Hopping Spread Spectrum,35 and hops 1,600–3,200 times a second across 79 channels throughout the 2.4–2.4835 GHz band. Because it’s spread out across the spectrum, it can be hard to notice and easily mistaken for noise by the untrained eye. Most Wireless IDS systems and security teams simply don’t look for it (yet).36,37
35. Sherri Davidoff, “Philosecurity, Blog Archive: Off the Grid,” July 28, 2008, http://philosecurity.org/2008/07/28/off-the-grid.
36. Joshua Wright, “Wireless Ethical Hacking, Penetration Testing, and Defense: Wireless Security Exposed, Part 4,” The SANS Institute, 2008.
37. Karen Scarfone and John Padgette, “Guide to Bluetooth Security: Recommendations of the National Institute of Standards and Technology,” Special Publication 800-121, National Institute of Standards and Technology, September 2008, http://csrc.nist.gov/publications/nistpubs/800-121/SP800-121.pdf (accessed December 31, 2011).
6.4.2.4 Wireless Port Knocking
Remember port knocking? Instead of installing a backdoor to listen on a particular port (where it might be noticed), l33t h4x0rs installed rootkits that would wait for a particular sequence of ports to be scanned, at which point the knocker’s IP address would be granted access. With wireless knocking, a rogue WAP sits on the network in monitor mode, listening for probe requests. When the rogue WAP receives a packet (or sequence of packets) with the preconfigured SSID, it awakens and switches to master mode. The program “WKnock” is designed for this purpose,38 and it can be installed on any WAP supported by the OpenWRT framework. During times when the rogue WAP isn’t active, it is silent and can’t be detected using common wireless scanning tools. Sneaky!39
38. “rstack: wknock,” 2011, http://rstack.org/oudot/wknock.
39. Oudot Laurent, “WLAN and Stealth Issues,” 2005, http://www.blackhat.com/presentations/bh-europe-05/BH_EU_05-Oudot/BH_EU_05-Oudot.pdf.
6.4.3 Evil Twin
The “Evil Twin” attack is when an attacker sets up a WAP with the same SSID as one that is used in the local environment, usually in order to conduct a man-in-the-middle attack on an 802.11 client’s traffic.
By default, commercial 802.11 clients associate with the SSID that their operators tell them to. If there is more than one WAP with the same SSID, as will be the case with most centrally-managed wireless network (either corporate or in a Wi-Fi “hotspot”) then the client will associate with the WAP providing the strongest signal. When the Evil Twin’s signal strength is stronger than the “real” WAP, 802.11 clients will associate with the Evil Twin.
It is trivial for any 802.11 device to masquerade as the closest infrastructure WAP for any given SSID. Any 802.11 device can be made to advertise itself as an available peer. These advertisements can be of two kinds: ad-hoc and infrastructure. By default, commercial WAPs are infrastructure devices and, by default, most commercial operating systems that support 802.11 networking devices allow them to advertise as ad-hoc networks for peer-to-peer purposes. However, it is not difficult to switch an 802.11 interface on a desktop or laptop into infrastructure mode. With Linux, it’s as easy as a single “iwconfig” command.
The “Evil Twin” ruse allows any sufficiently strong 802.11 broadcaster to become a “man-in-the-middle” between the unwitting client and every other system that it communicates with. Sufficiently strong broadcasting can be accomplished over surprisingly wide geographic areas.
Once a client has connected to the “Evil Twin,” the attacker can intercept traffic, replace images or words on the fly, conduct SSL-stripping attacks, harvest credentials, and more.
6.4.4 WEP Cracking
Security professionals often joke that “WEP” stands for “Weak Encryption Protocol.” This isn’t far off the mark (although “WEP” really stands for “Wired Equivalent Privacy,” as we discussed earlier). Due to flaws in the protocol, there are tools that can help attackers “crack” WEP keys in minutes, and thereby gain access to any WEP-protected network or packet capture.
WEP is designed to encrypt the payload of data frames on a wireless network using a shared key. The key, once selected, is distributed to all stations as a “pre-shared key” (PSK). The PSK itself is never exposed on the network, and so it is expected to be shared in some out-of-band way between the stations that need it.
Each station encrypts the payload of all data frames with the PSK and a randomly selected initialization vector (IV) so that the encryption key changes for every frame. The problem with using an IV in a reversible, symmetric encryption algorithm, such as RC4, is that stations have to supply the IV in plain text. Each station adds a cleartext 24-bit IV to each frame, but 24 bits is actually quite small when you consider the number of frames that can be transmitted across a WLAN. With only 24 bits of IV, the randomized values are bound to repeat at some point, given enough traffic. (This is guaranteed to happen after 224—or 16,777,216—frames. With a “maximum transmit unit” (MTU) of 1,500 bytes, that’s less than 24GB of network data.)
As it turns out, however, after only a few thousand packets you can reliably guess that at least some of those packets have been encrypted with the same IV, but have different plain text input and ciphertext output. This enables attackers to leverage the “related-key attack”, based on the knowledge of some of the bits of the key material.
An attacker’s ability to leverage the related key attack depends on the volume of IVs exposed. On a quiet network, it may take weeks to capture enough IVs to crack the key. Fortunately for the attacker (unfortunately for the rest of us), there are weaknesses in WAP behaviors and implementations that allow attackers to force stations on a WLAN to generate large volumes of IVs. Using widely published tools, attackers can force the generation of enough IVs to crack a WEP key within minutes—even on an unused WLAN.
If you see anomalous behavior from an unknown station on a WEP-encrypted WAP, it could be that the station is attempting to crack the WEP key in order to gain access to the network. Commonly, WEP-cracking tools used on relatively quiet networks are designed to force local stations to generate unnecessary packets, with lots of IVs to speed cracking.
6.5 Locating Wireless Devices
Perhaps the single most challenging aspect of wireless networks for the investigator is the inherent difficulty in physically locating devices of interest. A compromised laptop may physically move throughout an enterprise’s network; a rogue wireless access point may be hidden in crafty places like under ceiling tiles.
Strategies for locating wireless devices include:
1. Gather station descriptors, such as MAC addresses, which can help provide a physical description so that you know what to look for;
2. For clients, identify the WAP that the station is associated with (by SSID);
3. Leverage commerical enterprise wireless mapping software;
4. Poll the device’s signal strength; and
5. Triangule on the signal.
Of course all of this takes time, and is far more challenging if the device sought for is mobile and only transiently on the network—exactly the sort of thing that Wi-Fi networks were designed to accommodate.
6.5.1 Gather Station Descriptors
You can learn a lot about what a wireless device probably looks like from its network traffic. For example, recall our earlier discussion from Chapter 4, “Packet Analysis,” in which we learned that every network card is assigned a unique OUI by the manufacturer. The 802.11 frame indicates the source and destination station MAC addresses. (For wireless access points, the “BSSID” field in the 802.11 header is also the MAC address of the WAP’s network card.) Although MAC addresses can be changed, in most cases, no one bothers to change them. Hence, from sniffing Layer 2 network traffic and examining the MAC addresses in 802.11 frames of interest, you can make an educated guess as to the manufacturer of the device generating the traffic. Figure 6-9 shows the 802.11 frame of traffic between an Apple device and a Cisco WRT54G wireless router. Note that Wireshark automatically translates the OUI into a manufacturer description.
Figure 6-9 An 802.11 frame from an Apple device to a Cisco wireless router. Note that Wireshark automatically translates the OUI into a human-readable manufacturer description.
The content of wireless traffic itself can provide a surprising amount of insight regarding the physical description of a device. In Figure 6-10, we were able to crack the WEP key of the wireless traffic and decrypt the contents of the data frames. Now, we can see the contents of communications between the Apple device and its Layer 3 endpoint (routed through the Cisco WAP, of course). The traffic includes HTTP data, which contains User-Agent headers sent by the Apple device. The frame highlighted in Figure 6-10 reveals a User-Agent string “iTunes-iPad/3.2.1 (16GB).” That’s handy! Now we know that we’re most likely looking for a 16GB iPad, running OS version 3.2.1. This evidence correlates nicely with the Apple MAC address we examined moments ago.
Figure 6-10 With the packet capture WEP-decrypted, we can see the User-Agent client-side HTTP header, which seems to confirm that the device is indeed an Apple.
6.5.2 Identify Nearby Wireless Access Points
Your strategy for locating a wireless device will depend in part on the function of the device. For example, you may be searching for a rogue wireless access point or a roving endpoint station. In the case where you are searching for a client station that is actively associating with other WAPs, it is often helpful to identify which WAPs the station is associating with. Generally (although not always), endpoint stations associate with a wireless access point that is physically close by. In the case of a wireless bridged network, clients typically associate with the WAP in the bridged network that has the strongest signal, which is also often physically closest.
There are basically two ways to find out which WAPs a rogue endpoint client is associated with or attempting to associate with: WAP logs and traffic monitoring.
If you are lucky enough to be in an environment that captures wireless authentication attempts on a central logging system, you may be able to watch station association requests and responses by examining logs on the central server.
Otherwise, you can passively monitor the wireless traffic for association requests, responses, and other Layer 2 traffic related to the MAC address of interest. Generally, this requires that either you know the general vicinity of the rogue device already and can sniff traffic in that area, or that you have access to a wireless intrusion detection system with sensors distributed around a wide area.
In this way, you can track the station as it moves from device to device and locate the client using locations of known WAPs.
6.5.3 Signal Strength
There are many tools such as NetStumbler or Kismet that will list the nearby wireless access points and show you their relative signal strengths. Often, you can locate a mysterious wireless device simply by viewing the signal strengths using one of these applications and walking in the direction of increasing signal strength. This works well in situations where the station of interest is not mobile.
6.5.3.1 Received Signal Strength Indication (RSSI)
It is sometimes possible to see both the IEEE 802.11 Received Signal Strength Indication (RSSI) and the Transmit (Tx) Rate information when viewing a packet capture—but only if the tool that captured the packets supplies that data in its own additional framing. The 802.11 specification simply doesn’t include such information in the data link–layer header.
If available, per-frame RSSI and Tx Rate information can be added manually to Wireshark’s Packet List pane by editing user preferences.40
40. A. Orebaugh et al., Wireshark & Ethereal: Network Protocol Analyzer Toolkit (Syngress, 2006).
6.5.3.2 NetStumbler
NetStumbler41 is a Windows tool designed to discover 802.11 networks. Though it is extremely popular for blackhats and whitehats alike, it is not totally passive, which means that its presence and activities can be detected by other wireless auditing tools. Like most tools of its kind, it supports GPS integration for the mapping of signals to physical locations, making it useful for “wardriving” or “warwalking.” NetStumbler is free for download, though not open source.
41. Mariusm, “stumbler dot net,” February 16, 2010, http://www.stumbler.net/.
Due to considerable architectural differences between XP and Vista/Windows 7, NetStumbler does not work on the latter. Vistumbler is a similar tool designed to run on Vista, though provided by different authors, and so it has a different user interface and functionality.42,43 A more popular replacement for all three platforms is inSSIDer.44
42. Ibid.
43. “Vistumbler,” December 12, 2010, http://vistumbler.sourceforge.net/.
44. “inSSIDer,” http://www.metageek.net/products/inssider/.
6.5.3.3 Kismet
Kismet is a free, open source 802.11 discovery tool for Mac OS X that supports the same essential features as NetStumbler for Windows. It is capable of being totally passive. In addition to providing support for many attacks against authentication and encryption, it boasts the following features:45
45. “Kismet,” 2011, http://www.kismetwireless.net/.
• Wireshark- and tcpdump-compatible data logging
• Network IP range detection
• Hidden network SSID decloaking
• Graphical mapping of networks
• Manufacturer and model identification of access points and clients
• Detection of known default access point configurations
• Runtime decoding of WEP packets for known networks
• Named pipe output for integration with other tools, such as a Layer 3 IDS like Snort
• Distributed remote drone sniffing
• XML output
• Over 20 supported card types
6.5.3.4 KisMAC
KisMAC is a free, open source 802.11 discovery tool for Mac OS X, which is open source and supports the same essential features as NetStumbler for Windows. However, KisMAC supports totally passive scanning, meaning that it can merely observe RF traffic without emitting any RF itself. KisMAC boasts the following features and attack strategies:46
46. “kismacng,” January 2011, http://trac.kismac-ng.org/.
Features:
• Reveals hidden/cloaked/closed SSIDs
• Shows logged-in clients (with corresponding MAC addresses, IP addresses, and signal strengths)
• Mapping and GPS support
• Can draw area maps of network coverage
• PCAP import and export
• Support for 802.11b/g
• Different attacks against encrypted networks
• AppleScript-able
• Kismet drone support (capture from a Kismet drone)
Crypto attack support:
• Bruteforce attacks against LEAP, WPA, and WEP
• Weak scheduling attack against WEP
• Newsham 21-bit attack against WEP
6.5.4 Commercial Enterprise Tools
Enterprises that deploy campus-wide wireless LANs often install central management consoles, which include mapping and station tracking capabilities. Vendors such as Aruba and Cisco offer specialized wireless tracking and WIDS software for use in these environments.
For example, organizations can deploy a mesh of access points throughout their facilities using Cisco products. The access points are controlled by Cisco Wireless LAN Controllers, which in turn can be centrally managed through the Cisco Wireless Control System (WCS). The WCS can display the location of a wireless device on floor maps that have been uploaded to the system and preconfigured by network administrators. The Cisco Wireless Location Appliance (WLA) has even greater wireless device tracking and searching capabilities. The WLA receives data from the Wireless LAN Controllers, and uses this to provide network administrators with a central console for tracking wireless devices throughout the enterprise.47 Figure 6-11 shows a screenshot of devices located on an enterprise floor map. Known devices are marked with a box, while “rogue” devices are labeled with a skull.
47. “Cisco 2700 Series Wireless Location Appliance Deployment Guide [Cisco Wireless Location Appliance],” Cisco Systems, 2011, http://www.cisco.com/en/US/docs/wireless/technology/location/deployment/guide/depgd.html.
Figure 6-11 A screenshot of Cisco’s Wireless Location Appliance, which displays devices located on an enterprise floor map and allows system administrators to search and sort. This is WLA’s main view, listing stations detected, BSSID, signal strength, and more. Known devices are marked with a box, while “rogue” devices are labeled with a skull. Courtesy of Cisco Systems, Inc. Unauthorized use not permitted.49
6.5.5 Skyhook
Skyhook Wireless Positioning System (WPS) is a proprietary location tracking service provided by Skyhook Wireless. It is an extremely popular alternative to GPS, especially because it works well indoors and can provide results with 10–30m of accuracy in urban environments where GPS is less effective. For years, the company has employed hundreds of “data specialists” to wardrive and collect BSSIDs for beaconing WAPs and cell tower IDs, along with corresponding GPS data.48 Using this information, they have compiled an intensive database. When a client queries the Skyhook API in order to determine its own location, it sends information about surrounding wireless devices and cell towers to Skyhook’s Location Server. The Location Server searches the database for matches and provides the client with the corresponding GPS coordinates.
48. “Skyhook: How It Works,” http://www.skyhookwireless.com/howitworks/.
49. “Cisco 2700 Series Wireless Location Appliance Deployment Guide [Cisco Wireless Location Appliance],” Cisco Systems, 2011, http://www.cisco.com/en/US/docs/wireless/technology/location/deployment/guide/depgd.html#wp37848.
Popular products that use the Skyhook WPS include Apple iPhones, which have a “Locate Me” feature, and Eye-Fi SD cards, which tag photos taken by digital cameras with their GPS coordinates.
In 2008, several researchers published articles describing how to leverage the Skyhook system in order to get GPS coordinates of arbitrary MAC addresses.50 With knowledge of a WAP’s MAC address, third parties can query the Skyhook system to obtain a location from Skyhook’s highly granular database.51 This may or may not be legal, depending on your purposes and the laws in your area. However, you may be involved in an investigation where there is a legitimate need and legal way to query the Skyhook API for an arbitrary MAC address.
50. thebmxr, “Don’t Locate Me,” 2011, http://thebmxr.googlepages.com/Don_t_Locate_me.pdf.
51. Coderrr, “Get the Physical Location of Wireless Router from Its MAC Address (BSSID),” September 10, 2008, http://coderrr.wordpress.com/2008/09/10/get-the-physical-location-of-wireless-router-from-its-mac-address-bssid/.
6.6 Conclusion
With the explosion of mobile devices and wireless deployments in enterprises and homes, forensic investigators are increasingly tasked with examining wireless traffic and devices. Compared with wired Ethernet networks, wireless networks pose special challenges. For example, the 802.11 data link–layer protocol suite is fundamentally different from Ethernet, and even details such as the order that bits are transmitted may surprise network forensics investigators used to Ethernet traffic analysis.
In this chapter, we studied the IEEE’s 802.11 protocol series, including encryption algorithms and their flaws. We talked about the types of evidence that you can gather from wireless access points, and touched on wireless traffic capture and analysis. We reviewed common attacks on wireless networks that investigators should be familiar with so that you can recognize them in the field. Finally, we discussed one of the most common hurdles facing wireless network forensic investigators: locating wireless devices. The very feature that makes wireless networks so popular—client mobility—is perhaps our biggest investigative challenge.
6.7 Case Study: HackMe, Inc.
6.7.1 Inspecting the WAP
The most obvious place to begin analysis is Joe’s WAP. Along the way we expect—or at least hope—to learn something about the stations with which it was communicating, and to be able to infer a whole lot from the anomalous traffic we’re about to examine. Let’s begin by identifying and inspecting the WLAN under investigation.
6.7.1.1 Inspecting Beacon Frames
Probably the most straightforward way to identify the WAPs in a packet capture is to simply filter on Beacon frames. Figure 6-12 demonstrates how Wireshark can be used with a display filter on the appropriate frame type (0) and subtype (8): “wlan.fc.type_subtype == 0x08.” Note also the “BSS Id” in the frame: 00:23:69:61:00:d0.
Figure 6-12 An 802.11 management frame shown in Wireshark. As you can see in the Packet Details pane, this frame is type 0, subtype 8: a Beacon frame.
Using tcpdump with the BPF language, we can easily find this Beacon frame too, so long as we mind our endianness:
$ tcpdump -nne -r wlan . pcap 'wlan[0] = 0x80'
reading from file wlan . pcap, link - type IEEE802_11 (802.11)
09:56:41.085810 BSSID:00:23:69:61:00:d0 DA:
ff:ff:ff:ff:ff:ff SA:00:23:69:61:00:d0 Beacon ( Ment0rNet ) [1.0* 2.0* 5.5*
11.0* 18.0 24.0 36.0 54.0 Mbit ] ESS CH: 2, PRIVACY
We see the same BSSID as before, and some other useful information (SSID, channel, etc.). But what if the WAP of interest was specifically configured not to send Beacon frames? That’s not as big a problem for us as many people might think.
6.7.1.2 Filter on WAP-Announcing Management Frames
Let’s use our tshark invocation from Section 6.3.3.1 to filter traffic and display only Beacon and Probe Response frames that have the ESS subfield set to 1 and the IBSS subfield set to 0. (Recall that, by specification, WAPs set these fields accordingly.) Even if a WAP is not broadcasting Beacon frames, it may still send Probe Responses to stations that initiate Probe Requests.
$ tshark -nn -r wlan . pcap -R '((wlan.fc.type_subtype == 0x08 || wlan.fc.
type_subtype == 0x05) && (wlan_mgt.fixed.capabilities.ess == 1) && (
wlan_mgt.fixed.capabilities.ibss == 0))'
1 0.000000 00:23:69:61:00:d0 -> ff:ff:ff:ff:ff:ff 802.11 105 Beacon frame
, SN=3583, FN=0, Flags=........, BI=100, SSID=Ment0rNet
265 20.409086 00:23:69:61:00:d0 -> 00:11:22:33:44:55 802.11 211 Probe
Response, SN=3801, FN=0, Flags=........, BI=100, SSID=Ment0rNet
270 20.597504 00:23:69:61:00:d0 -> 00:11:22:33:44:55 802.11 211 Probe
Response, SN=3804, FN=0, Flags=........, BI=100, SSID=Ment0rNet
335 23.318463 00:23:69:61:00:d0 -> 00:11:22:33:44:55 802.11 211 Probe
Response, SN=3837, FN=0, Flags=........, BI=100, SSID=Ment0rNet
412 26.317951 00:23:69:61:00:d0 -> 00:11:22:33:44:55 802.11 211 Probe
Response, SN=3873, FN=0, Flags=........, BI=100, SSID=Ment0rNet
[...]
As you can see in Figure 6-13, you can use the same display filter in Wireshark to find Beacon or Probe Response frames that emanate from WAPs. To list the BSSIDs of the known WAPs in the packet capture, let’s use tshark along with some simple shell scripting. In the command below, we tell tshark to print only the BSSID field (“wlan.bssid”), and then we use the Linux tool “uniq” to get a count of the number of occurrances of each BSSID.
$ tshark -nn -r wlan.pcap -R '((wlan.fc.type_subtype == 0x08 || wlan.fc.
type_subtype == 0x05) && (wlan_mgt.fixed.capabilities.ess == 1) && (
wlan_mgt.fixed.capabilities.ibss == 0))' -T fields -e wlan.bssid | uniq -c
174 00:23:69:61:00:d0
Figure 6-13 A screenshot of Wireshark used with a display filter that tests for frames that emanate from WAPs. The display filter used is “((wlan.fc.type_subtype == 0x08 
wlan.fc.type_subtype == 0x05) && (wlan_mgt.fixed.capabilities.ess == 1) && (wlan_mgt.fixed.capabilities.ibss == 0)).”
As you can see, only one WAP sent Beacon or Probe Response frames in the packet capture—and it sent 174 of these frames. This WAP had the BSSID “00:23:69:61:00:d0.” We can confirm with Joe that that is indeed the BSSID printed on the label that Linksys put on the device, and that it is configured with the SSID “Ment0rNet.”
6.7.1.3 Take Inventory of Stations on the WLAN
Returning to the Beacon frame from earlier, let us inspect it further with Wireshark so that we can record a few more details about the WLAN that we may need later (and perhaps even create some display filters we can use later on with “tshark” to speed things up). Along the way we’ll answer a number of the questions posed in the challenge.
Figures 6-14, 6-15, and 6-16 highlight the BSSID, SSID, and channel, respectively. In these frames, we see that the WAP’s BSSID is “00:23:69:61:00:d0,” the SSID is “Ment0rNet,” and the WAP is operating on channel 2.
Figure 6-14 An 802.11 management frame with subtype 0x8 (a Beacon frame). The BSSID (00:23:69:61:00:d0) is highlighted.
Figure 6-15 An 802.11 management frame with subtype 0x8 (a Beacon frame). The SSID parameter set is shown, with the tag interpretation (“Ment0rNet”) highlighted.
Figure 6-16 An 802.11 management frame with subtype 0x8 (a Beacon frame). The field containing “Current Channel” (channel 2) is highlighted.
6.7.1.4 WLAN Encryption
Is the WLAN using encryption? Yes, it does appear to be. To answer this question, first, we can ask Wireshark to show us only the data frames: “wlan.fc.type_subtype == 0x20.” Figure 6-17 shows an example of a data frame. Notice the Protected bit (highlighted) is set to 1.
Figure 6-17 An 802.11 data frame shown in Wireshark. Notice that the “Protected” flag (highlighted) is set, indicating that the data is encrypted.
Using tcpdump and some BPF inspection, we can easily demonstrate that all the data frames in the capture are WEP protected. First, let’s count the data frames. By filtering on the version (0), type (2) and subtype (0) in the first byte of the frame (the byte at “offset zero”), and sending the output to the “wc” command to count lines, we get 59,274 total data frames:
$ tcpdump -nne -r wlan.pcap 'wlan[0] = 0x08'|wc -l
reading from file wlan.pcap, link-type IEEE802_11 (802.11)
59274
Next, let’s also filter on the “Protected” bit in the next byte (again, keeping in mind the endianness of the bits in transmission):
$ tcpdump -nne -r wlan.pcap 'wlan[0] = 0x08 and wlan[1] & 0x40 = 0x40'|wc -l
reading from file wlan.pcap, link-type IEEE802_11 (802.11)
59274
The resulting count of data frames is the same with or without a filter on a positive value for the “Protected” bit: 59,274. This means that all 59,274 data frames are also encrypted.
6.7.1.5 Associated Stations
Using Wireshark, we can easily construct a filter on the Association Response subtype of the management frames, and further filter on the 2-byte status code indicating successful association: “wlan.fc.type_subtype == 0x01 && wlan_mgt.fixed.status code == 0x0000.” Presumably the source of such frames should all be our known BSSID, and the various destinations would be the stations that successfully associated. Figure 6-18 illustrates this approach, as well as the large number of frames which show successful association.
Figure 6-18 So very many successful association messages . . .
With a little bit of tcpdump and BPF language, and some more command-line fu, we can aggregate data from these frames in a useful way. We begin by filtering on the version/type/subtype byte for the appropriate value for an Association Response (0x01, which translates to 0x10 in transmission order), and then locate the 2-byte field that indicates the status code (the 2 bytes starting at the 26th byte offset (remember, counting from 0)).
In the tcpdump output produced by the command below, the destination MAC address is the third field. We use the “awk” command to print only the third field, and then send these values line-by-line to “sort,” whose output then allows the “uniq” program to aggregate and count them. By sending the remaining output through the last “sort” invocation, we can see them listed in order of frequency.
$ tcpdump -nne -r wlan.pcap 'wlan[0] = 0x10 and wlan[26:2] = 0x0000 '|awk '{
print $3}'|sort|uniq -c|sort -nr
reading from file wlan.pcap, link-type IEEE802_11 (802.11)
68 DA:1c:4b:d6:69:cd:07
4 DA:00:11:22:33:44:55
1 DA:de:ad:be:ef:13:37
It seems that Joe successfully associated four times, an unknown station with the MAC address of “de:ad:be:ef:13:37” associated once, and another unknown station with the MAC address of “1c:4b:d6:69:cd:07” successfully associated 68 times. That seems a bit odd.
6.7.2 Quick-and-Dirty Statistics
Let’s gather some statistics on the traffic in this packet capture in order to better understand the actors and time frame.
6.7.2.1 Who Are the People in Your Neighborhood?
Let’s look again at the encrypted data frames. How many encrypted data frames are there? Who are they coming from and where are they going? Are there any that seem unusual?
Tshark is an excellent tool to help us look at statistics, as well as individual packets. Let’s begin by trying out a display filter that should provide a known result: the number of protected data frames in the capture. Since we know the BSSID of the WAP that is the focus of our investigation (00:23:69:61:00:d0), we will include the filter “wlan.bssid == 00:23:69:61:00:d0” in our tshark invocations in order to narrow the scope to our identified target of interest.
Note that in the display filter below, we specify the value of the type/subtype fields as the appear in the protocol specification (0x20), NOT the order in which they are transmitted (0x08). This is an important difference between the display filters we use with tshark/Wireshark and the BPF filters we used previously with tcpdump.
$ tshark -r wlan.pcap -R '((wlan.fc.type_subtype == 0x20) && (wlan.fc.
protected == 1)) && (wlan.bssid == 00:23:69:61:00:d0)'|wc -l
59274
That number corresponds with the results of our previous inspection. From there, we can begin to use tshark to extract individual fields from the WLAN protocol for aggregation and comparison. This invocation, the end of which should be familiar now, shows us an aggregated count of the number of encrypted data frames transmitted from each MAC address:
$ tshark -r wlan.pcap -R '((wlan.fc.type_subtype == 0x20) && (wlan.fc.
protected == 1)) && (wlan.bssid == 00:23:69:61:00:d0)' -T fields -e wlan.
sa|sort|uniq -c|sort -nr
42816 1c:4b:d6:69:cd:07
14127 00:11:22:33:44:55
1574 00:23:69:61:00:ce
757 de:ad:be:ef:13:37
In the example above, by extracting only the “sending address” field of the WLAN protocol (“wlan.sa”) from the data frames, and sorting and counting their occurrences, we can see that one of our unknown stations (1c:4b:d6:69:cd:07) sent roughly three times the number of data frames as Joe’s station during the same time period.
We also see a source of “00:23:69:61:00:ce,” which differs from the WAP’s BSSID by only the last octet. It’s interesting that this MAC address is very similar to that of the WAP’s BSSID. Recall that WAPs typically serve at least two functions: First, they provide access to wireless distribution services, and second, they act as stations on the network which provide services for WAP management, DHCP, logging, and other functionality. It is common to see different addresses used for different purposes. In this case, let’s hypothesize that the similarity between the MAC address “00:23:69:61:00:ce” and the WAP’s BSSID (00:23:69:61:00:d0) is not a coincidence. It is likely that “00:23:69:61:00:ce” is the WAP’s MAC address which it uses to participate as a logically distinct station in the wireless network. We will henceforth refer to this informally as the WAP’s “station” (STA) interface.52
52. IEEE, “IEEE Standard for Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications” (June 12, 2007): 40–41, http://standards.ieee.org/getieee802/download/802.11-2007.pdf (accessed December 31, 2011).
Last but not least, we also see a few data frames from the odd MAC address, “de:ad:be:ef:13:37.”
What if we were to look at the comparative count of frame destination addresses (“wlan.da”) in the same fashion?
$ tshark -r wlan.pcap -R '((wlan.fc.type_subtype == 0x20) && (wlan.fc.
protected == 1)) && (wlan.bssid == 00:23:69:61:00:d0)' -T fields -e wlan.
da|sort|uniq -c|sort -nr
42837 ff:ff:ff:ff:ff:ff
14816 00:23:69:61:00:ce
858 00:11:22:33:44:55
654 de:ad:be:ef:13:37
59 01:00:5e:7f:ff:fa
25 33:33:00:00:00:02
17 33:33:00:00:00:16
6 33:33:ff:33:44:55
2 33:33:ff:ef:13:37
Interesting: The results shown above indicate that approximately 42,837 encrypted data frames were sent to the broadcast MAC address (ff:ff:ff:ff:ff:ff). This is almost the same as the number of frames sent from station 1c:4b:d6:69:cd:07. Similarly, station 00:23:69:61:00:ce (likely the WAP’s STA interface) received roughly the same number of encrypted data frames as Joe’s station (00:11:22:33:44:55). Coincidence?
Let’s look at both source and destination:
$ tshark -r wlan.pcap -R '((wlan.fc.type_subtype == 0x20) && (wlan.fc.
protected == 1)) && (wlan.bssid == 00:23:69:61:00:d0)' -T fields -e wlan.
sa -e wlan.da|sort|uniq -c|sort -nr
42816 1c:4b:d6:69:cd:07 ff:ff:ff:ff:ff:ff
14076 00:11:22:33:44:55 00:23:69:61:00:ce
858 00:23:69:61:00:ce 00:11:22:33:44:55
740 de:ad:be:ef:13:37 00:23:69:61:00:ce
654 00:23:69:61:00:ce de:ad:be:ef:13:37
59 00:23:69:61:00:ce 01:00:5e:7f:ff:fa
18 00:11:22:33:44:55 33:33:00:00:00:02
14 00:11:22:33:44:55 ff:ff:ff:ff:ff:ff
13 00:11:22:33:44:55 33:33:00:00:00:16
7 de:ad:be:ef:13:37 33:33:00:00:00:02
6 00:11:22:33:44:55 33:33:ff:33:44:55
4 de:ad:be:ef:13:37 ff:ff:ff:ff:ff:ff
4 de:ad:be:ef:13:37 33:33:00:00:00:16
3 00:23:69:61:00:ce ff:ff:ff:ff:ff:ff
2 de:ad:be:ef:13:37 33:33:ff:ef:13:37
Sure enough, that mystery station (1c:4b:d6:69:cd:07) sent all 42,816 of its data frames to the broadcast address. Most of the remaining frames were sent between Joe’s station and the WAP’s presumed STA interface (with the majority of those frames sent from Joe’s station). The next most common exchanges appear to be between the other odd station, “de:ad:be:ef:13:37,” and the WAP.
To put this in perspective, of 59,274 data frames:
• 72% were sent from an unknown station (1c:4b:d6:69:cd:07) to the broadcast address (ff:ff:ff:ff:ff:ff)
• 25% were transmitted between Joe’s station (00:11:22:33:44:55) and the WAP (00:23:69:61:00:ce)
• 2% were transmitted between an unknown station (de:ad:be:ef:13:37) and the WAP (00:23:69:61:00:ce)
There are relatively few reasons that data frames would be sent to the broadcast MAC address. Perhaps the most common case is when clients send out ARP requests. However, the volume of traffic sent by 1c:4b:d6:69:cd:07 compared with other stations seems abnormally high to be legitimate ARP requests.
Another possibility is that 1c:4b:d6:69:cd:07 was conducting some sort of attack on the wireless network. WEP-cracking attacks often involve the attacker sending out a large number of 802.11 data frames. Recall that an attacker’s ability to leverage the related key attack depends on the volume of unique IVs exposed. In order to capture lots of unique IVs quickly, the attacker needs to send out traffic that triggers other stations on the network to respond. An effective tactic is to replay ARP requests, because ARP requests elicit timely responses from other systems.
A malicious actor can capture 802.11 frames and replay them on the network, even without knowing the WEP key. How does an attacker know which 802.11 traffic to replay if the traffic is encrypted? In the classic ARP replay attack, the attacker listens for data frames sent to the broadcast MAC address—likely ARP requests—and just blindly replays them. In this way, the attacker has a good chance of generating traffic that will trigger a response from other stations on the WLAN. By replaying data packets to the broadcast Layer 2 address, an attacker can cause other stations to generate frames with unique IVs, which can then be captured and used to dramatically speed up the WEP-cracking attack.
6.7.2.2 Patterns and Time Frames
Are there any patterns or stations that seem unusual (perhaps considering the known vs. unknown stations by volume)? Let’s use the Wireshark suite’s “capinfos” tool to quickly view the duration of the packet capture and other high-level information.
$ capinfos wlan.pcap
File name: wlan.pcap
File type: Wireshark/tcpdump/... - libpcap
File encapsulation: IEEE 802.11 Wireless LAN
Number of packets: 133068
File size: 8685397 bytes
Data size: 6556285 bytes
Capture duration: 414 seconds
Start time: Fri Sep 17 09:56:41 2010
End time: Fri Sep 17 10:03:34 2010
Data byte rate: 15852.64 bytes/sec
Data bit rate: 126821.09 bits/sec
Average packet size: 49.27 bytes
Average packet rate: 321.75 packets/sec
Note that our forensic workstation’s time zone was MDT (GMT-6) at the time of this analysis. The human-readable dates and times will be listed in MDT where applicable throughout the remainder of this case study. Please adjust for time zone accordingly when you do your own analysis.
For more granular timestamps, we can use tcpdump to print the first and last frame:
$ tcpdump -nnr wlan.pcap|head -1
reading from file wlan.pcap, link-type IEEE802_11 (802.11)
09:56:41.085810 Beacon (Ment0rNet) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0
Mbit] ESS CH: 2, PRIVACY
$ tcpdump -nnr wlan.pcap|tail -1
reading from file wlan.pcap, link-type IEEE802_11 (802.11)
10:03:34.662764 Request-To-Send TA:00:02:6f:05:cb:11
From the output above, we see that the total duration of the packet capture is approximately 414 seconds, or 6.9 minutes. In that time frame, Joe’s station (11:22:33:44:55:66) sent the following data frames to the destinations shown below:
$ tshark -r wlan.pcap -R '((wlan.fc.type_subtype == 0x20) && (wlan.fc.
protected == 1)) && (wlan.bssid == 00:23:69:61:00:d0) && (wlan.sa ==
00:11:22:33:44:55)' -T fields -e wlan.da|sort|uniq -c|sort -nr
14076 00:23:69:61:00:ce
18 33:33:00:00:00:02
14 ff:ff:ff:ff:ff:ff
13 33:33:00:00:00:16
6 33:33:ff:33:44:55
In that same amount of time, the unknown station 1c:4b:d6:69:cd:07 sent 42,816 data frames to broadcast, and none to anyone else:
$ tshark -r wlan.pcap -R '((wlan.fc.type_subtype == 0x20) && (wlan.fc.
protected == 1)) && (wlan.bssid == 00:23:69:61:00:d0) && (wlan.sa == 1c:4b
:d6:69:cd:07)' -T fields -e wlan.da|sort|uniq -c|sort -nr
42816 ff:ff:ff:ff:ff:ff
As we see below, this broadcast traffic from 1c:4b:d6:69:cd:07 occurred over a span of less than 69 seconds, from 09:59:42 to 10:00:50:
$ tshark -r wlan.pcap -R '((wlan.fc.type_subtype == 0x20) && (wlan.fc.
protected == 1)) && (wlan.bssid == 00:23:69:61:00:d0) && (wlan.sa == 1c:4b
:d6:69:cd:07)' -T fields -e frame.time|awk '{print $4}'|head -1
09:59:42.220425000
$ tshark -r wlan.pcap -R '((wlan.fc.type_subtype == 0x20) && (wlan.fc.
protected == 1)) && (wlan.bssid == 00:23:69:61:00:d0) && (wlan.sa == 1c:4b
:d6:69:cd:07)' -T fields -e frame.time|awk '{print $4}'|tail -1
10:00:50.972590000
That seems unusual, and worthy of further inquiry. Typically, being unable to explain such a large proportion of network activity would be a huge red flag. In this case, however, our sample size is so temporally short that it may only seem anomalous on a small scale. Perhaps some benign (if annoying) process on this device causes it to do the same thing every 10 minutes, and we’ve caught only one such burst.
Another interesting pattern to examine might be the distribution of communication partners with 00:23:69:61:00:ce (the WAP’s STA interface). It would be useful to find out what Layer 3+ services this device provides (perhaps from Joe, or through our own inspection). Typically DHCP is provided, as would be ARP service for the associated devices.53 In addition, most WAPs provide remote administrative access through the application layer—most commonly via HTTP (or better, HTTPS).
53. Address resolution between MAC and IP addresses is a service that any Layer 2 protocol must provide. However, any protocol for doing so must be dependent upon the details of both Layer 2 and Layer 3 protocols to function properly, and so 802.11’s ARP is necessarily different from Ethernet’s. In the former case, it becomes necessary to put ARP traffic into data frames.
We’ve seen that there are data frames coming from the WAP’s BSSID and STA MAC addresses. Let’s drill down further and inspect the data frames sent by the WAP. We look first at the distribution of destinations by number of data frames coming from the WAP’s BSSID (00:23:69:61:00:d0):
$ tshark -r wlan.pcap -R '(wlan.fc.type == 2) && (wlan.bssid ==
00:23:69:61:00:d0) && (wlan.sa == 00:23:69:61:00:d0)' -T fields -e wlan.da
|sort|uniq -c|sort -nr
44 00:11:22:33:44:55
2 1c:4b:d6:69:cd:07
1 de:ad:be:ef:13:37
Notice that Joe’s station (00:11:22:33:44:55) received far more data frames from the WAP’s BSSID interface than any other station on the network.
Let’s also look at the data frames coming from the WAP’s STA interface (00:23:69:61:00:ce) and the distribution of their destinations:
$ tshark -r wlan.pcap -R '(wlan.fc.type == 2) && (wlan.bssid ==
00:23:69:61:00:d0) && (wlan.sa == 00:23:69:61:00:ce)' -T fields -e wlan.da
|sort|uniq -c|sort -nr
858 00:11:22:33:44:55
654 de:ad:be:ef:13:37
59 01:00:5e:7f:ff:fa
3 ff:ff:ff:ff:ff:ff
As we might reasonably expect, most of the data frames from 00:23:69:61:00:ce (the WAP’s STA interface) were sent to Joe’s station. After all, he’s likely logged onto the device’s web-based administrative interface in hopes of troubleshooting the situation. Given that Joe is the network administrator, if anyone is interacting directly with the WAP above Layer 2, it should be him. However, as we saw in the command output above, a significant percentage of frames from the 00:23:69:61:00:ce were sent to the unknown station de:ad:be:ef:13:37.54 It’s certainly reasonable to wonder why de:ad:be:ef:13:37 appears to have had significant interaction directly with the WAP.
54. Obviously the MAC address itself is odd—almost like someone configured it to be easily identified in a lab environment (much like Joe’s station’s MAC). Our attacker, Eric, has been kinder in this regard than most actual perpetrators.
Why not look at the distribution of destination MAC addresses for data frames originating from de:ad:be:ef:13:37? That might give us some context:
$ tshark -r wlan.pcap -R '(wlan.fc.type == 2) && (wlan.bssid ==
00:23:69:61:00:d0) && (wlan.sa == de:ad:be:ef:13:37)' -T fields -e wlan.da
|sort|uniq -c|sort -nr
740 00:23:69:61:00:ce
7 33:33:00:00:00:02
4 ff:ff:ff:ff:ff:ff
4 33:33:00:00:00:16
2 33:33:ff:ef:13:37
2 00:23:69:61:00:d0
It’s clear from the above output that within the time frame of this packet capture, most of the data frames sent from de:ad:be:ef:13:37 were directed to one other station—the WAP’s STA interface. Given that we don’t yet know who or what de:ad:be:ef:13:37 is, other than that it appears to have successfully associated with our WAP, it might be a good idea to place those frames in context. In particular, how does the traffic from de:ad:be:ef:13:37 fit into our timeline? Let’s use tshark to obtain the start and end times of traffic originating from de:ad:be:ef:13:37.
$ tshark -r wlan.pcap -R '(wlan.fc.type == 2) && (wlan.bssid ==
00:23:69:61:00:d0) && (wlan.sa == de:ad:be:ef:13:37) && (wlan.da ==
00:23:69:61:00:ce)' -T fields -e frame.time|awk '{print $4}'|head -1
10:02:14.181505000
$ tshark -r wlan.pcap -R '(wlan.fc.type == 2) && (wlan.bssid ==
00:23:69:61:00:d0) && (wlan.sa == de:ad:be:ef:13:37) && (wlan.da ==
00:23:69:61:00:ce)' -T fields -e frame.time|awk '{print $4}'|tail -1
10:03:32.836868000
It appears that traffic occurred toward the end of the packet capture.
6.7.2.3 The Timeline So Far . . .
Putting together the information we’ve gathered so far, we can start to build a timeline, as shown below (times are rounded to the nearest second):
• 09:56:41—Packet capture begins
• 09:59:42 to 10:00:51—1c:4b:d6:69:cd:07 broadcasted large volumes of data frames
• 10:02:14 to 10:03:33—de:ad:be:ef:13:37 sent small volume of data frames to the WAP’s STA interface (00:23:69:61:00:ce)
• 10:03:35—Packet capture ends
6.7.3 A Closer Look at the Management Frames
Given the stations of interest we identified, let’s look at management frames specific to the BSSID of interest. To do this we can use Wireshark’s display filter “(wlan.fc.type == 0) && (wlan.bssid == 00:23:69:61:00:d0).”
6.7.3.1 Frequency by Source and Destination
Let’s start by obtaining a breakdown of the number of management frames by sender, to see if anything stands out. We can use tshark to show us this information:
$ tshark -r wlan.pcap -R '(wlan.fc.type == 0) && (wlan.bssid ==
00:23:69:61:00:d0)' -T fields -e wlan.sa|sort|uniq -c|sort -nr
14858 00:23:69:61:00:d0
146 1c:4b:d6:69:cd:07
100 00:11:22:33:44:55
6 de:ad:be:ef:13:37
It is reasonable to expect the WAP to send out more management frames than the stations, but two orders of magnitude more seems unusual, especially when there are only a few stations.
Let’s examine the WAP’s outbound management frames (from the BSSID interface) and sort them by destination MAC address:
$ tshark -r wlan.pcap -R '(wlan.fc.type == 0) && (wlan.bssid ==
00:23:69:61:00:d0) && (wlan.sa == 00:23:69:61:00:d0)' -T fields -e wlan.da
|sort|uniq -c|sort -nr
12217 1c:4b:d6:69:cd:07
2455 ff:ff:ff:ff:ff:ff
126 00:11:22:33:44:55
60 de:ad:be:ef:13:37
The overwhelming majority of management frames sent by the WAP’s BSSID interface were destined to one of the unknown stations—two orders of magnitude more than were sent to Joe’s station in the same time period. For that matter, the WAP’s BSSID interface sent more than 20 times as many management frames to the broadcast address as it did to Joe’s station.
Let’s view statistics regarding the subtypes of this traffic. In the output below, the first column is the number of matching frames, the second column is the management frame subtype, and the third column is the destination MAC address.
$ tshark -r wlan.pcap -R '(wlan.fc.type == 0) && (wlan.bssid ==
00:23:69:61:00:d0) && (wlan.sa == 00:23:69:61:00:d0)' -T fields -e wlan.fc
.subtype -e wlan.da|sort|uniq -c|sort -nr
12076 10 1c:4b:d6:69:cd:07
2454 12 ff:ff:ff:ff:ff:ff
118 5 00:11:22:33:44:55
73 11 1c:4b:d6:69:cd:07
68 1 1c:4b:d6:69:cd:07
55 5 de:ad:be:ef:13:37
4 11 00:11:22:33:44:55
4 1 00:11:22:33:44:55
2 11 de:ad:be:ef:13:37
1 8 ff:ff:ff:ff:ff:ff
1 3 de:ad:be:ef:13:37
1 1 de:ad:be:ef:13:37
1 12 de:ad:be:ef:13:37
Based on our analysis, the overwhelming majority of management frames from the WAP’s BSSID interface were sent to the unknown station 1c:4b:d6:69:cd:07, and were subtype 10 (0x0a): Disassociation. In other words, Joe’s WAP spent most of its frames trying to tell this station to “get lost.”
Its next-highest count of frames were broadcasting subtype 12 (0x0c): Deauthentication! In other words, it looks like Joe’s WAP also spent a bunch of time telling everyone to get lost! No wonder Joe was having problems.
Let’s look at the timing of these particular management frames. We’ll start by testing out a filter that should match all of the subtype 10 traffic within the WLAN of interest that was sent from the WAP’s BSSID interface to the unknown station 1c:4b:d6:69:cd:07. We should get 12,076 frames—the same as the number above:
$ tshark -r wlan.pcap -R '(wlan.fc.type_subtype == 0x0a) && (wlan.bssid ==
00:23:69:61:00:d0) && (wlan.sa == 00:23:69:61:00:d0) && (wlan.da == 1c:4b:
d6:69:cd:07)' -T fields -e frame.time|wc -l
12076
That worked, so now let’s use the same filter with the “head” and “tail” programs in order to find the time boundaries:
$ tshark -r wlan.pcap -R '(wlan.fc.type_subtype == 0x0a) && (wlan.bssid ==
00:23:69:61:00:d0) && (wlan.sa == 00:23:69:61:00:d0) && (wlan.da == 1c:4b:
d6:69:cd:07)' -T fields -e frame.time|awk '{print $4}'|head -1
09:59:42.221489000
$ tshark -r wlan.pcap -R '(wlan.fc.type_subtype == 0x0a) && (wlan.bssid ==
00:23:69:61:00:d0) && (wlan.sa == 00:23:69:61:00:d0) && (wlan.da == 1c:4b:
d6:69:cd:07)' -T fields -e frame.time|awk '{print $4}'|tail -1
10:00:47.611120000
It appears that Joe’s WAP told 1c:4b:d6:69:cd:07 to Disassociate 12,076 times in the 65 seconds that passed from 09:59:42 to 10:00:47. That seems unusual.
While we’re at it, let’s look at the timing of the subtype 12 frames that the WAP was broadcasting (that second-most common type of management frame seen):
$ tshark -r wlan.pcap -R '(wlan.fc.type_subtype == 0x0c) && (wlan.bssid ==
00:23:69:61:00:d0) && (wlan.sa == 00:23:69:61:00:d0) && (wlan.da == ff:ff:
ff:ff:ff:ff)' -T fields -e frame.time|wc -l
2454
$ tshark -r wlan.pcap -R '(wlan.fc.type_subtype == 0x0c) && (wlan.bssid ==
00:23:69:61:00:d0) && (wlan.sa == 00:23:69:61:00:d0) && (wlan.da == ff:ff:
ff:ff:ff:ff)' -T fields -e frame.time|awk '{print $4}'|head -1
09:59:03.241923000
$ tshark -r wlan.pcap -R '(wlan.fc.type_subtype == 0x0c) && (wlan.bssid ==
00:23:69:61:00:d0) && (wlan.sa == 00:23:69:61:00:d0) && (wlan.da == ff:ff:
ff:ff:ff:ff)' -T fields -e frame.time|awk '{print $4}'|tail -1
10:00:57.672520000
Joe’s WAP broadcast 2,454 Deauthentication messages during roughly the same time period (09:59:03 to 10:00:57). That also seems unusual.
6.7.3.2 Partial Explanation
Recall that the 802.11 specification does not include a mechanism for verifying the authenticity of a sender. As a result, management frames can be spoofed. This leaves WLANs vulnerable to trivial denial-of-service attacks. Attackers can broadcast Disassociation or Deauthentication frames in order to cause network-wide outages or knock specific stations off the network. It is entirely possible that some of the Disassociation and Deauthentication messages shown above were actually sent by an attacker masquerading as Joe’s WAP, and not the WAP itself.
Could the traffic we’ve seen have caused problems for Joe? Of course. Joe’s station likely interpreted the Deauthentication messages as valid communications from the WAP, which would cause his station to attempt a new authentication/association negotiation. It is also possible that another station in physical range could have spoofed some or all of these messages.
Let’s investigate further.
6.7.4 A Possible Bad Actor
Based on what we’ve seen so far, let us hypothesize that 1c:4b:d6:69:cd:07 is a suspicious actor (and for the moment our most obvious one, based on voluminous aberrant behavior).
Let’s catalog the activities of interest. We should make sure we record all the activities we see coming from this station and update our timeline.
The command below produces a count of frames sent by 1c:4b:d6:69:cd:07 sorted and counted by type and subtype. In the output below, the first column is the number of matching frames, the second column is the 802.11 frame type, and the third column is the frame subtype.
$ tshark -r wlan.pcap -R '(wlan.bssid == 00:23:69:61:00:d0) && (wlan.sa == 1c
:4b:d6:69:cd:07)' -T fields -e wlan.fc.type -e wlan.fc.subtype|sort -n|
uniq -c|sort -nr
42816 2 0
77 0 11
69 0 0
As you can see, there were 42,816 data frames from 1c:4b:d6:69:cd:07, 77 Authentication Requests, and 69 Association Requests. Let’s sort by type/subtype to help us build our timeline further:
• The following command produces the timestamp for the first Association Request (type 0 subtype 0) seen from 1c:4b:d6:69:cd:07:
$ tshark -r wlan.pcap -R '(wlan.bssid == 00:23:69:61:00:d0) && (wlan.sa
== 1c:4b:d6:69:cd:07) && (wlan.fc.type_subtype == 0x00)' -T fields -e
frame.time|head -1
Sep 17, 2010 09:58:51.776452000
• The following command produces the timestamp for the last Association Request (type 0 subtype 0) seen from 1c:4b:d6:69:cd:07:
$ tshark -r wlan.pcap -R '(wlan.bssid == 00:23:69:61:00:d0) && (wlan.sa
== 1c:4b:d6:69:cd:07) && (wlan.fc.type_subtype == 0x00)' -T fields -e
frame.time|tail -1
Sep 17, 2010 10:00:47.612104000
• The following command produces the timestamp for the first Authentication Request (type 0 subtype 11) seen from 1c:4b:d6:69:cd:07:
$ tshark -r wlan.pcap -R '(wlan.bssid == 00:23:69:61:00:d0) && (wlan.sa
== 1c:4b:d6:69:cd:07) && (wlan.fc.type_subtype == 0x0b)' -T fields -e
frame.time|head -1
Sep 17, 2010 09:58:51.773386000
• The following command produces the timestamp for the last Authentication Request (type 0 subtype 11) seen from 1c:4b:d6:69:cd:07:
$ tshark -r wlan.pcap -R '(wlan.bssid == 00:23:69:61:00:d0) && (wlan.sa
== 1c:4b:d6:69:cd:07) && (wlan.fc.type_subtype == 0x0b)' -T fields -e
frame.time|tail -1
Sep 17, 2010 10:00:47.606473000
6.7.5 Timeline
Based on the investigation so far, we can now cobble together a timeline of the events of interest to us on September 17, 2010 (times are rounded to the nearest second):
• 09:56:41—Packet capture begins
• 09:58:52—Station “1c:4b:d6:69:cd:07” begins sending both Authentication and Association Requests, essentially simultaneously, at a rate exceeding one per second
• 09:59:03—The WAP appears to begin broadcasting a larger flood of Deauthentication messages
• 09:59:42—The station “1c:4b:d6:69:cd:07” begins broadcasting an even larger flood of data frames
• 09:59:42 to 10:00:47—The WAP appears to send 12,076 Disassociation messages to 1c:4b:d6:69:cd:07
• 10:00:47—The station “1c:4b:d6:69:cd:07” stops sending Authentication and Association Requests
• 10:00:51—The station “1c:4b:d6:69:cd:07” stops sending broadcasted data frames
• 10:00:58—The WAP’s apparent Deauthentication broadcasts stop
• 10:02:14—Station “de:ad:be:ef:13:37” sends first data frame to the WAP’s STA interface
• 10:03:33—Station “de:ad:be:ef:13:37” sends last captured data frame
• 10:03:35—Packet capture ends
6.7.6 Theory of the Case
Based on Joe’s categorical assertion, the unknown station with MAC address “1c:4b:d6:69:cd:07” is an interloper at best. Taking into consideration its activities relating to Joe’s WAP, it may well be malicious.
Previously in this chapter we discussed how an attacker might seek to force the generation of unique IVs in order to brute-force a WEP key. The evidence suggests that in this case, the station 1c:4b:d6:69:cd:07 may have been an attacker attempting to gain access to the WLAN. In this section, we further explore this theory of the case.
6.7.6.1 Stimulus and Response
Based on the evidence we’ve seen so far, we hypothesize that the abnormal volume of broadcasted data frames sent by 1c:4b:d6:69:cd:07 are ARP requests which have been replayed in order to generate additional unique IVs to faciliate a WEP-cracking attack. If this is the case, and the attack was successful, then the number of unique IVs generated by stations on the WLAN would have significantly increased during the time period that the attacker sent the broadcasted data frames.
Recall that the packet capture began at 09:56:41.085810 and ended at 10:03:34.662764 on September 17, 2010. The station 1c:4b:d6:69:cd:07 began sending broadcasted data frames 09:59:42.220425 and ending at 10:00:50.972590 on the same day.
Let’s check to see how many unique IVs were generated by other stations on the WLAN during the time period that 1c:4b:d6:69:cd:07 was generating large amounts of data frames, and compare this result to other time periods.
• Before the flood of data frames began (09:56:41.085810 to 09:59:42.220425), 694 unique IVs were generated in 181.134615 seconds, as shown below. This is an average of 3.831405 unique IVs per second.
$ tshark -r wlan.pcap -R '(wlan.bssid == 00:23:69:61:00:d0) && (wlan.sa
!= 1c:4b:d6:69:cd:07) && (frame.time < "Sep 17, 2010
09:59:42.220425000")' -T fields -e wlan.wep.iv|sort -u|wc -l
694
• During the flood of broadcasted data frames (09:59:42.220425 through 10:00:50.972590) 13,657 unique IVs were generated in 68.752165 seconds, as shown below. This is an average of 198.641017 unique IVs per second.
$ tshark -r wlan.pcap -R '(wlan.bssid == 00:23:69:61:00:d0) && (wlan.sa
!= 1c:4b:d6:69:cd:07) && (frame.time <= "Sep 17, 2010
10:00:50.972590000") && (frame.time >= "Sep 17, 2010
09:59:42.220425000")' -T fields -e wlan.wep.iv|sort -u|wc -l
13657
• After the flood of broadcasted data frames ended (10:00:50.972590 through 10:03:34.662764) 1,240 unique IVs were generated in 163.690174 seconds, as shown below. This is an average of 7.575287 unique IVs per second.
$ tshark -r wlan.pcap -R '(wlan.bssid == 00:23:69:61:00:d0) && (wlan.sa
!= 1c:4b:d6:69:cd:07) && (frame.time > "Sep 17, 2010
10:00:50.972590000")' -T fields -e wlan.wep.iv|sort -u|wc -l
1240
The frequency of unique IVs generated during the flood of data frames was over 51 times greater than the frequency of unique IVs generated beforehand—and over 26 times greater than the frequency of unique IVs generated afterwards. In other words, it is entirely plausible that the flood of data frames sent from 1c:4b:d6:69:cd:07 could be indicative of a successful WEP-cracking attack.
6.7.6.2 WEP Cracking Attack
Given what we know, a reasonable theory is that a station with the MAC address of 1c:4b:d6:69:cd:07 waged an attack on Joe’s WAP and its associated stations beginning at 09:58:51 and lasting for a few minutes at most. If successful, it may have yielded sufficient key material for a “related key” attack on the WEP key.
We can test this theory, and will, in our answers below.
As a corollary, we could further theorize that the station with the MAC address of de:ad:be:ef:13:37 was able to authenticate and associate as a result of the previous activity. (Exactly how 1c:4b:d6:69:cd:07 and de:ad:be:ef:13:37 are related is a matter of interest, but that they are related is strongly implied by the timeline.) At a minimum, we can attempt to inspect de:ad:be:ef:13:37’s traffic to see if it is malicious.
6.7.7 Response to Challenge Questions
Now let’s answer the questions posed at the beginning of this case:
• What are the BSSID and SSID of the WAP of interest?
We were able to identify and verify these values from the traffic capture provided to us:
– BSSID: 00:23:69:61:00:d0
– SSID: Ment0rNet
• Is the WAP of interest using encryption?
Yes, every single data frame inspected was encrypted.
• What stations are interacting with the WAP and/or other stations on the WLAN? There were three stations that we could easily detect based on an analysis of management frame activity:
– 00:11:22:33:44:55
– 1c:4b:d6:69:cd:07
– de:ad:be:ef:13:37
• Are there patterns of activity that seem anomalous? There were several, including a flood of data frames coming from an unknown station that coincided with a spike in unique IVs being sent out from the WAP. Though it didn’t last for very long, the unusual activity was followed by yet another unknown station which appeared to associate successfully.
• How are they anomalous: Consistent with malfunction? Consistent with maliciousness? The anomalous behavior is consistent with a WEP-cracking attack. One station emitted a disproportionate number of data frames destined for the Layer 2 broadcast address. These data frames apparantly triggered a response from the WAP (and other stations as well), which resulted in the WAP generating a large number of frames with unique IVs. The proportion of data frames broadcasted one station was unusually high. However, it is a common symptom of a WEP-cracking attack because in order to crack the WEP key, an attacker needs to collect a large number of data frames with unique IVs.
• Can we identify any potentially bad actors? Station 1c:4b:d6:69:cd:07 emitted a large number of data frames sent to the Layer 2 broadcast address, which caused the WAP to respond with a large number of frames with unique IVs. Based on this, it is likely that 1c:4b:d6:69:cd:07 was an attacker attempting to launch a WEP-cracking attack.
Shortly after the apparent WEP-cracking attack ended, the unknown station de:ad:be:ef:13:37 successfully associated with the WAP. It is possible that this system’s activites are associated with the attack.
• Can we determine if a bad actor successfully executed an attack? Let’s investigate whether the WEP-cracking attack could have been successful. One way to figure that out would be to simply use aircrack-ng to try to recover the WEP key from the packet capture. If enough key material was revealed during that packet capture, we should be able to crack the key. Let’s find out:
$ aircrack-ng -b 00:23:69:61:00:d0 wlan.pcap
Aircrack-ng 1.0
[00:00:02] Tested 938 keys (got 26805 IVs)
KB depth byte(vote)
0 3/ 4 D0(33536) 1F(33024) 27(33024) BC(33024) 2F(31744) 7B
(31744)
1 0/ 1 E5(38656) 82(33024) 0C(32256) 3C(32000) EB(31744)
42(31488)
2 0/ 6 9E(34048) 27(33792) 7A(32768) E9(32512) 8B(31744) 0E
(31744)
3 0/ 4 B9(35328) D4(35072) 2E(34048) B9(33024) 00(32768)
06(32512)
4 8/ 10 6D(31488) 10(31232) B9(31232) 7A(30976) 95(30976) A5
(30976)
KEY FOUND! [ D0:E5:9E:B9:04 ]
Decrypted correctly: 100%
We were able to successfully recover the WEP key from the captured packets, which tells us that yes, it is certainly possible that the attacker’s WEP-cracking attack was successful. If we recovered the WEP key from these packets, then the attacker could have, too.
Recall that shortly after the apparent attack ended, the unknown station “de:ad:be:ef:13:37” successfully authenticated to the network, and there was additional WEP-encrypted communication between “de:ad:be:ef:13:37” and Joe’s WAP. It is entirely possible that after recovering the WEP key with station 1c:4b:d6:69:cd:07, the attacker used the key to authenticate with station “de:ad:be:ef:13:37.” Now that we have recovered the WEP key, we can decrypt the Layer 2 traffic and investigate further using higher-layer protocol analysis techniques.
6.7.8 Next Steps
At this point, we should probably verify with Joe that the 40-bit key we were able to expose (D0:E5:9E:B9:04) is the WEP key that he had set for his WAP. Then again a more certain confirmation can be had if the recovered WEP key decrypts the packets.
• Decrypting the data frames. Assuming all due permission and authority to proceed, the obvious next step would be to “decapsulate” the WEP-encrypted frames. The “airdecap-ng” tool performs this function nicely. The command below produces a file named “wlan-dec.pcap” with the decrypted WEP frames.
$ airdecap-ng -l -b 00:23:69:61:00:d0 -w D0:E5:9E:B9:04 wlan.pcap
Total number of packets read 133068
Total number of WEP data packets 56692
Total number of WPA data packets 0
Number of plaintext data packets 0
Number of decrypted WEP packets 56692
Number of corrupted WEP packets 0
Number of decrypted WPA packets 0
• Inspecting the decrypted content. It seems prudent to proceed with the assumption that some unknown station had forcibly gained access to Joe’s WLAN. Every indication seems to support this interpretation of events—including our ability to replicate an attacker’s likely successes so far. If we could crack the WEP key and decrypt the network traffic, anyone else with access to the RF waves could have done the same.
At this point we can return to our usual tools and techniques for network traffic and communications analysis—but not leaving aside what we’ve already learned and documented in our timeline. In addition, if we were to look further, we would discover that immediately after the traffic spike caused by 1c:4b:d6:69:cd:07, and after all of the Deauthentication frames were broadcast (perhaps spoofed), the station “de:ad:be:ef:13:37” appeared, associated, and authenticated for the first time. Once it authenticated, it immediately began talking to the WAP on port 80/TCP. According to Joe, this station is not an authorized network user, and so this is clearly suspicious traffic.
Reconstructing some of the last few decrypted streams reveals that “de:ad:be:ef:13:37” authenticated to the WAP’s administrative web interface. Figure 6-19 shows a reconstructed stream between “de:ad:be:ef:13:37” (192.168.1.109) and the WAP’s STA interface “00:23:69:61:00:ce” (192.168.1.1). Notice the HTTP “Authorization” header:
Authorization: Basic YWRtaW46YWRtaW4=
Figure 6-19 A screenshot of Wireshark showing a reconstructed stream between “de:ad:be:ef:13:37” (192.168.1.109) and the WAP’s STA interface “00:23:69:61:00:ce” (192.168.1.1). Notice the HTTP “Authorization” header, which indicates that HTTP Basic Access Authentication was used.
This indicates that the client “de:ad:be:ef:13:37” attempted to authenticate to the WAP’s administrative web interface using HTTP Basic Access Authentication (the credentials are Base64-encoded in transit, not encrypted). The shell command below decodes the Base64-encoded credentials, as shown:
$ echo "YWRtaW46YWRtaW4="|base64 -d
admin:admin
It appears from Figure 6-19 that the WAP was configured with a weak or default password of “admin,” and that we have a “volunteer” system administrator who is about to help us fix something. On further inspection it becomes clear that something adverse to Joe was done.
Exactly what, and how, is left as an exercise for the reader.