CVE-2025-53770: Unauthentifizierte Remotecodeausführung in SharePoint 2019 (Update vom 24.07.25)
Im vorherigen Beitrag haben wir die Schwachstelle CVE-2025-53770 bereits vorgestellt und ihre potenziellen Auswirkungen skizziert. In diesem Beitrag folgt nun die technische Analyse der Lücke, mit Fokus auf Angriffsvektor, Reproduktion und Möglichkeiten zur Erkennung sowie Prävention.
Einen Server mit nur einem einzigen simplen Request vollständig unter Kontrolle zu bringen, klingt wie ein zusammengefasster Wunschzettel zu Geburtstag, Ostern und Weihnachten, aus Sicht eines Angreifers. Mit der aktuellen SharePoint-Schwachstelle CVE-2025-53770 wird genau dieses Szenario Realität.
Während eines gezielten Tests auf einer frisch aufgesetzten Instanz von SharePoint Server 2019 konnte die Sicherheitslücke validiert werden. Die Lücke erlaubt es einem Angreifer, eigenen serverseitigen Code im Kontext des IIS-Anwendungspools auszuführen und das ohne Authentifizierung.
Im Beitrag werden deshalb folgende Punkte beschrieben:
- Der Angriffsvektor: _layouts/15/ – ein SharePoint-Relikt mit hoher Reichweite
- Eigener Versuchsaufbau zur Reproduktion
- Erkennung und Prävention mit Enginsight
Der Angriffsvektor: _layouts/15/ – ein SharePoint-Relikt mit hoher Reichweite
Das Verzeichnis _layouts/15/ ist jedem SharePoint-Admin ein Begriff. Es handelt sich um einen globalen Speicherort für serverseitige ASPX-Komponenten, die systemweit, also über alle Site Collections hinweg, verfügbar sind. Hier befinden sich essentielle Komponenten wie ToolPane.aspx, Settings.aspx oder auch SignOut.aspx.
Normalerweise unterliegt dieses Verzeichnis strengen Zugriffsbeschränkungen, vor allem, was das Hochladen oder gar Ausführen von benutzerdefinierten Dateien angeht.
Versuchsaufbau: ToolPane.aspx als Einstiegspunkt
Der erste Test richtete sich gegen eine native Datei: ToolPane.aspx. Mit einem simplen curl-Befehl wurde ein POST-Request an diese Seite geschickt:
curl -X POST http://<server>/_layouts/15/ToolPane.aspx \
-H „Referer: /_layouts/SignOut.aspx“ \
-H „Content-Length: 0“ -v
Die Antwort war HTTP 200 OK, dazu eine vollgerenderte HTML-Fehlerseite. Das bedeutet, dass die Seite vollständig serverseitig verarbeitet wurde, obwohl keinerlei Authentifizierung vorlag. Der Request wurde angenommen und durch den ASP.NET-Lebenszyklus geleitet, ein Hinweis darauf, dass es keine Zugangskontrolle an dieser Stelle gibt.
Der Schlüssel zur Umgehung liegt dabei im Referer-Header.
Dieser ist ein HTTP-Header, der dem Server mitteilt, von welcher Seite der aktuelle Request ursprünglich kommt. Er wird typischerweise vom Browser gesetzt, z. B. wenn ein Benutzer auf einen Link klickt. In Webanwendungen dient dieser Header gelegentlich als rudimentärer Schutzmechanismus, um zu prüfen, ob eine Anfrage aus einer vertrauenswürdigen Umgebung stammt.
In diesem Fall jedoch wertet SharePoint den Referer-Header fälschlicherweise als Vertrauensbeweis. Wird dieser gezielt auf eine interne Seite wie /layouts/SignOut.aspx gesetzt, nimmt SharePoint an, die Anfrage sei legitim, obwohl sie tatsächlich von einem externen, nicht authentifizierten Client stammt. Diese fehlerhafte Validierung führt effektiv zu einem Auth-Bypass.
Der Proof-of-Concept: Eigene Datei, echter Code
Die eigentliche Bestätigung der Lücke folgte mit einem eigenen Testfile: testpoc.aspx. Ziel war es, herauszufinden, ob der Server nicht nur auf diese Datei zugreifen, sondern sie auch tatsächlich ausführen würde. Die Datei bestand aus einer einzelnen Zeile serverseitigem C#-Code, der beim Aufruf den aktuellen Zeitpunkt zurückliefert:
<%@ Page Language=“C#“ %>
<%
Response.Write(„✅ PoC erfolgreich – Serverzeit: “ + DateTime.Now.ToString(„dd.MM.yyyy HH:mm:ss“));
%>
Sie wurde manuell in das Verzeichnis _layouts/16/ kopiert.
Wesentlich an diesem Code ist der Aufruf von DateTime.Now. Dieser Ausdruck erzeugt einen Zeitstempel, der nur zur Laufzeit auf dem Server generiert werden kann. Wenn ein Webserver diese Information in der Antwort zurückliefert, dann ist das ein klarer Beweis dafür, dass der Code ausgeführt und nicht nur als statische Datei ausgeliefert wurde, wie es beispielsweise bei einer .html- oder .txt-Datei der Fall wäre.
In ASP.NET durchläuft jede .aspx-Datei, die vom Webserver verarbeitet wird, den sogenannten Page Lifecycle. Das bedeutet: Der Server erkennt anhand der Dateiendung und des Inhalts, dass es sich um serverseitigen Code handelt. Er ruft zur Verarbeitung die ASP.NET-Runtime auf, kompiliert den Code und führt ihn dann im Kontext des IIS-Anwendungspools aus. Erst danach wird das Ergebnis an den Client zurückgegeben.
Im konkreten Test wurde ein HTTP-POST an die Datei gesendet.
curl -X POST http://<server>/_layouts/15/testpoc.aspx \
-H „Referer: /_layouts/SignOut.aspx“ \
-H „Content-Length: 0“ -v
Die Antwort war ein 200 OK mit exakt dem Text, den Response.Write(…) erzeugt, inklusive des aktuellen Zeitstempels.
curl -X POST http://<server>:80/_layouts/15/testpoc.aspx -H „Referer: /_layouts/SignOut.aspx“ -H „Content-Length: 0“ -k -v
* Trying 10.x.x.4:80…
* Connected to <server> (10.x.x.4) port 80 (#0)
> POST /_layouts/15/testpoc.aspx HTTP/1.1
> Host: <server>
> User-Agent: curl/7.74.0
> Accept: */*
> Referer: /_layouts/SignOut.aspx
> Content-Length: 0
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Cache-Control: private
< Content-Type: text/html; charset=utf-8
< Server: Microsoft-IIS/10.0
< X-SharePointHealthScore: 5
< X-AspNet-Version: 4.0.30319
< SPRequestGuid: ef06b4a1-3207-d0dc-adbb-71097a9a47ff
< request-id: ef06b4a1-3207-d0dc-adbb-71097a9a47ff
< X-FRAME-OPTIONS: SAMEORIGIN
< X-Powered-By: nosniff
< MicrosoftSharePointTeamServices: 16.0.0.10337: 1; RequireReadOnly
< Date: Mon, 21 Jul 2025 18:32:22 GMT
< Content-Length: 55
<
* Connection #0 to host <server> left intact
✅ PoC erfolgreich – Serverzeit: 21.07.2025 20:32:22
Das ist der entscheidende Moment: Der Server hat die Datei nicht einfach nur ausgeliefert, sondern den darin enthaltenen Code interpretiert, ausgeführt und die Ausgabe an den anfragenden Client geschickt.
Warum ist das relevant für CVE-2025-53770?
Die Lücke besteht nicht nur darin, dass Dateien im Layouts-Verzeichnis aufrufbar sind, sondern die Schwachstelle liegt vielmehr darin, dass keine Zugriffskontrolle greift, wenn zusätzliche (nicht-standardmäßige) Dateien dort abgelegt und direkt über HTTP angesprochen werden.
Diese Konstellation entspricht dem Bedrohungsszenario, das CVE-2025-53770 beschreibt:
- Serverseitige ASP.NET-Komponenten können ohne vorherige Authentifizierung ausgeführt werden.
- Die Ausführung erfolgt in einem global eingebundenen und privilegierten Verzeichnis.
- Eine Sicherheitsprüfung auf Anwendungsebene findet nicht statt.
- Die Ausführung erfolgt mit den Rechten des SharePoint Application Pools.
Für Angreifer ist das ein idealer Einstiegspunkt, um beispielsweise eine Web Shell zu installieren, interne Informationen auszulesen oder Persistenz in einem kompromittierten Netz zu etablieren.
Erkennung und Prävention mit Enginsight
Um Systeme frühzeitig vor der Ausnutzung von Schwachstellen wie CVE-2025-53770 zu schützen, ist nicht nur Patch-Management entscheidend, sondern auch eine zuverlässige Erkennung von Angriffsmustern im laufenden Betrieb.
Der Enginsight Pulsar bietet die Möglichkeit, SharePoint-Server auf das Vorhandensein verwundbarer Versionen zu überprüfen.
Darüber hinaus konnte erfolgreich nachgewiesen werden, dass das Intrusion Detection System (IDS) von Enginsight in der Lage ist, Exploit-Versuche zuverlässig ab Stufe 2 zu erkennen und je nach Konfiguration auch aktiv zu blockieren. So wurde unter Testbedingungen eine manipulierte POST-Anfrage gegen _layouts/15/testpoc.aspx erkannt und direkt unterbunden:
Die zugrunde liegende IDS-Regel prüft gezielt auf typische Merkmale des Exploits:
- Referer-Header mit verdächtigen Werten wie:
/layouts/SignOut.aspx - Pfadbestandteile wie:
/_layouts/15/ oder /_layouts/16/
Eine zusätzliche Regel erkennt verdächtige GET-Anfragen, die auf bekannte Exploit-Trigger wie z. B. /_layouts/spinstall0.aspx zielen – ebenfalls mit Varianten für SharePoint 2013, 20
Wichtiger Hinweis!
Es ist wichtig zu beachten, dass die IDS-Regeln nur bei unverschlüsseltem HTTP-Traffic greifen. Wird die Kommunikation über HTTPS abgewickelt (was in Produktivumgebungen üblich ist), kann der Inhalt der Anfragen nicht eingesehen werden. Um dennoch eine transparente Nachvollziehbarkeit sicherzustellen, wird empfohlen, zusätzlich die IIS-Logdateien in die Sicherheitsüberwachung einzubinden.
Ergänzende forensische Analyse: IIS Logs
Für eine tiefergehende Analyse empfiehlt es sich außerdem, die IIS-Logdateien auf verdächtige Requests zu untersuchen. Diese befinden sich standardmäßig unter:
C:\inetpub\logs\LogFiles\W3SVC<SiteID>
Hier lassen sich z. B. ungewöhnliche POST-Requests oder Aufrufe von .aspx-Dateien außerhalb typischer Muster nachvollziehen:
Mit dem Enginsight SIEM ist es über den File-Kollektor möglich, die Dateien direkt ins SIEM zu integrieren. Da SharePoint jedoch täglich eine neue Protokolldatei anlegt, muss der Kollektor bisher regelmäßig angepasst werden, um stets die aktuelle Datei zu erfassen. Das erschwert die kontinuierliche Überwachung und macht die Konfiguration aufwändiger.
Mit der kommenden Version Pulsar 6.8.6 wird die Einbindung deutlich vereinfacht: Der File-Kollektor unterstützt künftig ganze Verzeichnisse, wodurch alle neu erstellten Dateien automatisch erfasst werden. Besonders für die kontinuierliche Überwachung der SharePoint-Protokolldateien bedeutet dies eine spürbare Erleichterung und mehr Effizienz.
Nachdem die Logdateien über den File-Kollektor eingebunden wurden, stehen sie nun zentral im Enginsight DataLake zur Verfügung. Die Daten sind dort nicht nur vollständig sichtbar, sondern können auch gezielt durchsucht und ausgewertet werden.
Darüber hinaus besteht die Möglichkeit, auf Basis definierter Indikatoren, zum Beispiel verdächtiger Pfade wie /_layouts/SignOut.aspx, eigene Streams zu erstellen. Diese Streams filtern relevante Ereignisse in Echtzeit und lassen sich mit einem Workflow zur automatischen Benachrichtigung kombinieren. Auf diese Weise können sicherheitskritische Aktivitäten unmittelbar erkannt und weiterverarbeitet werden.
Fazit
Mit Hilfe von Enginsight lassen sich sowohl verwundbare Systeme identifizieren als auch aktive Exploit-Versuche erkennen und stoppen vorausgesetzt, der Netzwerkverkehr liegt unverschlüsselt vor oder wird per SSL-Inspection mitgeschnitten. Ergänzend zur technischen Prävention sind regelmäßige Log-Analysen sowie die Härtung der SharePoint-Konfiguration essenziell, um Angreifern keine Angriffsfläche zu bieten.
Handlungsempfehlung von Enginsight (Stand 22.07.25)
Die als kritisch eingestufte Schwachstelle in Microsoft SharePoint Servern (CVE-2025-53770) wird aktuell aktiv ausgenutzt. Unter bestimmten Voraussetzungen ermöglicht sie Angreifern, die vollständige Kompromittierung betroffener Systeme durch Remote Code Execution (RCE).
Nach unserem Kenntnisstand sind insbesondere folgende Versionen von selbstbetriebenden Servern betroffen:
SharePoint Server 2019
SharePoint Subscription Edition
SharePoint Server 2016 (noch ohne verfügbaren Patch)
Microsoft und CISA haben entsprechende Sicherheitswarnungen veröffentlicht und dringend zur sofortigen Einspielung bereitgestellter Updates geraten.
Allgemeine Empfehlungen:
– Installieren Sie umgehend die bereitgestellten Sicherheitsupdates von SharePoint.
– Aktivieren Sie AMSI-Schutzmechanismen und stellen Sie sicher, dass Microsoft Defender Antivirus/Endpoint aktiv ist.
– Rotieren Sie sensible MachineKeys und führen Sie anschließend einen Neustart der betroffenen Dienste durch (IIS).
– Überprüfen Sie Ihre Systeme auf Kompromittierungsindikatoren, insbesondere ungewöhnliche .aspx-Dateien, verdächtige POST-Anfragen und Systemveränderungen.
– Setzen Sie ggf. forensische Maßnahmen um und ziehen Sie bei Bedarf Unterstützung durch unser Security-Team hinzu.
Unsere Empfehlung nach aktuellem Kenntnisstand
Selbst nach aktiviertem Update scheint ein Angriff möglich zu sein. Wir empfehlen, selbstbetriebene Server auch nach erfolgtem Sicherheitsupdate vom Netz zu nehmen. Da wir die aktuelle Sicherheitslücke als sehr kritisch einstufen, empfehlen wir generell einen Alarm für neu aufkommende kritische CVE ab dem CVSS Score 9 anzulegen. Weiterhin arbeiten wir bereits kurzfristig an der Implementierung zur Erkennung möglicher Angriffe über die CVE-2025-53770. Über entsprechende Updates halten wir Sie zeitnahe auf dem Laufenden.
