A Practical Investigation of Identity Theft Vulnerabilities

in Eduroam

Sebastian Brenza Andre Pawlowski Christina Pöpper

Horst-Görtz Institute for Horst-Görtz Institute for Horst-Görtz Institute for
IT-Security IT-Security IT-Security
Ruhr-University Bochum Ruhr-University Bochum Ruhr-University Bochum
Bochum, Germany Bochum, Germany Bochum, Germany
[email protected] [email protected] [email protected]

ABSTRACT service at research and educational institutes, Internet ac-

Eduroam offers secure access to the Internet at participat- cess at participating institutes has been greatly simplified:
ing institutions, using authentication via IEEE 802.1X and Eduroam enables users to roam between participating insti-
secure forwarding of authentication data to the authentica- tutions and authenticate with the login data of their home
tion server of the user’s institution. Due to erroneous con- institutes which is securely forwarded for verification via a
figuration manuals and a lack of knowledge on the user side, network of authentication servers to the home institution.
though, a big share of client devices lack the required root With their increased popularity in the last couple of years,
CA certificate to authenticate the Eduroam network, yet still many networked mobile devices have been configured for
being able to access the network. Moreover, deficient soft- Eduroam usage by their users, including laptops, tablets,
ware implementations on client devices prevent users from and smartphones. One central point to the security of the
the secure execution of the authentication process. Eduroam usage is the proper setup of a root CA certificate
In this paper, we present an attack that exploits this fact to verify the authenticity of the network. However, secure
and uses the default behavior of wireless devices in order authentication is not given, if deficient software implemen-
to capture authentication data. This MITM attack is per- tations do not check the validity of the offered certificate
formed in real-time. It is achieved using a modified ver- correctly or client devices are wrongly configured with miss-
sion of hostapd, which exploits a compatibility setting of ing CA certificates. If the offered certificate is not checked
the widely used supplicant software wpa supplicant. It en- correctly, client devices cannot verify the authenticity of the
ables an attacker to authenticate users in EAP-TTLS/PAP network, which opens the door for connecting to rogue access
and in EAP-TTLS/MS-CHAPv2 without the necessity of points, also called Evil Twins [12], and man-in-the-middle
cracking the user password hash on the fly and thus without (MITM) attacks. This is an issue that also seems to be
inducing suspicious delays. In a practical study with sev- known in corporate networks [33].
eral hundred users we could show that more than half of the Institutions participating in Eduroam are supposed to pro-
tested devices were vulnerable to the attack. Based on the vide sufficient configuration instructions for their end users
results of the study, we propose countermeasures to prevent to allow for the authentic identification of access points at
the attack and minimize the amount of vulnerable devices. all times. Unfortunately, at a number of institutions par-
ticipating in Eduroam, the configuration manuals for users
are incomplete or have been so in the past. For example, at
Keywords our university the configuration manuals for Android, Mac
Network Security; WPA-Enterprise; Eduroam Authentica- OS and iOS devices were missing the instructions for setting
tion; EAP; MS-CHAPv2 up the CA certificate. Fixing this simple problem of incom-
plete configuration manuals does not prevent the problem
from prevailing in reality even months later, as we show by
1. INTRODUCTION a practical study involving several hundred participants.
Access to scientific and educational resources is important In this paper, we outline a number of problems regarding
in research and education. With the start of the Eduroam the authentication structure and processes of the Eduroam
network. Although the Extensible Authentication Protocol
(EAP) authentication methods used in Eduroam and En-
Permission to make digital or hard copies of all or part of this work for per- terprise networks, in particular EAP-TTLS and PEAP, are
sonal or classroom use is granted without fee provided that copies are not well-defined and have been thoroughly examined for flaws
made or distributed for profit or commercial advantage and that copies bear
this notice and the full citation on the first page. Copyrights for components by security experts, imprecisions in the implementations
of this work owned by others than the author(s) must be honored. Abstract- may lead to severe security vulnerabilities. We present a
ing with credit is permitted. To copy otherwise, or republish, to post on novel stealthy attack targeting client devices. The attack is
servers or to redistribute to lists, requires prior specific permission and/or a based on real-world software and configuration deficiencies.
fee. Request permissions from [email protected]. In more details, we use a modified version of the software
WiSec’15, June 22 – 26, 2015, New York, NY, USA access point hostapd [20] that exploits the network’s trust
Copyright is held by the owner/author(s). Publication rights licensed to
ACM. ACM 978-1-4503-3623-9/15/06 ...$15.00 structure and enables an attacker to authenticate users on
DOI: http://dx.doi.org/10.1145/2766498.2766512 the fly without owning the required username and password
.
 RADIUS
data. This makes it possible to capture authentication data Hierarchy
international level RADIUS

using an evil-twin access point and to gain control over the

network traffic of the victim.
national level RADIUS RADIUS
We investigate the applicability of the attack in a real-
world setting and we identify, classify, and evaluate possible
countermeasure – both on the side of the client devices as Client Access Visited networks Home
RADIUS
on the side of the infrastructure and service provider. 1 identity Point 2 server
RADIUS
3 certificate
In summary, this paper makes the following contributions:
secure tunnel authentication data
4
1. We present a novel attack on a widely used EAP-
TTLS/MS-CHAPv2 implementation that allows to by- 5
pass the inner MS-CHAPv2 authentication on devices accept / reject

with deficient certificate validation.

