Wireless Netw (2008) 14:159–169
DOI 10.1007/s11276-006-8870-6
Access points vulnerabilities to DoS attacks in 802.11 networks
M. Bernaschi · F. Ferreri · L. Valcamonici
Published online: 9 October 2006
C Springer Science + Business Media, LLC 2006
Abstract We describe possible denial of service attacks to
access points in infrastructure wireless networks using the
802.11b protocol. To carry out such attacks, only commod-
ity hardware and software components are required. The ex-
perimental results obtained on a large set of different ac-
cess points show that serious vulnerabilities exist in any de-
vice we tested and that a single malicious station can easily
hinder any legitimate communication within a basic service
set.
Keywords Access points . Firmware . Denial of service
1 Introduction
The use of 802.11 wireless networks is steadily increasing
despite of many studies that report security problems, mainly
related to authentication, privacy and confidentiality issues.
Besides that, the peculiar features of the wireless medium
suggest a greater exposure to Denial of Service (DoS) attacks
than wired networks. Since the wireless networks do not have
well defined physical boundaries, a malicious station can ap-
pear in the range of such a network and launch an attack in
order to stop any legitimate communication. The aim of the
present work is to investigate how this kind of attacks can
M. Bernaschi ()
IAC – CNR, Viale del Policlinico, 137, 00161 - Rome, Italy
e-mail: massimo@iac.cnr.it
F. Ferreri . L. Valcamonici
CASPUR, Via dei Tizii, 6b, 00185 - Rome, Italy
e-mail: f.ferreri@caspur.it
L. Valcamonici
e-mail: l.valcamonici@caspur.it
be carried out. In particular we identified some simple attack
schemes that might lead to a DoS effect and then observed
the reaction of various types of infrastructured networks to
these attacks. In the following section we describe the ba-
sic principles we followed in order to find possible attack
schemes; in Section 3 we describe the test-bed framework
in which we carried out our experiments and finally, in Sec-
tion 4, we report the results obtained for different types of
networks.
2 Working guidelines
The design of the attack schemes started with the following
considerations:
– The 802.11 protocol is based on the exchange of re-
quest/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);
– infrastructured networks rely on an access point (or a set of
them) as a central node through which every communica-
tion 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;
– 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 authen-
ticated to the target network.
1
A Basic Service Set is made of an AP and the client stations connected
to that AP.
Springer
160
Fig. 1 Finite state machine (FSM) representing the AP/STA interac-
tion. State 1 represents any client neither associated nor authenticated
to the AP yet (such as an external attacker station)
Following these guidelines, we started to identify mes-
sage sequences that could lead to an attack towards the AP.
The management frames of the 802.11 protocol look like
the most 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 ex-
changed (see Table 1). Starting from this classification, we
identified three simple attack schemes. They are essentially
flooding attacks that aim at gaining predominant access to
the wireless medium and wasting computational resources
of the AP. We describe these schemes in the next three
paragraphs.
Table 1 802.11 management frame classes
Class Frame types
1 probe request/response,
authentication, deauthentication
2 association request/response,
reassociation, disassociation
3 deauthentication
Springer
Wireless Netw (2008) 14:159–169
2.1 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. By send-
ing 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.
2.2 Authentication request flood (ARF)
AP response to an Authentication Request frame de-
pends on the authentication settings of the network:
open system networks: no cryptography is involved, the AP
processes each request, possibly comparing the MAC ad-
dress 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 chal-
lenge text and sends it to the station in a second authenti-
cation 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 informa-
tion about each new station that successfully authenticates.
As in the previous case, by sending a burst of Authentica-
tion Request frames, using MAC spoofing, it should be
possible to bring AP’s resources close to the saturation level.
2.3 Association request flood (ASRF)
According to the protocol FSM, Association Request
frames should not be sent by stations in unauthenti-
cated/unassociated state, so such requests should never re-
ceive 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.
2.4 Related work
Despite the large number of works related to wireless se-
curity, DoS attacks have not been deeply investigated yet.
Among the few works focused on these peculiar attacks, we
Wireless Netw (2008) 14:159–169 161

