
Débordement de tampon basé sur la pile dans MiniShare 1.4.1 accessible via une seule requête HTTP PUT.
Débordement de tampon basé sur la pile dans MiniShare 1.4.1, atteignable via une seule requête HTTP PUT.
Ce dépôt fait partie du matériel que j'utilise pour enseigner l'exploitation des corruptions mémoire (en plus de mon travail habituel, j'enseigne également dans différents cours de cybersécurité où je contribue à former la prochaine génération d'ingénieurs en rétro-ingénierie).
CVE-2020-13768 est un cas que j'utilise lorsque je veux montrer comment de simples serveurs exposés sur le réseau peuvent présenter des débordements de tampon classiques basés sur la pile via des méthodes de protocole standard. Le point de terminaison vulnérable ne requiert aucune authentification, le débordement est un écrasement direct de l'EIP, et le chemin d'exploitation est propre et bien défini. C'est un cas idéal pour apprendre la méthodologie complète d'exploitation dans un scénario réaliste à distance sans authentification.
Ce qui rend également ce cas intéressant comme exercice pédagogique, c'est que la même cause racine, une entrée non assainie copiée dans un tampon de pile de taille fixe, apparaît dans plusieurs entrées CVE concernant le même binaire. CVE-2018-19861, CVE-2018-19862 et CVE-2019-17601 décrivent tous la même classe de vulnérabilité, simplement signalée par différents chercheurs via différentes méthodes HTTP ou différents points de terminaison. Cela apprend aux étudiants à examiner les causes racines plutôt que de simples numéros de CVE.
Cette vulnérabilité affecte MiniShare 1.4.1, un serveur HTTP Windows léger et abandonné, conçu pour le partage de fichiers local simple. Le logiciel a été écrit sans tenir compte des pratiques de sécurité modernes. Ce qui rend ce cas particulièrement intéressant d'un point de vue pédagogique, c'est la combinaison de facteurs impliqués :
Cette combinaison fait de CVE-2020-13768 un excellent cas pour enseigner les fondamentaux de l'exploitation des débordements de tampon via le réseau dans un scénario réaliste sans authentification.
MiniShare est un serveur HTTP Windows minimal, conçu à l'origine pour le partage de fichiers local rapide sur un réseau local (LAN). Il écoute sur le port TCP 80 et prend en charge un petit sous-ensemble de méthodes HTTP, notamment GET et PUT. Le gestionnaire PUT traite les requêtes entrantes et copie le chemin de l'URI dans un tampon de pile de taille fixe sans valider sa longueur.
Détails techniques clés :
MiniShare traite les requêtes HTTP entrantes et les achemine vers le gestionnaire approprié en fonction de la méthode. Le gestionnaire PUT extrait le chemin de l'URI de la requête et le copie dans un tampon de pile de taille fixe sans vérifier sa longueur.
Une version simplifiée de la logique vulnérable ressemble à ceci :
char path_buffer[256];
strcpy(path_buffer, uri_path);
Étant donné que le tampon de destination a une taille fixe et que la longueur de l'entrée n'est pas validée, l'envoi d'un URI suffisamment long dans la requête PUT fait écrire la copie au-delà de la fin du tampon, atteignant finalement et écrasant l'adresse de retour sauvegardée (EIP) sur la pile.
Lorsque la fonction vulnérable effectue un retour, le CPU charge la valeur contrôlée par l'attaquant depuis la pile dans l'EIP et y saute. Si cette adresse pointe vers des données contrôlées par l'attaquant contenant du shellcode, l'exécution de code arbitraire est obtenue.
Le crash peut être reproduit en envoyant un URI surdimensionné dans une requête HTTP PUT. Aucune authentification n'est requise. Exemple utilisant Python :
import socket
HOST = '127.0.0.1'
PORT = 80
payload = b"A" * 3000
request = (
b"PUT /" + payload + b" HTTP/1.1\r\n"
b"Host: 127.0.0.1\r\n"
b"Connection: close\r\n"
b"\r\n"
)
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((HOST, PORT))
s.send(request)
s.close()
Lorsqu'il est exécuté sous un débogueur, le crash montre l'EIP écrasé par des données contrôlées par l'utilisateur :
EIP = 41414141
confirmant que l'adresse de retour sauvegardée a été corrompue par le débordement.
L'objectif de ce dépôt n'est pas seulement de démontrer le crash, mais aussi de parcourir pas à pas l'ensemble du processus d'exploitation, en suivant la méthodologie utilisée lors du développement de véritables exploits basés sur la pile.
Pour garder le README principal épuré, les notes d'exploitation détaillées, les scripts et les étapes de débogage sont placés dans le dossier Vulnerability 📂 de ce dépôt.
Vous y trouverez le flux de travail complet utilisé pour exploiter cette CVE, notamment :