MSMQ-Schwachstellen Proof of Concept

Dieses Repository enthält einen sofort ausführbaren Proof of Concept, der auf Microsoft Message Queuing abzielt, das auf TCP-Port 1801 horcht. Diese Arbeit basiert auf und verwendet Materialien aus dem ursprünglichen Projekt unter
https://github.com/leongxudong/MSMQ-Vulnerability

Dieses Repository verwendet die von diesem Projekt bereitgestellten binären Artefakte. Die im PoC enthaltenen und referenzierten Binärdateien sind:

1. establish_connection.bin
2. connection_parameters.bin
3. user_message.bin

Beschreibung

Dieser PoC versucht, die in CVE 2023 21554 beschriebene Bedingung zu reproduzieren, indem eine Sequenz von MSMQ-Protokollrahmen an einen Zielhost auf Port 1801 gesendet wird. Die PoC-Skripte führen ausschließlich netzwerkschichtige Aktivitäten durch und führen keine Post-Exploitation-Aktionen aus. Dieses Projekt ist ausschließlich für die Analyse und defensive Überprüfung in einer isolierten Laborumgebung vorgesehen.

Enthaltene Dateien

1. CVE-2023-21554.py — ursprüngliches PoC-Skript, das die drei binären Blobs sequentiell sendet
2. CVE-2023-21554.py — Helfer-Skript auf Angreiferseite, das Antworten, Hexdumps, Zeitstempel und Socket-Fehler protokolliert. Verwenden Sie dieses Skript, um aussagekräftigere Beweise auf Angreiferseite zu erhalten
3. establish_connection.bin — binäre Stufe-eins-Nutzlast aus dem ursprünglichen Repository
4. connection_parameters.bin — binäre Stufe-zwei-Nutzlast aus dem ursprünglichen Repository
5. user_message.bin — binäre Stufe-drei-Nutzlast aus dem ursprünglichen Repository
6. README.md — diese Datei

Voraussetzungen

1. Python 3 auf dem Angreifer-Host installiert
2. Netzwerkzugriff auf den Zielhost-Port 1801 und ausdrückliche Erlaubnis, diesen Host zu testen
3. Ein Snapshot der Ziel-VM, um Änderungen nach dem Test rückgängig machen zu können
4. Werkzeuge zur Aufzeichnung von Beweisen für die Überprüfung (z. B. Wireshark oder tcpdump) und Sysinternals procdump für Windows

So führen Sie den PoC in einer Laborumgebung aus

1. Platzieren Sie die drei Binärdateien im selben Ordner wie das PoC-Skript

2. Bearbeiten Sie das PoC-Skript oder CVE-2023-21554.py, um die Ziel-IP-Adresse festzulegen

3. Starten Sie eine Netzwerkerfassung auf Ihrem Angreiferrechner für die Ziel-IP und den Zielport. Beispielbefehl in einer separaten Shell (ersetzen Sie die IP durch Ihr Ziel):

   sudo tcpdump -i eth0 host 10.0.2.15 and port 1801 -w msmq_test.pcap

4. Führen Sie das erweiterte Prüfskript aus, um mit Zeitstempeln versehene Protokolle und Hexdumps zu erhalten

   python3 CVE-2023-21554.py

5. Speichern Sie die PoC-Ausgabe und die Netzwerkerfassungsdatei zur Analyse

Woran erkennt man, ob der PoC funktioniert hat

1. Indikatoren auf Angreiferseite

1. Das CVE-2023-21554.py meldet connection_reset oder orderly_close unmittelbar nach einer Nutzlaststufe (dies sind explizite Statusmeldungen, die vom Helfer ausgegeben werden).
2. Der PoC erhält eine nicht-triviale Antwort vom Ziel (kleine, ungewöhnliche Antwortbytes). Speichern Sie diese Antwort und erstellen Sie einen Hexdump zum Vergleich.
3. Die Netzwerkerfassung zeigt einen TCP-Reset (RST) oder einen anderen abnormalen Abbruch unmittelbar nach den Exploit-Paketen.

2. Indikatoren auf Zielseite

1. Der Message Queuing-Dienstprozess mqsvc.exe stürzt ab oder startet zum Zeitpunkt des Tests neu.
2. Die Windows-Ereignisanzeige enthält Anwendungs- oder Systemereignisse, die auf eine Zugriffsverletzung oder eine fehlerhafte Anwendung namens mqsvc.exe hinweisen.
3. Ein zum Zeitpunkt des Tests erfasster procdump zeigt eine Ausnahme im Prozess mqsvc.

Praktische Wireshark-Schritte und Filter (Copy-Paste-ready)

Ersetzen Sie <TARGET> durch Ihre Ziel-IP für jeden Filter.