recall [6] which appears to be the most closely related to our

work.
The authors focused on three types of attacks: deauthen-
tication and disassociation attacks rely on the repeated in-
jection 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 a mali-
cious 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.
Actually, deauthentication and disassociation attacks were
already known in the developers community, and proved to
be really effective. The virtual carrier-sense attack (i.e., the Fig. 2 Testing environment
malicious manipulation of the NAV) is more original and,
in principle, harder to defend against in practice. The au-
thors tested the NAV attack both by means of simulations Finally, there are a few public domain tools, like
(based on ns-2) and in real test-bed networks. Although the those available from http://home.jwu.edu/jwright or
attacks proved to be effective in the simulation environment, http://www.wlsec.net/void11/, but it looks like they
they didn’t lead to relevant results when applied to real-world have been tested only on a very limited base.
networks. According to the authors, this, somehow surpris-
ing, result, is due to wrong implementations of CSMA/CA
mechanisms by card vendors: basically many wireless de- 3 Testbed environment
vices seem to ignore information provided by the virtual NAV
mechanism. As a testing platform we used two identical laptops each
The attacks presented in [6] differ from the ones we de- equipped with a Netgear MA401 PCMCIA card, both run-
vised in terms of target localization and easiness of use. In ning Linux 2.4.20 and the HostAP device driver [11]. These
[6], deauthentication and disassociation attacks are directed two laptops were used as legitimate clients of the wireless
to single or multiple end-stations, whereas our attacks focus network, whereas a third machine was used to launch at-
on the AP as central node and possible single point-of-failure tacks against the wireless networks. We tested the behavior
for an entire wireless network. As to NAV attacks, they fo- of managed wireless networks, using different types of ac-
cus on overall medium availability, trying to prevent clients cess point. Legitimate clients authenticate and associate to
from gaining access to the shared medium, whereas our at- APs, and then run the netperf benchmark [12], or other
tacks aim to waste computational and memory resources of simple commands.
the AP. Besides that, NAV attacks rely on complex manip-
ulations carried out at firmware level (such as forging and
modifying frames stored in firmware memory), whereas our 3.1 Attacker station
attacks are carried out through simple software modules.
A DoS attack may also occur if an attacker exploits the Ex- As attacker station we used a third laptop, running the same
tensible Authentication Protocol (EAP) to flood the authen- version of Linux (2.4.20) and equipped with the same Net-
tication server with fake requests, thereby preventing valid gear MA401 PCMCIA card. To carry out the attack schemes
users from authenticating to the wireless network. From a dif- previously described, we needed a mechanism to forge ar-
ferent viewpoint, since EAP is, by definitiom, extensible, it bitrary 802.11 management frames and injecting them in
is possible to think of an authentication method that is robust the medium, regardless of protocol rules and constraints.
against this class of attacks. However, in the EAP Method To this purpose, we developed a simple application, named
Requirements for Wireless LANs document [13] there is no wfit (wireless frame injection tool), based on the Radiate
mention of such possibility. library [10]. 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
2
Each frame contains a duration field which indicates how long the (it seems that such feature has been discarded in more recent
current transmission will keep the medium busy; other STAs should versions of the driver). The library enables us to build all
wait for this amount of time before starting a new transmission; thus,
sending fake frames with a high duration value, should prevent other
types of 802.11 management and data frames passing them
STAs from transmitting. to the card firmware through the socket for transmission.

