Previous Section  < Day Day Up >  Next Section

Examples and Analysis of Common Wireless Attack Signatures

Now we have arrived to the point of discussing the specific attack tool signatures and attack signs. The best way of knowing these signatures is trying out the tools in question and sniffing out their output: "Attack through defending, defend through attacking" (Dr. Mudge). The best source on wireless network intrusion tool detection and attack signatures we are aware of is Joshua Wright's "Layer 2 Analysis of WLAN Discovery Applications for Intrusion Detection" and "Detecting Wireless LAN MAC Address Spoofing" papers. A large part of this chapter is inspired by these brilliant articles and our experience of analyzing WLAN traffic as real-life attacks take place.

A wireless network discovery or attack tool must transmit data to provide us with an IDS signature. There isn't a way to discover a passive traffic sniffer and WEP cracker, and it doesn't matter how hard you try. Recall that although a card in RFMON mode can transmit data if we force it to do so, it does not ACK the received data and generally does not respond to any traffic we send to it. Cisco Aironet cards do send probe request frames when in the monitoring mode, but reducing the transmission power to 1 mW should hide the attacker fairly well. Besides, newer Linux drivers that come with current kernels ensure that Cisco cards do not probe when in RFMON mode. Thus, the only reliable way to detect "passive" attackers is spotting them physically using optical devices and the "geek with a laptop and antenna" attack signature. Active scanning network discovery, DoS, traffic injection, and man-in-the-middle attacks are an entirely different issue.

NetStumbler and its smaller Pocket PC brother MiniStumbler are the most common wireless IDS signature generators in the wild. They are free, easy to install and use, and, of course, run under the most common operating system in the world. There are a couple of distinct features indicating a "NetStumbler kiddie in the house":

  • NetStumbler probes a discovered AP for additional information, usually the same information present in the SNMP MIB system.sysName.0 parameter. To do this it sends an LLC-encapsulated data probe frame to the AP.

  • LLC-encapsulated frames NetStumbler sends to the discovered APs use an organizationally unique identifier (OID) of 0x00601d and protocol identifier (PID) of 0x0001.

  • These frames have a data payload of 58 bytes.

  • Some versions of NetStumbler add a unique ASCII string to such a payload:

    • NetStumbler 3.2.0: Flurble gronk bloopit, bnip Frundletrune

    • NetStumbler 3.2.3: All your 802.11b are belong to us

    • NetStumbler 3.3.0: intentionally blank 1

  • NetStumbler was reported to transmit probe requests at a frequency higher than the usual active scanning probe request-sending frequency. This report requires additional verification.

MiniStumbler does not send data probes to the discovered APs. Thus, it is more difficult to identify.

BSD-airtools Dstumbler is also capable of active scanning as a proof of concept feature. We do not expect a sensible attacker armed with BSD-airtools to use this feature in real-life network discovery. There is always the RFMON mode. If active scanning with Dstumbler is used, the tool signatures are as follows:

  • Dstumbler generates probe request frames (frame control 0x0040) using low-numbered, modulo 12 sequence numbers.

  • Authenticate frame sent by Dstumbler uses a repetitive sequence value of 11 (0x0b).

  • The following association request frame has a sequence value of 12 (0x0c).

  • After receiving a probe response, Dstumbler attempts to authenticate and associate with the discovered AP. This is possibly the only reason why someone with Dstumbler would ever use active scanning (efficient hunting for the low-hanging fruit).

Another common active scanning WLAN discovery tool you are likely to encounter as a wireless network administrator or security consultant is Windows XP wireless service extension network scanning service. Why use NetStumbler if Windows XP itself can do it? The Windows XP network scanning service sends probe request frames with the broadcast ESSID ("ANY") and a second unique ESSID value. It is this second ESSID that gives the Windows XP users away. In the probe request frames sent, Windows XP sets a tagged value as a portion of the frame that uses up the whole ESSID field (32 bytes). This tagged value is a string of seemingly random nonprintable characters. This data string to hex is







0x14 0x09 0x03 0x11 0x04 0x11 0x09 0x0e

0x0d 0x0a 0x0e 0x19 0x02 0x17 0x19 0x02

0x14 0x1f 0x07 0x04 0x05 0x13 0x12 0x16

0x16 0x0a 0x01 0x0a 0x0e 0x1f 0x1c 0x12

It is not known if this is a bug or a feature of Windows XP. From the viewpoint of the IDS, this is a feature. Keep in mind that inexperienced Windows XP users might not be aware of their system scanning for wireless networks and even associating with them. Thus, what seems like an attack might be a lack of user education rather than malicious intent. As a side note, the same applies to Windows machines and infrared connectivity: Once the IR port is enabled, the system will continue scanning for networks and hosts and connect to the found links if possible. Crackers can abuse this by setting their laptops as IR traps, attacking connecting hosts without users ever understanding what happened.

Let's take a closer look at Wellenreiter and MAC spoofing on WLANs. We have already discussed some features of the Wellenreiter ESSID brute-forcing attack. Here is the actual piece of code from the older Wellenreiter 1.6 version that generates fake ESSIDs and MACs:







