Articles et actualités

Nous avons réalisé dernièrement, lors d'un test d'intrusion, un audit de sécurité WiFi dont les résultats se sont révélés assez typiques !

Grâce à nos cartes munies du chipset Atheros  et de la distribution en LiveCD Linux Backtrack , nous avons sniffé les communications Wifi et découvert que la sécurisation utilisée reposait sur le protocole propriétaire Cisco LEAP (LightWeight EAP).

Cisco décrit ainsi  la séquence d'authentification et d'échangede clés de la façon suivante :

Cisco LEAP is based on a username/password scheme and uses the following basic authentication process:

1. A client connects to the wireless medium.

2. The client sends a start message to an AP (Access Point).

3. The AP sends an access request on behalf of the client to the authentication server.

Il est important de noter que le trafic réseau entre l'AP et le serveur d'authentification (en général RADIUS) sont réalisées sur le LAN et donc hors de portée des attaquants. Par ailleurs, et c'est d'ailleurs le cas là, le serveur RADIUS utilisé est parfois directement embarqué sur l'AP.

4. The client sends its username to the AP, which forwards it to the authentication server.

5. The authentication server sends a challenge back.

6. The AP forwards the challenge to the client as an EAP message over 802.1X.

Ci-dessus, on observe bien le nonce de 8 octets.

7. The client runs the challenge through the Cisco LEAP algorithm, mixes challenge and user password together, and responds with a value, which the AP forwards to the authentication server.

La réponse du client est générée ainsi : 3 copies du nonce sont chiffrées en DES par 3 clés distinctes : on les obtient en hashant le mot de passe (via MD4, produisant un aggrégat de 16 octets), en le concaténant avec 5 octets null, puis en le découpant en 3 séquences (clés) de 7 octets.

Le client envoie alors le challenge-response de 24 (3x8) octets, que l'on peut observer dans la capture ci-dessus.

La faiblesse de LEAP tient dans le fait que le clair est connu (pas de chiffrement du nonce) et que la 3ème clé DES est quasiment connue : les 5 derniers octets (sur 7!) sont "0" !

Il devient assez simple de lancer une attaque par dictionnaire ou brute force en utilisant cette optimisation.. pour chaque test de mot de passe, seul le 3ème et dernier bloc DES est généré : si celui-ci correspond à la capture, le second bloc est calculé. En cas de correspondance, le premier bloc est alors calculé : si de nouveau il y a correspondance , le mot de passe est trouvé !

8. The authentication server runs the user password through the Cisco LEAP algorithm, which processes the challenge and client response, then compares its derived value with the value it received from the client. If the two values match, the authentication server sends a success message to the AP, which passes it to the client.

9. Now, the client sends a challenge to the authentication server to authenticate the AP (the network), and proceeds through the reverse Cisco LEAP process.

On voit bien le client envoyer un challenge de 8 octets.....

.. auquel l'Access Point répond par une donnée de 24 octets.

Dans une seconde trame, l'AP envoie la clé de session :

10. If the network is successfully authenticated, the client passes a success message through the AP to the authentication server, which opens a port. The user is live on the network.

11. Cisco LEAP RADIUS server a WEP key for that session and stores it in the AP.

12. The Cisco LEAP client locally derives the WEP key.

Lors de notre audit, nous avons évidemment tenté (et réussi à casser le mot de passe) grâce à l'outil thc-leapcracker en mode brute force :

La conclusion ? Une mauvais mécanisme de sécurité permet à un attaquant :

• d'obtenir en clair le login de l'utilisateur connecté
• d'obtenir le mot de passe chiffré (ou dérivé) attaquable en mode offline

Ce mot de passe est malheureusement celui du Wifi mais également celui du domaine, et de l'accès VPN !!! On comprend aisément les dégats..

C'est pourquoi nous préconisons :

• une politique de mots de passe forts et fréquemment changés qui reste la meilleure contre-mesure à la plupart des attaques. Si cette politique n'est pas applicable alors il existe des alternatives telles que l'authentification forte via des tokens (RSA, ActivCard, etc..) ou des certificats.
• une décorrelation des comptes (et des mots de passe) VPN, Domaine Active Directory,Wifi, Métier, etc...
• l'utilisation quasi systématique de VPN IPSEC même en mode WiFi
• une veille active autour de la sécurité (information, passage de patch, amélioration de la configuration ou des mécanismes de sécurité) lorsque de tels risques sont encourus. Dans le cas présent la mise en oeuvre de PEAP par l'établissement d'un tunnel SSL doublement authentifié (certificat serveur et client) permet d'assurer également une bonne sécurité (au prix d'un déploiement plus lourd sur les postes de travail).