Springer
162
Table 2 Frame injection rates
(frames/sec). Values refer to a Scheme Frames/sec
situation in which no other
PRF  810
station is accessing the medium
through CSMA/CA mechanisms ARF 260 ÷ 280
ASRF 260 ÷ 280
3.1.1 Frame injection rates
In preliminary test sessions, we checked that the physical
distance of the attacker station from the AP did not influ-
ence significantly the results. However, we found few limi-
tations on the maximum number of frames per second that
can be injected. These limits are not influenced by the ma-
chine 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, PCM-
CIA subsystem and card but we did not try to address such
issue. Maximum injection rates are listed in Table 2. 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 pres-
ence of many stations trying to gain access to the wireless
medium.
4 Experimental results
Hereafter, we present and discuss the results collected for
each network configuration we tested.
4.1 Enterasys RoamAbout R2 managed network
The PRF attack, performed at maximum rate, blocks com-
pletely the test bed network. The AP seems to be 100% busy
in managing Probe Request frames and normal communi-
cation among legitimate clients in the infrastructured network
is interrupted. This result does not depend on the protocol or
application used by legitimate clients (ping messages, telnet
sessions, HTTP sessions, and so on). Interestingly, a different
outcome is obtained if we disable the MAC spoofing mech-
anism, thus sending each frame with the same MAC address
(i.e., the real MAC address of the card): any DoS effect van-
ishes even though we are injecting frames at the same rate.
We provide a possible explanation of this result in the next
paragraph.
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 in-
dicates to be about 30% for a raw TCP stream between the
two legitimate clients in the network.
Springer
Wireless Netw (2008) 14:159–169
Fig. 3 PRF attack on the Enterasys RoamAbout managed network.
Note how Ethereal parses fake MAC addresses and “matches” them
against a list of known vendors
4.1.1 MAC spoofing and retransmission issues
In Fig. 3 we report a PRF attack pattern, with the MAC
spoofing mechanism enabled, as recorded by the Ethereal
sniffer: Probe Response frames with spoofed addresses are
not acknowledged by the attacker station because they have
a destination MAC address different from the real MAC ad-
dress of the card. As a consequence, the AP has to send each
response 4 times, until the 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 store and re-transmit frames until the limit is reached.
When MAC spoofing is disabled, the attacker’s card injects
frames with its real MAC address and then acknowledges im-
mediately responses from the AP that are directed to its own
address. In this case, the AP receives the acknowledgment
of each frame and thus does not need to buffer frames for re-
transmission. As a consequence, the DoS effect disappears.
Note that there is no way to set, via software, retry limits of
this AP.
In order to collect statistics about the attack schemes, we
ran the attacks for a period of 10 sec. while sniffing frames
with Ethereal for a period of 20 sec. The idea is to capture
all delayed response frames sent by the AP. From the resulting
data, we computed some values of interest, in particular:
– unique requests sent by the attacker station (Nreq);
– duplicate requests sent by the attacker station (Ndup);3
– number of requests responded by the AP (Nresp);
– number of requests not responded by the AP (Nlost);
– number of response frames for each request frame (Nrr);
3
In some cases the card firmware repeats the transmission of a frame
received from a user-space application.
Wireless Netw (2008) 14:159–169 163

Table 3 Attacks statistics for the Enterasys RoamAbout managed net- ture. From this viewpoint, the next section presents a pretty
work different situation.
Nreq Ndup Nresp Nlost Nrr Trr

