[English]Heute noch ein kurzer Nachtrag zum Patchday vom 8. Juli 2025. Microsoft hat zu diesem Datum die als kritisch eingestufte Schwachstelle CVE-2025-47981 im SPNEGO Extended Negotiation (NEGOEX)-Sicherheitsmechanismus offen gelegt und entsprechende Patches bereitgestellt. Windows-Nutzer sollten unbedingt zeitnah reagieren und entweder patchen oder die Schwachstelle per GPO abschwächen.
Windows-Schwachstelle CVE-2025-47981
SPNEGO bietet einen Verhandlungsmechanismus für Generic Security Services (GSS) API (GSS-API), wie in [RFC2743] beschrieben. Der SPNEGO Extended Negotiation Security Mechanism (NEGOEX) erweitert den in [RFC4178] beschriebenen Simple and Protected GSS-API Negotiation Mechanism (SPNEGO), wie Microsoft hier erklärt. NEGOEX definiert einige neue GSS-API-Erweiterungen, die ein Sicherheitsmechanismus unterstützen muss, um von NEGOEX ausgehandelt zu werden.
Nun wurde von Yuki Chen ein Heap-based Buffer Overflow in der NEGOEX-Implementierung von Microsoft entdeckt. Die Schwachstelle CVE-2025-47981 ermöglicht eine Remote Code Execution über gesendete Nachrichten im SPNEGO Extended Negotiation (NEGOEX) Sicherheitsmechanismus.
Ein nicht authentifizierter, entfernter Angreifer könnte laut Microsoft diese Schwachstelle ausnutzen, indem er eine speziell gestaltete Nachricht an einen verwundbaren Server sendet. Bei erfolgreicher Ausnutzung könnte ein Angreifer RCE-Rechte erhalten. Microsoft hat der RCE-Schwachstelle einen CVEv3 Score 9.8 zugeordnet, bezeichnet das Ganze als "kritisch" und sieht eine Ausnutzung als eher wahrscheinlich.
Diese Schwachstelle betrifft nach mir vorliegenden Informationen nur Windows-Systeme ab Windows 10 Version 1607 und höher, also auch Windows 11 (in CVE-2025-47981 habe ich nichts dazu gefunden, da werden alle unterstützten Windows-Versionen mit Patches aufgeführt). Hintergrund der Aussage "ab Windows 10 V1607 betroffen" ist, dass auf den Clients ein bestimmtes Gruppenrichtlinienobjekt (GPO) standardmäßig aktiviert ist. Details lassen sich im Supportartikel Network security: Allow PKU2U authentication requests to this computer to use online identities nachlesen. Bei Windows Server 2016 und höher sollte die Allwo PKU2U Authentication dagegen per GPO standardmäßig deaktiviert sein.
CERT-Warnung, direkt patchen
Ich hatte zum 8. Juli 2025 bereits im Beitrag Microsoft Security Update Summary (8. Juli 2025) auf das Thema hingewiesen. Bernhard Kanduth weist in diesem Kommentar darauf hin, dass es eine CERT-Warnung gebe, dass dringend alle Windows Systeme aktualisiert werden sollen.
Vom CERT werden auch nur die obigen Hinweise gegeben. Inzwischen wurde ich von Lesern kontaktiert, sie hätten eine Warnung erhalten, sofort zu patchen, was dahinter stecke. Auch ist mir eine Warnung von Universitäts-IT-Abteilungen untergekommen, die aber den CVEv3 Score noch auf 8.1 hat.
Administratoren sollten also die in den Blog-Beiträgen Patchday: Windows 10/11 Updates (8. Juli 2025) und Patchday: Windows Server-Updates (8. Juli 2025) aufgeführten Updates für Windows zeitnah installieren.
Ist kein sofortiges Patchen möglich, sollte die im Supportartikel Network security: Allow PKU2U authentication requests to this computer to use online identities beschriebene Richtlinie deaktiviert werden (sollte auf Windows Server sowieso standardmäßig deaktiviert sein). Ricardo gibt in diesem Kommentar Hinweise zur Gruppenrichtlinie. Hintergrund ist, dass es durch die Juli 2025-Patches bei Samba zu argen Problemen kommt.
Das Samba-Problem
Bolko weist in diesem Kommentar auf eine Inkompatibilität der Windows Sicherheitsupdates vom 8. Juli 2025 hin. Von Microsoft heißt es zum RPC Netlogon-Fix (siehe Patchday: Windows Server-Updates (8. Juli 2025)), dass das Update eine Änderung im Protokoll vornehme:
This update includes a change to the Microsoft RPC Netlogon protocol, which improves security by tightening access checks for a set of RPC requests.
Samba, das in diesen Umgebungen als Domänenmitglied läuft, wird von dieser Änderung betroffen sein, wenn eine bestimmte Konfiguration verwendet wird. Der RPC-Fix in den aktuellen Windows-Updates ist inkompatibel mit SMB/Samba/WinBind. Damit Samba-Server in einer Domäne funktionieren, braucht man ein Samba-Update, welches frühestens zum 7.7.2025 bereitgestellt wurde (siehe auch diesem Kommentar von Bolko).
Relevant wird dies möglicherweise bei Peripheriegeräten wie NAS-Einheiten, Drucker/Scanner-Kombinationen etc., die in der Firmware einen Samba-Server zum Dateiaustausch mit Microsoft Netzwerken beinhalten. Hier werden Administratoren von Unternehmensnetzwerken ggf. noch Zeit zum Testen benötigen und sollten die NEGOEX-Schwachstelle über die oben genannte Gruppenrichtlinie entschärfen.
Ähnliche Artikel:
Microsoft Security Update Summary (8. Juli 2025)
Patchday: Windows 10/11 Updates (8. Juli 2025)
Patchday: Windows Server-Updates (8. Juli 2025)
Patchday: Microsoft Office Updates (8. Juli 2025)
Windows 10/11: Preview Updates 24. /26. Juni 2025
Windows 11 24H2: Azure Virtual Desktop (AVD) App-Attach scheitert
Windows 11 24H2 Juni 2025-Update-Probleme: KB5060842 mit falschem Zeitstempel und Print to PDF
Update KB5060829 triggert Firewall-Events
WSUS hat Synchronisationsprobleme (9. Juli 2025)
MVP: 2013 – 2016
"Glücklicherweise betrifft diese Schwachstelle nur Windows-Systeme ab Windows 10 Version 1607 und höher."
Glücklicherweise? Nur?
Betrifft das nicht auch automatisch jede Windows 11 Version die nach Win10 1607 erschienen ist?
Der MS Artikel ist von 2022 und unter "Applies to" oben wird auch Windows 11 aufgeführt, auch wenn Windows 11 nicht nochmal explizit im Text erwähnt wird gehe ich jetzt erstmal davon aus das wir hier auch über Windows 11 reden.
Ich habe die verunglückte "Glücklicherweise"-Stelle bereits umformuliert. "ab Windows 10 Version 1607 und höher" impliziert auch Windows 11 sowie die Server-Versionen. Das "nur" bezog sich darauf, dass Windows 7 – Windows Server 2012 / R2 nicht betroffen scheinen, da dort die GPO nicht aktiv ist. Ist aber auch im Text begründet – und Patches gibt es für alle noch unterstützten Windows-Versionen.
Es ist auch nützlich zu erwähnen, dass es sich nur um ein Cloud Dingens handelt. Weiter unten in den Best Practices wird auch zur Deaktivierung der GPO geraten, wenn man keine Hybrid-Konfiguration hat:
"Within a domain, domain accounts should be used for authentication. Set this policy to Disabled or don't configure this policy to exclude online identities from being used to authenticate for on-premises only environments. Set this policy to Enabled for hybrid and Microsoft Entra joined environments."
Wieder mal zeigt sich: Keine Cloud, weniger Probleme. Patchen sollte man ohnehin, aber "direkt patchen" sehe ich hier nicht wenn alles on-prem läuft.
Kein Einfluss auf:
Microsoft 365 / Entra ID / Azure AD
Single Sign-On (SSO)
Outlook, Teams, OneDrive
Remote Desktop in Domänenumgebungen
Windows Hello
Webauthn / FIDO2
Kerberos / NTLM / LDAP / SAML / OIDC
Einfluss nur, wenn du Remote Desktop zwischen zwei Entra-joined Geräten nutzt, die nicht in einer Domäne sind.
Trotzdem ist die GPO auf allen Clients aktiv, solange die GPO nicht deaktiviert wird oder das Update installiert wird. Nicht konfiguriert heißt in diesem Fall, man ist vor so einem Angriff betroffen. Außer bei Servern. Da ist ist dies deaktiviert, bis die GPO aktiviert wird.
Bedeutet "Nicht konfiguriert" wirklich das Gleiche wie "aktiviert"?
Nein, genau das Gegenteil: "Disabled or don't configure" wie oben in meinem Text steht.
"This policy is enabled by default in Windows 10, Version 1607, and later."
aber:
"Not set: Not configuring this policy prevents online IDs from being used to authenticate the user. This option is the default on domain-joined devices."
learn. microsoft. com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/network-security-allow-pku2u-authentication-requests-to-this-computer-to-use-online-identities
Bei Windows 10 ab einschließlich Version 1607 (also auch Windows 11) ist diese GPO aktiviert, solange diese Computer nicht in einer Domäne integriert sind.
In diesem Fall muss man diese GPO selber auf "deaktiviert" oder "nicht konfiguriert" umstellen.
Man darf also nicht davon ausgehen, dass diese GPO auf "nicht konfiguriert" steht, nur weil man im Gruppenrichtlinieneditor dort gar nichts eingestellt hat.
@Pascal,
das GPO ist auf den Clients in einer Domäne 'Aktiviert', nicht 'Nicht konfiguriert'.
Bei uns in der Domäne steht es bei allen Geräten auf "Not defined" – ich bin ehrlich gesagt etwas verwirrt weil für mich "Not defined" definitiv nicht bedeutet das etwas aktiviert ist dann müsste ich ja keine GPOs mehr verwalten wenn ich bestimmte Features aktivieren/deaktivieren möchte.
Wir haben eine Hybrid-Umgebung daher tu ich mir schwer die GPO einfach mal so zu aktivieren auch wenn die Auswirkungen evtl. nicht so gravierend sind.
Hat irgendjemand eine aussagekräftige Empfehlung? :D
@Anonym,
wird etwas de- oder aktiviert, ist es nicht mehr einstellbar. Die Entra verwalteten Geräte benötigen das PKU2U für RCP. Für andere Geräte sollte es vorsichtshalber deaktiviert oder lokal abgegrenzt sein. Bedeutet, erstmal nichts ändern und die administrativen Vorlagen insoweit konsistent halten.
Die Cloud macht nichts einfacher. Insbesondere nicht bei Hybrid-Umgebungen.
Im Mittelstand funktioniert eine reine Cloud-Lösung leider selten bis gar nicht. Abgesehen davon ist man bei nahezu jeder Cloud-Solution noch immer für die Sicherungen und die Updates der Produkte und der Daten zuständig. Man wird On-Prem nicht los und damit werden die Probleme komplexer.
Dazu gesellt sich die steigende Rate an Vernetzungen. Was man da so an Verbindungen sieht, lässt einem das Blut in den Adern gefrieren.
Ich sehe nahezu täglich Nachrichten von angegriffenen Unternehmen – auch sehr große Unternehmen.
Das ist erschreckend. Am Ende kostet alles sehr sehr sehr viel Geld – in allen Fällen. Und dies haben viele Unternehmen leider nicht im Überfluss.
@Carsten,
der Angriff kann auf jeden Rechner erfolgen, und Code kann über dessen Netzwerk ausgeführt werden.
Kann es denn irgendwelche negative Auswirkungen haben, wenn man diese GPO einfach deaktiviert (PKU2U Authentifizierungsanfragen)?
Braucht man das ausschließlich nur für "Microsoft Entra ID"?
2.
Der Link im Satz
"Bolko weist in diesem Kommentar auf eine Inkompatibilität der Windows Sicherheitsupdates vom 8. Juli 2025 hin."
geht nicht zu meinem Kommentar, sondern zu einem (falschen) Artikel (Ameos-Klinikverbund).
Wenn man die GPO "Network Security: Allow PKU2U authentication requests to this computer to use online identities" deaktiviert:
=> Muss man die Computer neu starten damit PKU2U auch wirklich nicht mehr verwendet wird, oder wirkt die Einstellung an den Computern sobald die GPO angewendet wird? Hab da nichts dazu finden können…
Der Befehl gpupdate in einer Konsole aktiviert die GPOs sofort.
Ansonsten gibt es zwei Timer, nach deren Ablauf die GPOs aktualisiert werden.
HKEY_LOCAL_MACHINE oder HKEY_CURRENT_USER
Software\Policies\Microsoft\Windows\System
DWORD-32: GroupPolicyRefreshTime
Default: 90 (Minuten, dezimal)
zufällige maximale Varianz (als zufälliger positiver Offset zu dem vorherigen Timer):
HKEY_LOCAL_MACHINE oder HKEY_CURRENT_USER
Software\Policies\Microsoft\Windows\System
DWORD-32: GroupPolicyRefreshTimeOffset
Default: 30 (Minuten, dezimal)
Also 90 Minuten plus [0 bis 30 Minuten], also 90 Minuten bis 120 Minuten.
Weiß jemand auswendig ob das HP Multifunktionsgeräte betrifft? Habe auf die Schnelle nicht gefunden welche Protokolle die per default nutzen.
Welche Protokolle die Drucker verwenden, kannst du in deren Management-Konsole selbst einstellen. Solange der Drucker aber nicht Domain-joint ist, sollte das hier aber kein Thema sein.
Besser als die Richtlinie zu deaktivieren ist patchen, vor allem wenn man sein AD an Entra-ID angebunden ist, das kann nämlich tatsächlich zu Funktionsstörungen führen.
Da ich es leider nicht eindeutig herauslesen konnte wollte ich fragen ob ich das richtig verstehe und ob es hierfür eine offizielle Quelle gibt die das Bestätigt:
"Wenn Server nicht explizit so konfiguriert wurden, dass die GPO 'Network Security: Allow PKU2U authentication requests to this computer to use online identities' aktiviert wurde, bzw. dass der Registry Key 'AllowOnlineID' in 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\pku2u' auf '1' gesetzt wurde, sind Server nicht verwundbar"
Stimmt das so?
So verstehe ich es zumindest. Auch der offizielle Artikel von Microsoft (https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-47981) behinhaltet den Hinweis
"This vulnerability affects Windows client machines running Windows 10, version 1607 and above, due to the following GPO being enabled by default on these operating systems:…"
Es ist explizit von "Client machines" die Rede, man kann nur hoffen dass man sich darauf verlassen kann.
Jetzt nochmal genau überlegen… Die GPO ist auf noch unterstützten Windows-Versionen (ab 1607) per Default enabled, wenn sie auf "not configured" steht. Wer noch nicht patchen kann, soll sie auf "disabled" stellen.
Wir haben das heute intern im Team besprochen und wir sind zum selben Schlüss gekommen, wie Gänseblümchen oben schrieb, alles so schnell wie geht zu patchen. Damit angefangen haben wir allerdings schon gestern bei kritischen Systemen, die aufgrund ihrer Funktion sowieso besonders viele Authentifizierungen bekommen, sprich Domain-Controller, File- und Printserver, IIS, SQL, Sharepoint, usw.
Es wird aber auch die Einschränkung erwähnt dass sie nur dann per default enabled ist, wenn das Gerät nicht in einer Domäne ist. Ich glaube das steht so sogar in der Einstellung bei der GPO selbst in der Beschreibung. Ich gehe mal davon aus dass ihr auch nur wenige Clients habt die nicht in einer Domäne sind?
Auf Servern – von denen sprichst Du ja auch – sollte die Einstellung in der GPO soweit ich es verstehe defaultmäßig nicht aktiv sein.
@Froschkönig sagt:
Die GPO ist auf noch unterstützten Windows-Versionen (ab 1607) per Default enabled, wenn sie auf "not configured" steht.
Das steht dort nicht.
@Anonymous,
in einer Domäne ist der Standard 'Aktiviert'.
Richtlinie unter,
'Computerkonfiguration > Windows-Einstellungen > Sicherheitseinstellungen > Lokale Richtlinien > Sicherheitsoptionen',
'Netzwerksicherheit: Lässt an diesen Computer gerichtete PKU2U-Authentifizierungsanforderungen zu, um die Verwendung von Onlineidentitäten zu ermöglichen.'
'Nicht definiert' ist gleich 'Deaktiviert'.
'Nicht definiert' ist der Standard bei Win10.
'Deaktiviert' ist der Standard bei Server und DC.
Ist Windows 10 ab Version 1607 in einer Domäne, ist der Standard 'Aktiviert'.
Aber der Satz
"Ist Windows 10 ab Version 1607 in einer Domäne, ist der Standard 'Aktiviert'."
ist doch so nicht richtig, oder? Es steht doch in der Beschreibung im GPO Editor selbst genau andersrum? Das was Du schreibst gilt doch nur wenn die Windows Clients *nicht* in einer Domäne sind? Oder habe ich jetzt gerade wieder komplett ein Brett vor dem Kopf?
Die Richtlinie lässt die PKU2U zu. Das wollen wir nicht. Deshalb deaktivieren. Die Beschreibung aber irritiert. Sie muss vor und ab einer Version definieren. Windows 10 in einer Domäne ist vor 1607 'Deaktiviert', ab 1607 'Aktiviert'.
Drag and Drop von VOR und IN der Domäne:
In Versionen vor Windows 10, Version 1607, ist diese Richtlinie auf Computern, die in die Domäne eingebunden sind, standardmäßig deaktiviert.
Gibt es einen Netzwerkscanner (Nmap/Nessus/Github) der diese Schwachstelle , passiv (ohne Authentifizierung am System) Remote erkennen kann?
Früher gab es solche Scanner von MS oder Retina
Danke