Layer 1 DoS Attacks

A particularly troublesome issue for Wi-Fi security is the denial of service (DoS) attack. In a DoS attack, the goal of the attacker is not to penetrate or steal data from the network it is simply to disable the network. For mission-critical systems, this is a serious security concern. If the WLAN goes down, then any application or network resource being accessed through the WLAN is now no longer available. The wireless VoIP phone conversation comes to an abrupt end, communications with your database server are no longer possible, and wireless access to an Internet gateway has been closed.

Many denial of service attacks exist at layer 2 and occur when an attacker manipulates information in the layer 2 header of an 802.11 management frame and then retransmits the edited frames into a wireless environment with some sort of packet generator. Numerous published layer 2 DoS attacks exist. The most common is achieved by manipulating de-authentication or disassociation management frames. Currently, layer 2 DoS attacks cannot easily be prevented, but can be easily detected.

The 802.11w Task Group is addressing methods to also prevent many layer 2 DoS attacks. This method has been driven by Cisco’s Management Frame Protection under the Unified Wireless vision. In the meantime, wireless intrusion detection systems can detect and locate the radio card that is the source of a layer 2 DoS attack. But denial of service attacks to wireless networks can even more easily occur at layer 1 in the RF environment.

Layer 1 DoS attacks are a result of radio frequency interference interference. 802.11 WLAN radio cards use a medium access method called carrier sense multiple access/collision avoidance (CSMA/CA). This medium access method ensures that only one single radio card is transmitting at any given time in the half-duplex radio frequency medium. Part of the CSMA protocol is the clear channel assessment (CCA).

The simplest explanation of clear channel assessment is that 802.22 radio cards listen before they transmit. if an 802.11 radio is about to transmit, it will perform a CCA and listen of current RF transmissions in the same frequency space. If the RF medium is clear, the radio card will transmit. However, if the medium is not clear (based on sensing RF transmissions that exceed pre-defined energy thresholds), the 802.11 radio will defer for a defined amount of time and then perform the CCA once again to listen for a clear medium before transmitting.

But if there is a “continuous” RF transmission that is constantly heard during the CCA intervals, 802.11 transmissions will completely cease until the signal is no longer present. If 802.11 transmissions cease due to an interfering RF signal, the result is a denial of service to WLAN. What can cause layer 1 DoS? Layer 1 DoS can be a result of either intentional or unintentional interference.

Undetectable Rogue Access Points

The wireless security risk that receives the most attention is that of a rogue access point. Rogue 802.11 devices are most often connected to an 802.3 Ethernet data port by an employee who dose not realize the consequences of his actions. The issue is that the rogue device is now a portal to your 802.3 wired infrastructure. Anyone who can connect to the wireless rogue device now can potentially attack network resources via the wireless portal. WIDS solutions were first developed to detect rogue access point and rogue devices. Not only have WIDS solutions proved to be effective at detecting rouge WI-Fi devices but the same solutions have been extended to automatically disable the rouge devices using a number of published and unpublished termination methods.

The problem is that certain types of rogue access points currently go undetected because of the layer 1 analysis limitations of the WIDS/WIPS solutions. The 802.11 radio cards that reside inside a WIDS/WIPS solutions are designed to understand other Wi-Fi signals. Therefore any rogue device that uses the standard Wi-Fi protocols will be detected fairly instantly. (Although devises that use Wi-Fi in non-standard ways such as operating on a non-standard center frequency may not be easily detected). And devices that use other protocols will also not be detected. Examples of these non-Wi-Fi rogue devices include devices that use frequency hopping spread spectrum (FHSS) radio protocols. Legacy 802.11 access points that were manufactured from 1997-1999 often used a frequency hopping protocol called 802.11 FH. Additionally, a consortium of mobile wireless vendors called the HomeRF

Working Group used to exist. These vendors manufactured non-802.11 access points that also used FHSS transmissions in the 2.4 GHz frequency range. Although 802.11 FH and HomeRF devices are no longer sold, they are widely available at very little cost on eBay and other auction retailers. Bluetooth radios also use FHSS transmissions in the 2.4 GHz frequency range. Because Bluetooth radios are in many devices that also have Ethernet connectivity (Such as laptops), Bluetooth radios should also be considered a potential rogue threat.