PRF 4553 0 2089 2464 3.69 0.24
ASRF 886 886 886 0 3.88 0.0007
ARF 765 754 756 0 7.813 0.0008
– average elapsed time (in seconds) since a request frame
and correspondent first AP response frame (Trr).
Collected values are reported in Table 3: from the value of
Nrr, we extrapolate that the retry limit for an Authenti-
cation Response frame is set equal to 8, whereas it is set
equal to 4 for an Association Response frame (that is,
actually, a Deauthentication frame). Nonetheless, these
two attacks do not have a serious impact on the network. The
reason is probably 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.
Looking at the results shown in Table 3, the difference
between the PRF scheme and the other two (the ASRF and
the ARF) is readily apparent. 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
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.
4.1.2 Firmware upgrade
Recently, we upgraded the firmware of this AP to the latest
version (v6.02.07) in order to check whether its vulnerabili-
ties had been eliminated or, at least, mitigated. Actually, the
overall result has been even worse compared to the version
we tested earlier. The Enterasys AP equipped with the lat-
est firmware is vulnerable to all of the three attacks. Each
attack hinders any kind of communication among associated
clients. Detailed results are reported in Table 4. Even in this
case, the introduction of WEP does not change the global pic-
4.2 Netgear ME102 managed network
For the Netgear ME102 AP, we started the tests with WEP
(128 bit) cryptography enabled. The results can be summa-
rized as follows:
– The PRF attack has no effect on network performance;
– The ARF attack causes the AP to crash and stop working.
The AP needs to be restarted after each attack;
– The ASRF attack causes the exhaustion of the AP re-
sources. The communication among legitimate clients be-
comes impossible.
Actually, this network showed, in general, a worse perfor-
mance with respect to the previous one, even running under
normal conditions. This probably accounts for its higher sen-
sibility to flooding attacks executed at a lower frame injection
rate.
4.2.1 Detailed results
Looking at the Nrr values in Table 5, we see that 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
serious 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. 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 ef-
fect 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 send-
ing 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

Table 4 Attacks statistics for Enterasys AP with the latest Table 5 Attacks statistics for Netgear ME102 managed network (WEP
(v6.02.07) firmware enabled)

Nreq Ndup Nresp Nlost Nrr Trr Nreq Ndup Nresp Nlost Nrr Trr

PRF 5542 1 3017 2525 2.45 0.189 PRF 6621 0 4048 2573 1.009 0.002
ASRF 5920 0 3587 2333 2.4 0.164 ASRF 537 536 391 146 11.189 0.126
ARF 6003 0 3644 2359 2.392 0.163 ARF 617 616 72 545 10.708 0.167

Springer
164 Wireless Netw (2008) 14:159–169

version by the station. The anomalous sequence of crypto- Table 7 Attacks statistics for 3Com access point 8000 managed net-
graphic operations could induce a fatal workload on the AP work (no WEP)
or produce illegal operations that cause the crash. Unfortu- Nreq Ndup Nresp Nlost Nrr Trr
nately, no details are available to us about the internals of this
PRF 10288 1 724 9504 1 0.588
AP.
ASRF 1040 1039 875 165 1 0.399
ARF 1021 1020 146 875 7.938 3.064
4.2.2 Disabling WEP

After disabling WEP, no attack leads to DoS situations, even
though retry limits are unchanged: Table 6 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 there is no interruption of normal communications
between the legitimate clients. These results led us to revise
our statement that frame retransmission is the origin of the
DoS effect. Actually, it looks like the efficiency of our flood-
ing attacks 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.
4.3 3Com access point 8000 managed network
Testing the 3Com AP we noted a somehow different behavior:
– The PRF attack completely blocks the testbed network,
even though the retry limit for probe response frames
is set equal to one;
– The ARF attack blocks the testbed network, but it doesn’t
cause a crash of the AP. After the attack stops, communi-
cations among legitimate clients are restored;
– The ASRF attack does not show relevant effects on the
network.
4.3.1 Detailed results
Interestingly, although the retry limit 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. To this purpose, it is useful to
compare the 3Com pattern with that produced by the Net-
gear. 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 con-
stant rate (about a response every 2–4 requests) whereas the
3Com AP seems to be completely subverted by the requests
flow. By looking at the data of the entire test period (20-sec).
we found 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. Data re-
ported in Table 7 show that the attacker station is able to
send out up to 10000 frames in 10 sec. In other words, it has
an almost exclusive access to the wireless medium. The re-
sponse time also denotes a very high latency (half a second)
when compared to other APs.
In case of an ARF attack, the 3Com AP shows a better
promptness (indeed, the ARF attack has a lower injection
rate) but a high retry limit (nearly 8) still causes a DoS ef-
fect: the number of lost frames (Table 7) is very high and
the response time reaches 3 sec. We could expect a simi-
lar 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.
4.4 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 [11]. 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 we used it to gain further information
about the DoS attacks we devised. When exposed to flood-
ing attacks, the HostAP network reacts in a way which is
quite similar to the Enterasys AP: a PRF attack causes

