Lancement de “Dienekes Cyber Protect”, une solution de sécurité complète et gratuite

J’ai décidé de passer mon temps libre à travailler sur une suite logicielle gratuite, de qualité professionnelle, mais avec une licence très restrictive (utilisation gratuite mais interdiction de réutiliser le code dans un produit commercial), visant à assurer la cyber défense des entreprises utilisatrices.

L’architecture que j’ai en tête figure ci-dessus. Elle n’a rien de définitive, c’est juste une image de ma réflexion à un instant t. Tout ce qui est en jaune fait partie de mon projet, ce qui est en blanc fait partie de l’entreprise à protéger des cyber attaques.

Le projet s’appelle DIENEKES, du nom du meilleur défenseur de Sparte lors de la bataille des Thermopyles en 480 av JC.

L’idée générale de la suite est de surveiller les tentatives d’intrusion via les points d’accès wifi, via le réseau interne de l’entreprise, et via du monitoring local sur chaque machine du parc à protéger. Les petits plus étant de nettoyer tous les emails entrant des risques de chevaux de troie, de mettre la base de connaissance vitale de l’entreprise dans un bunker numérique, de collecter et corréler les logs pour y déceler une attaque furtive (APT), de faciliter la gestion des identités numériques au sein de la société.

L’idée est de fournir une suite efficace, modulaire, dont le paramétrage est extensible facilement, simple à mettre en oeuvre, bien documentée. Ainsi l’entreprise utilisatrice pourra mettre en place une cyber défense gratuite, sans avoir besoin de payer des consultants. Le code sera open source, mais non ré-utilisable dans un produit commercial.

Il y a du travail, mais le projet est enthousiasmant. Hormis le nettoyage des emails pour lequel il faudra que je fasse quelque recherche, pour le reste je pense maîtriser la technologie nécessaire pour spécifier et coder chaque brique techno.


Cryptologie : différence entre hash, hmac, et pbkdf2

Dès lors qu’on s’intéresse à la cryptologie moderne, on tombe très vite sur ces 3 notions. Elles sont différentes, mais complémentaires. Elles sont très utilisées. La protection WPA2 du wifi, par exemple, utilise les 3.

Commençons par la notion de hash

Un hash, ou fonction de hachage en français, est une fonction qui prend en entrée un message de taille variable, pour en faire en sortie un résumé (appelé « digest » en anglais, ou « condensat » en Français) de taille fixe. Ce digest repose sur un algorithme étudié pour générer de très grandes variations dans le digest si le moindre bit du fichier d’entrée évolue. De plus, l’algorithme est théoriquement étudié pour que deux fichiers d’entrée différents donnent deux digests différents. Si deux fichiers d’entrée différents donnent le même digest, on dit qu’il y a une collision, ce qui n’est pas le cas souhaité.

Ces fonctions de hachage servent souvent à conserver un mot de passe sous forme chiffrée en mémoire ou sur un disque dur. En effet, si le support est compromis, le fait de retrouver le mot de passe haché est quasi impossible puisque la fonction de hachage n’est pas réversible.

Les deux algorithmes de hachage les plus connus sont MD5 et SHA. MD5, qui date de 1991, est obsolète et n’est presque plus utilisé. Il génère des condensats de 32 octets. SHA-1 date de 1995 et est considéré comme plus robuste que MD5, bien que les puissances de calcul modernes le rendent moins sûr. Il génère des condensats de 20 octets. SHA-1 est en passe de se faire détrôner par SHA-256.

Voir en fin d’article le code source pour mettre en œuvre SHA-1 dans un programme en langage C.

Passons maintenant à la notion de HMAC (Keyed hash message authentication code)

Un HMAC fait la même chose qu’un hash, mais prend en entrée, en plus du fichier à condenser, une clé. L’avantage se comprend immédiatement, en plus de prouver l’intégrité d’un message (ce que fait le hash, lorsqu’il est utilisé en signature), le HMAC peut prouver l’authenticité d’un message (seul celui qui dispose de la clé a pu calculer la signature). Casser un HMAC est plus dur que casser un hash puisqu’en plus d’une infinité de fichiers d’entrée possibles, il y a aussi une infinité de clés possibles.

Le hmac est défini comme étant :

Dans la formule ci-dessus, h est une fonction de hachage (SHA-1 par exemple, on parle alors de HMAC-SHA1, mais on peut aussi évidemment faire du HMAC-MD5). La robustesse du HMAC est intimement liée à la robustesse de l’algorithme de hachage utilisé. Le symbole + représente l’opération logique XOR (ou exclusif) et || la concaténation.