Figure 1: Authentication Process in Eduroam
2. We investigate the vulnerability of different Android-
and Mac OS/iOS-based devices and tablets to this at-
tack and show that they are all vulnerable (in some either authenticated towards the user or both are mutually
cases depending on their configuration and user inter- authenticated; in phase 2 the user subsequently authenti-
action). cates towards the AS. The authentication is executed as fol-
lows (as shown in Figure 1):
3. We report results on a practical study of this vulnera-
bility with about 350 users and more than 500 devices. Phase 1 (Outer Authentication):
Of these tested devices, a share of 52 % turned out to
be vulnerable to our attack. 1. When a user requests network access, the user’s iden-
tity is queried by the AP. The user identity is provided
4. We propose multiple client- and infrastructure-side to the AP in the format: [email protected],
countermeasures and evaluate their effectiveness where tld is the top-level domain.
against the presented attack. To minimize the share
of wrongly configured devices, we show an automated 2. The AP forwards the user identity to the home AS
way to check device configurations that can be de- of the network, which checks its responsibility for the
ployed by institutions offering Eduroam services. user’s institution and top-level domain. In case the
user requested access to a foreign network, the iden-
The rest of this paper is structured as follows: First, the tity is proxied to the next RADIUS AS on national or
technical background for the attack is presented in Section 2. international level—based on the user’s identity—until
Prerequisites and the attacker model are introduced in Sec- the user’s home AS is found.
tion 3. In Section 4, the approach and characteristics of
the attack are described, followed by details on the practical 3. The user’s home AS checks if the identity is valid,
study in Section 5. Countermeasures are discussed in depth starts tunnel establishment, and answers with its server
in Section 6. Finally, related work is presented in Section 7 certificate. The user then validates the server certifi-
and we conclude the paper in Section 8. cate and a secure tunnel is established between the
user and the AS.
2. PRELIMINARIES
Phase 2 (Inner Authentication):
This section presents the technical background necessary
for the attack described later in this paper. It introduces 4. After the secure tunnel establishment, inner authenti-
authentication in Eduroam and IEEE 802.1X along with the cation is executed inside the tunnel between client and
targeted tunneled authentication protocols as well as PAP AS, using credentials of the user’s home institution.
and the MS-CHAPv2 authentication protocol.
5. The user’s home AS validates the login data and passes
2.1 Authentication in Eduroam the result to the AP, which subsequently grants or re-
Authentication in Eduroam is carried out following the fuses network access.
IEEE 802.1X standard for port-based network access con-
trol [17]. The system roles Supplicant, Authenticator, and Due to privacy reasons it is encouraged to provide an anony-
Authentication Server (AS) correspond in Eduroam to the mous outer identity in phase 1 and the actual/private iden-
user’s client device, the access point (AP), and the RADIUS tity inside the tunnel in phase 2 [30].
authentication server of the user’s home institution [30].
In order to enable users to gain network access using the 2.2 802.1X Protocols
same login data and network configuration at each partic- During the authentication process in IEEE 802.1X, au-
ipating institution, a hierarchical layer of RADIUS AS is thentication and communication between the client device—
introduced. The AS are organized on organizational, na- also called peer —, the AP, and the AS are carried out using
tional, and international level to determine user affiliation. the Extensible Authentication Protocol (EAP).
Eduroam provides mutual authentication either via X.509 EAP holds the data of the used authentication method,
client and server certificates or by tunneled authentication called EAP method, and is based on an exchange of EAP Re-
methods. This work focuses on tunneled authentication, quest (sent by the authenticator) and EAP Response mes-
which is carried out in two phases: In phase 1, the AS is sages (sent by the client). In a typical EAP conversation
 Supplicant Authenticator Authentication Access Point (AP) / Authentication Server /
Server Client (Authenticator) TTLS Server

1 Phase 1: Handshake Phase

EAPOL RADIUS
EAP Request: Identity
EAP EAP
EAP Response: Identity
Carrier Protocol (CP): Identity

outer authentication: inner authentication: CP: EAP-TTLS Start

EAP Request: EAP-TTLS Start
EAPOL / RADIUS TLS
EAP EAP / TLS-Handshake, including Certificate exchange
inner method

2 Phase 2: Data Phase

TLS tunnel
Inner authentication method (AVPs)

Figure 2: 802.1X Communication and Protocol En- TLS finished

CP: Access Accept / Reject
capsulation EAP Success / EAP Failure

the authenticator first queries the identity with an EAP Re- Figure 3: Sample EAP-TTLS Authentication Pro-
quest: Identity and concludes with an EAP Success or EAP cess
Failure, depending on the authentication result [5].
EAP was designed to run within the point-to-point pro-
Access Point (AP) / Authentication
tocol (PPP). In order to operate in a LAN environment, Client (Authenticator) Server
like Ethernet or IEEE 802.11, EAP data is encapsulated Phase 1: Handshake Phase
1
between client and AP using EAP over LAN (EAPOL) as EAP Request: Identity
carrier protocol [17]. Prior to forwarding it to the AS, which
implements the authentication method, the AP decapsulates EAP Response: Identity
Carrier Protocol (CP): Identity
the EAP data and encapsulates it using RADIUS as carrier
protocol, which is the designated authentication protocol in CP: PEAP Start
EAP Request: PEAP Start
Eduroam [30]. The communication between components in
802.1X, as well as the protocol encapsulation, are depicted TLS-Handshake, including Server Certificate
in Figure 2.
Because the tunneled authentication methods used in Edu- Phase 2: Data Phase
2
roam rely on Transport Layer Security (TLS) as secure tun- Executing full inner EAP method:

nel, EAP packets also encapsulate the TLS records, which TLS tunnel
EAP Request / Response: Identity
hold the inner authentication data in form of an EAP method
or a different authentication method. In Eduroam basically EAP Request / Response

every EAP-compatible authentication method that fulfills EAP Request: Success / Failure indication
the Eduroam service definition can be used [30].
EAP Response: Success / Failure indication

EAP Tunneled Authentication Methods

TLS finished
CP: Access Accept / Reject
EAP-TTLS and PEAP are EAP methods for tunneled au- EAP Success / EAP Failure

thentication that rely on TLS to provide mutual or server

authentication and protection against man-in-the-middle at-
tacks. The execution of EAP-TTLS and PEAP authentica- Figure 4: Sample PEAP Authentication Process
tion are depicted in Figures 3 and 4.
The authentication methods consist of two phases, which
start after an initial identity request: A handshake phase
(step 1 in Figure 3 and 4), which establishes the TLS tunnel Because they are important for the attack presented later
and is equivalent to Phase 1 in Section 2.1 and a data phase in this paper, a description of the used inner authentication
(step 2 in Figure 3 and 4), where inner authentication is methods follows.
executed, equivalent to Phase 2 in Section 2.1. As part of the
TLS handshake, the AS certificate chain is provided, which
is validated by the client. After successful authentication PAP
key material is distributed to the peer. In the password authentication protocol (PAP), the client
EAP-TTLS supports a selection of inner authentication authenticates against an AS using a combination of user-
methods, in particular the point-to-point protocols PAP and name and password. The client repeatedly submits an au-
MS-CHAPv2, which are introduced below. The TLS hand- thentication request containing user identity and password
shake data is also used to implicitly generate challenge ma- until a response from the AS is received. The AS validates
terial for the inner authentication methods invoked in EAP- the transmitted data upon reception and answers either with
TTLS [14]. an Access Accept or Access Reject [19].
The PEAP version used in Eduroam is Microsoft’s imple- The authentication data is submitted in plaintext without
mentation of PEAP version 0, which only supports the EAP any form of protection and can thus be recovered by eaves-
method EAP-MS-CHAPv2 as inner authentication method dropping when not protected by other measures, such as a
for non-certificate-based authentication [6][18]. secure TLS [13] tunnel.
 Client Authenticator