system("$fromconf{iwpath} $fromconf{interface} essid

'this_is_used_for_wellenreiter'");

system("$fromconf{ifconfig} $fromconf{interface} down");

my $brutessid = shift (@g_wordlist);

my $mactouse = build_a_fakemac;

system("$fromconf{ifpath} $fromconf{interface} hw ether $mactouse");

print STDOUT "\nI test now the essid: $brutessid";

system("$fromconf{iwpath} $fromconf{interface} essid $brutessid");

system("$fromconf{ifpath} $fromconf{interface} up");

return ($true);

The build_a_fakemac subroutine for creating fake MAC addresses is as follows:













sub build_a_fakemac

{

my $fakemac;

# Perform 4 iterations of the following statements. This is actually a bug, should

# be 5 iterations to generate a 40\x{00AD}bit value. This procedure will consistently

# generate MAC addresses that ifconfig will pad with a trailing hex 40.

for (my $i =0;$i < 4;$i++)

{

# $temp contains a random hex value between 0 and 255

my $temp = sprintf "%x", int(rand(255));

if (length($temp) == 1)

{

# prepend single\x{00AD}digit values with a leading zero

$temp = '0' . $temp;

}

# append the hex value in $temp to the generated MAC address

$fakemac = $fakemac . $temp;

}

# prepend a leading 00 to the generated MAC address to avoid conflict with reserved or

# multicast/broadcast MAC addresses

$fakemac = '00' . $fakemac;

return ($fakemac);

As you can see, the first ESSID to be set is this_is_used_for_wellenreiter, then the brute-forcing (well, actually a dictionary attack, my $brutessid = shift (@g_wordlist);) begins. The MAC addresses produced will start from 00 to avoid generating multicast-specific MACs. Wellenreiter generates multiple MAC prefixes that do not follow the OUI allocation list published in RFC 1700. By monitoring such traffic and comparing the OUIs to the RFC list, crackers who are using randomized MAC prefixes without a prior thought can be easily detected. Note that the same principle would apply to any cracker tool that generates random MAC addresses, unless the tool takes the OUI allocation table into account during the frame generation process. An example of such a smart tool is the Black Alchemy's FakeAP. Joshua Wright has written an example maidwts.pl Perl script that compares source MAC address OUIs to the IEEE OUI list and generates alerts when the prefix is not allocated to a known hardware vendor:







arhontus:~# perl maidwts.pl -h

Usage:

  maidwts [options]

    -i, --interface

    -f, --filename

    -c, --count

    -n, --nopromisc

    -t, --timeout

    -a, --rfmonwlan

    -z, --stdethernet

    -v, --verbose

    -h, --help



e.x. "maidwts -c 500 -i eth1 -a" To capture in 802.11 RFMON

e.x. "maidwts -c 500 -i eth1 -z" To capture std ethernet frames

Such functionality can be a worthy addition to your IDS tool or scheme.

How about man-in-the-middle attack detection? AirJack sets a default ESSID "AirJack"; because the fata_jack DoS tool also uses the airjack_cs driver, the default EISSD would be the same (note essid_jack and wlan_jack). There will be a surge of spoofed deauthentication frames directed against the attacked host and a very brief loss of connectivity between that host and the AP. However, the best shot at detecting Layer 2 man-in-the-middle attacks (or any Layer 2 spoofing) on WLANs is through the analysis of 802.11 frame sequence numbers.

The sequence number field in 802.11 frames is a sequential counter that is incremented by one for each nonfragmented frame. The number starts at zero and goes up to 4,096. Then the counter is reset back to zero and a new count begins. The catch is you can't set this parameter to an arbitrary value even if you generate completely custom frames with a tool like Wnet's dinject. When an attacker interferes with the existing transmission pattern, the sequence numbers of the attacker-transmitted frames will not correspond to the sequence numbers of frames normally present on the network. As an example, FakeAP generates traffic pretending to originate from different access points in the area. When you look at the ESSIDs and MAC addresses only, you won't be able to tell FakeAP beacon frames from legitimate beacon frames that could have been transmitted. However, the sequence number incrementation by one would flag the FakeAP traffic out. If several APs were really around, you'd see several incrementing counters, not one with changing MACs and ESSIDs.

In the case of AirJack, we'll have to baseline the sequence numbers between the AP and the host the attacker will deauthenticate. In practical terms, this is a difficult task on large wireless networks, especially if roaming hosts are present; however, it is not impossible. If the frame sequence number window of the legitimate traffic between the client and the AP lies in a range from X to Z, spoofed frame sequence numbers coming from the attacker would stick out of the X–Z range like a sore thumb. Check out an example of such an attack detection using Ethereal in Joshua Wright's original "Detecting Wireless LAN MAC Address Spoofing" article. Of course, if a DoS attack is launched against a legitimate wireless client or even the AP itself and is followed by the cracker spoofing as a knocked-out host, the sequence number chain would also be broken. This makes 802.11 frame sequence number baselining, monitoring, and analysis a great way to detect and thwart spoofing attacks on WLANs. However, in the real world some wireless client cards are broken in the sense of not following the 802.11 standard specification for sequence number generation. This applies to Lucent cards with old firmware releases before the 8.10 version—one more reason to keep your firmware updated. Also, roaming hosts will generate false positives by being out of the sequence number cycle when moving from cell to cell. Thus, 802.11 frame sequence number analysis is somewhat useless on networks with a large number of roaming users and should be built into the IDS applications as an option that can be turned off when necessary.

When analyzing the attack tool signature examples presented, one thing becomes obvious: Crackers can easily modify or eliminate the signatures to avoid detection. There are reports of NetStumbler users who employ hex editors to remove the strings mentioned from the NetStumbler data probe frames. ESSIDs sent by tools such as Wellenreiter or AirJack can be easily changed. For example, in airjack.c (at the time of writing) the default ESSID was defined on line 1694:







memcpy(ai->essid + 1, "AirJack", 7);

Thus, we have completed the full circle and returned to the beginning of this chapter: A proper wireless IDS should implement and integrate both attack signature comparison and network traffic anomaly detection.

    Previous Section  < Day Day Up >  Next Section