Access points vulnerabilities to DoS attacks in 802.11 networks L. Valcamonici
IAC – CNR Viale del Policlinico, 137, 00161 - Rome, Italy Email: [ferreri,massimo]@iac.cnr.it
CASPUR Via dei Tizii, 6b, 00185 - Rome, Italy Email:
[email protected]
CLASS 1 & 2 frames
Abstract— We describe possible denial of service attacks to infrastructured wireless 802.11 networks. To carry out such attacks only commodity hardware and software components are required. The results show that serious vulnerabilities exist in different access points and that a single malicious station can easily hinder any legitimate communication within a basic service set.
The peculiar features of wireless networks suggest a greater exposure to Denial of Service (DoS) attacks than wired networks. Since the wireless medium does not have well defined physical bounds, a malicious station can appear in the range of such a network and launch an attack in order to stop any legitimate communication. The aim of this paper is to investigate how these kinds of attacks can be carried out. In particular we tried to identify some simple attack schemes that might lead to a DoS effect and then observed the reactions of various types of infrastructured networks to these attacks. Our guidelines can be summarized as follows: [1] The 802.11 protocol is based on the exchange of request/response messages: each request sent by a station (STA) in the network triggers a corresponding response on its counterpart, which can be, in turn, another station or an Access Point (AP) [1]; [2] infrastructured networks rely on an access point (or a set of them) as a central node through which every communication is routed, thus an AP can easily become a bottleneck for the entire network (or, at least, for the Basic Service Set it defines1 ). An AP failure causes the block of the entire network or a part of it; [3] attack patterns should be as simple as possible, in order to apply both to open systems and WEP-protected networks. From this viewpoint, a malicious station should be able to launch an attack even if it is neither associated nor authenticated to the target network. Following these guidelines, we started to identify message sequences that could lead to an attack towards an AP. The management frames of the 802.11 protocol look like the most 1 a Basic Service Set is made of an AP and the client stations connected to that AP
WCNC 2004 / IEEE Communications Society
CLASS 1,2 & 3 frames
I. I NTRODUCTION
1 Unauthenticated and unassociated Successful authentication Deauthentication notification
2 Authenticated and unassociated Successful association
Deauthentication notification
CLASS 1 frames
F. Ferreri and M. Bernaschi
Disassociation notification
3 Authenticated and associated
Fig. 1. Finite State Machine (FSM) representing the AP/STA interaction. State 1 represents any client neither associated nor authenticated to the AP yet (such as an external attacker station)
suitable to this purpose, because any management frame sent to an AP triggers an elaboration with consequent consumption of computational resources. Figure 1 shows a Finite State Machine (FSM) representing the interaction between an AP and any station in a 802.11 infrastructured network. State 1 in the FSM represents stations that have not gained any privilege yet (they are neither associated nor authenticated to the AP), thus this is a common situation for a malicious station willing to launch an attack. 802.11 management frames are divided into three classes, in each state of the FSM only certain classes of frames can be exchanged (see tab. I). Starting from this classification, we identified three simple flooding attack schemes. A. Probe request flood (PRF) Probe request frames are used by stations to actively scan an area in order to discover existing wireless networks; any AP receiving a probe request frame must respond with a proper probe response frame that contains information about the network, to allow the station to associate.
634
0-7803-8344-3/04/$20.00 © 2004 IEEE
Class 1 2 3
frame types probe request/response, authentication, deauthentication association request/response, reassociation, disassociation deauthentication TABLE I 802.11 MANAGEMENT FRAME CLASSES .
By sending a burst of probe request frames very quickly, each with a different MAC address (MAC spoofing) to simulate the presence of a large number of scanning stations in the area, we can induce a heavy workload on the AP, resulting in a wasting of computing and memory resources which can not be used for normal operations. B. Authentication Request Flood (ARF) AP response to an authentication request frame depends on the authentication settings of the network: open system networks: no cryptography is involved, the AP processes each request, possibly comparing the MAC address with an access control list, then it responds with a frame containing the authentication process result; shared key networks: after receiving an authentication request by a station, the AP generates a random challenge text and sends it to the station in a second authentication frame; the challenge text has to be encrypted with a proper WEP key by the station to gain access to the network. In both cases the AP must allocate memory to keep information about each new station that successfully authenticates. As in the previous case, by sending a burst of authentication request frames, using MAC spoofing, it should be possible to bring AP’s resources close to the saturation level. C. Association request flood (ASRF) According to the protocol FSM, association request frames should not be sent by stations in unauthenticated/unassociated state, so such requests should never receive an answer by the AP. Actually we discovered that many APs respond to “illegal” association request frames by sending a disassociation or deauthentication frame. As a consequence, even a burst of association request frames is able to consume computational resources on an AP. D. Related work Despite the great number of works related to wireless security, DoS attacks have not been deeply investigated yet. Among the few works focused on these peculiar attacks, we recall [3] and [2]. The latter appears to be the most closely related to our work. The paper describes deauthentication and disassociation attacks which rely on the repeated injection of fake deauthentication or disassociation frames (both from the AP to STAs and from a STA to the AP) in order to cause legitimate clients to be disconnected from the AP in use. A third kind of attack is based on
WCNC 2004 / IEEE Communications Society
a malicious manipulation of the Network Allocation Vector (NAV)2 information contained in 802.11 frames, in order to prevent legitimate stations from gaining access to the medium. While the deauthentication/disassociation attacks were already known in the developers community, and have proved to be really effective, attacks based on the NAV seem to be ineffective in real networks, due to a wrong implementation of CSMA/CA mechanisms by card vendors. The attacks presented in the paper differ from the ones we have devised in terms of target localization and easiness of use. While deauthentication/disassociation attacks are directed to single or multiple clients and NAV attacks focus on medium availability, our attacks focus on the AP as a central node and a possible bottleneck for the entire network, also having, as a side effect, a negative impact on medium availability, due to high frame injection rates. Moreover, NAV attacks rely on complex manipulations that are located at the firmware level, whereas our attacks are possible through simple software components. There are also a few public domain tools, like those available from http://home.jwu.edu/jwright or http://www.wlsec.net/void11/, but it looks like they have been tested only on a very limited base. II. T ESTBED ENVIRONMENT As a testing platform we used two identical laptops each equipped with a Netgear MA401 PCMCIA card, both running Linux 2.4.20 and the HostAP device driver. These two laptops were used as legitimate clients of the wireless network, whereas a third machine was used to launch attacks against the wireless networks. We tested the behavior of four different types of access point: an Enterasys RoamAbout R2 equipped with a CSIBD-AB-128 card, a Netgear ME102, a 3Com AP 8000 and a PC-based access point, running the HostAP driver. Legitimate clients authenticate and associate to APs, and then run the netperf benchmark [5] or other simple commands. As attacker station we used a third laptop, running the same version of Linux (2.4.20) and equipped with the same Netgear MA401 PCMCIA card. To carry out the attack schemes previously described, we needed a mechanism to forge arbitrary 802.11 management frames and injecting them in the medium, regardless of protocol rules and constraints. Thus, we developed a simple application, named wfit (wireless frame injection tool), based on the Radiate library [4]. The Radiate library is built on top of an old version of the HostAP driver, which uses a netlink socket to receive “loose” frames from user-space applications (it seems that such feature has been discarded in more recent versions of the driver). The library enables us to build all types of 802.11 management and data frames passing them to the card firmware through the socket for transmission. During the test and tuning phase, we found few limitations 2 each frame contains a duration field which indicates how long the current transmission will keep the medium busy; other STAs should wait for this amount of time before starting a new transmission; thus, sending fake frames with a high duration value, should prevent other STAs from transmitting
635
0-7803-8344-3/04/$20.00 © 2004 IEEE
on the maximum number of frames per second that can be injected. These limits are not influenced by the machine speed, but mainly depend on the rate at which frames are passed by the application layer to the netlink socket. This is probably due to the configuration of the kernel, PCMCIA subsystem and card but we did not try to address such issue. Maximum injection rates are listed in tab. II. As we can see, ARF and ASRF rates are much lower than the PRF one. These values are measured in the absence of any other station or AP. In a managed network, they tend to decrease to an unpredictable value due to the presence of many stations trying to gain access to the wireless medium. Scheme PRF ARF ASRF
frames/sec 810 260 ÷ 280 260 ÷ 280
TABLE II F RAME INJECTION RATES ( FRAMES / SEC ). VALUES REFER TO A SITUATION IN WHICH NO OTHER STATION IS ACCESSING THE MEDIUM THROUGH
... 2.4830 2.4837 2.4843 2.4853 2.4862 2.4871 2.4880 2.4887 2.4894 2.4905 2.4913 2.4917 2.4923 2.4930 2.4935 2.4945 2.4956 2.4966 2.4973 ...
00:1a:24:44:9d:89->Broadcast P.Req. 00:8e:04:63:01:f6->Broadcast P.Req. Enterasy_c6:c0:ba->00:f2:68:1c:56:37 P.Resp. Enterasy_c6:c0:ba ->00:8e:04:63:01:f6 P.Resp. Enterasy_c6:c0:ba->00:8e:04:63:01:f6 P.Resp. Enterasy_c6:c0:ba->00:8e:04:63:01:f6 P.Resp. Enterasy_c6:c0:ba->00:8e:04:63:01:f6 P.Resp. 00:b2:54:02:bb:55->Broadcast P.Req. Enterasy_c6:c0:ba->00:b2:54:02:bb:55 P.Resp. Enterasy_c6:c0:ba->00:b2:54:02:bb:55 P.Resp. 00:c2:85:cf:34:15->Broadcast P.Req. 00:9e:5c:dd:b5:6b->Broadcast P.Req. Enterasy_c6:c0:ba->00:b2:54:02:bb:55 P.Resp. 00:74:a7:d3:90:fd->Broadcast P.Req. Enterasy_c6:c0:ba->00:b2:54:02:bb:55 P.Resp. Enterasy_c6:c0:ba->00:c2:85:cf:34:15 P.Resp. Enterasy_c6:c0:ba->00:c2:85:cf:34:15 P.Resp. Enterasy_c6:c0:ba->00:c2:85:cf:34:15 P.Resp. ToyotaMa_21:4e:48->Broadcast P.Req.
Fig. 2. PRF attack on the Enterasys RoamAbout managed network. Note that Ethereal parses fake MAC addresses and matches them against a list of known vendors.
CSMA/CA MECHANISMS .
III. E XPERIMENTAL RESULTS Hereafter we present and discuss the results collected for each of the four network configurations we tested. A. Enterasys RoamAbout managed network The PRF attack, performed at maximum rate, blocks completely the test bed network. The AP seems to be 100% busy in managing probe request frames and normal communication among legitimate clients in the infrastructured network is interrupted. This result does not depend on the protocol or application used by legitimate clients A different outcome is obtained if we disable the MAC spoofing mechanism, thus sending each frame with the same MAC address (i.e., the real MAC address of the card): any DoS effect vanishes even though we are injecting frames at the same rate. Below, we provide a possible explanation of this result. Beside that, we did not observe any significant result while executing ARF and ASRF attacks, if we exclude an obvious performance degradation, which the netperf benchmark indicates to be about 30% for a raw TCP stream between the two legitimate clients in the network. All the attack patterns have been analyzed using the Ethereal sniffer. Due to space limitations we can not show all the data so we chose to report in fig. 2 just the PRF attack pattern for the case in which the MAC spoofing mechanism is enabled. Probe response frames with spoofed addresses are not acked by the attacker station because they have a destination MAC address which is different from the real MAC address of the card. As a consequence, the AP has to send each response 4 times, until a retry limit is reached and the frame is discarded. This is, likely, the cause of the DoS effect: the AP needs a relevant amount of memory and computing time to manage unacked frames that must be stored and retransmitted
WCNC 2004 / IEEE Communications Society
until the limit is reached. This can also explain why the DoS effect does not appear when MAC spoofing is disabled. In this case, the attacker’s card injects frames with its real MAC address and then acknowledges responses from the AP that are directed to its own address. The AP receives the acknowledgment of each frame and thus does not need to buffer frames for retransmission. Note that there is no way to set, via software, retry limits of this AP. The retry limit for an authentication response is set equal to 7, whereas it is set equal to 4 for an association response (that is, actually, a deauthentication frame). Nonetheless, the ARF and ASRF attacks do not have a serious impact on the network. The reason could be found in the lower frame injection rate as compared to the PRF case. If it were possible to send authentication and association frames at higher rates we could probably cause a DoS effect as well. To collect some statistics about the attack schemes, we ran the attacks for a period of 10 seconds, while sniffing frames with Ethereal for a period of 20 seconds. In such a way, we could capture all delayed response frames sent by the AP and then measure: Nreq: number of unique requests sent by the attacker station; Ndup: number of duplicate requests sent by the attacker station 3 ; Nresp: number of requests responded by the AP; Nlost: number of requests not responded by the AP; Nrr: number of response frames for each request frame; Trr: average elapsed time (in seconds) since a request frame and correspondent first AP response frame . Collected values are reported in tab. III. In the PRF case more than half of the requests are not fulfilled by the AP. Moreover, the average response time is almost three orders of magnitude larger than in the other cases. This is probably due to a lack 3 In some cases the card firmware repeats the transmission of a frame received from a user-space application
636
0-7803-8344-3/04/$20.00 © 2004 IEEE
PRF ASRF ARF
Nreq 4553 886 756
Ndup 0 886 754
Nresp 2089 886 756
Nlost 2464 0 0
Nrr 3.69 3.88 7.813
Trr 0.24 0.0007 0.0008
After disabling WEP, no attack leads to DoS situations, even PRF ASRF ARF
TABLE III ATTACKS STATISTICS FOR THE E NTERASYS ROAM A BOUT MANAGED NETWORK .
Nreq 6621 537 617
Ndup 0 536 616
Nresp 4048 391 72
Nlost 2573 146 545
Nrr 1.009 11.189 10.708
Trr 0.002 0.126 0.167
TABLE IV ATTACKS STATISTICS FOR N ETGEAR ME102 MANAGED NETWORK (WEP ENABLED ).
of buffer space and a heavy consumption of resources on the AP. Unfortunately, AP’s built-in counters give no valuable information about internal resources usage. As an additional result, it looks like the introduction of WEP cryptography (128 bit) does not modify significantly the picture. From this viewpoint, we will see a pretty different situation in the next section. B. Netgear ME102 managed network In the present case, we started the tests with WEP (128 bit) cryptography enabled. The results can be summarized as follows: [1] The PRF attack has no effect on network performance; [2] the ARF attack causes the AP to crash and stop working. The AP needs to be restarted after each attack; [3] the ASRF attack causes the exhaustion of the AP resources. The communication among legitimate clients becomes impossible. In general, this network showed a worse performance with respect to the previous one, even running under normal conditions. This probably accounts for its higher sensibility to flooding attacks executed at a lower frame injection rate. The Netgear AP has a retry limit set equal to 1 for probe response frames. This can explain why the attack does not have a major impact: no frame is stored for retransmission and no buffer space is required for deferred transmissions. However, there is still a high number of frames that receive no response by the AP. This could be due to a lack of buffers for the reception but it looks like there are no bad side effects (normal communications among clients are not hindered). In both the ARF and the ASRF case, the retry limits are set equal to 11. Tab. IV shows numerical values collected during the attacks. We can see that, under the ASRF and the initial phase of the ARF attack, the response time is about 60-80 times higher than in the PRF case. While the DoS effect caused by the ASRF attack can still be justified by high retry limits, the most interesting effect is the crash caused by the ARF attack. Since WEP is enabled, the AP reacts to an authentication request generating a challenge text and sending it to the station that originates the request. It is possible that back-to-back challenge text generation may lead the AP to a crash. Another possible explanation is that the AP pre-encrypts each challenge text before receiving the encrypted version by the station. The anomalous sequence of cryptographic operations could induce a fatal workload on the AP or produce illegal operations that cause the crash. Unfortunately, no details are available to us about the internals of this AP.
WCNC 2004 / IEEE Communications Society
though retry limits are unchanged: table V reports the results for this case. Response times and lost frames values (except for the PRF and the ARF cases) are similar to the previous ones, but normal communications among clients are granted and no interruption is observed. These results led us to revise our previous considerations: we stated before that unacked frame retransmission is a key component in determining the efficiency of our flooding attacks. Actually, it looks like the real impact strongly depends on the overall AP performance. When WEP is enabled, the Netgear AP has to manage a heavier workload even in normal conditions, so it is easy to cause a DoS through a flooding attack regardless of the (low) injection rate. Disabling WEP probably frees memory and computational resources that allow the AP to withstand to the same attack. PRF ASR AR
Nreq 849 550 619
Ndup 1 549 618
Nresp 790 396 449
Nlost 59 154 170
Nrr 1 11.247 10.797
Trr 0.0015 0.115 0.123
TABLE V ATTACKS STATISTICS FOR N ETGEAR ME102 MANAGED NETWORK (WEP DISABLED ).
C. 3Com Access Point 8000 managed network Testing the 3Com AP we noted a somehow different behavior: [1] The PRF attack completely blocks the testbed network, even though the retry limit for probe response frames is set equal to one; [2] the ARF attack blocks the testbed network, but it doesn’t cause a crash of the AP. After the attack stops, communications among legitimate clients are restored; [3] the ASRF attack does not show relevant effects on the network. Although the retry limit for this AP is set equal to one, the PRF attack still causes a DoS effect. This result seems to be somehow in contrast with the previous ones, so a more detailed analysis is required. It is useful to compare the 3Com case with the Netgear one. Both APs have the retry limit set equal to one, but the latter is not susceptible to the attack. Under the PRF attack, the Netgear AP keeps sending responses at an almost constant rate (about a response every 2-4 requests) whereas the 3Com AP seems to be completely subverted by the
637
0-7803-8344-3/04/$20.00 © 2004 IEEE
PRF ASRF ARF
Nreq 10288 1040 1021
Ndup 1 1039 1020
Nresp 724 875 146
Nlost 9504 165 875
Nrr 1 1 7.938
Trr 0.588 0.399 3.064
TABLE VI ATTACKS STATISTICS FOR 3C OM ACCESS P OINT 8000 MANAGED NETWORK ( NO WEP).
requests flow. We found in the attack log very long sequences of probe request frames without any response from the AP. It is as if the 3Com AP were not able to gain access to the wireless medium in case of flooding attacks regardless of retry mechanisms. If we look at data collected in tab. VI, we see that the attacker station is able to send out up to 10000 frames in 10 seconds. In other words, it has an almost exclusive access to the wireless medium. The response time also denotes a very high latency (half a second) when compared to other APs. In the case of the ARF attack pattern, the 3Com AP shows a better promptness (indeed, ARF attack has a lower injection rate) but a high retry limit (nearly 8) which causes the DoS effect: the number of lost frames (tab. VI) is very high and the response time reaches 3 seconds. We could expect a similar behavior in the ASRF case, but the retry limit set equal to one prevents any DoS effect. It is worth noting that a vulnerability to a low-rate attack, such our ARF, suggests a serious weakness of the implementation. The activation of WEP cryptography does not modify significantly the overall results. D. HostAP, PC-based managed network A minimal AP can be set up by using a laptop computer equipped with a Prism2 card (such as the Netgear MA401 we use in our testbed) and the HostAP driver (http://hostap.epitest.fi/). Clearly, this kind of infrastructured network does not have the same range of action of a specialized AP (unless an additional antenna is used) but it can be useful to gain further information about the DoS attacks we devised. When exposed to flooding attacks, the HostAP network reacts in a way which is quite similar to the Enterasys AP: a PRF attack causes DoS (all communications are hindered), whereas ARF and ASRF attacks do not cause major troubles to the network. In table VII we report some results: the AP has a retry limit equal to 3 for all kinds of frames. Under the PRF attack, there is a high loss of frames and a response time which is about two order of magnitude higher than in the ARF and ASRF cases. The HostAP driver PRF ASRF ARF
Nreq 9629 788 736
Ndup 1 786 736
Nresp 860 787 736
Nlost 8769 1 0
Nrr 2.98 2.998 2.997
Trr 0.44 0.004 0.0024
TABLE VII ATTACKS STATISTICS FOR H OSTAP MANAGED NETWORK .
WCNC 2004 / IEEE Communications Society
provides further information about the PRF attack. Looking at some of the fields available in the /proc filesystem, we noted a large number of TxDeferredTransmissions (43478) which indicates that the AP is under heavy load and a lot of frames are in queue for transmission. The TxRetryLimitExceeded counter (845) correctly reported the number of frames that have been retransmitted until the retry limit. Interestingly, the RxDiscardsNoBuffer (14762) parameter had a high value, an indication that a lot of frames were discarded (neither elaborated nor responded) due to the lack of buffer space for reception. IV. C ONCLUSION We have shown how some simple flooding attacks, based on the injection of forged frames, may cause a serious service degradation in 802.11 wireless networks. The key points we discovered can be summarized as follows: [1] PRF, ARF and ASRF flooding attacks can be executed by any malicious station in the area of a wireless infrastructured network, without being neither associated nor authenticated to the access point; [2] AP’s main vulnerability to these flooding attacks seems to reside in unacked frame retransmission, which causes memory buffers exhaustion and freezes AP functionalities; [3] weak implementations of the 802.11 protocol in access points can determine further vulnerabilities, which allow malicious stations to crash an AP. We have designed a detection and defense mechanism and tried to embed it in the Linux HostAP PC-based access point. Unfortunately, we realized that its vulnerability to PRF attacks can not be mitigated by acting at the software driver level, since probe request frames are managed directly in the Network Interface Card (NIC) without being passed to the upper (device driver) level. It is likely that, more in general, the AP vulnerabilities to our DoS attacks are caused by a naive implementation of the firmware level. Thus, an effective and robust defense mechanism should reside at the firmware level (we don’t know, at this time, whether it makes sense to implement any defense at the lowest, physical, level). Obviously the development of a solution at the firmware level requires vendors’ support that should, at least, provide adequate documentation and development toolkits. We are looking for a vendor willing to collaborate in making 802.11 networks more reliable. R EFERENCES [1] M. Gast,“802.11 Wireless Networks - The Definitive Guide”, O’Reilly, 2002. [2] J. Bellardo and S. Savage, “802.11 Denial-of-Service Attacks. Real Vulnerabilities and Practical Solutions”. In Proceedings of the 12th USENIX Security Symposium, Washington, D.C., August 4-8, 2003. [3] V.Gupta, S. Krishnamurthy and M. Faloutsos, “Denial of Service Attacks at the MAC Layer in Wireless Ad Hoc Networks”. In Proceedings of 2002 MILCOM Conference, Anaheim, CA, October 2002. [4] M. Schiffman, “The Need for an 802.11 Wireless Toolkit”. Black Hat Briefings, July 2002 [5] http://www.netperf.org/.
638
0-7803-8344-3/04/$20.00 © 2004 IEEE