Authenticator Challenge CA
3.1 System Prerequisites
1
We assume that the following prerequisites are met re-
2
garding the configuration of the wireless network and the
(Challenge CP, Peer Response RP)
RP = compute RPcheck victims’ clients:
f(CP,CA,User,Pwd) RPcheck = RP ?

(Success, Authenticator Response RA) 3 (a) The wireless network of the victims uses WPA(2)-Enter-
4 RA =
/ Failure f(CA,CP,User,Pwd,RP) prise for authentication and accepts the widely used
compute RAcheck methods EAP-TTLS/PAP, EAP-TTLS/ MS-CHAPv2,
RAcheck = RA ?
or PEAP/MS-CHAPv2 for authentication.

Figure 5: MSCHAPv2 Authentication Process (b) The client has saved the target network in its known
network list, e. g., due to prior connections, thus having
configured an authentication method accepted by the
MS-CHAPv2 network.
The Microsoft Challenge-Handshake Authentication Proto- (c) The client connects to the wireless network AP with the
col Version 2 (MS-CHAPv2) is a challenge-response authen- highest signal strength while roaming. It also recognizes
tication protocol. MS-CHAPv2 extends MS-CHAP [36] and already known enterprise networks solely by their broad-
was designed to provide mutual authentication of authenti- casted SSID and automatically connects when a known
cator and peer. The detailed authentication process is de- network is in range. Note that this is the common de-
picted in Figure 5 and described as follows [35]: fault behavior on many devices.
1. The authenticator chooses a random 16-octet long au-
thenticator challenge CA and sends it to the peer. (d) At least one of the following certificate prerequisites is
2. Upon reception, the peer chooses a CP analogous to fulfilled:
CA and computes the 24-octet long Response RP —
also called NT-Response—as 1. The client does not check the CN (common name)
string of the offered certificate, thus lacking a valida-
RP = ChallengeResponse(CHash, MD4(P W )), (1) tion of the server name. As shown in [3], client de-
vices with such a deficient certificate validation are
where Android, Mac OS and iOS devices, unless the Apple
• P W is the user’s password devices are configured by installing a configuration
• CHash = trunc[0..7](SHA1(CP ||CA ||U serN ame)) profile.
2. The client has an insufficient device configuration in
• trunc[0..7] truncates the SHA1 digest to the first
which the CA of the network is not setup. Thus the
8 octets
client does not validate the certificate chain during
• ChallengeResponse(·) provides DES encryption the handshake phase of the authentication process
and sends CP ||RP to the authenticator as Peer Re- and accepts an arbitrarily offered certificate. Our
sponse. practical study later in this paper (Sec. 5) demon-
3. The authenticator computes RP check and compares it strates on a large number of devices that this case is
to the received RP . If RP = RP check , the authentica- not uncommon.
tor answers with the Authenticator Response
3.2 Attacker Model
RA = SHA1(D||CHash||M 2), (2) Our assumptions about the capabilities of the attacker
are:
where
• D = SHA1(MD4(MD4(P assword))||RP ||M 1) • The attacker is able to communicate with the victim
and the target network over the wireless channel. Also
• M 1 and M 2 are ”magic constants” specifically de- she is able to capture and modify forwarded network
fined for response generation traffic using appropriate software, e. g., sslstrip [23].
4. The peer verifies the Authenticator Response and ter-
minates the connection if RAcheck 6= RA , otherwise it • The attacker is able set up an own network AP with a
continues. signal strength higher than the signal strength of the
The security of MS-CHAPv2 was thoroughly analysed in the target network.
past [25], pointing out its design flaws. In 2012 the complex- • The attacker is able to forward network traffic to a
ity of the protocol was greatly reduced, making brute-force valid network AP and set up an own DHCP-server.
attacks feasible [22]. Nevertheless, MS-CHAPv2 is still used
as inner authentication method in tunneled authentication • The attacker is able to gain a valid signed certificate
protocols such as EAP-TTLS or PEAPv0, which are being with an arbitrary CN string by one of the CAs which
used in Eduroam and enterprise networks. has the same top-level authority as the Eduroam RA-
DIUS server certificate.
3. SYSTEM AND ATTACKER MODEL Note that in the case of Eduroam, usually one top-level
In this section, we present our assumptions about the net- CA is used for the whole infrastructure of a country. This
work, the victim and his client device, as well as the capa- means when an attacker is able to get a certificate signed
bilities of an attacker. by this top-level CA, she is able to attack every client that
uses the Eduroam infrastructure of that country. For ex- 4.2 Malicious AP Setup
ample, some universities offer free signed server certificates For the attack a modified version of the open source soft-
within their domain namespace (which uses the Eduroam ware AP hostapd [20] is used. The hostapd version is ex-
top-level CA) with the only restriction that an ID card has ecuted on a Linux machine with a Xubuntu 13.10 AMD64
to be shown. This service creates a large set of certificates an operating system equipped with two wireless NICs: One
attacker may possibly leverage (with or without social engi- used by hostapd1 , and one for connecting with the target
neering techniques). Also signed but revoked certificates can network. The wireless NIC used by hostapd is a TP-Link
be used by an attacker because the clients are not designed TL-WN7722N. Additionally an own DHCP server is set up
to check a certificate revocation list. to route victims into the target network.
As part of the attack, the following modifications are made
4. ATTACK DESCRIPTION to hostapd:
Our attack uses a modified version of the software AP
hostapd [20] to capture user login data and successfully au- 1. Modify user database access to accept every identity
thenticate users without possessing the users’ authentication in order to capture login data.
data.
2. Disable verification of authentication data in the in-
In the following, we describe the general approach of the
voked EAP methods of hostapd to authenticate the
attack, the setup and necessary modifications to hostapd,
user on the malicious AP.
and the technical characteristics of the used exploit.
4.1 Goals and Approach Additionally, hostapd is extended by a custom logger, which
logs MAC-addresses and user credentials for cracking them
The attack pursuits two main goals, which are to be ac- later (a number of credential crackers exist, e. g., Cloud-
complished subsequently: Cracker [22] or Asleap [31]).
1. Capture login data in order to gain network access and Modifying database access. Database access modifica-
access to other services. tions are required to capture user authentication data while
using inner MS-CHAPv2, since the MS-CHAPv2 implemen-
2. Authenticate the user on the malicious AP in order
tation in EAP-TTLS does not process challenge values when
to perform a MITM-attack and gain control over his
no match is found for the victim in the user database and
network traffic.
aborts in PEAP after the identity request. Therefore it is
Capture Login Data. In order to achieve the first goal, necessary that hostapd accepts arbitrary user identities in
the attacker configures a malicious AP to mimic a valid the data phase.
Eduroam access point by setting up the same SSID, cre- During runtime, user database entries are stored in host-
ating a server certificate with an arbitrary CN string, and apd as elements inside a linked list. To accept arbitrary
getting it signed by one of the valid CAs which have the same identities, a dummy user entry is introduced, serving as a
top-level authority as the RADIUS server certificate. The placeholder for an arbitrary data phase identity. The func-
last one turns out to generally not cause problems because tion returning user entries from the list is modified by insert-
a common used certificate infrastructure for the Eduroam ing a conditional break statement, so that it always returns
network is to have a large CA as a top level authority (for the dummy user entry when a data phase user is queried.
Germany the Deutsche Telekom Root CA 2 ). The top level Disabling verification. Disabling authentication data
authority commonly signs multiple intermediate CAs which verification inside the EAP methods serves the purpose of
often offer certificate signing services for server certificates. successfully finishing user authentication in EAP-TTLS by
Client devices fulfilling the prerequisites from Section 3.1, making hostapd accept every submitted user password value
especially prerequisite d), will connect to the attacker’s AP in EAP-TTLS/PAP and EAP-TTLS/MS-CHAPv2.
and successfully finish the handshake phase because each In PAP, verification of authentication data is a simple
communicating party in TLS is responsible for validating comparison of submitted username and password to the val-
certificates [13]. ues stored in database. Disabling the comparison to always
The attacker thus exploits insufficient information check- return true enables the attacker to authenticate users in
ing, stemming from erroneous or misconfigured user clients. EAP-TTLS/PAP.
This enables the attacker to capture username and pass- In MS-CHAPv2, hostapd has to accept the received NT-
word for the inner PAP authentication or for user identity, Response as valid by disabling the comparison with RP check
authenticator challenge, and peer response when using inner in order to successfully authenticate unknown users (see Fig-
MS-CHAPv2 authentication (see Section 2.2). ure 5). Additionally the subsequent state of the inner au-
Authenticate Users. The second goal aims at devices thentication is changed to success to omit computation of
that use wpa supplicant [21] as supplicant software and have the authenticator response, submit a success message, and
configured EAP-TTLS as authentication method (prerequi- thus exploit the eap_workaround setting. In the following
site a). section, we describe the technical characteristics and the im-
The attacker exploits the eap_workaround compatibility pact of the exploit.
setting of wpa supplicant to successfully authenticate the
victim at his malicious AP. The attacker can now act as a 4.3 Exploit Characteristics
MITM, providing network access by routing the victim over Handling of EAP is implemented as state machine (SM)
the malicious AP into the target network. For this purpose, similarly to [29] on hostapd and wpa supplicant, with inner
the attacker can use either own authentication data if he authentication running as a SM on top of each EAP SM.
has access to the target network or some other users’ data
1
captured in step 1 (capture login data). The wireless NIC must support AP-mode.
 EAP: PROPOSE_METHOD START
