AdSense

Monday, October 17, 2016

WI-FI PT / 3 - ATTACKS AGAINST AUTHENTICATION AND ENCRYPTION / 3.10 - Attack against WPA/WPA2 Enterprise and RADIUS authenticacion


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.