Table 6 Attacks statistics for Netgear ME102 managed network

(WEP disabled) Table 8 Attacks statistics for HostAP managed network

Nreq Ndup Nresp Nlost Nrr Trr Nreq Ndup Nresp Nlost Nrr Trr

PRF 849 1 790 59 1 0.0015 PRF 9629 1 860 8769 2.98 0.44
ASR 550 549 396 154 11.247 0.115 ASRF 788 786 787 1 2.998 0.004
AR 619 618 449 170 10.797 0.123 ARF 736 736 736 0 2.997 0.0024

Springer
Wireless Netw (2008) 14:159–169 165

DoS (all communications are hindered), whereas ARF and Table 9 Attacks statistics for the D-Link DWL-1000AP+ managed
ASRF attacks do not cause major troubles to the network. In network (no WEP)
Table 8 we report some results: the AP has a retry limit equal Nreq Ndup Nresp Nlost Nrr Trr
to 3 for all kinds of frames. Under the PRF attack, there is a
PRF 10227 0 785 9442 1.89 0.004
high loss of frames and a response time which is about two
ASRF 609 608 536 73 19.68 0.279
orders of magnitude higher than in the ARF and ASRF cases. ARF (40s) 2491 2490 908 1583 19.46 0.299
The HostAP driver provides further information about the
PRF attack. By looking at the /proc filesystem (Fig. 4), we
Table 10 Attacks statistics for the Linksys WRT54G managed net-
found a large number of work (no WEP, f/w v1.41.2)
TxDeferredTransmissions that indicates that the AP is
under heavy load and a lot of frames are in queue for Nreq Ndup Nresp Nlost Nrr Trr
transmission. The TxRetryLimitExceeded counter cor- PRF 10196 0 263 9933 6.81 0.298
rectly reported the number of frames that have been retrans- ASRF 938 937 162 776 19.135 9.386
mitted until the retry limit. Interestingly, the RxDiscard- ARF 941 940 175 766 18.228 10.142
sNoBuffer parameter had a high value, an indication that
a lot of frames were discarded (neither elaborated nor re-
sponded) due to the lack of buffer space for reception. 4.6 Linksys WRT54G

This AP proved to be vulnerable to “any” attack. It is

4.5 D-Link DWL-1000AP+
This AP proved to be vulnerable only to the ARF attack.
Moreover, it had a particular behaviour: the DoS effect was
not instantaneous, as for the other APs, but it appeared only
after running the attack for (about) 20–25 sec. It seems like,
the AP had, in the beginning, enough resources (mainly
buffer space) to handle the flood of fake requests but, since
the attack lasted for a while, it ran out of resources and nor-
mal communications could not be managed any more. We
report some data in Table 9: since the DoS effect appears
only after about 25 sec. we ran ARF attacks for 40 sec. and
monitored the AP for a period of 60 sec. in order to catch all
delayed responses. We can see that, in the ARF and ASRF
cases, each request triggers nearly 20 response frames. The
introduction of WEP had no impact on the experimental
results.
quite simple to hinder any communication by executing a
PRF, ARF or ASRF attack with MAC spoofing enabled. In
Table 10 we report the data collected during these attacks.
If the MAC spoofing is disabled, any DoS effect vanishes.
This suggests that, once again, the DoS is a consequence
of the buffer exhaustion which, in turn, is due to the patho-
logical number of retransmissions (that is the same situation
we found in the Enterasys and HostAP tests). It is worth
noting that the number of frame retransmissions is very high
in the ARF and ASRF cases, with response times up to 10
seconds. Results are quite similar when WEP is enabled.
4.6.1 Upgrading the firmware
We decided to upgrade the firmware from version 1.02.1 to
version 1.41.2 since the latter enabled us to arbitrarily change
the retry limits. We found a quite different behaviour after
the upgrade, suggesting that changes at the firmware level
may lead to completely different reactions to DoS attacks.
In particular, Linksys AP with firmware 1.41.2 proved to
be vulnerable only to ARF and ASRF attacks (regardless of
retry limits we set). The disabling of MAC spoofing did not
modify these results.