Previous
SUCCESS EAP state
EAP: METHOD_REQUEST
PHASE1
- establishes TLS tunnel
SEND_RESPONSE
IDLE
- waits for requests - passes data to lower
EAP: METHOD_RESPONSE layer for sending
Exploit State
PHASE2_START when PAP:
Transition
- validates user data
SUCCESS
when MSCHAPv2: Exploit: skip state Regular flow in
- builds Authenticator Response RECEIVED MS-CHAPv2:
METHOD
EAP: METHOD_REQUEST - parses received request
- checks EAP method state - processes EAP method data
PHASE2_MSCHAPV2_RESP - saves EAP method state
- decides if:
continue, success - builds responses
EAP: METHOD_RESPONSE - checks, if peer accepted
Authenticator Response or failure

Figure 6: State flow for inner TTLS authentication Figure 7: State flow for inner TTLS authentication
on the server side. The dashed arrow indicates state with exploit on the client side. The dashed arrow in-
skip in EAP-TTLS/MS-CHAPv2 used for the ex- dicates state transition triggered by a received EAP
ploit. success after omitting the Authenticator Response
in EAP-TTLS/MS-CHAPv2.

To authenticate Eduroam users in EAP-TTLS/PAP the

modification described in Section 4.2 is sufficient due to the eap_workaround setting.
simple design of PAP (Section 2.2). The compatibility setting is enabled when the supplicant
For EAP-TTLS/MS-CHAPv2, the eap_workaround com- wpa supplicant is run with default settings—as it is done in
patibility setting of wpa supplicant is exploited. This com- Android [1]—and must be deactivated by adding the option
patibility setting exists because of non-conforming authenti- eap_workaround=0 in the wpa supplicant configuration file
cation server implementations, one of them being the EAP- either by providing this option in the user interface or by
TTLS/MS-CHAPv2 implementation in a legacy version of having access to the configuration file. Unfortunately Wi-Fi
FreeRADIUS [28].2 As we could identify, this implementa- configuration settings are highly restricted in Android such
tion omitted the concluding success message / authenticator that this is not possible without having root access to the
response in EAP-TTLS (see Figure 5). In order to be op- device.
erable with the legacy FreeRADIUS version, the default au- Applicability. The described exploit was tested on eight
thentication state in inner MS-CHAPv2 of wpa supplicant different types of wireless devices. The results are presented
was set to conditional success after transmitting RP . By in Table 1. As shown in the table, all tested Android-
accepting the provided RP and additionally skipping the based devices prior to version 5.0 are vulnerable to the pre-
following state and directly advancing to success, the inte- sented exploit. This is due to the infeasibility of deactivating
grated authentication server in hostapd does not respond eap_workaround in the Wi-Fi-settings without having root
with the authenticator response and behaves like FreeRA- access to the device and usage of wpa supplicant version 2.2
DIUS, transmitting an EAP success. or older.
When wpa supplicant receives the transmitted EAP suc- The exploit turned out to also work for Apple devices
cess, the EAP-TTLS method returns to the calling EAP SM when the user can be tricked to accept the presented CA cer-
with conditional success and the authentication is success- tificate and he has configured his device using the restricting
fully concluded by both parties without knowing the user user interface (UI) and not by pre-built configuration pro-
password. The resulting state flows are depicted in Figure 6 files.3 When using the UI, the only parameters which can
for the server part and Figure 7 for the client. Figure 6 shows be set are username, password, followed by a CA certificate
the EAP-TTLS server state machine for MS-CHAPv2, trig- prompt.
gered by the EAP SM. After receiving the EAP Response Reporting and Bug Fixing. After the detection of
and validating the contained user data, the exploit forces the presented security issues, we followed the responsible
the EAP-TTLS SM to directly process to SUCCESS, in- disclosure policy and got in contact with the respective de-
stead of submitting the authenticator response and waiting velopment teams. We can report the following results: i)
in PHASE2 MSCHAPV2 RESP for the client to validate it. The described problem was reported to the Android secu-
The server therefore passes the same state sequence as if us- rity team of Google on June, 12th 2014 and was fixed for
ing PAP and behaves as if the authentication was finished the final release of Android 5.0 Lollipop. ii) The EAP-TTLS
successfully by sending an EAP Success. The EAP Suc- compatibility setting, which led to the presented vulnerabil-
cess message triggers the EAP SM of the client, depicted ity, was removed in wpa supplicant version 2.3, released on
in Figure 7, into SUCCESS instead of proceeding to state October, 9th 2014.
METHOD and process the received data because it does
not necessarily expect an authenticator response due to the 3
These profiles are created by Eduroam CAT [4] or Apple
Configurator [2] and enable the user to set the CA certifi-
2
This compatibility setting is no longer necessary for recent cate and configure otherwise unavailable settings, including
versions, as tests with version 2.1.10 of FreeRADIUS, in- authentication method, outer identity, and server name pin-
stalled from Ubuntu 12.04 LTS packet archives, have shown. ning (common name check, CN).
Table 1: Malicious AP Test results for various devices. Mac OS and iOS devices require acceptance of the
server certificate by the user.
Device Software version EAP-TTLS/PAP EAP-TTLS/MS-CHAPv2
HTC Desire CM 7.2.0.1 (Android 2.3.7) authenticates authenticates
Tolino Shine 1.3.0 Rev.1722 (Android 2.3.7) authenticates authenticates
Samsung Galaxy S3 Android 4.3 TouchWiz authenticates authenticates
LG Google Nexus 5 Android 4.4.4 authenticates authenticates
Sony Xperia mini pro CM 10.2.0.1 (Android 4.0.2) authenticates authenticates
Ipad Mini (1st Gen) iOS 7.1 N/A may authenticate
Macbook Pro (2013) Mac OS X 10.9.3 N/A may authenticate
LG Google Nexus 4 Android 5.0.1 authenticates does not authenticate (fixed)

