3.10
- Attack against WPA/WPA2 Enterprise and RADIUS authenticacion
- WPA/WPA2
Enterprise, also known as 802.1x mode or WPA (as opposed to WPA-PSK),
has the purpose of providing authentication services for enterprise
enviroment networks. WPA/WPA2 Enterprise works hand to hand with a
RADIUS server. The protocol used for authentication is usually the
Extensible Authentication Protocol (EAP), which is available in a lot
of different versions. The most important EAP versions are:
- EAP - PEAP: supported by Microsoft and Cisco, it uses only a server side certificate. The EAP - PEAP - MSCHAPv2, natively integrated with Windows, is the most popular of all EAP versions as Wi-Fi security mechanism.
- EAP - TLS: it is considered the most secure, because a certificate is necessary both at the server and the client sides.
- EAP - TTLS: the server uses a certificate, but the client can optionally authenticate with a Certification Authority to the server, which simplifies a lot the whole process. It is faster, but less secure than TLS.
- EAP - FAST: Cisco propietary, used to replace the obsolete LEAP.
- At
this practice, an attack against WPA-Entreprise with RADIUS using
EAP-PEAP wil be exposed, but exactly the same method could be use to
crack EAP-TTLS. In both cases, the trick consists of capturing the
MSCHAP
challenge/response
pair, and applying a dictionary attack with the tool Asleap.
- The
most used protocol for EAP-PEAP with Windows devices is MSCHAP, which
is the Microsoft version of the Challenge Handshake Authentication
Protocol (CHAP). There are two different versions: MS-CHAPv1 and
MS-CHAPv2. MSCHAPv2 is often used as an authentication option for
RADIUS servers, providing security for Wi-Fi under the WPA Enterprise
scenario.The Challenge Handshake Authentication Protocol (CHAP) is
used to authenticate a user or a host to an authenticating entity,
for instance a RADIUS server. The verification is based on a key
secret shared by the client and the server or authenticator. The
whole process consists of a 3 way handshake. After the intial
establishment phase, the authenticator sends a "challenge"
message to the client. The client responds with a one-way hash,
calculated with the challenge and the secret combined. The
authenticator compares the received hash with its own calculation of
the hash value. If both hashes match, the authenticator acknowledges
as valid the authentication. At random intervals the authenticator
sends a new challenge to the peer.
- The
topology used for this practice will be a little bit different than
other practices, because in this case it is necessary to introduce
RADIUS server authenticators. On the one hand, the victim "roch"
should authenticate with the legitimate AP using the services of a
legitimate RADIUS server. However, let's suppose that for any reason
an attacker has achieved the goal of forcing the victim to connect to
a rogue AP, which is using the services of a Free Radius server
running on a "kali" Linux machine. For instance:
- In
this practice, to setup an AP honeypot will be used a D-Link Access
Point, broadcasting an ESSID called "withRadius". The
honeypot will try to fake a supposedly real network, which could work
for instance with Windows Server 2003, 2008 or 2012 Radius server,
integrated with Active Directory.
- Because
an external RADIUS server is going to be used, WPA/WPA2 Enterprise is
needed:
- The
AP is pointing as a client to the FreeRadius server, which is running
on the "kali" attacker with IP 192.168.0.198, listening on
port 1812. Also, a Shared Secret is needed ("test"), shared
between the AP and the FreeRadius server:
- Verifiying
that "kali"s IP (FreeRadius server) is 192.168.0.198:
- On
the server side, FreeRadius is configured to use EAP-PEAP by default,
at eap.conf file:
- Also,
FreeRadius needs to be aware of its client D-Link AP, whose IP is
192.168.0.2:
- As
said before, both AP client (192.168.0.12) and FreeRadius server
(192.168.0.198) have to share a secret key ("test"):
- The
shared key is introduced at the clients.conf file for the client
192.168.0.2:
- Then,
FreeRadius server is started at "kali", listening on port
1812 to authentication requests:
- A
victim user "daniel" from "roch", tries to join
the "withRadius" wireless network, and he is prompted for
authentication:
- Previously,
the certification validation option for EAP has been turned off at
the client "roch", with the purpose of showing the
potential weakness of this type of authentication. Of course, if a
certificate (fake, created by FreeRadius at the attacker "kali")
is offered and accepted by the user, the result would be the same.
Because the "validate server certificate" is off, the
victim is not able to verify if a certificate is either fake of
truthful. Not only that, if the "Connect to these servers"
option is also turned off, an attacker could get a real certificate
from any list of authorized authorities. In case of been accepted by
the client, the result would be again the same:
- The
connection is succesful:
- FreeRadius
debugs the success of the authentication process:
- In
the meanwhile, the process of the mschap username / challenge /
response is being tailing from radius.log:
- Finally,
the tool Asleap, after a brute force attack with the help of the
wordlist "diccionario.txt", is able to crack the password
for user "daniel": abcdefghi
- It is important to notice that in this practice, and for the purpose of a more clear demonstration, valid credentials have been introduced. However, if non valid credentials had been used, the log would have captured them in the same way, and eventually Asleap also would have been able to crack them.
