Dans vulnerable.c, le programme fait ceci :

Le programme réserve 32 octets pour buffer, puis appelle gets() pour lire l'entrée. Le problème : gets() ne vérifie pas la taille du tampon. Il continue à lire des caractères jusqu'à rencontrer un saut de ligne. Si l'utilisateur tape 40 ou 50 caractères, les caractères supplémentaires débordent au-delà du tampon de 32 octets.

Comment la mémoire est disposée sur la pile

Lorsqu'une fonction C s'exécute, la pile (une région mémoire) stocke :

1. Les variables locales (comme buffer)
2. Le EBP sauvegardé (pointeur de base de la fonction appelante)
3. L'adresse de retour sauvegardée (où le CPU doit sauter lorsque la fonction retourne)

Représentez-le ainsi :

Lorsque gets() fait déborder buffer avec trop d'entrées, les octets supplémentaires écrasent le EBP sauvegardé puis l'adresse de retour.

Si nous concevons soigneusement le débordement pour placer une adresse spécifique dans le champ de l'adresse de retour, le CPU sautera vers cette adresse lorsque la fonction tentera de retourner.

Comment fonctionne l'exploit : étape par étape

1. Le programme démarre et alloue buffer[32] sur la pile.
2. Il appelle gets(buffer) pour lire une ligne d'entrée utilisateur.
3. Nous envoyons une chaîne plus longue que 32 octets (disons 50 octets).
4. gets() n'a pas de vérification de taille, donc il écrit les 50 octets dans le tampon.
5. Les 18 octets supplémentaires débordent au-delà de buffer et écrasent le EBP sauvegardé et l'adresse de retour.
6. Nous construisons soigneusement le débordement pour que l'adresse de retour pointe vers le shellcode sur la pile.
7. Lorsque la fonction retourne, le CPU lit l'adresse de retour écrasée.
8. Le CPU saute vers le shellcode.
9. Le shellcode s'exécute avec les permissions du programme.

C'est la forme la plus simple d'exécution de code via un débordement de tampon.

Ce qui se passe dans le shellcode : la charge utile

messageBox.asm est un petit morceau de code conçu pour s'exécuter après le débordement.

Il fait ce qui suit :

1. Charger USER32.DLL : Appelle LoadLibraryA avec la chaîne "USER32.DLL" pour s'assurer que la bibliothèque est en mémoire.
2. Préparer les arguments pour MessageBoxA : Pousse quatre arguments sur la pile (handle de fenêtre, texte du message, légende, type de bouton).
3. Appeler MessageBoxA : Appelle la fonction API Windows pour afficher une boîte de message avec le texte "CAN I HACK THE PC?".
4. Quitter proprement : Appelle ExitProcess pour terminer le programme en toute sécurité.

Le point clé : il s'agit de code exécutable qui s'exécute après que le débordement a redirigé l'exécution vers lui. Lorsque la boîte de message apparaît à l'écran, cela prouve trois choses :

1. Le débordement de tampon a fonctionné et a réécrit l'adresse de retour.
2. L'exécution a sauté vers le shellcode sur la pile.
3. Le shellcode s'est exécuté avec succès et a effectué des appels API Windows.

Dans une attaque réelle, cette charge utile pourrait faire n'importe quoi : voler des données, créer un utilisateur, télécharger un logiciel malveillant, etc. La boîte de message n'est qu'un moyen visible et sûr de démontrer qu'une exécution de code arbitraire a eu lieu.

Cette charge utile spécifique utilise des adresses mémoire codées en dur pour MessageBoxA (0x751D8830) et ExitProcess (0x7437ADB0). Ces adresses sont spécifiques à un système. La charge utile devrait être ajustée pour une version ou un système Windows différent.

Comment construire et exécuter la démo

Étape 1 : Désactiver les protections

Windows moderne dispose de multiples fonctionnalités de sécurité qui empêchent cet exploit :

• Stack Canaries (drapeau GS) : détecte les écrasements de pile.
• ASLR (DYNAMICBASE) : randomise les adresses mémoire afin que les adresses codées en dur ne fonctionnent pas.
• DEP/NX (NXCOMPAT) : marque la pile comme non exécutable pour empêcher l'exécution de code.

Pour cet exercice d'apprentissage, nous désactivons toutes ces protections.

Étape 2 : Compiler sous Windows

Utilisez MSVC (Microsoft Visual C++) avec des indicateurs spécifiques :

Signification des indicateurs :

• /GS- désactive la protection contre les dépassements de tampon de pile.
• /DYNAMICBASE:NO désactive la randomisation de la disposition de l'espace d'adressage (ASLR).
• /NXCOMPAT:NO désactive DEP, permettant au code sur la pile de s'exécuter.

Si vous avez déjà l'exécutable, vous pouvez désactiver les protections avec editbin :

Étape 3 : Exécutez-le

1. Lancez vulnerable.exe.
2. Lorsque vous y êtes invité, entrez une longue chaîne (plus de 32 caractères).
3. Si le débordement fonctionne, l'adresse de retour sauvegardée est écrasée.
4. Le programme peut planter, sauter vers une mémoire aléatoire, ou (dans un véritable exploit avec un shellcode approprié) exécuter la charge utile.

Pourquoi le README est complet

Ce README explique :

1. Ce qu'est gets() et pourquoi il est dangereux (pas de limite de taille).
2. Comment la pile stocke les variables locales, les registres sauvegardés et les adresses de retour.
3. Comment un débordement peut écraser l'adresse de retour.
4. Comment le CPU utilise l'adresse de retour lorsqu'une fonction retourne.
5. Comment le shellcode peut s'exécuter lorsque l'adresse de retour pointe vers lui.
6. Quelles protections existent et pourquoi nous les désactivons.
7. Comment construire et exécuter l'exemple.

Vous comprenez maintenant l'ensemble du flux d'exploitation par débordement de tampon. Lisez les fichiers de code et comparez-les à cette explication pour consolider votre compréhension.

Avis de sécurité important

Cet exemple est uniquement destiné à l'apprentissage. N'utilisez pas cette technique contre des systèmes que vous ne possédez pas ou pour lesquels vous n'avez pas l'autorisation explicite de tester. L'accès non autorisé à des systèmes informatiques est illégal.