On voit que l’algorithme utilise deux tampons opad et ipad, ils sont utilisés comme suit :

Un exemple de calcul de HMAC-SHA1 est donné en langage C à la fin de cet article.

Venons en maintenant au PBKDF2

PBKDF2 signifie “Password key derivation Function 2”. C’est une fonction, la deuxième du nom comme son nom l’indique, qui est définie dans la norme RFC2898 et dans la norme PKCS (Public Keys Cryptographic Standard) #5 V2.0

Cette fonction est miraculeuse car elle permet, à partir d’un mot de passe secret relativement simple de générer des clés de chiffrement de la taille que l’on souhaite.

La fonction prend 5 paramètres en entrée :

PBKDF2 (PRF, Password, Sel, nbre d’itération, longueur de clé désirée)

PRF peut être une fonction de type HMAC (HMAC-SHA1 par exemple).

La fonction itère un grand nombre de fois, en moulinant sur du HMAC, ce qui rend très difficile l’attaque par force brute, ainsi que l’attaque par Rainbow tables.

SHA-1, HMAC-SHA1 et PBKDF2 appliqués au Wifi WPA2

Le chiffrement wpa2 du wifi utilise toutes ces notions comme évoqué précédemment.

La fonction pbkdf2 est appelée avec une fonction PRF qui est HMAC-SHA1 (qui elle même utilise SHA1 si vous avez bien suivi), un password qui est le mot de passe qui protège la box wifi, un sel qui est le SSID (nom du réseau) wifi, un nombre d’itération égal à 4096. Cette fonction génère une clé de 32 octets appelée PMK.

A partir de cette clé PMK, est calculée une clé PTK, avec PTK=PRF(PMK, 32, “Pairwise key expansion”, 22, data, 76, PTK, 512), dans laquelle data est la concaténation sur 76 octets de minimum (adresse mac point d’accès, adresse mac client), maximum (adresse mac point d’accès, adresse mac client), minimum (nonce point d’accès, nonce client), maximum (nonce point d’accès, nonce client)

Le code source de cette fonction PRF est le suivant (on voit qu’elle aussi utilise un HMAC-SHA1):

Voilà, vous êtes maintenant incollable sur ces notions de hash, hmac-sha1 et pbkdf2.

Chose promise, chose due (et c’est un beau cadeau si vous faites de la crypto parce que ces fonctions, en tout cas dans leur version qui marche bien, ne sont pas si faciles à trouver sur le net), voici une petite archive C contenant tout ce qu’il faut pour utiliser SHA1, HMAC-SHA1 et pbkdf2 dans vos propres programmes.

Capturer les handshakes wifi WPA2 en langage C avec les Raw Sockets

Nous allons voir dans cet article comment capturer les handshakes wifi wpa en utilisant les RAW SOCKETS en langage C

Beaucoup de programmes de ce type existent en Python, mais il est assez difficile, et pour tout dire quasi impossible d’en trouver en C. Pourtant beaucoup de gens aiment programmer en C, il est donc dommage de ne pas pouvoir bénéficier de ces connaissances dans ce langage, et ce d’autant plus que, les raw sockets permettent de faire tout ce qu’on veut.

Le code source de mon programme est publié ci-dessous. Il compile sous linux sans problème avec la commande : gcc gethanshake.c -o gethandshake

Mais avant de parler de capturer les handshakes, voyons d’abord ce que c’est.

Un réseau wifi domestique est composé d’un point d’accès wifi, auquel on connecte des appareils clients. Le point d’accès (AP pour access point) émet plusieurs fois par seconde des trames appelées “beacons”, qui lui permettent d’être détecté par les appareils environnants. C’est grâce à ces trames que ce réseau wifi apparait dans la liste des réseaux wifi disponibles.

Si un des clients souhaite se connecter à ce réseau, il va contacter le point d’accès pour d’abord s’associer à celui-ci (échange de trames dites d’association), puis, et c’est ce qui nous intéresse ici, il va s’authentifier auprès de ce point d’accès. S’authentifier signifie que les deux entités (le point d’accès et le client) vont s’échanger 4 trames, qui ont pour but de faire en sorte que chacun des deux va prouver à l’autre qu’il connait le secret, sans pour autant jamais se l’échanger. Le secret, c’est typiquement le code de connexion au réseau wifi (celui qui figure sur votre livebox et que vous devez entrer sur votre machine pour vous connecter au réseau).

