CVE-2025-53770 Forschungslabor

Dieses Repository scheint ein Proof-of-Concept-Forschungsprojekt zur Validierung eines SharePoint-ähnlichen Deserialisierungs- und ToolPane-Verarbeitungsproblems in einer kontrollierten Laborumgebung zu sein. Es enthält einen Python-Treiber, eine scheinbar angreifbare Anwendung und Container-Assets für isolierte Tests.

[!WARNING] Dieses Projekt darf nur auf Systemen, Containern oder Netzwerken verwendet werden, die Ihnen gehören oder für die Sie ausdrücklich zur Durchführung von Tests autorisiert sind. Führen Sie diesen Code nicht gegen öffentliche Infrastruktur, Dienste Dritter, Produktionsumgebungen oder ein Ziel ohne schriftliche Genehmigung aus. Unautorisierte Sicherheitstests können gegen Gesetze, Verträge, Richtlinien oder Nutzungsbedingungen verstoßen.

Der Inhalt dieses Repositories sollte als sensibles Sicherheitsforschungsmaterial behandelt werden. Wenn Sie dieses Projekt für Bewertungsarbeiten verwenden, halten Sie die Ausführung isoliert, protokollieren Sie alle Aktivitäten und stimmen Sie sich vor dem Testen mit dem Systembesitzer ab.

Projektumfang

Das Repository enthält derzeit:

• sploit.py: asynchroner Python-Treiber, der manipulierte Anfragen an einen ToolPane-Endpunkt sendet.
• lab/mock_vulnerable_app.cs: scheinbare ASP.NET-Anwendung, die einen Validierungsmarker zurückgibt und in ihrer aktuellen Form einen übergebenen Befehl im Labor-Container ausführen kann.
• lab/docker-compose.yml: lokales Zwei-Container-Labor, das das scheinbare Ziel vom Angreiferterminal trennt.
• lab/Dockerfile: mehrstufiger .NET-Build, der die scheinbar angreifbare Anwendung in ein kleineres ASP.NET-Laufzeitimage veröffentlicht und als Nicht-Root-Benutzer ausführt.
• lab/attacker.Dockerfile: Python-Angreifer-Containerdefinition, die die für das Laborterminal benötigten Skriptabhängigkeiten vorinstalliert.
• lab/vulnerable.csproj: .NET 6 Web-Projektdatei für die scheinbar angreifbare Anwendung.
• lab/genGadget.py: Hilfsskript zum Generieren einer komprimierten Base64-Nutzlast für Deserialisierungstests nur im Labor.

Einrichtung und Verwendung

Dieser Workflow ist nur für das lokale Labor vorgesehen.

Voraussetzungen:

• Docker Engine mit Compose-Unterstützung
• Eine lokale Shell mit Berechtigung zum Ausführen von Docker-Befehlen

Starten Sie das Labor aus dem Verzeichnis lab/:

cd lab
docker-compose up --build -d

Wenn Ihre Docker-Einrichtung erhöhte Rechte erfordert, führen Sie die gleichen Befehle mit sudo aus.

Bestätigen Sie, dass beide Container laufen:

docker-compose ps

Protokollierung für den Fall von Problemen oder Exploit-Validierung:

docker logs sp_attacker
docker logs sp_vulnerable_lab

Das Labor ist bewusst isoliert:

• Der Zielcontainer läuft im internen lab_net-Netzwerk;
• Es werden keine Ports auf dem Host veröffentlicht;
• Der Angreifercontainer wird als wegwerfbares Terminal im selben privaten Netzwerk bereitgestellt.

Öffnen Sie eine Shell im Angreifercontainer:

docker exec -it sp_attacker bash

Im Angreifercontainer können Sie laborsichere Überprüfungen durchführen, wie z.B. die Erreichbarkeit des Ziels bestätigen und das Skript im Überprüfungsmodus gegen das scheinbare Ziel testen:

python3 sploit.py http://sp_vulnerable_lab/
# Falls die DNS-Auflösung des Dienstnamens in Ihrer Umgebung fehlschlägt, verwenden Sie die Labor-IP:
# python3 sploit.py http://10.10.10.5
# Falls Sie über die Basisvalidierung hinausgehen möchten, können Sie gewünschte Befehle angeben.
python3 sploit.py http://sp_vulnerable_lab whoami

Erwartetes Verhalten in der lokalen scheinbaren Umgebung:

