[English]Die Übernahme eines eines Domain Controllers durch geklaute Admin-Passwörter ist ja ein beliebter Ansatz von Cyber-Kriminellen. Ich bin über Twitter auf einen Artikel aufmerksam geworden, der sich mit der Frage befasst, wo Angreifer auf SYSVOL und über GPO-Vorgaben Kennwörter finden könnten.
Anzeige
Vorab: Ich habe keine Ahnung, ob und wie das für Administratoren in diesem Bereich relevant ist – vielleicht ist es ein alter Hut. Dann lasst es links liegen. Andernfalls ist es vielleicht eine Sonntagslektüre wert.
Finding Passwords in SYSVOL & Exploiting Group Policy Preferences, by @PyroTek3https://t.co/d45cASXasa
— DirectoryRanger (@DirectoryRanger) May 14, 2020
Die Details finden sich im englischsprachigen Artikel, der in obigem Tweet verlinkt wurde. Vielleicht ist es ja hilfreich.
2015
Naja viele Punkte sind nobrainer.
Microsoft Local Administrator Password Solution (LAPS) ist hier schon länger im Einsatz, zumal man das mit jeder zentralen Softwareverwaltung so einfach ausrollen kann. Genau weil man sich im Zweifel eben nicht mit dem Domänen-Admin-Rechten auf Computern einloggt. Siehe der Vorfall bei heise.de
Ansonsten macht man die dort beschriebenen Sachen auch nicht.
Der Artikel ist von 2015 und jemandem der Kennwörter mit GPOs setzt ist eh nicht zu helfen
Das ist immer wieder für einen Lacher gut.
Interessant ist hierbei, dass die ersten Artikel zur Ausnutzung dieses Umstandes etwa 2012 im Netz zu finden waren, obwohl es ja bereits in Server 2008 zum Einsatz kam und nachweislich auch 2007 schon samt Schlüssel bei MSDN dokumentiert war. Fast 5 Jahre lang hat das niemand hinausposaunt, obwohl es vermutlich schon einige wussten und die Konsequenzen verstanden hatten-
Auch frage ich mich schon, warum so viele Admins dieses Feature überhaupt benutzen wollten – das Kennwort wird verschlüsselt in der GPO gespeichert, aber logischerweise haben alle Computer selbst ja den Schlüssel inne und somit auch potentiell Dritte. Das also für überall eingesetzte Adminkonten zu verwenden, war somit von vornherein (h)ausgemachter Wahnsinn.
1. Desktopstandard hat entschieden, das es aufgrund der geringem Kundenanzahl ein akzeptables Risiko darstellt, da sich diese Kunden kaum sehen und es eine geringe Angriffsfläche darstellt.
2. der zwang zur Offenlegung der Verschlusselungstechnik kam später durch die EU import Richtlinien. Die Technik ist von 2004/2005
3. der Kauf durch Microsoft im September 2006 hat es erst in die Masse gebracht und dadurch wurde es kritisch.
Alle Windows Systeme wurden nun angreifbar, statt der wenigen Kunden von Desktopstandard.
Zudem war die anforderung, das die Schlüssel / Schloss Kombination silent mit boardmitteln sicher verteilbar sein musste. Da war der hardcodierte Weg in der DLL der einfachste.
Wie gesagt, das man den aufgrund einer import Richtlinie offen legen musste ist doof gelaufen aber keinesfalls von vornherein Wahnsinn.
Moin Mark.
Wir haben den Desktop-Standard-Kram auch 2003 schon unter Win2k eingesetzt – ist mir wohlbekannt, dass es von denen stammt. Ob MS nun zur Offenlegung gezwungen wurde, oder nicht – ihnen ist irgendwann klar geworden, wie gefährlich es ist – unter Server 2012 war ja zumindest schon eine Warnung in der GPP GUI zu lesen, bevor es dann später rausgenommen wurde.
Wenn ich von Wahnsinn schreibe, dann meine ich ja nicht, dass der Schlüssel offengelegt wurde, sondern, dass Admins reihenweise so vorgegangen sind: "oh, wir können nun Konten samt Kennwörtern verteilen, cool. Wie wird denn das Kennwort übertragen, etwa plain text!? Nee, verschlüsselt, na dann ist ja gut!" – und das obwohl das samt Schlüssel alles dokumentiert ist seit 2007. Ich habe nur meine Verwunderung darüber ausgedrückt, dass es bis zum Patch überhaupt keine Wellen geschlagen hat, obwohl die Doku öffentlich war und 5 Jahre älter ist.
Im Jahr 2014 hat Microsoft diese Lücke geschlossen. Ein gewissenhafter Admin hat davon nichts mehr im Netz.
Weitere Details: https://www.gruppenrichtlinien.de/artikel/passworte-in-gruppenrichtlinienobjekten-entfernen/
Ich habe mal den Befehl "findstr /S /I cpassword \\\sysvol\\policies\*.xml" über unser AD laufen lassen, Ergbins: Nichts.