[English]Kürzlich haben Sicherheitsforscher auf eine potentielle Schwachstelle hingewiesen, die in den unter Windows Server 2025 neu eingeführten delegated Managed Service Accounts (dMSAs) lauert. Durch den Missbrauch von dMSAs können Angreifer jeden Principal in der Domäne übernehmen. Ein Sicherheitsforscher äußert sich kritisch über die Tatsache, dass Microsoft mit einem Patch zuwartet. Und ein Entwickler hat ein .NET-PoC erstellt, mit dem man die Schwachstelle testen kann – hier ein Nachtrag.
Anzeige
BadSuccessor: dMSA AD-Privilegien-Erhöhung
Microsoft hat in Windows Server 2025 delegierte verwaltete Dienstkonten (dMSAs) eingeführt. Ein dMSA ist ein neuer Typ von Dienstkonto im Active Directory (AD), der die Möglichkeiten von gMSAs (Group Managed Service Accounts) erweitert.
Eine dMSA wird in der Regel erstellt, um ein bestehendes Dienstkonto zu ersetzen. Dabei ermöglicht ein dMSA, bestehende nicht verwaltete Dienstkonten zu migrieren, indem sie nahtlos in dMSAs umgewandelt werden. Um einen nahtlosen Übergang zu ermöglichen, kann eine dMSA die Berechtigungen des alten Kontos beim Migrationsprozess "erben". Durch die Migration wird das dMSA eng an das abgelöste Konto gekoppelt.
Durch Analyse des Migrationsvorgangs in Windows Server 2025 hat der Akamai-Sicherheitsforscher Yuval Gordon eine Schwachstelle entdeckt, die es Angreifern ermöglicht, jeden Benutzer in der Active Directory (AD) zu kompromittieren.
Der BadSuccessor genannte Angriff nutzt die Funktion "Delegated Managed Service Account" (dMSA) aus, die in Windows Server 2025 eingeführt wurde, mit der Standardkonfiguration funktioniert und einfach zu implementieren ist. Ich hatte das Ganze im Blog-Beitrag BadSuccessor: dMSA zur Privilegien-Erhöhung in Active Directory missbrauchen beschrieben.
Anzeige
Kritik an Microsofts Verhalten
Sicherheitsexperte Florian Roth hat das Verhalten von Microsoft bei BasSuccessor in nachfolgendem Tweet massiv kritisiert.
Roth sieht den Fall als Beleg, dass das Eco-System in diesem Bereich ziemlich kaputt sei. Eine Privilegien-Anfälligkeit wird gemeldet, Microsoft bestätigt, dass die Schwachstelle real ist, stuft sie aber als moderat ein und will irgendwann bei Gelegenheit patchen. Das Tool Rubeus unterstütze bereits den Missbrauch der obigen Schwachstelle.
Seine Schlussfolgerungen bzw. Annahmen: Microsoft kann entweder Bugs nicht mehr einschätzen, oder hat aufgehört, sich um On-Prem AD zu kümmern (weil Entra ID das ist, was sie verkaufen wollen). Und die Sicherheitsexperten haben haben sich zur Offenlegung entschieden, obwohl dies ein schwerer Schlag sein würde.
Hier kann ich irgendwie beide Seiten verstehen: Microsoft muss wohl bestimmte Regeln einhalten, die festlegen, ob etwas sofort gepatcht werden muss. Und ich kann die Sicherheitsforscher verstehen, die sich nicht ernst genommen fühlen und die Erkenntnisse publizieren. Andererseits scheint auch die Kommunikation seitens Microsoft extrem doof gelaufen zu sein.
Ich denke, es hätte die Möglichkeit gegeben, die Veröffentlichung zurückzustellen, wenn ein Patch für Sommer 2025 avisiert worden wäre. Aktuell stecke ich in einem ähnlichen Dilemma, nachdem ein Blog-Leser mir eine potentielle Schwachstelle bei einer Praxissoftware für Zahnärzte gemeldet hat. Der eingeschaltete Landesdatenschutzbeauftragte hat nachgeforscht und erhielt die Antwort "alles kein Problem, muss beim Einrichten berücksichtigt werden". Den Leser erreiche ich nicht und die Klärung des Sachverhalts durch den Landesbeauftragten für Datenschutz dauert an. Mal sehen, wann ich was wie weitgehend offenlege.
Am Ende des Tages, so Florian Roth, sieht keiner der Beteiligten (Microsoft, die Akamai-Sicherheitsforscher, die das veröffentlicht haben) gut aus und es gibt nur Verlierer. Wie schließt Roth seine Philippika: "Das einzig Gute ist, dass Windows Server 2025 noch nicht weit verbreitet ist, so dass der Aktionsradius des Schadens in der realen Welt heute begrenzt ist". Wie im ersten Beitrag und nachfolgend im Kommentar erwähnt, muss Windows Server 2025 zudem als DC laufen, was weiter einschränkt.
SharpSuccessor: BadSuccessor im .NET-Format
Zum Wochenende ist mir dann nachfolgender Tweet untergekommen, wo Logan Goins seine .NET-Version eines BadSuccessor-Exploits, als SharpSuccessor bezeichnet, vorgestellt.
SharpSuccessor ist ein, auf auf GitHub bereitgestelltes, .NET Proof of Concept (POC) zur Demonstration der Ausnutzung des von Yuval Gordon (@YuG0rd) von Akamai beschriebenen BadSuccessor-Angriffs. Ein Benutzer mit geringen Privilegien und CreateChild-Berechtigungen für eine beliebige Organisationseinheit (OU) in der Active Directory-Domäne kann seine Privilegien zum Domänenadministrator ausbauen.
Anzeige
Nö die Auffassung von Roth muss man nicht teilen.
Microsoft wurde responsible informiert, hat sich das angeschaut und alles als gar nicht so schlimm abgebügelt. Won't fix.
Und genau damit hat Microsoft selbst alles für die Öffentlichkeit freigegeben.
Ende der Diskussion. Alles was nun folgt ist Mimimi und "war ja nicht so gemeint".
> wenn ein Patch für Sommer 2025 avisiert worden wäre.
Ist er aber nicht.. Was gibt es an "won't fix" zu deuten?
Der einzige Trost, 2025 muss als DC laufen (fehlt bei Dir als Info) und die sind in der Tat noch relativ selten.
"Won't fix. " . nicht ganz, sie wollen es irgendwann fixen, vielleicht ändert sich das mit den jetzt verfügbaren POCs und das Thema dadurch dringlicher.
Ich sehe das noch gelassen, denn imho ist Server 2025 ohnehin noch nicht reif für den Produktiv-Betrieb, erst recht noch nicht als DC. Dazu muss erstmal das erste "Service Pack" kommen, wie man das früher nannte. Dazu kommt noch, dass man mit Domain-Level 2025 nach meinem Verständnis die Teilnahme einiger älterer Windows/Server-Versionen an der Teilnahme am AD ausschließt, XP, Vista, 7, 8 und zugehörige Server. Sollte man zwar ohnehin besser nicht tun, aber scheinbar sind manche Unternehmen gezwungen, es dennoch zu tun, weil da irgendwelche (noch) "unersetzliche" Soft- oder Produktionshardware dran hängt. Sowas muss man natürlich sehr gut schützen, aber das ist ein anderes Thema.
Das Akamai-Script kann man ja trotzdem schon mal laufen lassen, selbst wenn man noch DC 2016, 2019 oder 2022 einsetzt und noch keine 2025er, es findet trotzdem AD-Objekte, die man prophylaktisch mal putzen sollte.
der DFL/FFL hat noch NIE NICHT einen Einfluss auf Clients gehabt und wird er auch nicht !1!11
für alle noch Mal zum mitschreiben: DFL und FFL sind einzig und allein beim Thema Replikation interessant und erlauben die Freischaltung neuer Funktionen, bzw erlauben es nicht solange der Level ein niedriger ist.
Es geht darum, welches DC OS noch mitspielen aka replizieren kann, wobei das älteste DC OS den Level bestimmt, als kleinster gemeinsamer Nenner.
nach Ablösung des ältesten DC OS kann der Level angehoben werden.
den authentifizierenden Client ist es komplett egal. Total und vollkommen Pumpe.
Windows XP wird schon seit einem Update aus 2024? 2023? die Neuaufnahme/Domainjoin in ein AD 2016 aufwärts verweigert. bestehende Trusts zu Clients sind nicht von dem Update betroffen.
> Windows XP wird schon seit einem Update aus 2024? 2023? die Neuaufnahme/Domainjoin in ein AD 2016 aufwärts verweigert.
"Schon" Du hast wirklich das Wörtchen "schon" verwendet? ;-)
> sie wollen es irgendwann fixen..
Dir ist schon klar, wann man sowas sagt, wenn man etwas "irgendwann" fixen will? Kommt so kurz nach einem "wenn ich Zeit habe" oder "hängt von der relativen Mondfeuchte ab".
@Thomas Jakobs: Warum man es so sehen muss wie Florain Roth: Standard-Konfig ist betroffen. Kann man natürlich darunter abtun, dass es noch sehr viele andere Standard-Einstellungen gibt die fragwürdig sind und geändert werden sollten. Aber die Tragweite ist in der Regel nicht ganz so krass und üblicherweise sind es eben Einstellungen und nicht Berechtigungen wo man eher wenig am Standardverhalten ändert.
Was mir immer noch nicht so ganz klar ist und auch irgendwie widersprüchlich beschrieben wird, was man nun genau für Rechte für eine Ausnutzung benötigt.
Ein Child-Schreibrecht gibt es ja durchaus öfter mal. Der Domain-Admin kann ja nicht alles selber machen. Alleine die Erstellung von Mitarbeiter oder noch etwas krasser, Kontakte welcher ein User selber erstellen kann. Zumindest sofern das nicht irgendwie mit anderen Schnittstellen gelöst ist, die wiederum ein Dienstkonto dafür nutzen.
Das 2025 ein Muss ist, steht im Text von Günther. Auch im Vorhergehenden vor ein paar Tagen und auch im Englischen Teil. ;)
> Kann man natürlich darunter abtun, dass es noch sehr viele andere Standard-Einstellungen gibt die fragwürdig sind und geändert werden sollten. (…)
Wenn Du Dein Hauptargument selbst schon widerlegst, wie soll ich das dann noch?
> Aber die Tragweite ist in der Regel nicht ganz so krass.
Ah, hier könnte ich doch ansetzen. Was hältst Du davon, dass auf jedem Client Default-User Adminrechte haben? Oder in jedem Windows automatisch C$ als Share freigegeben ist? Dass es unterhalb C:/Windows Ordner gibt, wo unpriviligierte User Schreibrechte haben? Dass Onedrive und ähnlicher Dreck nicht etwa im Programmordner sondern in %LOCALAPPDATA% per Default liegen, damit dann jeder unpriviliegerter Depp (oder eine Malware) da rumpfuschen kann und z.b. die automatisch bei Anmeldung gestartete .exe einfach austauscht? Frag mal den hier mitlesenden Stefan Kanthak. Er könnte Dir eine lange Liste voller "Security by Microsoft" Fälle schildern…
>Wenn Du Dein Hauptargument selbst schon widerlegst, wie soll ich das dann noch?
Ist so ein Punkt den man beleuchten kann wie es einem grad passt. Daher sehe ich das nicht als Widerlegung sondern als Bestätigung. MS sollte dieses UND andere schlechte Standardverhalten "fixen" bzw. wenigstens nicht ständig neue schaffen. Man kommt als ITler teilweise gar nicht mehr hinterher.
Ansonsten: Es läuft in den letzten ~10-15 Jahren einiges gegen den mit Vista eigentlich mal eingeschlagen. Fairerweise muss man sagen, das gilt aber für die ganze Branche, nicht nur für MS. Die bisher grösste Schande sind die ganzen AppX die im User-Kontext installiert werden. Nun kommt noch AI dazu. Da wird den kreativen Malware-Akteuren ein wunderbares Werkzeug zu Verfügung gestellt.
"nicht ständig neue schaffen"
Ich glaube nicht, dass die mit Absicht Sicherheitslücken oder Funktionsfehler einbauen. Es ist halt so, je größer ein System ist, je mehr es kann, um so mehr Fehler entstehen ganz automatisch. mach mal ein Studion zu Informatik, Software-Engeneering und so, da wirst du gleich in der ersten Einführungsvorlesung Statistiken präsentiert bekommen, wieviele Fehler unbewusst/ungewollt sich einfach so pro 1000 Zeilen Code einschleusen. Programmierer sind eben auch nur Menschen, und je komplexer die Software wird, um so schwieriger wird es, alle Randbedingungen zu berücksichtigen. Und Dinge, die früher nie als Fehler oder Schwachstelle erkannt/eingeschätzt wurden, werden dann Jahre später dann doch als solche eingestuft, und das ist auch unabhängig davon, ob Quellcode öffentlich einsehbar ist oder nicht. Auch KI in der Softwareentwicklung wird da nicht helfen, weil sie die Fehler aus anderer Software mit lernt.
Bin ich nicht einverstanden. Ich spreche nicht von Programmierfehler von neuen sinnvollen Features, sondern bewussten Fehlentscheidungen welche die Sicherheit betreffen. Vista ist mit einer sehr guten Idee gestartet, unter 7 habens die meisten Hardware-Hersteller endlich auch kapiert mit den Treibern und es wurde stabil.
Seither geht es nur noch bergab mit Unterhöhlungen aus dem eigenen Hause.
– AppX mit X möglichen Versionen pro App auf Userbasis
– Nicht managebare Firewall-Regeln des AppX-Zeugs
– halbgar maskierte "svchost.exe" Prozesse, die keine Firewallausnahmen zulassen und somit svchost.exe generell freigegeben werden muss bzw. Ports. Auch wenn die Maskierung angeblich gut wäre. Das generelle freigeben verhindert aber z.B. die aktive Filterung von Telemetrie-Verbindungen die man evtl. nicht will.
– App Blocker als eher schlechten Nachfolger von SRP (gemäss Sicherheitspezis)
– UEFI-Drama und sonstige versteckte Partitionen wo man nicht so genau weiss, was da drin abläuft und auch andere nutzen können, fernab der Kontrolle (naja, nicht nur MS sondern eher generell)
– Keylogger (wo angeblich niemand weiss was er genau macht, ich weiss nichtmal obs ihn tatsächlich gibt. Gerücht hält sich aber hartnäckig)
– Handschriften Index der nur mit TI-Rights abschaltbar ist, angeblich mit Upload zu MS (verlässliche Infos habe ich leider nie gefunden, das abschalten aber schon)
– Cortana mit allenfalls Auto-Upload-Funktion (so genau weiss das wohl auch niemand)
– Das absolut gräusliche IPv6/IPv4 Geraffel mit Teredo das alles an Firewall-Einstellungen untergräbt, das man bis dahin hatte.
– Und nun tatatata das Meisterstück mit AI/Recall/Copilot. Fix eingebaute Spyware ins OS.
Und das ist nur das Zeug was mir grad auf Anhieb so einfällt und neu dazu kam. Und einige Datenschutz-Fragwürdige Dinge noch nicht dabei. ;)
Die Entscheidungsträger nehmen eindeutig zu wenig von dem Zeug, dass sie einnehmen. Klar die Behörden mit drei Buchstaben aus den USA freut das alles, wäre mir vor ein paar Jahren sogar halb egal gewesen, aber genauso tut es das andere schwierige Zeitgenossen aus anderen Ländern.
Was ist AppX?
Aus eigener Erfahrung:
– Zur Windows-Firewall: Funktioniert, könnte aber besser managebar sein. svchost und Firewall. Ja schwierig, man muss halt die Woher-Wohin-IPs und Ports kennen, auf die Exe kann man sich da nicht verlassen. Geht irgendwie.
– Applocker ist wesentlich besser als SRP.
– Zu UEFI: Sag Danke zu Apple, die Grundzüge (EFI) sind dort verbrochen worden. MS ist nur nix besseres eingefallen. In diese Partitionen muss man aber normalerweise nicht reingucken, ist wie eine Dampfmaschine, schwarzer Kasten, vorne Kohle und Wasser rein, hinten Dampf und Rauch raus, was dazwischen ist muss man nicht wissen.
– Keylogger? Handschriften? Cortana-Upload? Alufolie zum Braten einwickeln nehmen, nicht als Kopfbedeckung!
– Toredo? Nutz eine RICHTIGE Firewall, kein Spielzeug.
– Copilot? Hab ich in der Firma per GPO komplett abgewürgt.
Würde ja sagen, kommst du bei mich, bringe ich dir bei, wie man damit professionell umgeht. Dann kannste alle deine Gerüchte und Schlechtschwätzerei in die Tonne kippen und mal drüber lachen. Mach ich aber nicht, sonst hab ich ja hier nix mehr lustiges zu lachen.
Im Akamai Artikel sind die dafür nötigen Berechtigungen eh beschrieben nämlich msDS-DelegatedManagedServiceAccount.
Das folgt natürlich dann auch auf "Create all child objects" und hier liegt ja das Problem begraben, warum bekommen user überhaupt "create all child objects permissions" so etwas ist auch ohne dem Sicherheitsproblem großes Pfui für sonst unterprivilegierte User.
Ein ad abzusichern ist mittlerweile unmöglich geworden.
MS kackt auf on prem Kunden sieht man ja bei Exchange was da abgeht.
100% Sicherheit gibts ohnehin nicht, egal ob AD, Windows … oder … Trommelwirbel … Linux. (Das ist doch das, was du meinst, oder?)
Aber hier wie dort kann man einem Angreifer ganz viele Stöckchen in den Weg werfen, so viele, dass er keinen Bock mehr hat, da überall drüber zu klettern.
Das ist in erster Linie kein Problem des Windows Server 2025 sondern ein organisatorisches UserManagement Problem. Und hier sehe ich auch leider die Kehrseite der SecurityBranche, wenn Probleme aufgebauscht werden und "Gefahren" größer gemacht werden als sie sind (s. zB auch curl). Finde ich sehr Schade, weil dann andere schwerer Probleme möglicherweise dafür andererseits nicht die richtige mediale Aufmerksamkeit erhalten. Nicht falsch verstehen, finde es wichtig, dass das Problem angesprochen wird, aber warum soll MS hier einen Patch liefern, was Admins mit zu großzügigen Berechtigungen verbockt haben?
MS hat in diesem Fall Recht, dass es keine schwere Lücke ist, da das Problem in erster Linie darin besteht user mit Pauschalberechtigungen ("create all user child objects") auszustatten, die sie generell nicht haben sollten. Berechtigungen sollten immer granular vergeben werden, wer sich nicht daran hält braucht sich nicht wundern, dass es früher oder später zum Sicherheitsproblem wird.
so wie ich das hier verstanden habe entsteht das Problem nicht durch falsch vergebene Berechtigungen sondern ist als standardverhalten von Microsoft so implementiert.
berichtigt mich gern, sollte ich aber recht haben ist zweifelsfrei Microsoft auch Urheber des Problems und die Tragweite ist groß, wenn es das Standardverhalten von Windows Server darstellt.
Ich werde das in wenigen Stunden bei mir mal prüfen, ich habe Standard-Usern bisher keine zusätzlichen Berechtigungen abseits von Dateifreigaben vergeben. wenn das angeblich alles unproblematisch ist, sollte bei mir ja auch keine Rechteausweitung möglich sein.
BSI trifft nun auch eine Bewertung, CVSS 9.9:
https://wid.cert-bund.de/portal/wid/securityadvisory?name=WID-SEC-2025-1138
Ich hatte es gesehen – danke.