Despite the fixes in Android 5.0.1 and wpa supplicant 2.3,

the issues presented in this paper remain highly relevant: At Table 2: Results of the Practical Study
the time of writing, Android 5 has only a negligible market Category Amount Percent
share according to the Google Platform Version statistics. In Number of Users ∼ 350
addition, the CN check configuration is still not accessible Total devices 507
for the user on Android 5 devices4 . Therefore Android 5 Share Apple 193 38 %
devices can still be authenticated in EAP-TTLS/PAP due to Total wrongly configured 264
the simple protocol structure, although the exploit described Share using inner PAP 53 20 %
in 4 does not work any more (see Table 1). Share Apple 34 13 %

5. PRACTICAL STUDY
To find out how many devices in the field would be af- The logged data consists of timestamp, user identity, and
fected by insufficient device configurations, a practical study MAC address, enabling clear identification of participants.
on an educational event in cooperation with the IT-Centre In order to distinguish correctly and wrongly configured
of the Ruhr-University Bochum was carried out. At this clients, client classification based on stages reached in the
event, client device configurations were scanned remotely authentication process was achieved by tracking the EAP
while providing information about a proper device configu- SM state flow in hostapd (see Section 4.3). A device is
ration to members of the university and giving the chance to vulnerable and considered wrongly configured once the TLS
improve it. This section describes the setup of the practical connection is established and the phase 2 identity is success-
study and its results. ful queried. When the anonymous identity was successfully
queried and the peer rejected the presented server certificate,
5.1 Setup then the device is considered as configured correctly.
For the practical study, a modified version of hostapd was If the anonymous identity indicates an user from a foreign
used to remotely validate client device configuration, tar- institution, then it is considered invalid and the correspond-
geting members of the university. It was set up to mimic ing client will be ignored and rejected before starting the
a valid Eduroam access point in a room that was largely TLS handshake.
isolated from other wireless networks to avoid interference To prevent multiple user entries due to connection reat-
with the Eduroam network and users not informed about tempts after rejection, a check was introduced if an entry
the event. The group of participants consisted of volunteers already existed in the SQLite database. If so, merely the
who were invited to check their device configuration follow- timestamps were updated. The logged data was evaluated
ing a university-wide announcement. The entire event was in anonymised form.
conducted by the members of the university’s IT-Centre.
Affected users were displayed in anonymised form on a large 5.2 Results
screen and direct configuration help was offered at the event. The results of the practical study are presented in Table 2.
In technical terms, the used hostapd version was modified They are based on data collected during the one-time edu-
as follows: cational event in a time period of approximately 3.5 hours,
mid-day, during the semester. There was no selection of user
• It filters the domain suffix for @realm.tld (domain of
devices, every provided device was accepted.
the university) or missing domain suffix and hence ad-
The event took place roughly five months after the in-
dresses only members of the university.
structions for the correct configuration of devices for using
• It rejects every connection attempt and does not log Eduroam were updated on the website of the IT-center and
key material and passwords. leaflets on this topic had been distributed to students and
staff (regarding the use of MS-CHAPv2 instead of PAP and
• It detects usage of PAP as inner authentication method. the correct installation of the root of trust for the certificate
chain).
• It logs data in an SQLite database and distinguishes
Since Apple devices turned out to be also affected in case
between correctly and wrongly configured devices.
EAP-TTLS/MS-CHAPv2 is used, their share on the total
4
Filed as issue 74244 in the Android bugtracker. numbers is additionally listed in Table 2. They could be
identified based on the vendor part of the HW-address since
Apple is one of few hardware manufacturers that uses an Table 3: Effectiveness of Countermeasure Combina-
registered MAC address space for their devices. tions. Effectiveness is divided into: ”4”: Prevents
The total amount of devices was determined by the total attack entirely; ”ž”: Only increases difficulty; ”5”:
count of different MAC addresses. From a total of 507 de- Does not prevent attack.
vices, 52 % devices were vulnerable. A total 20 % of the vul- C1 C2 C3 I1 I2
nerable devices used PAP as inner authentication method
and thus were leaking authentication data in unencrypted C1 5 4 ž 4 ž
form. C2 4 5 ž 5 ž
C3 ž ž 5 5 ž
6. DISCUSSION & COUNTERMEASURES
Our study showed that the majority of the users of the I1 4 5 5 5 ž
Eduroam network are vulnerable to our attack. I2 ž ž ž ž ž
In the following, we discuss the results of our study and
propose countermeasures to prevent the presented attack.