Je renvoie le lecteur à mon article précédent sur la faille Krack pour comprendre le détail de cette mécanique. L’idée générale est que le secret ne doit jamais être échangé sur les ondes car il pourrait être intercepté.

En résumé :

Etape 1 : le point d’accès envoie au client un nombre aléatoire appelé ANonce. Ce nombre est présent dans la première trame, qui est émise par le point d’accès.

Etape 2: Connaissant maintenant ANonce, le client choisit lui aussi un nombre aléatoire appelé SNonce, et il calcule une clé PTK qui est fonction : du secret, de ANonce, de SNonce, de l’adresse MAC du point d’accès, et de l’adresse MAC du client. Dans la deuxième trame, qui va cette fois du client vers le point d’accès, le client envoie au point d’accès SNonce, mais aussi une signature cryptographique de cette trame réalisée à partir d’un morceau de la clé PTK. Cette signature est appelée le MIC

Etape 3 : le point d’accès connait maintenant SNonce, et est donc en mesure de calculer la même clé PTK que celle du client. Il calcule une clé GTK, qu’il chiffre avec un bout de la clé PTK et l’envoie vers le client dans la trame numéro 3.

Etape 4 : le client déchiffre la clé GTK, l’installe et accuse réception au point d’accès dans la 4è et dernière trame de cette séquence d’authentification qu’on appelle le 4 way handshake

Mon programme en C scrute tout ce qui passe dans les airs et affiche à l’écran les valeurs des Nonces et des MIC contenus dans les trames qu’il voit passer.

A quoi cela sert-il ? A comprendre ce que ferait un pirate qui chercherait à pénétrer votre réseau wifi.

La démarche du pirate est la suivante : il va capturer les handshakes qui passent (donc il connait ANonce, SNonce, les adresses MAC du client et du point d’accès). Le seul élément qui lui manque pour calculer lui aussi la clé PTK et accéder au réseau, c’est le secret.

Il va donc prendre un secret “au hasard”, calculer la clé PTK qui va avec ce secret, calculer les MIC correspondant à ceux théoriquement contenus dans les trames du handshake, puis comparer les MIC qu’il calcule à ceux qu’il a capturés. S’il y a correspondance, c’est qu’il a trouvé le secret (donc la bonne clé PTK, et il accède au réseau), sinon, il choisit un autre secret “au hasard”.

“au hasard” est entre guillemets puisqu’en réalité, soit il va tester toutes les clés possibles (attaque par force brute), soit il va essayer sur des mots ciblés (attaque par dictionnaire), soit par d’autres moyens (attaque par rainbow tables par exemple)

Bon bref, vous voyez le principe.

Petit détail, comme généralement le pirate n’est pas patient, il ne va pas attendre des heures que quelqu’un se connecte au point d’accès pour récupérer les handshakes. Généralement ce qu’il fait c’est qu’il émet une trame dite de deauthication soit ciblée vers un client précis déjà connecté, soit vers tous les clients (broadcast) pour les obliger à se reconnecter au point d’accès. Ainsi tous les clients se mettent instantanément à refaire des handshakes avec le point d’accès et le pirate récolte ce qu’il veut de suite.

Je vous vois d’ici : “Comment ? Les clients ne vérifient même pas que les trames deauth proviennent bien du point d’accès ?”

En fait, si parfois, et non parfois. En fait, cela ne change rien puisque les fausses trames deauth sont construites comme les vraies, c’est à dire que dedans l’adresse MAC d’émission n’est pas celle du pirate mais celle du point d’accès. Le client n’a donc aucun moyen de séparer les fausses trames des vraies.

Ces trous de sécurité (le fait qu’on puisse lire les handshakes aussi facilement, et qu’on puisse balancer des trames deauth qui fonctionnent aussi facilement) seront normalement comblés avec la norme WPA3 qui s’annonce.

Inutile de dire que mon programme n’envoie aucune trame deauth.

Voici mon programme en action sur un test constitué de mon smartphone Android partageant un réseau wifi nommé “Honor 8”, et de mon iPad qui se connecte dessus. L’iPad et le smartphone font un handshake en 4 temps capturé par mon PC sous Linux et faisant tourner gethandshake.

Le code source du programme figure ici.