Gesamten Verkehr zwischen Angreifer und Ziel auf dem MSMQ-Port anzeigen: ip.addr == <TARGET> && tcp.port == 1801

Nur vom Server stammende TCP-RSTs anzeigen: ip.src == <TARGET> && tcp.port == 1801 && tcp.flags.reset == 1

Pakete mit Anwendungsdaten (nicht-leere TCP-Nutzlasten) anzeigen: ip.addr == <TARGET> && tcp.port == 1801 && tcp.len > 0

Segmente mit Länge null oder FINs anzeigen: `ip.addr == && tcp.port == 1801 && (tcp.len == 0 || tcp.flags.fin == 1)

Wiederholungsübertragungen und TCP-Anomalien anzeigen: tcp.analysis.retransmission || tcp.analysis.fast_retransmission || tcp.analysis.duplicate_ack

Schritte zum Extrahieren der Server-Antwortbytes (roher Hexdump)

1. Suchen Sie das betreffende Serverpaket im Paketlistenbereich. Achten Sie auf kleine tcp.len-Werte oder das Paket unmittelbar vor einem RST.
2. Rechtsklick auf das Paket → Follow → TCP Stream.
3. Wählen Sie im Dialog "Follow TCP Stream" Show data as: Raw und dann Save As, um die genauen Bytes zu exportieren.
4. Alternativ können Sie das Paket auswählen und Bytes aus dem Bereich Packet Bytes kopieren. Speichern Sie die rohen Bytes/den Hexdump als Beweismaterial (z. B. server_reply.hex).

Woran erkennt man, ob der Reset vom Ziel oder von einer Middlebox stammt

1. Überprüfen Sie, ob die Quell-IP des RST mit dem Ziel übereinstimmt. Wenn dies der Fall ist, deutet dies stark darauf hin, dass der Zielhost oder sein Kernel den Socket geschlossen hat.
2. Wenn die RST-Quelle ein anderes Gerät auf dem Pfad ist, deutet dies in der Regel darauf hin, dass stattdessen eine Middlebox oder Firewall die Verbindung abgeworfen hat. TTL-Unterschiede und Schnittstellen-IPs können bei der Diagnose helfen.

Zeitkorrelation (wichtig)

1. Notieren Sie die Zeitstempeldifferenz zwischen dem Exploit-Paket und der Serverreaktion. Abstürze oder abrupte RSTs treten typischerweise innerhalb von Zehntel- bis Hundertstelsekunden nach dem angreifenden Paket auf. Zeichnen Sie diese Zeiten als Teil Ihrer Beweise auf.

Vergleichstest

1. Erfassen Sie dieselbe Sequenz gegen einen bekanntermaßen gepatchten Host und vergleichen Sie das Vorhandensein oder Fehlen von RST, FIN oder kurzen Serverantworten. Unterschiede stärken Ihre Schlussfolgerung.

Checkliste zur Beweissammlung

1. Speichern Sie das vollständige stdout-Protokoll von CVE-2023-21554.py in einer Textdatei
2. Speichern Sie die Netzwerkerfassungsdatei (z. B. msmq_test.pcap)
3. Exportieren Sie aus der Ereignisanzeige die Anwendungs- und Systemereignisse, die dem Testzeitpunkt entsprechen
4. Erfassen Sie, falls verfügbar, einen Absturzabbild von mqsvc.exe mit procdump und speichern Sie ihn zur Analyse

Sicherheits- und Rechtshinweis

Dieser Code kann zu Dienstabstürzen und Instabilität auf Zielhosts führen. Führen Sie ihn nicht gegen Systeme aus, die Ihnen nicht gehören oder für die Sie keine ausdrückliche Erlaubnis zum Testen haben. Testen Sie immer in einer isolierten Laborumgebung und erstellen Sie vor dem Test einen VM-Snapshot. Die ursprüngliche Arbeit wird dem Upstream-Projekt zugeschrieben unter:
https://github.com/leongxudong/MSMQ-Vulnerability

Namensnennung

Dieses Repository ist vom ursprünglichen Projekt abgeleitet unter:
https://github.com/leongxudong/MSMQ-Vulnerability

Beitrag

Wenn Sie Erkennungshilfen oder Skripte zur Beweissammlung hinzufügen, dokumentieren Sie diese bitte und fügen Sie Anweisungen für die sichere Nutzung im Labor bei

Kontakt und weiterführende Literatur

Beziehen Sie sich für den ursprünglichen Kontext und binäre Artefakte auf das Upstream-Repository unter dem obigen Link. Für defensive Leitlinien konsultieren Sie die Herstellerhinweise und veröffentlichte Analysen zu CVE 2023 21554