6.1 Discussion wireless devices properly, especially the CA certificate.

As the results presented in Section 5.2 show, a share of Simplifying and streamlining the configuration process
52 % wrongly configured devices existed in our study, months would make it less tedious in the users’ eyes and in-
after the configuration manuals for Eduroam access had crease their motivation to properly configure their de-
been updated. The comparatively small share of 13 % of vices. Automating the process, e. g., by using configu-
wrongly configured Apple devices might be due to simpli- ration profiles like on Apple devices, would help elim-
fications of the Wi-Fi configuration by importing pre-built inate error sources. When automated features are not
configuration profiles. available, lowered restrictions in the UI should make
Given the erroneous configuration manuals, it is also prob- already implemented supplicant features available for
able that the remaining 230 vulnerable devices were Android configuration by the user. Additionally, access points
devices, although this cannot be determined with certainty, which automatically validate the used configuration of
since the vendor part of the HW address does not enable to the client would help to eliminate the high number of
draw conclusions about the used OS in other cases than Ap- incorrectly configured devices. We further elaborate on
ple. In the case that they were indeed Android-based, these this idea in Section 6.3.
devices could additionally fall victim to the attack described
in Section 4, since eap_workaround deactivation in Android C2. Activating CN check: Activating the CN check helps
is not possible unless having root access to the device, which to identify the attacker’s rogue access point. Wpa sup-
is very uncommon. plicant is capable of performing the CN check by setting
Note that the case study only examined wrongly config- the subject_match option in its configuration. How-
ured client devices. It does not provide results about cor- ever, this option is not reachable from the UI on An-
rectly configured devices that are vulnerable to this attack droid devices and activation requires root access to the
because they do not check the CN string of the certificate. device. Therefore, it is only accessible to technically-
minded users which have root access to their Android
6.2 Countermeasures device.
There are multiple approaches to provide resilience against On Apple devices the CN check is an option which is
the attack described in this paper. We categorize the follow- provided by the configuration profile and can be acti-
ing countermeasures into client-side and infrastructure-side. vated by installing the configuration profile for the wire-
Note that only two combinations of the proposed counter- less network. However, with a manual configuration of
measures (C1 and C2 or C1 and I1) are able to entirely the wireless network access, the CN check is also not an
prevent the attack, as shown in Table 3. The others only available option to the user.
make the described attack more difficult.
C3. Deactivating eap_workaround: In order to provide re-
Client-side. Multiple ways exist to minimize the share of silience against the exploit described in Section 4.3, the
users with wrongly configured devices, thus reducing the eap_workaround setting must be deactivated in the net-
attack surface. The following approaches provide resilience work entry of wpa supplicant [21]. Disabling this com-
against the attack as long as the users are able or willing to patibility setting makes wpa supplicant expect the cor-
make changes to their device configurations. rect submission of the Authenticator Response RA for
validation in EAP-TTLS/MS-CHAPv2. This applies to
C1. Correct client configuration: According to the re- Linux and Android, since wpa supplicant is the default
sults presented in Section 5.2, 45% of the participants supplicant software in these operating systems, yet re-
own (checked) a second wireless device in average. This quires root device access in Android.
number is likely to increase in the future, with every
device being a possible security weakness because cer- However, this countermeasure does not prevent the at-
tificate validation is in responsibility of the client [13], tacker from capturing the user credentials and using
configured by the user. This underlines the need of services like CloudCracker [22] to recover the used pass-
actively educating the user about the risks of using word.
an unprotected connection and ways to configure their
 National Level National Level CA. On most devices, i.e., Android devices, it is not
Root CA Certificate Root CA Certificate possible to use the pre-installed well known CAs for
the Wi-Fi settings. Hence, a used top level CA has
to be manually installed in the same way a self gener-
... Intermediate CA Intermediate CA
ated Eduroam CA is. Though, a top level CA makes
Eduroam vulnerable against the described attack.
... Local CA Local
Eduroam CA
During the authentication process, the client devices
Does only sign: are routed to their home RADIUS instance and only
... RADIUS AS RADIUS AS establish a TLS tunnel with this server (Section 2.1).
Because of this routing process, the proposed change
to the Eduroam certificate infrastructure does not even
Figure 8: National certificate structure of Eduroam affect the roaming capability. Therefore we consider it
before and after applying countermeasure I1: On as the simplest and most effective way to prevent the
the left: Current situation with an indefinite amount presented attack.
of intermediate and server certificates signed by the
same root CA and therefore valid for rogue authen- I2 Using Evil Twin detection techniques: Since the
tication. On the right: Resulting structure after attack setup introduces an additional AP which for-
applying I1. Because the local Eduroam CA is only wards traffic, the usage of rogue AP detection on the
used for RADIUS AS, it is not possible anymore for infrastructure and/or client side can help to forestall
an attacker to obtain a valid rogue certificate. this attack. It would, however, introduce additional
network overhead for detection mechanisms and re-
quire additional hardware. Countermeasures on the
Infrastructure-side. Several approaches can be applied in infrastructure side cover introducing probe traffic and
order to prevent the attack by making changes on the used sensors as described in [34] and [9], while monitoring
infrastructure. This is important due to the difficulty of network behavior and maintaining a host database.
enforcing or enabling the client-side countermeasures previ- On the client side the usage of a hop-based rogue AP
ously presented, leaving numerous client devices vulnerable detection, like ETSniffer [27] or WiFiHop [24], could
against the attack described in this paper. Furthermore, we be used to prevent connecting to the rogue AP, intro-
believe that a change on the server side of the infrastructure ducing more responsibility and configuration effort to
is simpler and more realistic than a software fix on each the user, which already is a problem regarding the cer-
client, e. g., to enable the activation of the CN string check tificate configuration. While these approaches state to
on all Android devices. have a very high success rate on detecting evil twin
APs, they have been tested in corporate network sce-
I1 Changing the Eduroam certificate infrastruc- narios but not in the Eduroam environment, which
ture: Currently, the top level CA typically precedes might have a more dynamic characteristic. Also this
a chain of signed intermediate CAs. One of the inter- countermeasure would only detect an attacker rather
mediate CAs signs the RADIUS server certificate. than prevent the attack entirely.
Because the majority of clients are not able to check
the CN string of the certificate offered by the RADIUS
6.3 Automated Configuration Validation
server (see also C2), even correctly configured clients The Eduroam infrastructure has an exceptionally large
are vulnerable to the attack described in this paper. user base and its security also relies on user cooperation,
The only requirement for this attack to be successful is wherefore it is hard to prevent configuration errors.
that the certificate is signed by one of the intermediate In order to further lower the number of incorrectly con-
CAs (or top level CA) in the certificate chain. The figured client devices, we have modified the rogue software
valid signed certificate can have an arbitrary CN string AP used in our attacks into a proof of concept configu-
because it is not checked. ration validator. The configuration validator is based on
the software AP hostapd and mimics a valid Eduroam AP
However, all clients are able to check the validity of the using a server certificate signed by an intentionally invalid
certificate with respect to the top level CA. Therefore, ”rogue” CA. Clients fulfilling the requirements and behavior
we suggest to change the used certificate infrastructure presented in Section 3.1 will automatically connect to the
of the Eduroam network to use a separated CA which AP which tracks the authentication process and derives the
is entirely used for the local Eduroam instance, as de- configuration status from the reached authentication phase:
picted in Figure 8. With a separated Eduroam CA
for each participating institution, which only signs the • Phase 1: Rejecting the server certificate indicates a
RADIUS server certificate, each correctly configured correctly configured client.
client is immune against this attacker. For instance, in
• Phase 2: Successful TLS tunnel establishment and user
the case of a university, the network operations center
identity reception indicates wrong client configuration.
would generate its own Eduroam CA and sign the RA-
DIUS server certificate exclusively. To work correctly, The AP logs the reached authentication phase and the used
the Eduroam CA has to be installed and configured EAP method. In order to identify the user and his device,
on each client that authenticates itself against the uni- the hardware address of the device, the submitted identity,
versity’s RADIUS server. Note that this process, i. e., and the timestamp of the connection attempt are logged.
the authentic distribution of certificates, must also be However, the configuration validator never finishes authen-
done in the current setting with the official top level tication and does not log any key or password data.
 Given this data, it is also possible to detect clients which establishment and authentication process in Eduroam: cap-