/*
This software demonstrates how to catch wifi WPA2 handshakes in C using Raw sockets
It turns your wifi adapter into monitor mode and then show the 802.11 wifi traffic
When a handshake is detected, handshake data are displayed : ANonce, SNonce, and MIC
No cracking is performed, the tool only reads public data
No deauth frame sent, the tool is completely passive
Instructions :
Declare the name of your wifi adapter in the INTERFACE variable below (often “wlan 0”, but you can use iwconfig to check)
then compile :
gcc gethandshake.c -o gethandshake
and run with root privileges :
sudo ./gethandshake
Terminate with Ctrl-C when done. The wifi adapter goes back to managed mode
Enjoy
Code by alain.quemeneur@gmail.com
*/

La faille wifi KRACK pour les nuls

La faille KRACK (Key Reinstallation AttaCK) a été présentée au CSS en novembre 2017 à Dallas, par le binôme de chercheurs belges Frank Piessens et Mathy Vanhoef, de l’université de Louvain.

Cette faille a fait grand bruit dans le monde de la cybersécurité car elle entraîne une vulnérabilité concernant les liaisons wifi sécurisées en WPA2, qui non seulement étaient jusque là utilisées depuis une quinzaine d’années sans qu’aucune attaque ne soit connue, mais dont la sécurité avait été en plus prouvée formellement inviolable.

Cette faille est assez élaborée, ce qui explique peut-être pourquoi il est très difficile de trouver un article de vulgarisation, qui ne soit pas de trop haut niveau (type dépêche AFP), ni de trop bas niveau (il n’y a que les spécialistes qui comprennent). Je vais tenter de combler cette faille (si j’ose dire).

Avant d’expliquer comment fonctionne l’attaque, il est tout d’abord nécessaire de regarder comment se passe une connexion à un réseau wifi en dehors de toute attaque.

La connexion au wifi

Nous excluons ici les réseaux wifi ouverts (non sécurisés, comme ceux des gares ou des aéroports) ou réseaux d’entreprise. Nous nous intéressons uniquement aux réseaux dits “de particuliers” (comme celui que vous avez quand vous partagez en wifi la connexion 4G de votre téléphone, ou celui de votre livebox à la maison), sécurisés en WPA2.

Lorsqu’un “client” se connecte à un réseau wifi WPA2 offert par un “point d’accès”, il y a deux phases d’échanges : la phase d’association et la phase d’authentification. La phase qui nous intéresse est la phase d’authentification.

La phase d’authentification a pour but de faire en sorte que le client et le point d’accès se prouvent mutuellement qu’ils connaissent bien la clé du réseau wifi, sans jamais s’échanger cette clé, d’une part, et d’autre part de négocier une clé de session commune qui sera utilisée pour chiffrer tous les échanges ultérieurs à la phase d’authentification. Pour cela, le client et le point d’accès utilisent le 4 way-handshake, ou poignée de main en 4 temps en français.

La poignée de main en 4 temps (4 way handshake)

Le principe est le suivant. Sachant que le client et le point d’accès connaissent la clé du réseau (le mot de passe que vous mettez pour partager en wifi votre connexion Android) qu’on appelle PMK (Paiwise Master Key), et qu’ils doivent chacun prouver à l’autre qu’il connait cette clé sans jamais l’échanger :

1er temps : Le point d’accès envoie au client une série de chiffre (qu’on va appeler “nonce”) tirés au hasard. On nomme cette série de chiffres ANonce.

A la réception de ANonce, le client va lui aussi tirer au hasard une série de chiffres (qu’on va appeler SNonce) et va calculer une nouvelle clé, PTK (Pairwise Transcient Key) en dérivant la clé PMK, selon la formule PTK = PRF (PMK, ANonce, SNonce, Adresse MAC du client, Adresse MAC du point d’accès).

Rappelons que chaque équipement réseau possède une adresse physique, appelée adresse MAC (6 octets notés généralement XX:XX:XX:XX:XX:XX, dont les 3 premiers identifient le fabricant, et les 3 derniers sont uniques pour chaque fabricant), censée être unique au monde (censée car il est très facile avec des logiciels comme macchanger de prendre l’adresse MAC qu’on veut)

La formule exacte de PRF (Pseudo Random Function) a peu d’intérêt dans un article de vulgarisation. Sachez juste qu’elle produit un résultat de 384 ou 512 bits selon le protocole sélectionné (384 bits en WPA2/AES256, 512 bits en WPA/TKIP mais ce protocole n’est presque plus utilisé)

