Endpoint Protection

by Raul Siles, GSE

Introduction

The huge adoption of wireless technologies over recent years has placed wireless data (or Wi-Fi) networks, based on the 802.11 specifications, as one of the major attack vectors for organizations nowadays. Incident handlers and law enforcement have been forced to deal with the complexity associated with these technologies when managing and responding to security incidents.

This two-part series looks at the issues associated with collecting and analyzing network traffic from wireless networks in an accurate and comprehensive way; a discipline known as wireless forensics.

Part one of this article focuses on the technical details and challenges for traffic acquisition, and provides design requirements and best practices for wireless forensics tools. The second part will address the main considerations and challenges for wireless traffic analysis, including advanced anti-forensic techniques and some legal aspects associated with this discipline.

The reader should note that for simplicity, all practical examples and specific technical details covered in the article use Linux and open-source tools.

Wireless forensics overview

Wireless Forensics is a discipline included within the computer forensic science, and specifically, within the network forensic field, and it’s a term coined by Marcus Ranum in 1997. Its main goal is to provide the methodology and tools required to collect and analyze (wireless) network traffic that can be presented as valid digital evidence in a court of law. The evidence collected can correspond to plain data or, with the broad usage of Voice-over-IP (VoIP) technologies, especially over wireless, can include voice conversations.

The wireless forensic process involves capturing all data moving over the network and analyzing network events in order to uncover network anomalies, discover the source of security attacks, and investigate breaches on computers and wireless networks to determine whether they are or have been used for illegal or unauthorized activities.

When performing wireless forensics, the security analyst must follow the same general principles that apply to computer forensics: identify, preserve and analyze the evidence, in order to impartially report the findings and conclusions.

Technical challenges for WiFi traffic acquisition

The main technical challenges associated to wireless forensics are due to the intrinsic nature of radio frequency (RF) communications and the complexity of the physical medium and the 802.11 specifications. The following sections focus on the major handicaps the forensic examiner, and his capture tools, must overcome.

Dealing with the wireless physical medium

The 802.11 wireless data networks divide the frequency spectrum (see Table 1) in several channels that can be used to establish multiple non-overlapping communications. Wireless networks are commonly deployed in specific channels with the goal of avoiding interference.

[1]: 802.11a indoor specification. Other frequencies are available for outdoor usage.

The first wireless forensic tool consideration is that it must support the 802.11 modulation of the network to monitor; therefore, it is recommended that one use 802.11 a/b/g multi-band wireless cards that support the three most common standards. Atheros is the most popular chipset for a/b/g cards today. The main drawback of multi-band cards is that US FFC regulations do not allow removable antennas on 802.11a equipment working on the UNII1 frequency ranges, which are utilized by most cards.

Standard wireless equipment only contains a single radio component; therefore, it is only capable of listening to an specific channel in a given moment. Wireless tools have used a technique called channel hopping to scan the whole frequency spectrum and sample all the different channels, however, using this method the radio is only listening for a few milliseconds in each channel.

When dealing with a single wireless access point, capturing traffic is not a challenge, because the access point transmits in a unique channel, so the analyst simply needs to configure its card to listen to that channel (as shown below). The following Linux command sets an Atheros (wadwifi driver) card into monitor mode on channel 13.

# iwconfig ath0 mode monitor channel 13

However, enterprise and large environments with multiple access points present a challenge for accurate traffic captures. Wireless forensics tools must be capable of capturing all the traffic from all the wireless networks in a given area when a suspect is located. Therefore, the tools need to listen to all channels simultaneously. The only way of accomplishing this goal is by having as many radio devices as there are channels to monitor.

Although laws and regulations specify the 802.11 channels allowed in every country or region, as described in Table 2 [ref 1] [ref 2], (surprisingly) attackers don't follow the law. Therefore, when talking about 802.11b/g networks, it is imperative for the forensic analyst to collect traffic from all 14 channels available worldwide. Besides, some countries have their own specific local regulations, out of the FCC, U-NII or ITU standards.

