Stack Shellcode
Informations de base
Le shellcode de la pile est une technique utilisée dans l'exploitation binaire où un attaquant écrit un shellcode dans la pile d'un programme vulnérable, puis modifie le Pointeur d'Instruction (IP) ou le Pointeur d'Instruction Étendu (EIP) pour pointer vers l'emplacement de ce shellcode, le forçant à s'exécuter. Il s'agit d'une méthode classique utilisée pour obtenir un accès non autorisé ou exécuter des commandes arbitraires sur un système cible. Voici une explication du processus, y compris un exemple simple en C et comment vous pourriez écrire une exploitation correspondante en utilisant Python avec pwntools.
Exemple en C : Un programme vulnérable
Commençons par un exemple simple d'un programme C vulnérable :
Ce programme est vulnérable à un dépassement de tampon en raison de l'utilisation de la fonction gets()
.
Compilation
Pour compiler ce programme en désactivant diverses protections (pour simuler un environnement vulnérable), vous pouvez utiliser la commande suivante :
-fno-stack-protector
: Désactive la protection de la pile.-z execstack
: Rend la pile exécutable, ce qui est nécessaire pour exécuter le shellcode stocké sur la pile.-no-pie
: Désactive l'exécutable indépendant de la position, facilitant la prédiction de l'adresse mémoire où notre shellcode sera situé.-m32
: Compile le programme en tant qu'exécutable 32 bits, souvent utilisé pour simplifier le développement de l'exploit.
Exploit Python utilisant Pwntools
Voici comment vous pourriez écrire un exploit en Python en utilisant pwntools pour effectuer une attaque ret2shellcode:
Ce script construit une charge utile composée d'un glissement NOP, du shellcode, puis écrase l'EIP avec l'adresse pointant vers le glissement NOP, garantissant l'exécution du shellcode.
Le glissement NOP (asm('nop')
) est utilisé pour augmenter les chances que l'exécution "glisse" vers notre shellcode indépendamment de l'adresse exacte. Ajustez l'argument p32()
à l'adresse de départ de votre tampon plus un décalage pour atterrir dans le glissement NOP.
Protections
ASLR devrait être désactivé pour que l'adresse soit fiable à travers les exécutions, sinon l'adresse où la fonction sera stockée ne sera pas toujours la même et vous auriez besoin d'une fuite pour savoir où la fonction gagnante est chargée.
Les Canaris de la pile devraient également être désactivés, sinon l'adresse de retour EIP compromise ne sera jamais suivie.
NX La protection de la pile empêcherait l'exécution du shellcode à l'intérieur de la pile car cette région ne serait pas exécutable.
Autres exemples et références
64 bits, ASLR avec fuite d'adresse de pile, écrire du shellcode et sauter dedans
32 bits, ASLR avec fuite de pile, écrire du shellcode et sauter dedans
32 bits, ASLR avec fuite de pile, comparaison pour éviter l'appel à exit(), écraser une variable avec une valeur, écrire du shellcode et sauter dedans
Last updated