Ce qui est intéressant, c’est que le résultat de ce calcul (PTK donc) est ensuite coupé en plusieurs clés :

  • Les bits 0 à 127 vont être utilisés en tant que clé dite MIC ou MK (Master Key) de 128 bits
  • Les bits 128 à 255 vont être utilisés en tant que clé dite EK (Encryption Key) de 128 bits
  • Les bits 256 à 383 représentent la clé temporaire 1, ou TK1 (Transcient Key 1)
  • Et enfin, les bits 384 à 511, s’ils sont présents, représentent la clé temporaire 2 (TK2)

2ème temps : Le client envoie au point d’accès un message contenant SNonce, ce message est signé par la clé MIC (MK)

A la réception de ce message, le point d’accès a maintenant lui aussi tout ce qu’il faut pour calculer de son côté PTK = PRF (PMK, ANonce, SNonce, Adresse MAC du client, Adresse MAC du point d’accès), ainsi que les clés dérivées à savoir MIC/MK, EK, TK1 et TK2 si elle existe. Les résultats des calculs du point d’accès sont évidemment les mêmes que ceux du client. A ce stade, le point d’accès n’installe pas encore la PTK.

3ème temps : Le point d’accès envoie au client la GTK (Group Temporal Key), chiffrée par la clé EK et signée par la clé MIC (MK)

A la réception de ce message, le client déchiffre et authentifie la clé GTK et installe PTK et GTK.

4ème temps : Le client accuse réception auprès du point d’accès de la bonne réception de GTK

A la réception de ce message, le point d’accès installe PTK (GTK étant installée au démarrage du point d’accès) et à partir de là tous les échanges ultérieurs sont chiffrés.

Le 4 way handshake est terminé, les deux parties ont chacune prouvé qu’elles connaissaient PMK sans jamais l’échanger, et se sont mises d’accord sur un certain nombre de clés de chiffrement.

Figure 1 – Poignée de main à 4 temps, la partie basse montre ce qui se passe lorsque le point d’accès fait une mise à jour de la GTK et communique la nouvelle aux clients

La sécurité du système

Violer un tel système de sécurité n’est pas trivial, c’est le moins qu’on puisse dire. La sécurité de ce système a été, rappelons le, démontrée formellement.

Deux mesures de sécurité, dont nous n’avons pas encore parlé, sont intégrées au dispositif.

Premièrement, il est très difficile de monter une attaque de type man in the middle (avec un faux point d’accès situé au milieu et qui intercepterait/transmettrait les paquets entre le client et le point d’accès) car du fait de l’adresse MAC différente de ce faux point d’accès, il ne dériverait pas correctement la PTK

Deuxièmement, comme on peut le voir sur la figure 1, un “replay counter” (appelé r) est systématiquement intégré aux messages, empêchant un attaquant de rejouer des échanges passés. Si le point d’accès met r comme replay counter dans son message, la réponse du client contiendra aussi r, puis le point d’accès passe à r+1 pour son prochain message auquel le client répondra par un compteur lui aussi à r+1 et ainsi de suite.

Voyons concrètement ce qui se passe via une capture faite par Wireshark (un logiciel permettant de capturer les échanges réseaux) lorsque mon iPad se connecte au réseau WIfi partagé par mon smartphone Android.

Figure 2

On voit dans la partie haute que 4 paquets EAPOL sont échangés. Le premier paquet, figure 2, comporte bien ANonce (32 octets), un replay counter à 1, et aucune signature MIC.

Figure 3

Figure 3 : Le deuxième message, qui va de l’iPad vers le point d’accès, a lui aussi un replay counter à 1, comporte le SNonce de 32 octets et a une signature MIC. Dans la partie Data, le client informe le point d’accès des protocoles de chiffrement qu’il supporte.

Figure 4

Figure 4 : Le troisième paquet, qui va du point d’accès au client a un replay counter à 2, une signature MIC et une partie Data comportant la clé GTK chiffrée par la clés EK.

Figure 5

Figure 5 : le 4è message a un replay counter à 2, et ne comporte qu’une signature MIC. C’est un message ACK.

L’attaque KRACK

Comme je le disais au début, elle est assez compliquée et peut concerner soit la partie 4 way handshake, soit la partie Group Key handshake (voir figure 1). Pour être concis, on ne regardera que la partie 4 way handshake.

L’idée générale est de forcer la réinstallation de clés en se mettant en man in the middle et en empêchant le point d’accès de recevoir le message 4 du client.

Figure 6 – L’attaque sur la partie 4 way handshake