do not use an anonymous phase 1 identity, e. g., Apple clients turing authentication data using an evil-twin access point
which were not configured using a configuration profile. Be- and hooking up to the connection as a MITM, thus being
cause the email address corresponding to the logged identity able to capture and manipulate the victims’ network traffic.
is known to the Eduroam service provider, the operator is The attack exploits the fact that many Eduroam users have
able to notify the user about the deficient configuration of a missing or incorrect CA certificate configuration on their
his device and can take further measures. wireless devices. Furthermore, the current national trust
In order to make sure to monitor only local students, the structure in Eduroam often enables an attacker to perform
AP filters the submitted identity in authentication phase 1 this attack despite correct device configurations. Tests with
according to the realm suffix and immediately rejects con- various mobile wireless devices have shown that every de-
nection attempts from visitors. vice whose Eduroam access is configured using default user-
The AP runs on a headless Raspberry Pi Model B using available configuration options is vulnerable to this exploit.
an AP-enabled USB Wi-Fi NIC and can be integrated into Our presented countermeasures show that a proper de-
the institution’s network. To ensure data privacy, the device vice configuration with an accessible CN check, and thus a
is encrypted and has to be securely unlocked over network correct certificate validation, is an effective countermeasure
on boot. to prevent this attack. Due to technical restrictions and
the vast amount of client devices, it is not possible to acti-
vate the CN check on a great share of devices, though. We
7. RELATED WORK therefore proposed an isolated local Eduroam CA as a sim-
Online released versions of modified software AP and AS ple change to the network’s trust infrastructure. This CA
used for attacks and vulnerability detection are [32, 15, 7]. does not affect the roaming functionality, yet turns out to
In [32] a rogue RADIUS authentication server was intro- be a highly effective countermeasure for the presented at-
duced which is also able to log credentials from EAP meth- tack, since it is not possible for an attacker to obtain a valid
ods used in Eduroam. In comparison to the hostapd setup server certificate for a rogue AP. Additionally, to detect and
presented in this paper, it does not provide EAP-TTLS further minimize the amount of wrongly configured devices
MSCHAPv2 user authentication and introduces an addi- we have shown an automated way to check for such devices.
tional component by using the modified FreeRADIUS, which
needs to be set up and running.
Hostapd was also used as diagnostic tool in [15] to detect 9. REFERENCES
vulnerability for the heartbleed exploit and for logging user [1] android Git repositories. online:
data in [7], targeting EAP-FAST and PEAP/MS-CHAPv2 https://android.googlesource.com/.
credentials. [2] Apple Business & Education Support. online:
Scientific publications related to our work include [8, 16, https://www.apple.com/support/iphone/business/.
26, 11, 10]. MITM attacks in tunneled EAP methods were [3] Devices that are compatible with eduroam. online:
discussed in [8] and [16]. In [16], EAP-MD5 and EAP-TTLS https://confluence.terena.org/display/
were subject to attacks using a modified hostapd with EAP- H2eduroam/How+to+deploy+eduroam+on-site+or+on+
MD5 as targeted inner authentication. The MITM attack in campus#Howtodeployeduroamon-siteoroncampus-
[8] used a different setup: It captures data from clients using Devicesthatarecompatiblewitheduroam.
legacy authentication protocols, like MS-CHAPv2 or MD5, [4] eduroam Configuration Assistant Tool. online:
and tunnels the data into PEAP or EAP-TTLS sessions. https://cat.eduroam.org/.
A MITM-attack setup that also authenticates users on a [5] B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, and
rogue AP without possessing user credentials is presented in H. Levkowetz. Extensible Authentication Protocol
[26]. It uses the LEAP authentication method as oracle for (EAP). Technical report, IETF, June 2004.
PEAP in order to authenticate the user on a rogue AP and [6] H. Andersson, S. Josefsson, G. Zorn, and B. Aboba.
targets especially Apple devices. Protected Extensible Authentication Protocol
An elaborated attack against WPA2-Enterprise authenti- (PEAP). Technical report, IETF, October 2001.
cation was presented in [11], using UI shortcomings in com-
[7] B. Antoniewicz. Hacking EAP-FAST Phase 0 with
mon operating systems to mimic the target network and
hostapd-wpe. online:
forged certificates and jamming techniques to disassociate
http://blog.opensecurityresearch.com/2013/04/
the victim and thus making it connect to the fake network.
hacking-eap-fast-phase-0-with-hostapd.html,
In order to perform a MITM attack, the MS-CHAPv2 val-
2013.
ues of the inner authentication were cracked using a specific
[8] N. Asokan, V. Niemi, and K. Nyberg.
high performance system. This step is not needed in our
Man-in-the-middle in tunnelled authentication
case.
protocols. In 11th International Workshop of Security
Work on certificate validation errors has been presented
Protocols, Cambridge, UK, Revised Selected Papers,
by Brubaker et al. [10]. They focused on the automated
pages 28–41, 2003.
generation of fake certificates in order to fuzz the SSL/TLS
implementations. Their results also show that established [9] P. Bahl, R. Chandra, J. Padhye, L. Ravindranath,
techniques still have erroneous implementations—an insight M. Singh, A. Wolman, and B. Zill. Enhancing the
that we further substantiate in this paper. security of corporate wi-fi networks using dair. In
Proceedings of the 4th International Conference on
Mobile Systems, Applications and Services, MobiSys
8. CONCLUSION ’06, pages 1–14, New York, NY, USA, 2006. ACM.
This paper presented a twofold attack on the connection [10] C. Brubaker, S. Jana, B. Ray, S. Khurshid, and
 V. Shmatikov. Using frankencerts for automated evil twin attack through multi-hop detection. In
