Nous avons utilisé Burp Suite pour démontrer une expérience d'énumération des identifiants de sessions créés à l'aide du langage PHP. Le code source a utilisé un mécanisme vulnérable pour créer l'ID de session en attribuant une valeur numérique dans une plage prédéterminée et en la liant au profil de l'utilisateur. Lorsque l'ID de session n'est pas généré aléatoirement, cela rend l'application Web vulnérable aux attaques de piratage de session. Nous avons utilisé les jeux de guerre OverTheWire Natas Level 18 – 19 à des fins de démonstration. . Cela faisait partie de OverTheWire War Games Natas Niveau 18 – 19

Obtenir les notes du certificat OSCP

Notes pratiques de Burp Suite

Mot de passe Natas niveau 19

8LMJEhKFbMKIL2mxQKjv0aEDdk7zpT0s

Transcription vidéo

Que se passe-t-il les gars ? Bienvenue à nouveau dans cette vidéo aujourd'hui. Nous faisons des WarGames par fil.
Et nous allons aborder le niveau 18. Donc la dernière vidéo que nous avons faite, c'était au niveau 17, est-ce qu'ils faisaient le niveau 18 et je vais vous rappeler que la nuit est le niveau ou la nuit a des défis pour la pénétration de nos applications Web. défis de test. Nous nous dirigeons donc vers la remarque 18 après avoir fourni le mot de passe du niveau précédent.

Je verrai un formulaire de connexion. D'accord, nous cliquons sur afficher le code source car il s'agit d'une sorte de test de stylet en boîte blanche. Nous avons accès au code source de l'application. On clique donc sur le code source de The View.
Et la première chose que l’on remarque ici, c’est cette ligne ? Cette ligne définit une variable nommée Max ID, cette variable est égale à 640.
Si nous lisons le code. Cette ligne contient une fonction pour créer un identifiant. Et comme vous pouvez le voir ici, l'ID est généré. Être compris entre 1 et l'ID maximum qui a été défini plus tôt dans le code pour être égal ou égal à 640. Donc faire défiler vers le bas plus tard. On voit ici la fonction chargée de générer la session.

Et voici ce que nous obtenons si nous avons la bonne session, donc fondamentalement, le problème dans ce code réside ici, l'ID de session ou ce numéro est utilisé pour générer l'ID de session. D'accord. Désormais, les identifiants de session si l'attaquant est capable de les deviner, de les générer ou de trouver l'ID de session correct pour l'utilisateur qui s'en occupe.
L'attaquant pourra accéder au profil de l'utilisateur sans avoir besoin de trouver le mot de passe. Nous appelons donc cela le détournement de session. Et quel est le problème ici ? Le problème est que la session est définie ou générée est un nombre généré entre un et six cent quarante.

Cela signifie que la plupart des utilisateurs enregistrés sur ce site Web. D'accord, en tant qu'utilisateurs. D'accord, ces utilisateurs ont un tel identifiant entre un.
Et 640, ce qui signifie que nous sommes capables de deviner quel ID utilisateur appartient à quel utilisateur nous allons pouvoir accéder à n'importe quel profil utilisateur.

C'est donc le problème dans ce code. Désormais, l'alternative sécurisée consiste à générer de manière aléatoire l'ID de session.

Nous ne pouvons pas définir une valeur ou une plage spécifique pour l'ID de session. D'accord. Donc, ce que vous faites ici, nous pouvons résoudre ce défi en utilisant deux méthodes. Nous pouvons soit le faire en utilisant python. Nous créons un script et nous Brute Force l'ID de session de l'utilisateur administrateur. Fondamentalement, nous allons essayer des nombres entre un et six quarante à chaque session pour voir lequel se retrouve avec l'utilisateur administrateur ou nous devrons utiliser burp Suite que je vais utiliser dans cette vidéo car nous en avons fait beaucoup. défis où nous résolvons le défi en utilisant Python aujourd'hui. Nous allons utiliser du bonbon violet. Revenons en arrière et ouvrons Burp Suite. Jetons d'abord un coup d'œil à la demande, disons donc que nous démarrons admin admin.

Maintenant, simulons une demande de connexion en utilisant le nom d'utilisateur admin et le mot de passe admin.
Nous pouvons maintenant intercepter la réponse car nous voulons voir le cookie attribué.

Jetons un coup d'oeil ici. Comme vous pouvez le voir les gars dans la réponse. Nous voyons que l'ID de session est défini sur 498.
D'accord. Maintenant, ce que nous allons faire, c'est prendre ceci et l'envoyer à l'intrus. D'accord, alors maintenant nous allons avancer et maintenant nous allons à nouveau définir l'interception ou revenir à la demande d'interception. Donc actualiser.

Alors maintenant, simulons la requête une fois de plus. Très bien, c'est donc à nouveau la demande et remarquez ici que la demande est une demande de réception.
Et une autre chose à noter ici est l'ID de session. Nous allons donc le faire ici. Nous voulons maintenant forcer brutalement l'ID de session et trouver le numéro correct lié au compte administrateur. D'accord, nous voulons donc envoyer ceci à l'intrus avant de faire cela. Nous devons supprimer cela d'une manière ou d'une autre, nous devons supprimer cette ligne.
Nous souhaitons uniquement conserver l'identifiant de session. Et puis il est prêt à être envoyé à l'intrus.

Poursuivre. Il définirait les positions de la charge utile à libérer et fixerait la position. De zéro. Nous mettons donc ici en surbrillance l’ID de session et nous cliquons sur AJOUTER. Et maintenant, l'ID de session est mis en surbrillance, puis nous définissons le type de charge utile. Nous définissons donc le type de deux nombres et ici nous définissons la séquence. Nous allons donc commencer à partir de zéro et aller jusqu'à atteindre 1 000. Vous pouvez définir plus mais ne définissez pas moins de 700 environ.

140 et puis nous partons à l'attaque. Très bien, maintenant que cela a commencé.
Comme vous pouvez le voir ici, toutes les demandes ont une longueur de réponse similaire. Jetez un oeil ici. La plupart d'entre eux sont 608 608 607 désolé 67 et donc 67 se termine par 68. Nous allons donc chercher une réponse qui est en quelque sorte très différente en taille, comme très éloignée de cette longueur.

Pour que nous sachions que nous avons une réponse différente à cette demande. Nous examinons la demande et nous prenons note de l'ID de session et nous allons l'essayer. Attendons maintenant.
D'accord, donc l'intrus a terminé et ici j'ai trouvé que l'ID était 119 qui a généré la réponse au risque différente. Nous allons donc le mettre comme nouvel identifiant de session et nous allons dire forward.
Je vérifie le navigateur et comme vous pouvez le voir les gars, c'est le salaud pour le niveau suivant. Ainsi, l'ID du bon idéal était 119.

Vidéo pas à pas

A propos de l'Auteur

Je crée des notes de cybersécurité, des notes de marketing numérique et des cours en ligne. Je fournis également des conseils en marketing numérique, y compris, mais sans s'y limiter, le référencement, les publicités Google et Meta et l'administration CRM.

Voir les Articles