La figure 6 montre l’attaque. Le faux point d’accès attaquant est la ligne du milieu. On va l’appeler Mitm.

D’abord un mot sur cette position. On a vu plus haut qu’elle était en théorie très difficile à atteindre puisque les adresses MAC sont utilisées dans la dérivation. Les auteurs de l’attaque ont habilement contourné cette difficulté en créant un faux point d’accès ayant le même nom (SSID) mais sur une fréquence wifi (channel) différente et avec la même adresse MAC (via macchanger, l’outil qui permet de prendre l’adresse MAC qu’on veut). Ce faux point d’accès, si le client s’accroche dessus, est en Man in the middle et dispose de la bonne adresse MAC.

Mitm va transmettre sans les altérer les messages 1, 2 et 3, mais il va bloquer le message 4 envoyé au final par le client.

Le client, croyant que le point d’accès a reçu le message 4, va commencer son trafic chiffré. Ce trafic est intercepté par Mitm et non retransmis vers le point d’accès réel.

Celui-ci, ne voyant pas arriver le message 4, va ré-émettre le message 3 au bout d’un moment (avec un replay counter augmenté). Mitm peut choisir de renvoyer ce nouveau message 3 vers le client tout de suite ou attendre un peu pour capturer un maximum de messages chiffrés en provenance du client.

Quoi qu’il en soit, lorsque Mitm va envoyer le nouveau message 3 vers le client, celui va être perturbé. A partir de là, tout dépend de la manière avec laquelle la norme wifi a été implémentée dans le client :

  • Soit le client accepte ce nouveau message 3, auquel cas, il réinstalle les mêmes clés, c’est à dire qu’il va réinitialiser sa séquence de flux de chiffrement (sa clé de flux de chiffrement) et donc se mettre à chiffrer son trafic ultérieur en réutilisant le même flux de codage que précédemment, ce qui est une énorme faille de sécurité (on verra juste en dessous pourquoi). Certes, le nombre de messages différents codés avec le même flux de codage va être faible, mais il ne faut pas oublier que Mitm peut toujours envoyer à intervalle régulier des messages dits de “deauthentication”, qui obligent celui-ci à se déconnecter et rejouer le 4 way handshake et donc l’attaque est repartie pour un tour. Avec ces deux techniques cumulées, Mitm peut faire en sorte que le flux de codage soit réinitialisé et réutilisé pour pratiquement tout le trafic du client.
  • Soit le client n’accepte que les messages 3 chiffrés à ce stade (vu que les clés sont installées de son côté). Dans ce cas l’attaque est différente et se complexifie d’une manière qui dépasse le cadre d’un article de vulgarisation (l’attaquant s’en sort en comptant sur le temps de propagation qui existe entre la carte Wifi et le CPU, mais c’est impossible à expliquer de manière simple). C’est le cas de MacOS, Android et OpenBSD. A noter que les auteurs ont publié en octobre 2018 une mise à jour de leur papier expliquant qu’ils savaient maintenant se passer du temps de propagation carte wifi/CPU.
  • Soit le client réinstalle des clés ne contenant que des 00 ! Ce bug semble être lié à un paragraphe de la norme Wifi qui prête à confusion. Ce bug est présent dans un client wifi appelé wpa_supplicant et couramment utilisé sous Linux et Android, ce qui rend ces 2 OS particulièrement vulnérables à l’attaque KRACK (avant patch évidemment)

Venons en maintenant à la question de fond : pourquoi est-ce si grave de réutiliser le même flux de chiffrement ?

Les chiffrements par flux se font généralement par l’opération XOR (OU exclusif) entre le message en clair et une clé de flux (ie une suite pseudo aléatoire d’octets)

OCTET en clair XOR OCTET de clé = OCTET chiffré

Pour déchiffrer : OCTET chiffré XOR OCTET de clé (le même évidemment) = OCTET en clair

Et au niveau du flux, c’est pareil :

Message en clair XOR f(clé, indice) = Message chiffré

Message chiffré XOR f(clé, indice) = Message en clair

Indice vaut 1 pour le premier octet, 2 pour le 2è octet, etc.

Normalement quand on chiffre deux messages différents sans réinitialiser le flux de la clé (ie avec des indices différents), on a :

Message 1 en clair XOR f(clé, indice 1) = Message 1 chiffré

Message 2 en clair XOR f(clé, indice 2) = Message 2 chiffré

Tout va bien, le système est protégé.