4.7 Netgear WG602

With this AP we didn’t manage to hinder communications,

despite of our attacks. Only in the ARF and ASRF cases we
noticed a sudden DoS effect in the beginning of the attack
that disappeared in less than a second. After that the AP
began to ignore our fake requests. We got a step further by
looking into the AP setup utility: we realized that the AP has
an internal limit on the number of authentication/association
Fig. 4 HostAP driver statistics requests that can be handled. When the limit (that seems to be

Springer
166 Wireless Netw (2008) 14:159–169

Table 11 Attacks statistics for the Netgear WG602 managed network to 1 (the minimum value accepted): DoS effects are always
(no WEP) present and the only notable difference is a reduction in the
Nreq Ndup Nresp Nlost Nrr Trr value of Trr that decreases to (about) 17 sec. On the basis
of these observations, we can not relate the vulnerabilities
PRF 5415 0 5397 18 1 0.001
simply to the retransmission of unacknowledged frames. The
ASRF 3394 3393 49 3345 7.795 0.114
ARF 2987 2986 29 2958 7.482 0.232 behaviour showed by this AP, under the ARF or ASRF attack,
is quite similar to the behaviour of the 3Com Access Point
8000 under the PRF attack: during the requests flooding, the
close to 60) is reached, the AP ignores any further request AP is unable to gain access to the medium to send out a re-
(that is, it does not respond at all). Unfortunately, the list sponse or to transmit the data frames belonging to legitimate
of accepted authentications/associations is never refreshed. communications. This is probably due to the implementation
Then, if an ARF or ASRF attack fills it with fake stations choices with respect to transmit/receive queues and memory
requests, the AP doesn’t allow any other client, even legit- management, but a definitive analysis requires support from
imate, to authenticate/associate to it. From this viewpoint, the vendor.
our attacks prevent new legitimate clients from getting ac-
cess to the network, that is a different, but still annoying, 4.9 Compaq/HP WL520
form of Denial of Service. As for the other APs, results are
reported in Table 11. As a final investigation, we tested our attacks against a “real-
world” wireless network located in the Bio-Medical Cam-
pus in Rome. The BSSID we targeted was managed by a
4.8 Cisco AP 350
Compaq/HP WL520 access point. For this experiment, we
resorted to a new attack tool we developed, which is essen-
This AP proved to be vulnerable to both ARF and ASRF
tially a modified version of the HostAP driver that “embeds”
attacks, with all communications blocked by the flood of
the attack schemes at kernel level. By means of this tool, we
requests even if the attack is executed at a low injection
are able to execute the attacks at a rate that exceeds 900
rate. Although all the DoS effects disappear when the MAC
frames/sec, regardless of the attack scheme (i.e., the ARF
spoofing mechanism is disabled, it is quite difficult to ex-
and ASRF attacks are more powerful). In such a way, we
plain such severe vulnerability only as a consequence of the,
managed to hinder the network with all of the three attack
already cited, retransmission problems. Actually, the analy-
schemes. However, we noticed an unconventional behaviour:
sis of the logs captured by Ethereal revealed the existence
after being flooded for a while, the AP decided to switch
in the attack process of two different phases: firstly, when the
channel, thus eluding the attacks. Obviously, it is easy to by-
attack is in progress, the AP is completely subverted by the
pass such defense mechanism by switching channel on the
flood of requests, and it is not able to send out any response
attacking machine. Moreover, it is not clear if the channel
frame (we saw a similar behaviour with the 3Com Access
switching is a true defense mechanism or a side-effect of
Point 8000); in a second phase, when the attack is over,
some different feature of the AP.
the AP starts to send out the responses related to the initial
flood of requests. By looking at the values reported in Ta-
ble 12, we can see that the AP sends out only 13 responses,
whereas the number of requests is two orders of magnitude 5 Concluding remarks
larger than that (1600−1900).
The delay between a request frame and the correspond- We showed how some simple flooding attacks, based on
ing response frame reaches the astonishing value of 35 − 37 the injection of forged frames, may cause, under certain cir-
sec. The retry limit is set equal to 32 by default, but it can be cumstances, a serious service degradation in 802.11 wireless
changed through the configuration interface. However, there networks. Figure 5 compares the packet loss experienced by
is no significant change even if the retry limit is set equal all the APs we tested under the three different attack tech-
niques we devised. It is apparent how no AP is fully immune
although some APs are much more vulnerable than others.
Table 12 Attacks statistics for the Cisco AP 350 managed network Figure 6 shows a similar comparison for the response times
(no WEP)
of the APs under attack.
Nreq Ndup Nresp Nlost Nrr Trr The key points we discovered can be summarized as fol-
PRF 4576 0 2127 2449 1.94 0.002
lows:
ASRF 1633 0 13 1620 32 37.705
– PRF, ARF and ASRF flooding attacks can be exe-
ARF 1951 0 13 1938 32 35.847
cuted by any malicious station in the area of a wireless