[1]: Not approved by regulations yet; country-based.
[2]: The indoor 802.11a channel numbers are 34, 36, 38, 40, 42, 44, 46, 48, 52, 56, 60 and 64.

Regulations also define the maximum transmission power (in mW or W) for 802.11 equipment, but again, attackers will break these limits. The analyst must be prepared for this illegal usage, as well as for future wireless technologies, such as MIMO (802.11n) [ref 3] and WiMAX (802.16) [ref 4].

Mobile clients and roaming

One of the major advantages wireless networks provide is client mobility, that is, the capability of moving around the wireless network range without losing the network connection. For large networks, this is mainly accomplished through roaming, a technique to fast switch from the current access point to the nearest one while sending and receiving data. This functionality presents complex challenges for wireless forensics.

Wireless clients roam from one access point to another once their network card determines that the former access point signal is too weak to continue transmitting and receiving data. These roaming events typically involve moving from one channel to another. If the wireless forensic tool used to capture data during roaming activities does not monitor all channels, specifically the initial and final channels, portions of the session will be lost, negatively affecting the evidence collected.

Additionally, the location of mobile wireless clients and the facility’s physical layout directly influence from where the traffic can be captured. Occasionally, the location from where the forensic examiner is collecting traffic is no longer valid once the client moves, for example, to an opposite location inside a building. Sometimes, only one end of the communication can be collected.

The only place where the data can be accurately collected for a wireless infrastructure network (seeing both ends of the communication) is near the access point, but this is not a realistic scenario, especially when the network is conformed by multiple access points (the analyst cannot be in all them at the same time) or when wireless ad-hoc (client to client) networks are used. From a wireless forensic perspective this challenge can only be solved by placing multiple traffic capture sensors around the facilities that must be monitored. Having three or more sensors can also help to apply triangulation methods to approximately locate the source of a transmission.

Wireless traffic features and extent

When capturing wireless traffic it is important to consider its main characteristics, such as frames types, sizes, approximate number of frames and bandwidth requirements.

The 802.11 MTU (Maximum Transmission Unit) for data frames is 2304 bytes (frame payload size before encryption). Based on the encryption method use, the final payload size varies: WEP adds a header of 8 bytes for a total of 2312 bytes, WPA (TKIP) adds a header of 20 bytes for a total of 2324 bytes, and WPA2 (AES) adds a header of 16 bytes, for a total of 2320 bytes.

As an example, when using WEP, the maximum total frame size (payload + 802.11 header + trailer) is 2346 bytes (2312 + 30 + 4 bytes). This is the number reflected in the 802.11 specification [ref 5], much bigger than the default MTU for Ethernet, 1500 bytes.

Additionally, the 802.11 specifications define three different types of frames required to manage the unreliable RF medium: control, management and data frames. The first two only exist on wireless networks, as opposed to wired networks, and will influence the amount of data captured during the forensic activities.

For example, due to synchronization requirements, wireless networks (specifically the access point) generate a special type of management frame called beacons. Commonly, each AP generates 10 beacons per second by default. This means that, for a single wireless network based on only one access point, the forensic examiner is going to collect 36000 frames per hour. The implications of these environment peculiarities from the performance and storage perspective must be considered in advance.

To exemplify all these peculiarities using a real-world scenario, Table 3 reflects the details and numbers obtained while collecting 802.11b/g data, from all 14 channels, using a 6dBi omnidirectional antenna. It corresponds to a case following a suspect by car, at low speeds (20-40 Km/h – 12-25 Mph), in a less crowded small town, mainly made of two or three-storey buildings and detached houses.

In the same scenario, another example associated to the static collection of traffic around the suspect facilities from the parking lot, provided the details of Table 4.

These two examples provide a rough estimation of the minimum amount of traffic you can find in a wireless forensics exercise, or around 200-300Mbytes/hour. Obviously, the requirements would increase tremendously in more densely populated locations, such as in major cities and downtown areas with dozens of multi-tenant buildings shared by multiple companies and individuals.

