2007-01-08
Introduction
In part one of this series, we discussed the technical challenges for wireless traffic acquisition and provided design requirements and best practices for wireless forensics tools. In this second article, we take it a step further and focus on the technical challenges for wireless traffic analysis. Additionally, advanced anti-forensic techniques that could thwart a forensic investigation are analyzed. Finally, apart from the technical details, as a forensic write-up, the article covers some legal aspects about wireless forensics for both the U.S. and Europe.
Wireless forensics: Technical considerations for traffic analysis
Once the traffic has been collected by the forensic examiner, it must be analyzed to draw some conclusion about the case. The main technical considerations, tools and challenges associated to the analysis of 802.11 traffic from a wireless forensics perspective are presented below.
The scope of the article is to focus on wireless forensics from the traffic point of view, although in a real scenario, there are other sources of information to complement the data related with the case. These sources of information would include access points and wired network devices logs, ARP and CAM tables, and the data collected by wireless IDS.
Network Forensic Analysis Tools (NFAT): Commercial and open-source traffic analysis tools
The analysis of wireless traffic demands the same capabilities required in pure wired network forensics, that is, an in-depth understanding of the protocols involved in the data communications collected. For wireless, this commonly means TCP/IP-based protocols over 802.11.
The set of network tools used to analyze traffic from a forensic perspective is commonly called NFAT (Network Forensic Analysis Tool), a term coined in 2002. The major commercial players in the wired field are Sandstorm NetIntercept [ref 1], Niksun NetVCR [ref 2] and eTrust Network Forensics [ref 3]. Wireless forensics would require these tools to provide wireless traffic analysis capabilities, that is, advanced analysis functions for the specific 802.11 headers and protocol flows and behaviors. At the time of this writing, both NetIntercept and eTrust NF state 802.11 capabilities.
From an open-source perspective, there are no well-known, dedicated NFAT alternatives. However, there are multiple tools [ref 4] that provide network traffic analysis capabilities that are very useful for the forensic examiner to find specific pieces of information in the evidence collected.
Simplifying things, the graphical Wireshark [ref 5] protocol dissector is used to inspect in-depth every field of the frames captured, ngrep (network grep) [ref 6] is used to search for specific strings in the contents of the frames, and the text-based tcpdump [ref 7] or tshark [ref 5] sniffers are used to automate and script the analysis of certain tasks, such as filtering traffic based on specific conditions. Most commercial and open-source tools support the standardized Pcap file format (referenced in the first part of this article) for interoperability and data exchange purposes.
Analyzing wireless traffic
The traffic analysis process involves multiple tasks, such as data normalization and mining (to be able to easily manipulate and search through the data obtained), traffic pattern recognition (required to identify anomalies and suspicious patterns), protocol dissection (very relevant for understanding all the different protocol header fields and their contents) and the reconstruction of application sessions (to obtain application-level visualization).
The coverage of all these areas (very similar to standard traffic analysis for wired networks) could require its own book, therefore, this section contains specific technical issues that should be considered during the analysis phase for wireless traffic. These issues include merging traffic from multiple channels, managing traffic from overlapping channels, filtering capabilities and fast analysis. One of the main particular challenges associated with wireless forensics is related to the built-in 802.11 layer-2 encryption features of this technology. This aspect is covered in the next section.
One of the first wireless analysis issues to consider is the merge of the capture files corresponding to all the individual channels. When using a multi-card device, as the one suggested on the first part of this article, each card listens to a specific channel and collects data for this channel in a single Pcap file.
In some scenarios, such as with roaming clients, it is required to merge the data from various channels to reconstruct the roaming session. For this purpose, it is possible to use the mergecap tool included with Wireshark. The tool allows one to merge multiple capture files in a single output Pcap file (-w option), as shown below:
# mergecap -w all_channels.pcap channel_1.pcap channel_2.pcap ... channel_14.pcap
Wireshark also provides a menu option, “File – Merge...” to merge two Pcap files. This is required to merge the packets chronologically to reflect the traffic over the time.
An example has been made available to the reader to follow along [ref 8]. It is a slightly modified version of a file capture provided by Aircapture, and includes two Pcap files containing a VoIP session from a roaming client switching between two access points, from channel 11 to channel 1. The example is provided so that the reader can test the merging functionality using Wireshark and reconstruct the audio conversation (that, by the way, contains a commercial message) for this VoIP session. The details about how to use Wireshark (previously called Ethereal) to reconstruct the VoIP RTP protocol sessions have been detailed in a previous SecurityFocus article [ref 9]. The briefly summarized steps for the new Wireshark version are:
- Decode RTP packets: Select the first RTP packet in the Pcap file and select “Statistics – RTP – Stream Analysis...”.
- RTP Stream Analysis: Select “Save payload...” to store the media stream.
- Save the audio: Select the “.au” format, the “forward” channel and the filename to save the audio stream that contains the voice captured.
Due to the lack of SIP packets, and the usage of 8000 as the source and destination ports, the RTP packets in the capture file for channel 1 are decoded by default in Wireshark as OICQ packets. It is required to decode them as RTP; this can be accomplished by selecting any OICQ packet, go to “Analyze – Decode As...”, find and select the RTP protocol and click OK.
To get the most from this exercise, it is recommended that the reader first reconstruct and listen to the media stream for the two individual files, and then merge both into a single file, and reconstruct its media stream. The later contains the concatenation of the media stream fragments captured from each wireless channel. At about 30 seconds into the playback, the roaming takes place.
Additionally, another wireless analysis issue to consider is the fact that the capture file for a given channel might contain data from overlapping channels, that is, traffic from networks in adjacent channels. Based on the access point transmission and the analyst’s reception device capabilities, such as the output transmission (Tx) power, the reception (Rx) sensitivity, and the antennas used, it is possible to capture data from multiple channels simultaneously.
The capture file shown below in Figure 1, which is also available to the reader [ref 10], corresponds to the beacon frames of a capture session on channel 9. The sniffer collected traffic from channels 9 (Null SSID and SSID “WLAN_7B”), 11 (SSID “WopR”) and 12 (SSID “ANA”). The channel information is included in the beacon frame, specifically, in the “DS Parameter set: Current Channel” field of the “Tagged parameters” section inside the “IEEE 802.11 wireless LAN management frame” header.
Figure 1. Beacons frames from multiple channels captured from channel 9.
Therefore, during the analysis phase it is necessary to identify and discard duplicated frames and manage these kind of multi-channel interferences and collisions.
Probably, the most commonly used feature when dealing with huge amounts of information is the traffic analyzer filtering capabilities. Once the traffic has been merged in a single Pcap file, for example, filters allow one to display the traffic associated to a single client across all channels, based on its MAC address, or display just the traffic from a single access point, based on its BSSID address, or only display data frames (versus management and control frames). The filtering options in tools like Wireshark are uncountable [ref 11] and something the forensic examiner must get familiarized with.
Finally, there is a relatively new open-source tool to parse single or multiple Pcap files and produce an initial analysis report identifying significant traffic events, statistics and flows, called Honeysnap [ref 12]. It provides security analysts a pre-processed list of high value network activity, aimed at focusing manual forensic analysis and saving relevant incident investigation time.
Although it was designed as a honeynet-related tool to quickly analyze the data collected by a honeynet, it could be very helpful for the network forensic investigator to draw initial facts about the traffic collected. Once the analyst has identified data that interests him, he can then use other tools for more in depth analysis. Currently, the tool can decode TCP and UDP-based protocols, such as HTTP, IRC or DNS, but does not have wireless capabilities, therefore, it is only useful on the wireless unencrypted traffic. However, due to its extensible modular infrastructure, it can be easily modified to include the wireless knowledge required for forensics analysis.
Continued on page 2... (link below)
[ref 1] Sandstorm NetIntercept. http://www.sandstorm.net/products/netintercept/
[ref 2] Niksun NetVCR. http://www.niksun.com/Products_NetVCR.htm
[ref 3] eTrust Network Forensics. http://www3.ca.com/solutions/Product.aspx?ID=4856
[ref 4] “Summary of tools commonly used to support network forensic investigations”. http://searchsecurity.techtarget.com/searchSecurity/
downloads/NetworkForensicToolsSidebar.pdf
[ref 5] Wireshark & tshark. http://www.wireshark.org
[ref 6] ngrep (network grep). http://ngrep.sourceforge.net
[ref 7] tcpdump. http://www.tcpdump.org
[ref 8] “Pcap files containing a roaming VoIP session”. http://www.raulsiles.com/downloads/VoIP_roaming_session.zip
[ref 9] “Two attacks against VoIP”. Peter Thermos. April 2006. http://www.securityfocus.com/print/infocus/1862
[ref 10] “Pcap file containing traffic from multiple channels and captured from a single channel, 9”. http://www.raulsiles.com/downloads/multi_channel_beacons.pcap
[ref 11] “Wireshark & Ethereal Network Protocol Analyzer Toolkit”. Angela Orebaugh, Gilbert Ramirez, Jay Beale (Series Editor). Syngress. ISBN: 1597490733. Chapter 5 – “Filters”: http://www.syngress.com/book_catalog/377_Eth_2e/sample.pdf
[ref 12] Honeysnap. The Honeynet Project. 2006. http://www.honeynet.org/tools/honeysnap/
ไม่มีความคิดเห็น:
แสดงความคิดเห็น