Bluetooth radios can all be used by an attacker as rogue devices and will go undetected by current WIDS/WIPS solutions. In fact, because of this weakness, they make very attractive approaches for someone trying to maliciously install an open port onto your network. The proper tool needed to detect and locate these rogue devices is a spectrum analyzer. Spectrum analyzers can detect all types of non-WiFi radio devices, including frequency hopping radios. In fact, some analyzers can look at the RF signature of the device, and determine exactly what type of non-WiFi radio has been found. Another potential rogue device that can go undetected is an access point that transmits in a frequency range not supported by 802.11 radios. 802.11 radios either transmit in the unlicensed 2.4 GHz ISM frequency band or in the unlicensed 5 GHz UNII frequency bands. Non-802.11 wireless networking equipment exists that operates in the 902-928 MHz unlicensed ISM frequency band. Only a spectrum analyzer that sweeps the 900 MHz frequency range could detect this type of device because 802.11 radios do not listen in 900 MHz frequency range.

A Layer 2 WIDS/WIPS solution is still a recommended solution for detection and prevention of many 802.11 rogue devices. But adding a full-time spectrum analysis solution provides for greater detection of a wider range of rogue devices.

Wi-Fi Security Concerns

WLANs have additional security threats to consider that are RF in nature. Protocol-level attacks that attempt to penetrate Wi-Fi data security include rogue access points, authentication attacks, evil twin access point, man-in-the-middle, Wi-Fi phishing, and malicious eavesdropping. Most of these attacks exit at layer 2 of the OSI model. Proper authentication, encryption, and segmentation security solutions can be implemented to mitigate many of these well-known attacks. Layer 2 security monitoring solutions can also be put in place to detect when layer 2 attacks are taking place.

But a major oversight in current wireless intrusion detection systems (WIDS) solutions is that they have been unable to detect layer 1 security threats WIDS typically use 802.11 radio cards that have limited layer 1 visibility. They are only capable of monitoring high-level layer 1 statistics such as received signal strenght and signal-to-noise ratio (SNR) across a channel. These limited capabilities are completely insufficient for full spectrum analysis. For this reason, the 802.11 radio card that resides in a mobile or sensor-based WIDS solution can perform only layer 2 security monitoring and layer 2 performance analysis. With that in mind, it should be understood that the only effective tool for accomplishing proper layer 1 spectrum analysis and layer 1 security monitoring is a true spectrum analyzer.

Packet capture

Image via Wikipedia

Packet sniffer’s, are protocol analyzers meant to capture the packets that are seen by a machine’s network interface. When a sniffer runs on a system, it grabs all the packets that come into and goes out of the Network Interface Card (NIC) of the machine on which the sniffer is installed. This means that, if the NIC is set to the promiscuous mode, then it will receive all the packets sent to the network if that network is connected by a hub. Unfortunately, in a switched network, since switches do not broadcast the packets, sniffers cannot see any packet that is not having the destination address of the machine on which it is installed.

This is unfortunate for testing reasons, but fortunate for security reasons. It is fortunate because, if an attacker installs a sniffer in a trusted network, but if the trusted network uses a hub to broadcast the packets within that network, then the sniffer would be able to look at every single packet that is going across the network.

Many network monitoring tools are based on passive packet capture. The principle is
the following: the tool passively captures packets flowing on the network and analyzes
them in order to compute traffic statistics and reports including network protocols being used, communication problems, network security and bandwidth usage. Many network
tools that need to perform packet capture ([tcpdump], [ethereal], [snort]) are based on a popular programming library called libpcap [libpcap] that provides a high level
interface to packet capture.

The main library features are:
• Ability to capture from various network media such as ethernet, serial lines, virtual interfaces.
• Same programming interface on every platform.
• Advanced packet filtering capabilities based on BPF (Berkeley Packet Filtering),
implemented into the OS kernel for better performance.

Depending on the operating system, libpcap implements a virtual device from which
captured packets are read from userspace applications. Despite different platforms
provide the very same API, the libpcap performance varies significantly according to
the platform being used.

On low traffic conditions there is no big difference among the various platforms as all the packets are captured, whereas at high speed1 the situation changes significantly. The following table shows the outcome of some tests performed using a traffic generator [tcpreplay] on a fast host (Dual 1.8 GHz Athlon, 3Com 3c59x ethernet card) that sends packets to a mid-range PC (VIA C3 533 MHz, Intel 100Mbit ethernet card) connected over a 100 Mbit Ethernet switch (Cisco Catalyst 3548 XL) that is used to count the real number of packets sent/received by the hosts3.

The traffic generator reproduces at full speed (~80 Kpps) some traffic that has been captured previously, whereas the capture application is a simple application named pcount based on libpcap that counts and discards, with no further analysis, the captured packets.