Continued on page 2... (link below)

[ref 1] “Cisco Channels and Antenna Settings”. Cisco. http://www.cisco.com/en/US/products/hw/wireless/ps4570 /products_configuration_guide_chapter09186a0080209251.html
[ref 2] “HP ProCurve Wireless Radio Country Approvals Matrix”. HP. November 2005. http://www.hp.com/rnd/pdfs/country_approvals_matrix520wl.pdf
[ref 3] IEEE 802.11 – TGn. IEEE. http://grouper.ieee.org/groups/802/11/index.html
[ref 4] IEEE 802.16 (WiMAX). IEEE. http://grouper.ieee.org/groups/802/16/index.html
[ref 5] “Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications”. IEEE. June 2003. http://standards.ieee.org/getieee802/download/802.11-1999.pdf

Performance issues capturing wireless traffic

From a hardware design perspective, the wireless capture device must be able to accommodate the theoretical maximum throughput associated to all the communication channels. By default, 802.11g networks can transmit at 54 Mbps rates, that is, an aggregated throughput of 756 Mbps (14 channels x 54 Mbps).

The device internal architecture bus, interconnecting all the wireless cards, can affect the tool performance and discard traffic, invalidating the evidence collected. To avoid that, the computing architecture must support this maximum aggregated capacity. As a reference, these are the maximum data rates for the most commonly used PC-based bus technologies available nowadays: PCI 2.2 (264 Mbps), USB 2.0 (480Mbps), CardBus (1056 Mbps), PCI-X (1064 Mbps), Express Card (2.5 Gbps) and PCI-X 2.0 (4.3 Gbps). Not only the main bus, but other components, such as the memory bus or the disk interface and hard drives must support the previously mentioned data rate. As a reference, DDR2-667 SDRAM memory modules provide high data transfer up to 42 Gbps and current SATA disks support 1.5 Gbps data rates.

Based on a specific legal case, the analyst could be required to collect data from multiple domains, such as static locations, like office buildings or company facilities, the suspect’s home, public areas such as hotels or airports, and moving locations, such as in a car prosecution. Therefore, wireless forensics solutions require large storage devices to save all the data collected.

Open-source and commercial tools

The type of tool required for professional wireless forensics activities can be built using standard equipment, such as a common PC-architecture and commercial wireless network cards. However, a high-quality device that meets all the different requirements mentioned along this article would require a considerable design and implementation investment.

Nowadays there are also a couple of commercial tools that could be used for wireless forensics:

• The Janus Project [ref 6] is a commercial tool, presented at the Defcon 2006 conference, that contains 8 wireless cards for wireless scanning, data capture and encryption cracking.
• The WLAN-14 [ref 7] Linux-based commercial device, from Aircapture, was designed as a pure wireless forensics tool for law enforcement and security officers to securely collect 802.11b/g wireless data. It offers 15 wireless cards, a GPS, one external antenna connector and support for hot-swappable disks.

The former was conceived as a wireless traffic capture and cracking tool, and the later is a pure wireless forensic device.

Tool design requirements and best practices for wireless forensics

The following list summarizes some best practices, tips and tricks, and additional technical forensic considerations that should be evaluated when building or acquiring a wireless forensic tool or device for capturing 802.11 network traffic as legal evidence.

• The device should have 15 radio components (or cards) to be able to monitor all fourteen 802.11b/g channels and, at the same time, channel hop through the spectrum to identify new wireless networks (this being the purpose of the 15th radio).
• The use of a GPS (Geographical Positioning System) device can provide accurate timestamps and outdoor location capabilities, required to corroborate when and where the evidence (wireless traffic) was collected. Open-source implementations, such as gpsd [ref 8], are commonly used for this purpose by wireless tools like Kismet for wardriving purposes. This GPS logging information is crucial during the analysis phase to match the data collected with the physical location of the capturing devices.

  From a forensic perspective, and in order to be able to consider the GPS data as evidence too, it is very relevant to measure and log the internals of when the GPS device is synchronized with the GPS satellites, that is, be able to show that the device is providing accurate information.

   