Mais si un attaquant réussit à réinitialiser l’indice, et donc qu’on rechiffre avec le même flux, alors on obtient :

Message 1 en clair XOR f(clé, indice 1) = Message 1 chiffré

Message 2 en clair XOR f(clé, indice 1) = Message 2 chiffré

Ou dit autrement :

Message 1 en clair XOR constante = Message 1 chiffré

Message 2 en clair XOR constante = Message 2 chiffré

Il est alors facile de faire disparaître la constante de l’équation :

Message 1 en clair XOR Message 2 en clair = Message 1 chiffré XOR Message 2 chiffré

Donc, à partir du moment où l’on sait où telle page web a été consultée (Message 1 en clair connu) et qu’on a réussi à capturer le trafic chiffré (Message 1 chiffré, et Message 2 chiffré connus), il est facile de retrouver Message 2 en clair sans pourtant jamais avoir eu connaissance de la clé. Et si au final Message 2 en clair c’est un flux web sur lequel on a donné une information sensible comme un couple login/mot de passe ou un numéro de carte bleue, dommage (sauf bien sûr si l’on utilise un protocole de plus haut niveau chiffré, comme https).

Et ça, c’est pour les OS qui font une réinitialisation des indices. Pour ceux qui repartent carrément sur une clé dans laquelle tous les octets sont à 00, l’attaquant voit alors de base tout le trafic en clair.

Conclusion

Depuis que cette faille KRACK a été rendue publique, les fabricants ont eu le temps de proposer des correctifs. Sauf que depuis que la faille a été rendue publique, les auteurs de l’attaque l’ont aussi améliorée (voir ici) et aboutissent à la conclusion que de s’en protéger de manière sûre n’est en fait pas si simple. A chaque fois qu’on ferme une porte, ils arrivent à rentrer par la fenêtre.

L’autre point intéressant à noter est qu’alors que ce mécanisme a été formellement prouvé comme inviolable, l’implémentation qui en a été fait a souvent permis d’introduire des vulnérabilités.

On ne répétera jamais assez de faire les mises à jour régulièrement. Et de choisir des mots de passe robustes. En effet, et il faut en avoir conscience, quand bien même la faille KRACK serait fermée définitivement, que rien n’empêche un attaquant de capturer les messages 1 et 2 du 4 way handshake, récupérant ainsi ANonce et SNonce pour ensuite tenter de retrouver PTK en essayant des PMK jusqu’à trouver la bonne. Si le mot de passe PMK du point d’accès est bien choisi et robuste, cette recherche va prendre des milliards d’années. Mais si le mot de passe est 1234567 ou équivalent, la bonne PMK va être trouvée dans les 5 mn par une attaque par dictionnaire.

Voilà, j’espère être resté dans le domaine de la vulgarisation, mais moi-même j’ai des doutes 🙂

Alain QUEMENEUR

Tagués avec : ,

[Cours système Linux – Episode 4] Visualiser les processus et l’environnement

Le but de ce module est de toucher du doigt ce que sont les processus et les variables d’environnement.

1) La commande de base pour visualiser les processus lancés est la commande ps. Cependant, on peut visualiser tous les processus de la machine avec l’arbre de filiation en tapant la commande :

pstree

2) Visualiser l’état des processus de la machine en tapant la commande :

ps aux Lire la suite ›

Tagués avec : , ,

[Cours système Linux – Episode 3] Les commandes de base

Contrairement aux utilisateurs Windows ou Mac, les unixiens/linuxiens ont l’habitude de taper des commandes au clavier dans un interpréteur de commandes. Sous Ubuntu il suffit de faire Ctrl+Alt+t pour faire apparaitre cet interpréteur (c’est l’équivalent de l’invite de commandes sous Windows).

Dans le monde Unix / Linux, cet interpréteur de commandes s’appelle un shell (une coquille en français). Historiquement il y a eu plusieurs shells (sh, zsh, csh, etc.). Celui qui est universellement utilisé aujourd’hui est bash (Bourne Again Shell).

Il y a deux raisons qui font que, dans le monde unix (sauf sur Mac, mais c’est dû à la clientèle friquée qui ne met pas les mains dans le cambouis) on tape souvent des commandes dans le shell : Lire la suite ›

Tagués avec : , ,

[Linux] Programmer un VPN perso pour passer tous les barrages