adversarial testing of certificate validation in SSL/TLS Proceedings of the 16th European Symposium on
implementations. In Security and Privacy (SP), 2014 Research in Computer Security (ESORICS), Leuven,
IEEE Symposium on, pages 114–129. IEEE, 2014. Belgium, 2011, pages 21–39, 2011.
[11] A. Cassola, W. K. Robertson, E. Kirda, and [25] Mudge, B. Schneier, and D. Wagner. Cryptanalysis of
G. Noubir. A practical, targeted, and stealthy attack Microsoft’s PPTP Authentication Extensions
against WPA enterprise authentication. In 20th (MS-CHAPv2).
Annual Network and Distributed System Security https://www.schneier.com/paper-pptpv2.html,
Symposium (NDSS), San Diego, California, USA, September 1999.
2013. [26] P. Robyns, B. Bonné, P. Quax, and W. Lamotte.
[12] D. Dai Zovi and S. Macaulay. Attacking automatic Short Paper: Exploiting WPA2-enterprise Vendor
wireless network selection. In Information Assurance Implementation Weaknesses Through Challenge
Workshop, 2005. IAW ’05. Proceedings from the Sixth Response Oracles. In Proceedings of the 2014 ACM
Annual IEEE SMC, pages 365–372, June 2005. Conference on Security and Privacy in Wireless &
[13] T. Dierks and E. Rescorla. The Transport Layer Mobile Networks, WiSec ’14, pages 189–194, New
Security (TLS) Protocol Version 1.2. Technical report, York, NY, USA, 2014. ACM.
IETF, August 2008. [27] Y. Song, C. Yang, and G. Gu. Who is peeping at your
[14] P. Funk and S. Blake-Wilson. Extensible passwords at Starbucks? - to catch an evil twin access
Authentication Protocol Tunneled Transport Layer point. In Proceedings of the IEEE/IFIP International
Security Authenticated Protocol Version 0 Conference on Dependable Systems and Networks
(EAP-TTLSv0). Technical report, IETF, August 2008. (DSN), Chicago, IL, USA, 2010.
[15] L. Grangeia. Heartbleed, Cupid and Wireless. online: [28] The FreeRADIUS Server Project. The FreeRADIUS
http://www.sysvalue.com/heartbleed-cupid- Project. online: http://freeradius.org/, 2014.
wireless/, 2014. [29] J. Vollbrecht, P. Eronen, N. Petroni, and Y. Ohba.
[16] H. Hwang, G. Jung, K. Sohn, and S. Park. A study on State Machines for Extensible Authentication Protocol
MITM (man in the middle) vulnerability in wireless (EAP) Peer and Authenticator. Technical report,
network using 802.1x and eap. In Information Science IETF, August 2005.
and Security, 2008. ICISS. International Conference [30] K. Wierenga, S. Winte, and T. Wolniewicz. The
on, pages 164–170, Jan 2008. eduroam architecture for network roaming
[17] IEEE. IEEE Std 802.1X-2004. Technical report, IEEE, draft-wierenga-ietf-eduroam-01.txt. Technical report,
December 2004. IETF, February 2014.
[18] V. Kamath, A. Palekar, and M. Wodrich. Microsoft’s [31] J. Wright. asleap Main. online: http:
PEAP version 0 (Implementation in Windows XP //wirelessdefence.org/Contents/AsleapMain.htm.
SP1). Technical report, IETF, October 2002. [32] J. Wright. FreeRADIUS Wireless Pwnage Edition.
[19] B. Lloyd and W. Simpson. PPP Authentication online:
Protocols. Technical report, IETF, October 1992. http://www.willhackforsushi.com/?page_id=37,
[20] J. Malinen et al. hostapd: IEEE 802.11 AP, IEEE 2010.
802.1X/WPA/WPA2/EAP/RADIUS Authenticator. [33] J. Yavor. The BYOD PEAP Show - Mobile Devices
online: http://hostap.epitest.fi/hostapd/, Bare Auth. online:
February 2014. [version 2.1]. https://www.defcon.org/images/defcon-21/dc-21-
[21] J. Malinen et al. Linux WPA/WPA2/IEEE 802.1X presentations/Yavor/DEFCON-21-Yavor-The-BYOD-
Supplicant. online: PEAP-Show-Updated.pdf, August 2013.
http://hostap.epitest.fi/wpa_supplicant/, 2014. [34] H. Yin, G. Chen, and J. Wang. Detecting protected
[version 2.1]. layer-3 rogue aps. In Broadband Communications,
[22] M. Marlinspike. Divide and Conquer: Cracking Networks and Systems, 2007. BROADNETS 2007.
MS-CHAPv2. online: https://www.cloudcracker. Fourth International Conference on, pages 449–458,
com/blog/2012/07/29/cracking-ms-chap-v2/. Sept 2007.
[23] M. Marlinspike. sslstrip. online: [35] G. Zorn. Microsoft PPP CHAP Extensions, Version 2.
http://www.thoughtcrime.org/software/sslstrip/, Technical report, IETF, January 2000.
2009. [36] G. Zorn and S. Cobb. Microsoft PPP CHAP
[24] D. Mónica and C. Ribeiro. Wifihop - mitigating the Extensions. Technical report, IETF, October 1998.