• Das Ziel sollte vom Angreifercontainer aus als http://sharepoint-target erreichbar sein;
• Die scheinbare Anwendung gibt einen deterministischen Marker zur Überprüfung zurück;
• Alle vom Skript erzeugten Ergebnisartefakte verbleiben im eingehängten Laborarbeitsbereich.

Betriebshinweise:

• Halten Sie das Labor von externen Netzwerken getrennt und veröffentlichen Sie den Zieldienst nicht auf dem Host;
• Verwenden Sie diese Umgebung nicht für Produktionsbewertungen;
• Wenn Sie die scheinbare Anwendung oder Containerdefinitionen ändern, erstellen Sie die Images vor einem erneuten Test neu.

Bereinigung

Stoppen und entfernen Sie die Labor-Container und das Netzwerk:

cd lab
docker-compose down

Wenn Sie auch die erstellten Images entfernen möchten:

docker-compose down --rmi local

Wenn Sie die Arbeitsbereichsartefakte des Labors vollständig zurücksetzen möchten, entfernen Sie nach dem Herunterfahren alle generierten Ergebnisdateien:

rm -f vuln.lst

Empfohlene Bereinigungspraxis nach jeder Übung:

1. Fahren Sie das Labor mit docker-compose down herunter;
2. Entfernen Sie Ergebnisartefakte, die nicht bestehen bleiben sollen;
3. Erstellen Sie das Labor vor dem nächsten Durchlauf neu, wenn Sie Code, Abhängigkeiten oder Containereinstellungen geändert haben.

Validierungszusammenfassung

Das Projekt ist als lokales Forschungslabor strukturell gültig, sollte aber in seiner aktuellen Form nicht als produktionssicherer Validator behandelt werden.

Was funktioniert:

• Die Labortopologie ist einfach und reproduzierbar.
• Der Python-Treiber kann ein Ziel oder eine Liste von Zielen testen.
• Die scheinbare Anwendung liefert deterministische Erfolgsindikatoren für die Laborvalidierung.

Was Vorsicht erfordert:

• Das Hauptskript enthält explizites Befehlsausführungsverhalten, wenn ein zweites Argument angegeben wird.
• TLS-Überprüfung ist bei ausgehenden Anfragen deaktiviert.
• Positive Ergebnisse werden in vuln.lst geschrieben, was unnötige sensible Restdaten erzeugen kann.
• Die scheinbare Anwendung führt Shell-Eingaben direkt aus und sollte niemals außerhalb eines isolierten Labors exponiert werden.

Methodik

Verwenden Sie dieses Projekt nur für kontrollierte Validierung von Erkennung und Exposition, nicht für operative Ausnutzung.

Empfohlene Methodik:

1. Erstellen Sie eine isolierte Laborumgebung ohne externe Exposition.
2. Validieren Sie Netzwerkgrenzen, sodass nur der Forscher den scheinbaren Dienst erreichen kann.
3. Starten Sie das Laborziel und bestätigen Sie, dass die Anwendung auf den vorgesehenen Endpunkt antwortet.
4. Verwenden Sie den Treiber nur im nicht-destruktiven Überprüfungsmodus, um zu bestätigen, ob das Ziel den erwarteten Marker zurückgibt.
5. Erfassen Sie Anforderungs- und Antwortartefakte zur Dokumentation und zerstören Sie die Laborumgebung nach dem Test.

Für reale Bewertungsarbeiten ist der sicherere Standard, die Exploit-artige Validierung durch eine oder mehrere der folgenden Maßnahmen zu ersetzen:

• Version- und Patch-Level-Überprüfung;
• Authentifizierte Konfigurationsüberprüfung;
• Log-Analyse auf Webebene;
• EDR-, SIEM- und WAF-Telemetrie-Überprüfung;
• Vom Anbieter bereitgestellte Kompromittierungsindikatoren und Gesundheitschecks.

Auswirkungen

Wenn ein Ziel tatsächlich anfällig für einen Deserialisierungsfehler in einer privilegierten Anwendungskomponente ist, können die potenziellen Auswirkungen schwerwiegend sein:

• Remote-Codeausführung im Sicherheitskontext des betroffenen Dienstes;
• Vertraulichkeitsverlust für Anwendungsdaten, Anmeldeinformationen und Geheimnisse;
• Integritätsverlust durch Inhalts- oder Konfigurationsmanipulation;
• Verfügbarkeitsverschlechterung durch destruktive Befehle oder Folgemaßnahmen;
• Laterale Bewegungsmöglichkeiten, wenn der Host umfassende Netzwerk- oder Identitätsprivilegien besitzt.

