Risiko lokaler Administrator
Das Speichern von Authentifizierungsinformationen im System können Sie nicht verhindern, aber das erste Ziel des Angriffs ist immer der Administrator, denn dieser ist immer vorhanden. Angreifer können einen Client wählen, der "hinten an der Laderampe" steht, den niemand beobachtet und bei dem es unbemerkt bleibt, wenn der Angreifer ihn aufschraubt. Der Bösewicht wird aufgrund diverser Zugangsbeschränkungen nicht direkt in ein Rechenzentrum oder einen Serverraum einbrechen, aber das schwächste Glied der Kette, einen Client der voll "Domain Joined" ist, hat keiner im Blick.

Hier nun liest der Angreifer den Kennwort-Hash des lokalen Administrators aus, erhält "<MeinClient>\Administrator" und den Hash. Die Hashes sind bei Microsoft nicht je System individualisiert, sondern dasselbe Kennwort erzeugt an jedem System denselben Hash. Jeder Admin weiß, dass er sich an jedem System anmelden kann, wenn er das Kennwort des lokalen Administrators kennt. Er muss nur in der GUI bei der Nachfrage "<Zielcomputer>\ Administrator" verwenden und das Kennwort eintippen. Genau das umgehen nun Tools wie mimikatz: Der Angreifer ist Administrator, er darf alles, kann sich im Systemkontext als "Authentifizierter Benutzer" am AD anmelden (genau genommen hat das das System längst erledigt) und generiert eine Liste aller Computer im AD. Jetzt erzeugt er für jeden Computer den Eintrag "Computername\Administrator + Hash" im eigenen System, sodass der eigene Client und jedes Ziel davon ausgehen, dass er sich erfolgreich angemeldet hat. Ab diesem Moment sitzt der Angreifer auf jedem Computer als Administrator und wartet auf weitere Anmeldungen.

Die Lösung ist klar: Deaktivieren Sie das Administratorkonto und erzeugen Sie keine eigenen Administratoren lokal an den Systemen! Diese werden schlicht nicht benötigt. Das Sicherheitsrisiko steht in keinerlei Verhältnis zum angeblichen Nutzen und jeglichem Argument der Verwendung. Professionelle Administration erfolgt über ein Domänenkonto in der Gruppe der Administratoren.

Im Regelbetrieb wird der lokale Administrator nicht benötigt, außer der Client verliert seine Verbindung zur Domäne. "Ha! Jetzt brauch ich doch das lokale Konto", sagt der Admin und hat Recht, doch wie gerade geschildert ist der "Angriff " über Utilman in fünf Minuten erledigt. Das System wird legal vom Admin selbst gehackt und das Konto per net user Administrator /active:yes kurzfristig aktiviert. Der Domain Join erfolgt und anschließend wird der Account über eine Gruppenrichtlinie wieder deaktiviert ("Computerkonfiguration /... / Sicherheitsoptionen / Konten: Administratorkontostatus").

Ist das System mit BitLocker verschlüsselt, dauert es zwei Minuten länger, denn vor dem Offline-Zugriff muss per manage-bde der Wiederherstellungsschlüssel der Platte eingegeben werden, damit sie entsperrt wird. Ein aktives Administratorkonto ist nur an Systemen akzeptabel, die sich nicht direkt per Turnschuh erreichen lassen. Alle lokalen, physisch erreichbaren Rechnern kommen ohne aktives Administratorkonto aus. Führen Sie sich vor Augen, dass wir hier nur von einem minimal längeren Prozess sprechen. Das Argument "wenn der Rechner aus der Domäne fliegt" ist als Vorfall viel zu selten und der Umweg zu kurz, um das Risiko zu akzeptieren, auf allen Rechnern das Konto aktiviert zu lassen. Hier sollten IT-Verantwortliche ehrlich zu sich selbst sein und die Bequemlichkeit zurückstellen.

Für eine Systemverwaltung ohne dieses Konto sind eine klare Struktur und die Möglichkeit, Domänenkonten zur Administration zu verwenden, notwendig. Sie sollten daher eine Delegation [2,3] etablieren. Oftmals findet sich der lokale Administrator zur Administration im Tagesgeschäft. Das ist ein klares Zeichen, dass in der Organisation noch nie über Delegation nachgedacht wurde oder diese schlecht umgesetzt ist. Das gehört schleunigst auf den Hausaufgabenzettel.

Identische Kennworte verhindern
Die Verwendung identischer Kennworte einzuschränken und diese gegen individuelle Kennworte an jedem System auszutauschen, erfordert nur minimal mehr Aufwand als die Tilgung des lokalen Adminkontos. Seit Mai 2015 gibt es von Microsoft das Tool "Local Admin Password Solution" (LAPS) [4], das schon seit 2012 als Freeware – damals noch ohne Support – existiert.