Springer
Wireless Netw (2008) 14:159–169
Fig. 5 Packet loss (%): this
graph compares the results of all
APs we tested
Fig. 6 Response times (in
seconds): this graph compares
the response times during DoS
attacks (log scale)
infrastructured network, without being neither associated
nor authenticated to the access point;
– the minimum frame injection rate required to cause a DoS
depends on the AP in use. For some of the devices we tested
( e.g., the 3Com Access Point 8000), it is surprisingly
low.
– AP’s main vulnerability to these flooding attacks seems
to reside in unacknowledged frame retransmission, which
causes memory buffers exhaustion and freezes AP func-
tionalities;
– weak implementations of the 802.11 protocol in the ac-
cess points can determine further vulnerabilities, which
allow malicious stations to crash an AP (as shown in the
167
Netgear ME102 case), or to prevent other legitimate sta-
tions from associating to the AP.
It is worth to note how the attacks we devised require only
very simple hardware and software components (basically
a laptop with a Prism card and the HostAP driver plus the
Radiate library) and thus they can be easily executed with a
very limited effort.
Our experiments showed that the extent of vulnerability
to DoS attacks strongly depends on the firmware used by
the APs. As a matter of fact, by running different versions
of firmware on the same AP, the results may change sig-
nificantly. This is apparent in the case of the Enterasys
Springer
168 Wireless Netw (2008) 14:159–169

and Linksys AP. Moreover, it is interesting to note that https://courseware.vt.edu/users/marchany/

