loader

Kit cyber - Chapitre 5 : Récupération de données en clair

Second chapitre du parcours Ecoute des communications du kit cyber

Lorsqu’un client et un serveur échangent des messages sans protection, ces derniers circulent en clair.
Cela veut dire que toute autre carte micro:bit réglée sur le même canal peut également recevoir les messages envoyés.
Dans un contexte critique, comme une application bancaire, cela pose problème : si le client envoie son identifiant et que le serveur renvoie son solde, un observateur peut voir passer directement ces informations sensibles.

Une communication en clair signifie que les données envoyées ne sont pas protégées. Toute personne qui capte le signal peut les lire telles qu’elles sont transmises.
C’est exactement ce qui se passe quand un site Internet utilise le protocole HTTP sans chiffrement : les identifiants, mots de passe ou informations personnelles circulent directement sur le réseau, accessibles à quiconque sait écouter.
Avec les micro:bits, la situation est la même : si un message radio contient un identifiant ou un solde, une troisième carte, réglée sur le même canal et groupe, peut les afficher sans aucune difficulté : c’est ce qu’on appelle le sniffing.

Dans un premier temps, la carte malveillante va écouter tous les messages radio, et les afficher dans la console de l’interface Vittascience. De cette manière, dès qu'un message est reçu, son contenu (clé + valeur) sera écrit dans la console.
Ensuite, plutôt que de simplement afficher les données reçues, on va mettre en forme les résultats pour une lecture plus claire. Le programme, lorsqu’il va recevoir des données, va devoir lier l’identifiant de compte à son solde.
Ainsi, la carte malveillante affichera directement les informations importantes, plutôt que toutes les données, qui ne sont pas forcément pertinentes. Pour cela, on va créer deux variables : identifiant et solde. Lorsqu’on reçoit le message de demande de la part du client, on stocke son identifiant dans la variable identifiant, et on fait la même chose avec le solde contenu dans la réponse du serveur. Et comme la réponse du serveur est le dernier message de l’échange, on peut effectuer l’affichage des données lorsque la réponse du serveur est reçue.


Si tu es bloqué :
  • Affiche name et value dans la console pour vérifier que tu vois bien passer les messages demande_solde puis reponse_solde.
  • Pense à mémoriser l’identifiant reçu avec demande_solde, puis à afficher cet identifiant avec le solde reçu quand tu reçois reponse_solde.
  • Tu peux utiliser le bloc Créer le texte pour correctement mettre en forme les résultats sous la forme identifiant : solde

Lance les trois cartes (client, serveur et malveillante) avec la même configuration radio (même canal, groupe et taille de données). Depuis la carte client, envoie plusieurs demandes de solde avec des identifiants différents. Observe la console de la carte malveillante : tu dois voir s’afficher directement, pour chaque échange, le couple identifiant / solde correspondant.

Lorsque les messages sont envoyés sans aucune protection, ils peuvent être lus par n’importe qui disposant du bon canal de communication. Cela montre que la confidentialité n’est pas garantie et que des informations sensibles (comme un identifiant ou un solde bancaire) peuvent être facilement compromises.
Dans un vrai système, ces données pourraient être revendues, utilisées pour se connecter à un compte, ou combinées avec d’autres informations pour mener des attaques plus avancées.
Pour sécuriser réellement les échanges, il faudra mettre en place des mécanismes supplémentaires, comme le chiffrement ou la vérification d’intégrité, afin d’éviter que des tiers puissent lire ou manipuler les données transmises.

Pour aller plus loin : 
  • Chercher les mots-clés « sniffing réseau », « écoute passive » ou « analyseur de paquets » pour voir comment des outils comme Wireshark permettent d’observer les messages qui circulent sur un vrai réseau.
  • Se renseigner sur HTTPS, TLS ou le chiffrement de bout en bout, qui sont entre autres conçus pour empêcher qu’un attaquant puisse lire des données sensibles (mots de passe, identifiants, etc.) même s’il arrive à écouter les échanges.

Licenza d'uso

Licence Creative Commons

Questa risorsa è resa disponibile secondo i termini della Creative Commons Attribution License - Condivisione alle stesse condizioni 2.0 France