Die Software besteht aus einer ClientDLL, die sich vollständig in den Gruppenrichtlinienprozess einklinkt und damit zentral administrierbar ist. Sie bringt alle notwendigen Skripte zur Installation als PowerShell-Cmdlet mit. Die DLL schreibt ein individuelles Kennwort (Klartext) in das betreffende Computerobjekt des AD und fügt ein Ablaufdatum hinzu.

Damit das funktioniert, müssen Sie diese vier Punkte erledigen:

1. Das AD benötigt zwei neue Attribute (Schemaerweiterung), die bei der Installation einmalig erzeugt werden. Diese sind bei Microsoft dokumentiert und supported.
2. Der Computer benötigt das sogenannte "SELF"-Schreibrecht auf diese beiden Attribute, damit er selbst als Computersystem die Werte in sein Computerobjekt im AD schreiben kann.
3. LAPS müssen Sie per Registry-Ke y (Gruppenrichtlinie) anschalten.
4. Die DLL muss auf dem Computer vorhanden sein.

Wer Richtlinien (also etwa ein GPOTeam) an den Client verteilen darf, muss den Registry-Key zur Aktivierung von LAPS verteilen. Das kann per Gruppenrichtlinien geschehen. Zuletzt muss aber auch die DLL und damit das Clientpaket an den Computer ausgeliefert werden, was durch das Deployment-Team oder die Clientbeauftragten erfolgt. Logischerweise müssen die Attribute auch vor lesendem Zugriff durch Unbefugte/Authentifizierte Benutzer geschützt werden, die dafür notwendigen Skripte sind ebenfalls Bestandteil des Installers.

LAPS ist eine tolle Lösung, die wir immer integrieren würden, da sie technisch sauber ist, einen geringen Einfluss auf die Struktur hat und sehr trivial in der Handhabung ist. Trotzdem sollten Sie daran denken, dass diese Komponente überhaupt nur deswegen notwendig ist, weil das Administratorkonto (oder ein alternatives, einfach zu erratendes Konto) aktiv ist.

Wäre das Konto deaktiviert, ließe sich zwar der Hash auslesen, aber kein Angreifer kann sich an einem anderen Computer anmelden, da dort das Konto deaktiviert ist. Wir setzen mit LAPS eine Technik ein, die wir eigentlich gar nicht benötigen, da es schon einen einfacheren Weg gibt.

Wir halten jedoch eine Filterung von LAPS auf Systemen mit aktivem Administratorkonto und jenen ohne, wo LAPS nicht benötigt wird, für zu viel Arbeit. Es ergeben sich False Positives und die Aufgabe, den Filter zu pflegen, verursacht mehr Arbeit als das Erzeugen eines individuellen Kennworts auf jedem Rechner durch einen automatisierten Systemprozess.

Allerdings bietet LAPS ein interessantes Bonusfeature: Sogenannte "OneDay Admins". Dabei wird das Kennwort zum Beispiel an einen Techniker oder Dienstleister herausgegeben. Dieser kann es anschließend ändern und er ist lokaler Administrator für einen bestimmten Job, etwa für die Einrichtung einer Software. LAPS bekommt von der Änderung nichts mit und der Admin kann gleichzeitig mit der Herausgabe das Ablaufdatum des Kennworts setzen. So endet der Zugang, wenn der Techniker seine Arbeit erledigt hat. Die Gruppenrichtlinie prüft in jedem Prozesslauf, ob das Kennwort abgelaufen ist. Falls ja, wird wieder ein individuelles Kennwort erzeugt und im AD-Computerobjekt dokumentiert.

Seite 2: Identische Kennworte verhindern

Im dritten und letzten Teil der Workshopserie geht es unter anderem darum, warum sie überflüssiges Clientgeschwätz abschalten und generell die Anzahl der Konten reduzieren sollten. Im ersten Teil beschäftigten wir uns mit dem grundlegenden Ablauf der Attacke und erklärten, warum Admin-Accounts oft nur die erste Anlaufstelle sind.

<< Vorherige Seite

Seite 2 von 2

jp/ln/Mark Heitbrink

[2] www.gruppenrichtlinien.de/de/artikel/verwaltung-der-lokalen-administratoren/
[3] www.gruppenrichtlinien.de/artikel/lokaler-administrator-install-agent-delegation-pro-computer/
[4] www.microsoft.com/en-us/download/details.aspx?id=46899