Trier et décoder les trames récoltées

Apprendre à trier les trames Wireshark

Une fois cela fait, les trames dont nous avons besoin ont dû être capturées, il faut donc maintenant se rendre sur Wireshark et arrêter l’acquisition.

L’analyse de trames peut donc commencer. Pour rappel, voici les étapes d’une négociation ternaire :

Analyse des paquets

La première étape de connexion TCP dans nos captures est donc la suivante (surligné) :

La deuxième correspond à l’accord où l’on voit bien [SYN=1 ACK= 1 N°ACK = 1] :

Et enfin la troisième qui confirme la connexion avec [ACK= 1 N°ACK = 1 N°SEQ= 1] :

Maintenant que les 3 trames de connexions TCP sont identifiées, ce qui vient par la suite est le formulaire HTML.

Sur cette trame il est clairement identifiable car le protocole utilisé est le http réclamant (GET) la page ‘/ppe/login.php’ du serveur.

Les informations du serveur source vont donc passer en clair dans cette trame, et Wireshark nous le donne directement !

Cette trame nous indique le navigateur utilisé, sa version, les langues du navigateur et d’autres paramètres relatifs au serveur, ce n’est pas ce que nous recherchons.

Paquets côté client

À la suite de ces trames, après un acquittement le serveur nous renvois directement le code source de la page…

Et on répond aussi par un acquittement pour confirmer la réception.

Voici les informations que Wireshark nous renvoi :

Nous avons ici accès à tout le code source de la page, nous pouvons y voir les boutons du formulaire, le texte…

Une fois ceci fait, il y à donc demande de déconnexion (surligné), un acquittement pour la déconnexion (sous le noir) puis une confirmation de déconnexion juste en dessous (avec FIN=1 & ACK=1).

Par la suite, après avoir été renvoyé sur l’autre page (celle rappelant nos identifiants) grâce à un acquittement, nous avons dans une seconde trame HTTP de type POST cette fois ci, nos identifiants en clair (puis on acquitte de la réception).

Dans cette trame, ce qui nous intéresse le plus se trouve à la fin :

Nous pouvons voir ici les identifiants que nous avons envoyés au serveur, c’est-à-dire notre login (thomas) et notre mot de passe (1234).

Paquets côté serveur

Ceci dis, cela provenais des informations transmises entre le client et le serveur, et non pas du serveur au client, ce qui pourrait être plus intéressent pour tester la sécurité du serveur (s’il est crypté par exemple ou si le certificat est efficace), la trame de renvoi du serveur se trouve donc juste après…

Venant du serveur (192.168.1.75) au client (192.168.1.64)

Et que contient cette trame ?

Nos identifiants en clair, encore une fois !

Cela prouve donc qu’il n’y a aucune sécurité entre les transmissions que ce soit d’un côté ou de l’autre.

Une fois que nous quittons le serveur non-sécurisé, nous retrouvons de nouveau les étapes d’une déconnexion comme ceux que nous avons vus précédemment pour le serveur HTTP :

Et voilà, en quelque trames il nous a été possible de trouver toutes les informations qui passait entre nous et le serveur, que ce soit les demandes de connexion ternaires ou nos propres identifiants, tout a été identifié et trouvé en clair grâce à Wireshark !