• The tool must capture all traffic without applying any capture filter, to not miss any real evidence. Only if regulations enforce it, filters would be applied during the capture phase to only collect traffic from specific access points or clients based on their MAC addresses (BSSID or station address). Filters can always be applied later, during the analysis phase, to focus on specific traffic flows.
• It is recommended that the wireless forensic tool be a completely passive device, not generating any traffic into the medium. This constraint can be enforced by design using a hardware attenuator that reduces or cancels the transmission power, or/and a one-way reception amplifier. This can also be enforced at the software level by placing the wireless cards in monitor mode, although it is important to denote that the latest Linux wireless cards drivers allow one to inject traffic in this “passive” mode.
• The device should provide an external antenna connector to expand the default wireless cards’ reception capabilities by using high-gain directional or omnidirectional antennas. The antennas increase the distance from where the RF signal, and therefore network traffic, can be collected. For high range reception, it is recommended to use, as a generic reference, omidirectional antennas of around 15dBi and directional parabolic grid antennas of around 24dBi.
• In some risky scenarios, it can be dangerous for the forensic examiner (and his physical integrity) to stay near or around the suspect area, so it would be desirable to have some kind of remote access capabilities to the capture device. For example, including an additional 802.11a interface to a pure 802.11b/g capture device allows accessing the system wirelessly and remotely without interferences. This remote management interface must be strongly secured so that the forensic device is not compromised, both from the wireless access perspective, and from the upper-layer protocols point of view, using SSH, SSL or IPSec to provide strong authentication and encryption.
• In order to collect additional information about the traffic, and what the estimated suspect location is, it is recommended to add specific signal strength information, in the form of the Prism monitoring header, when capturing wireless traffic.

  This additional header (see Figure 1 below) adds 144 bytes, is generated by the wireless driver, and contains received signal strength (RSSI), capture device, channel, and other signal/noise quality information [ref 9].

   

Figure 1. Prism monitoring header through Wireshark.

Although the signal information reported by the wireless cards cannot be accurately translated to the physical layout location due to multiple RF behaviors, such as reflection, refraction, diffraction or scattering, this information can be very useful to compare the different values collected during a capture session and map network traffic with signal properties.

The following commands show how to enable and disable the Prism monitoring header in Linux for various wireless cards/drivers. Based on the driver version the header can be available by default and the set/unset commands can vary:

- Prism 2.X cards (hostap driver): # iwpriv wlan0 monitor 3    --> Prism header ON # iwpriv wlan0 monitor 2    --> Prism header OFF - Prism 2.X cards (wlan-ng driver): # wlanctl-ng wlan0 lnxreq_wlansniff prismheader=true enable=true channel=6 # wlanctl-ng wlan0 lnxreq_wlansniff enable=true channel=6 - Atheros cards (madwifi driver): # sysctl -w dev.ath0.rawdev=1         --> Create ath0raw # ifconfig ath0raw up # sysctl -w dev.ath0.rawdev_type=0    --> Normal 802.11 frames # sysctl -w dev.ath0.rawdev_type=1    --> 802.11 + Prism headers - PrismGT cards (prism54 driver): [*] # iwpriv eth1 set_prismhdr 1    --> AVS WLAN header ON # iwpriv eth1 set_prismhdr 0    --> AVS WLAN header OFF