Selbst in einem Labor erhöhen Befehlsausführungssemantiken das Risiko erheblich, da sie Arbeitsabläufe normalisieren, die streng kontrollierten, autorisierten Untersuchungen vorbehalten sein sollten.

Gegenmaßnahmen

Der richtige Abhilfepfad ist defensiv und mehrschichtig.

Sofortmaßnahmen:

1. Wenden Sie Sicherheitsupdates und Notfallanleitungen des Anbieters für die betroffene Produktversion an.
2. Entfernen Sie die öffentliche Exposition oder schränken Sie den Zugriff auf die angreifbare Anwendungsoberfläche ein.
3. Setzen Sie Anmeldeinformationen zurück und überprüfen Sie privilegierte Dienstkonten, wenn ein Kompromittierungsverdacht besteht.
4. Überprüfen Sie Protokolle, geplante Aufgaben, Kindprozesse und ausgehende Verbindungen auf Aktivitäten nach der Ausnutzung.
5. Bewahren Sie Beweise vor der Bereinigung auf, wenn die Umgebung möglicherweise bereits kompromittiert ist.

Härtungsmaßnahmen:

1. Erzwingen Sie Netzwerksegmentierung um SharePoint oder gleichwertige Anwendungsebenen.
2. Platzieren Sie den Dienst hinter einem Reverse-Proxy, WAF oder einer gleichwertigen Filtersteuerung.
3. Reduzieren Sie Dienstkonten-Berechtigungen und lokale Ausführungsfähigkeiten, wo immer möglich.
4. Aktivieren Sie zentrale Protokollierung und Alarmierung für verdächtige Anfragen an /_layouts/15/ToolPane.aspx und angrenzende administrative Pfade.
5. Überwachen Sie unerwartete Prozesserstellung aus dem Anwendungsworker-Kontext.

Spezifische Gegenmaßnahmen für Forschungslabore:

1. Halten Sie das Labor in einem isolierten Bridge-Netzwerk ohne Host-Port-Veröffentlichung.
2. Entfernen Sie Befehlsausführungscode aus der scheinbaren Anwendung, es sei denn, er wird für eine kontrollierte Demonstration strikt benötigt.
3. Trennen Sie gutartige Validierung von gefährlichen Funktionen in verschiedene Skripte oder Zweige.
4. Vermeiden Sie das Speichern von positiven Ziellisten, es sei denn, es besteht ein dokumentierter Aufbewahrungsbedarf.
5. Zerstören und erstellen Sie das Labor nach jeder Übung neu.

Haftungsausschluss

Diese README enthält keine Anweisungen zur Ausnutzung von Systemen in der Produktion. Sie dokumentiert das Repository als kontrolliertes Forschungsartefakt und beschreibt sicherere Validierungs- und Abhilfepraktiken.

Referenzen

• CVE.org: CVE-2025-53770 – kanonischer CVE-Eintrag mit CNA-Metadaten, betroffenen Versionen, CVSS und verlinkten Referenzen.
• NVD: CVE-2025-53770 Detail – NIST-Anreicherung, CPE-Abdeckung, CWE-Zuordnung und Referenzaggregation.
• Microsoft Security Update Guide: CVE-2025-53770 – primäre Anbieterberatung mit Auswirkung, Ausnutzbarkeit, Gegenmaßnahmen und Sicherheitsupdate-Informationen.
• Microsoft Learn: Configure AMSI integration with SharePoint Server – Microsoft-Härtungsanleitung, auf die in der Anbieterberatung für Gegenmaßnahmen und Validierung verwiesen wird.
• Microsoft MSRC Blog: Customer guidance for SharePoint vulnerability CVE-2025-53770 – Anbieteranleitung und Reaktionskontext für aktive Ausnutzung.
• CISA Alert: Microsoft Releases Guidance for Exploitation of SharePoint Vulnerability CVE-2025-53770 – US-Regierungswarnung und operative Reaktionsanleitung.
• CISA Known Exploited Vulnerabilities Catalog entry for CVE-2025-53770 – Bestätigung, dass die Schwachstelle in KEV aufgenommen wurde, zusammen mit Abhilfefristen und Handlungsanleitungen.

Autor

• J4ck3LSyN
• github