Le problème avec les VPN classiques (OpenVPN, …) est qu’ils sont souvent bloqués dans les hôtels ou les réseaux wifi publics. En effet, l’anonymat que ces outils procurent ne plaît pas forcément aux tenanciers. Le blocage des outils VPN connus est facile, il suffit de bloquer les ports TCP correspondant.

Au final vous êtes obligé de surfer en clair, avec tous les problèmes de sécurité que cela implique.

Par ailleurs, on sait très bien que, même si openvpn passe, il est fortement déconseillé d’acheter sur des sites de e-commerce via ces connexions qui aboutissent souvent chez des prestataires (sauf si le serveur openvpn est chez vous, mais c’est la mort à paramétrer).

Avec mon système, vous pouvez contourner l’empêchement des VPN dans les hôtels et même acheter sur des sites de e-commerce en toute sécurité, et la configuration de l’architecture est simplissime.

Je l’ai testé dans des hôtels un peu partout dans le monde, dont beaucoup bloquaient les VPN, et il a fonctionné partout.

Comment ça marche ? Lire la suite ›

Tagués avec : , , ,

[Linux] Lecture d’une webcam en langage C (Video4Linux2)

Nous allons voir dans cet article comment accéder à la webcam sous Linux depuis un programme en langage C.

Les webcams sont détectées et gérées sous Linux par un sous-système du noyau appelé Video4Linux2 (v4l2). Il s’agit d’une couche d’abstraction offerte au programmeur lui permettant d’accéder à la webcam par une API indépendante de la webcam installée.

Video4Linux2 dispose de capacité de détection et de reconnaissance des webcams très performantes, comme c’est souvent le cas sous Linux. L’API à utiliser n’est cependant pas triviale à utiliser, c’est pourquoi le programmeur trouvera utile d’avoir dans sa boite à outils un exemple de code « qui marche ».

Ce bout de code qui marche est présenté ci-dessous. Il est très simple en termes de fonctions mais difficile à écrire from scratch. En gros, il initialise l’interface video4linux2, ouvre une fenêtre à l’écran, et entre dans une boucle infinie qui lit l’image courante sur la webcam et rafraîchit l’image dans la fenêtre au fur et à mesure. Pour tuer le programme, il faudra donc faire un Ctrl-C dans la fenêtre dans laquelle on l’a lancé.

Voici ce que donne le programme à l’exécution.

Lire la suite ›

Tagués avec : , , , , , ,

[Cours système Linux – Episode 2] Les rôles du noyau

Dans cette partie nous allons voir les nombreux rôles que je le noyau Linux, ce qui vous montrera la complexité d’un tel programme, et fera comprendre que seuls les meilleurs programmeurs du monde peuvent entreprendre une tâche aussi titanesque et complexe.

Gestion de la mémoire

Le premier rôle du noyau est de gérer la mémoire, la fameuse RAM, présente sur l’ordinateur. Pour ce faire, le noyau qui est, rappelons le, le premier programme à monter en mémoire, va se loger dans une zone à haut privilège de la mémoire physique, et va considérer que le reste de la mémoire physique est de la mémoire virtuelle.

La mémoire est découpée en pages. La taille de ces pages fait, selon l’Unix sur lequel on se trouve, généralement 4 à 8 Ko. Le lien entre la notion de mémoire virtuelle et la notion de mémoire physique se fait de la manière suivante :

Le noyau gère des processus. Les processus se sont les programmes en mémoire. Par exemple, lorsque je lance mon navigateur Internet, j’ai un programme en mémoire, donc un processus. Sur la figure ci-dessus, sont représentés deux processus X et Y. La mémoire physique de l’ordinateur, la seule qui existe vraiment, est représentée au milieu. Lire la suite ›

Tagués avec : , ,

[Cours système Linux – Episode 1] Introduction

Le savoir que nous allons aborder dans ce cours système Linux fonctionne en réalité dans n’importe quel environnement Unix.

Unix est un système d’exploitation multi-processus et multi-utilisateurs inventé dans les années 60. Historiquement, il s’est rapidement séparé en deux familles d’Unices (c’est le pluriel d’Unix) : System V, plutôt porté par le monde industriel, et BSD porté par l’Université de Berkeley. Les unices d’aujourd’hui ont fini par être compatible de ces deux mondes.

Est un Unix tout système d’exploitation conforme au standard Posix qui définit ce qu’est un Unix. Si demain je me mets devant mon ordi et que je programme de zéro un OS conforme à cette norme, alors mon OS est de facto un Unix. Lire la suite ›

Tagués avec : , , ,
Top