[*]: The AVS WLAN header is an alternative Prism header format, that only adds 64 bytes to the standard 802.11 frames [], introduced by Absolute Value Systems for the wlan-ng monitor mode, which is used by Prism54 and other drivers.
• The tool should collect the traffic in the standard Pcap format (Packet CAPture, associated to the libpcap library [ref 10]), recognized by most commercial and open-source traffic capture and analysis tools.
• The wireless hardware (cards or radio components) used must have very good receive sensitivity (Rx), to increase the chance of collecting traffic even in the worst conditions. The best wireless cards in the market nowadays are capable of providing a Rx of -105 dBms at very low rates, such as the Atheros XR technology [ref 11] (-85 dBm is the reference value reflected in the IEEE 802.11 specification).

  The wireless output power is not relevant unless the tool implements some active transmission capabilities, such as when traffic is generated to increase the chance of obtaining the WEP key (covered in part two). Prior to running active actions, their legal implications must be evaluated.

   

• The physical characteristics of the multiple wireless hardware components limit the reception quality of the device. The internal device design should consider the usage of a high performance low noise reception amplifier to compensate the loss associated to all the cabling, the power splitter and the connectors linking all the different built-in cards.
• It is recommended to have advanced logging capabilities in the capture device itself, so that all the actions and steps executed in the device can be accurately tracked and used as evidence corroboration in the court of law. The integrity of these logging records should be assured through hashing algorithms (MD5 and SHA-1).
• Finally, all the data collected, specifically, the Pcap files and GPS information, must be cryptographically hashed once the capture session has been finalized, and apart from having a repository of hash values, they should be included in the audit log too. This hashing information will help to preserve and verify the integrity of the evidence.

Concluding part one

Wireless technologies, and especially Wi-Fi, are here to stay and are expanding to new devices used with both harmless and malicious intent. The first part of this article series has described wireless forensics as a discipline required to investigate security attacks and incidents through (and over) 802.11 wireless data networks.

The article has pointed out the challenges and the complexity associated with wireless traffic acquisition, and has provided design requirements, tool references and best practices for wireless forensics. In part two we shall introduce the challenges for wireless traffic analysis, including advanced anti-forensic techniques and some legal connotations.

References

[ref 1] “Cisco Channels and Antenna Settings”. Cisco. http://www.cisco.com/en/US/products/hw/wireless/ps4570 /products_configuration_guide_chapter09186a0080209251.html
[ref 2] “HP ProCurve Wireless Radio Country Approvals Matrix”. HP. November 2005. http://www.hp.com/rnd/pdfs/country_approvals_matrix520wl.pdf
[ref 3] IEEE 802.11 – TGn. IEEE. http://grouper.ieee.org/groups/802/11/index.html
[ref 4] IEEE 802.16 (WiMAX). IEEE. http://grouper.ieee.org/groups/802/16/index.html
[ref 5] “Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications”. IEEE. June 2003. http://standards.ieee.org/getieee802/download/802.11-1999.pdf
[ref 6] The Janus Project. http://www.tgdaily.com/2006/08/30/defcon2006_janus_project/
[ref 7] WLAN-14. AirCapture. http://www.aircapture.net
[ref 8] “GPSD: GPS Daemon”. http://gpsd.berlios.de
[ref 9] “Pcap file containing two packets with Prism and AVS headers respectively”. http://www.raulsiles.com/downloads/80211_headers.pcap
[ref 10] “LibPcap: Packet capture library”. Tcpdump. http://www.tcpdump.org
[ref 11] “Atheros Extended Rate XRTM Technology”. May 2004. http://www.atheros.com/pt/whitepapers/atheros_XR_whitepaper.pdf

About the author

Raul Siles is a senior independent security consultant based in Spain and a SANS certified instructor. His current security research interests, related with this article, include wireless security, incident handling and computer forensics, and VoIP security. He is one of the few individuals who have earned the GIAC Security Expert (GSE) designation. More information can be found on his website, www.raulsiles.com.

Reprints or translations

Reprint or translation requests require prior approval from SecurityFocus.

© 2007 SecurityFocus

Comments?

Public comments for Infocus technical articles, as shown below, require technical merit to be published. General comments, article suggestions and feedback are encouraged but should be sent to the editorial team instead.

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