more recent versions of firmware do not necessarily behave
better than older versions. For instance, the latest version
of the firmware for the Enterasys AP does not introduce
any defense mechanism against DoS attacks and, from this
viewpoint, it is no better than its predecessor.
We tried to embed some defenses at software driver level
in the Linux HostAP PC-based access point but the attempts
revealed unsuccessful since there were no hooks in the driver
to achieve the necessary fine-grain control of the Network
Interface Card (NIC). What would be necessary is, at least,
the possibility to set retry limits and timeouts for the trans-
mission of replies to Probe Request, Authentication
Request and Association Request frames. Actually, we
believe that really effective defense mechanisms should re-
side at firmware level (or below it). One of the reasons is
that Probe Request frames are managed directly in the
NIC without being passed to the upper (device driver) level.
Thus, an effective and robust solution to the attacks we de-
scribed, should be found working directly at firmware level,
relying on vendors’ support that could either fix the prob-
lems directly or provide adequate documentation and devel-
opment tools. At this time without such information we can
only think of generic mechanisms of resources management
that prevent an access point from running out of memory.
Other solutions based, for instance, on cookies included in
the frames could be considered, but they probably would re-
quire changes in existing procedures that might cause incom-
patibilities with old equipment and interoperability issues if
not properly standardized.
As a final remark we note that very recently new seri-
ous flaws in 802.11 equipment of major vendors have been
reported [14, 15]. Although these vulnerabilities are due to
problems in the management of packets at upper layers (arp
requests and fragmented udp packets), they confirm that
much work remains to be done before wireless networks
can be safely employed in locations (e.g., hospitals) where
denial of service attacks could cause severe damage.
ECE5560/Papers/lough.vulnerabilities.802.11.pdf
6. 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. (Aug. 2003).
7. A. Misra, M. Shin and W. Arbaugh, An empirical analysis of the
IEEE 802.11 MAC layer handoff process, Department of Computer
Science, University of Maryland.
8. 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 (Oct. 2002).
9. J. Wright, Detecting wireless lan mac address spoofing. (Jan.
2003). http://home.jwu.edu/jwright/ papers/wlan-
mac-spoof.pdf
10. M. Schiffman, The need for an 802.11 wireless toolkit, Black Hat
Briefings (July 2002).
11. Host AP driver for Intersil Prism2/2.5/3,
http://hostap.epitest.fi/
12. http://www.netperf.org/
13. http://www.ietf.org/rfc/rfc4017.txt
14. http://www.thunkers.net/∼deft/advisories/
dlink udp dos.txt
15. http://www.cisco.com/warp/public/707/cisco-sa-
20060112-wireless.shtml
Francesco Ferreri graduated in Software Engineering in 2004 at Rome
University “Tor Vergata”. He then joined CASPUR (Italian Interuni-
versities Consortium for Supercomputing Applications) where he led
research activities involving wireless networks and IPv6 integration.
He’s currently employed at NaMeX, Rome’s Internet Exchange Point,
as a network and systems engineer.

References

1. ANSI/IEEE Std 802.11 1999 Edition.

2. M. Gast, 802.11 Wireless Networks—The Definitive Guide,
O’Reilly (2002).
3. A.W. Arbaugh, Narendar Shankar and Y.C. Justin Wan, Your 802.11
Wireless Network Has No Clothes. Department of Computer Sci-
ence, University of Maryland (March 2001).
4. T. Karygiannis and L. Owens, Wireless network security 802.11,
Bluetooth and handheld devices. National Institute of Standards
and Technology, Technology Administration, U.S. Department of
Commerce.
5. D.L. Lough, Nathaniel J. Davis and Randy C. Marchany,
Security vulnerabilities of IEEE 802.11. Apr. (2002),
Leonardo Valcamonici graduated in Maths in 1994 at “La Sapienza”
University in Rome. After that he joined CASPUR (Italian Interuni-
versities Consortium for Supercomputing Applications) where, in the
beginning, he was involved in research activities in the field of parallel
and distributed computing. After that he became a network and security
engineer. He is now CASPUR’s Information Systems Security Officer
and Network Applications and Services Team Leader.”

Springer
Wireless Netw (2008) 14:159–169 169

Massimo Bernaschi graduated in physics in 1987 at “Tor Vergata”

University in Rome. After that he joined the IBM European Center for
Scientific and Engineering Computing (ECSEC) in Rome. He spent
ten years with IBM working in the field of parallel and distributed
computing. Currently he is with the Italian National Research Council
(CNR) as chief technology officer of the Institute for Computing Ap-
plications. Moreover, he is an adjunct professor of Computer Science
in “La Sapienza” University in Rome.

Springer