von Redaktion IT-A…
Lesezeit
4 Minuten
Pass-the-Hash-Angriffe vermeiden (3)
Mit einer erfolgreichen Pass-the-Hash-Attacke wird ein Angreifer leicht Administrator der Windows-Domäne. Doch weil es technisch sehr schwierig ist, Inhalte des Arbeitsspeichers zu verteidigen, gibt es für die seit mehr als zwei Jahrzehnten bekannte Sicherheitslücke keinen Patch, sondern nur Empfehlungen für eine bessere Organisation der IT. Denn der ursprünglich sehr aufwändige Pass-the-Hash-Angriff ist heutzutage nur noch eine Sache weniger Klicks. 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.
Clientgeschwätz abschalten
Stellen wir uns vor, das Administratorkonto ist aktiv, es hat auf jedem Rechner im Unternehmen dasselbe Kennwort – die ersten drei Probleme dieses Artikels sind also noch nicht beseitigt. Der einfachste Schutz ist: Tür zu. Tatsächlich ist der effektivste Ansatz, die Kommunikation der Clients untereinander zu verhindern. Denn warum sollten Clients untereinander aufeinander zugreifen können? Dort gibt es keinerlei benötigte Ressourcen, nur Administratoren brauchen Zugriff im Supportfall. Die Clients sprechen mit dem Server, aber eben nicht untereinander. Hier bietet sich die Windows Firewall an, die sich über Gruppenrichtlinien steuern lässt.
Ein weiterer einfacher Schritt, die Tür zu schließen, ist die Gruppenrichtlinie "Zugriff vom Netzwerk auf diesen Computer verweigern" ("Computerkonfiguration / Richtlinien / Windows Einstellungen / Sicherheitseinstellungen / Lokale Richtlinien / Zuweisen von Benutzerrechten"). Hier können Sie auf eine mit Windows 8.1 und Server 2012 R2 eingeführte WellknownSID zurückgreifen: "LOKALES KONTO (S-1-5-113)". Konfigurieren Sie diese Richtlinie mit diesem Konto, wird jedem lokalen Benutzerkonto der Zugriff über das Netzwerk verweigert. Das Konto kann nur lokal an der Maschine (zum Beispiel per Teamviewer oder VNC) zum Einsatz kommen, aber nicht per RPC oder RDP genutzt werden, da diese eine Netzwerk-Pre-Authentifizierung verlangen.
Selbst wenn dem Angreifer die Kontoinformationen in Klartext vorliegen und die Firewall jegliche Kommunikation erlaubt, verhindert die lokale Definition der Benutzerrechte einen Zugriff aus der Ferne. Wir reduzieren erneut die Angriffsfläche und sperren den Account praktisch ein. Natürlich ist ein Zugriff mit einem Domänenkonto weiterhin möglich. Der Name des Wellknown Accounts ist wörtlich logisch. Ein Angreifer wird natürlich auf der Maschine Diverses hinterlegen und veranstalten können, aber sich nicht über den ersten einfachen Weg verbreiten können. Der Angreifer benötigt den Hash eines Domänenkontos und das bringt uns zum nächsten PtH-Angriff.
Keine sensiblen Konten an unsicheren Rechnern nutzen
Das grundsätzliche Problem ist weiterhin, dass ein Angreifer mit entsprechenden Rechten und Werkzeugen alle Anmeldeinformationen des angegriffenen Systems in die Hand bekommt. Sie "erleichtern" es einem Angreifer extrem, wenn Sie sich regelmäßig mit einem Konto, das Mitglied der Domänen-Admins ist, am unsichersten Rechner im Unternehmen (wir erinnern uns an den unbeobachteten Rechner hinten an der Laderampe) anmelden. Eigentlich muss sich dieser Administrator dann um Sicherheit keine Gedanken mehr machen, er hat sie schon verspielt. Ein Domänenadmin ist ein Administrator der Domäne, des AD, der zentralen Anmeldedatenbank und Struktur – er ist aber kein Clientadmin.
Neben der Netzwerksegmentierung, die Sie aufbauen sollten, um sicher von unsicher oder vertrauenswürdig von nicht vertrauenswürdig zu unterscheiden, kommen jetzt noch logische Sicherheitsbereiche innerhalb der IP-Infrastruktur hinzu. Innerhalb dieses Bereichs gibt es spezielle Konten mit administrativen Rechten, die aber nur hier diese Rechte haben. Wir erhöhen also die Anzahl der administrativen Accounts für eine Person massiv, es gibt pro Kreis ein Anmeldekonto.
Dass diese Konten über unterschiedliche Kennworte verfügen, sollte spätestens nach diesem Artikel nicht mehr in Frage gestellt werden. Damit das Konstrukt nicht völlig unübersichtlich wird, können Sie hier eventuell auf einem 20 bis 25 Zeichen langen Kennwort aufbauen. Darin integrieren Sie einen 3- oder 4-stelligen dynamischen Anteil für leichteres Merken. Alternativ setzen Sie Werkzeuge wie Keepass ein. Ebenfalls steuern Sie per Richtlinie noch ein Anmelden mit dem "falschen" administrativen Konto außerhalb des definierten Sicherheitsbereichs über "Lokales Anmelden erlauben" (Zuweisen von Benutzerrechten) oder gar einem expliziten "Lokales Anmelden verweigern". Der PtH-Angriff ist weiterhin erfolgreich, er reduziert sich dann aber auf den Sicherheitsbereich und der Flächenbrand lässt sich eventuell verhindern – natürlich nur bezogen auf die jeweilige Größe eines Bereichs.
Anzahl der Konten reduzieren
Das Zauberwort lautet immer Reduktion der Angriffsfläche. Je weniger Konten es gibt, desto geringer ist die Angriffsfläche. Lokal wird es maximal nur ein Konto geben, ein zweites ist sinnlos. Aber das System speichert die letzten zehn Anmeldungen am System, die Anzahl der Cached Credentials sollte also reduziert werden. Sonst kann es dazu kommen, dass ein Domänenadminkonto, das sich vor Jahren an einem Client angemeldet hat, immer noch lokal in den Cached Credentials zu finden ist.
Eine Reduzierung der Cached Credentials auf "0" oder "1" ist schwierig, denn "0" erzwingt einen verfügbaren DC und "1" wird spätestens bei Notebooks benötigt, an denen sich Benutzer offline anmelden. Bei letztgenannter Einstellung gibt es oft ein Workflow-Problem, wenn sich vor dem Notebook-Anwender noch ein Admin für Wartungsarbeiten angemeldet hat. In dem Moment war dieser der letzte angemeldete Benutzer und der eigentliche Anwender kann sich zuhause nicht einloggen, da seine Credentials nicht mehr zur Verfügung stehen. Es hätte zuvor eine Anmeldung im LAN mit DC-Kontakt für den Anwender ausgeführt werden müssen. Das wird in der Praxis gerne vergessen und aufgrund dieser Prozessproblematik wird eine Einstellung von "2" in den meisten Security Guidelines empfohlen. Sie konfigurieren den Wert unter "Computerkonfiguration / Einstellungen / Windows Einstellungen / Lokale Richtlinien / Sicherheitsoptionen Interaktive Anmeldung: Anzahl zwischenzuspeichernder vorheriger Anmeldungen (für den Fall, dass der Domänencontroller nicht verfügbar ist)". Je weniger Konten sich an einem Rechner anmelden, desto geringer ist das Risiko.
Fazit
Jede genannte Maßnahme stellt für sich einen Baustein gegen Pass-the-Hash dar. Manche unserer Bausteine machen es unbequem und verlangsamen Prozesse und Wege. Aber keine der hier genannten Techniken ist Raketenwissenschaft, die nicht umgesetzt werden kann. Gerade in kleinen Unternehmen sind die meisten der genannten Probleme in zwanzig Minuten gelöst.
jp/ln/Mark Heitbrink
Stellen wir uns vor, das Administratorkonto ist aktiv, es hat auf jedem Rechner im Unternehmen dasselbe Kennwort – die ersten drei Probleme dieses Artikels sind also noch nicht beseitigt. Der einfachste Schutz ist: Tür zu. Tatsächlich ist der effektivste Ansatz, die Kommunikation der Clients untereinander zu verhindern. Denn warum sollten Clients untereinander aufeinander zugreifen können? Dort gibt es keinerlei benötigte Ressourcen, nur Administratoren brauchen Zugriff im Supportfall. Die Clients sprechen mit dem Server, aber eben nicht untereinander. Hier bietet sich die Windows Firewall an, die sich über Gruppenrichtlinien steuern lässt.
Die erste Regel lautet: Eingehende Verbindungen im Domänenprofil werden blockiert. Die Ausnahme stellt eingehender Traffic von speziellen Rechnern dar, aber nur im Domänenprofil der Firewall. Sie erstellen demnach zwei Bereiche im Netz: dem einen vertrauen Sie, der andere sind nicht die Standardclients. Eine Segmentierung auf Netzwerkebene macht es wesentlich leichter, um das "Clientnetzwerk", das ab jetzt per Definition nicht mehr vertrauenswürdig ist, von dem Netzwerk zu trennen, aus dem heraus administriert wird und dem Sie vertrauen. Sollte das Segment nicht unterteilt sein, so kann die Windows Firewall auch einzelne IP-Adressen eintragen. Das Regelwerk lässt sich in einem ungerouteten Netzwerk ohne Segmente umsetzen. Es werden nur wenige Workstations freigegeben und über MAC-Reservierungen lassen sich leicht statische IP-Adresszuordnungen definieren.
Bild 3: Über eine Gruppenrichtlinie lässt sich zentral festlegen, dass Clients ihre sicherheitsgefährdenden Zwiegespräche dauerhaft beenden.
Selbst wenn dem Angreifer die Kontoinformationen in Klartext vorliegen und die Firewall jegliche Kommunikation erlaubt, verhindert die lokale Definition der Benutzerrechte einen Zugriff aus der Ferne. Wir reduzieren erneut die Angriffsfläche und sperren den Account praktisch ein. Natürlich ist ein Zugriff mit einem Domänenkonto weiterhin möglich. Der Name des Wellknown Accounts ist wörtlich logisch. Ein Angreifer wird natürlich auf der Maschine Diverses hinterlegen und veranstalten können, aber sich nicht über den ersten einfachen Weg verbreiten können. Der Angreifer benötigt den Hash eines Domänenkontos und das bringt uns zum nächsten PtH-Angriff.
Keine sensiblen Konten an unsicheren Rechnern nutzen
Das grundsätzliche Problem ist weiterhin, dass ein Angreifer mit entsprechenden Rechten und Werkzeugen alle Anmeldeinformationen des angegriffenen Systems in die Hand bekommt. Sie "erleichtern" es einem Angreifer extrem, wenn Sie sich regelmäßig mit einem Konto, das Mitglied der Domänen-Admins ist, am unsichersten Rechner im Unternehmen (wir erinnern uns an den unbeobachteten Rechner hinten an der Laderampe) anmelden. Eigentlich muss sich dieser Administrator dann um Sicherheit keine Gedanken mehr machen, er hat sie schon verspielt. Ein Domänenadmin ist ein Administrator der Domäne, des AD, der zentralen Anmeldedatenbank und Struktur – er ist aber kein Clientadmin.
Neben der Netzwerksegmentierung, die Sie aufbauen sollten, um sicher von unsicher oder vertrauenswürdig von nicht vertrauenswürdig zu unterscheiden, kommen jetzt noch logische Sicherheitsbereiche innerhalb der IP-Infrastruktur hinzu. Innerhalb dieses Bereichs gibt es spezielle Konten mit administrativen Rechten, die aber nur hier diese Rechte haben. Wir erhöhen also die Anzahl der administrativen Accounts für eine Person massiv, es gibt pro Kreis ein Anmeldekonto.
Dass diese Konten über unterschiedliche Kennworte verfügen, sollte spätestens nach diesem Artikel nicht mehr in Frage gestellt werden. Damit das Konstrukt nicht völlig unübersichtlich wird, können Sie hier eventuell auf einem 20 bis 25 Zeichen langen Kennwort aufbauen. Darin integrieren Sie einen 3- oder 4-stelligen dynamischen Anteil für leichteres Merken. Alternativ setzen Sie Werkzeuge wie Keepass ein. Ebenfalls steuern Sie per Richtlinie noch ein Anmelden mit dem "falschen" administrativen Konto außerhalb des definierten Sicherheitsbereichs über "Lokales Anmelden erlauben" (Zuweisen von Benutzerrechten) oder gar einem expliziten "Lokales Anmelden verweigern". Der PtH-Angriff ist weiterhin erfolgreich, er reduziert sich dann aber auf den Sicherheitsbereich und der Flächenbrand lässt sich eventuell verhindern – natürlich nur bezogen auf die jeweilige Größe eines Bereichs.
Anzahl der Konten reduzieren
Das Zauberwort lautet immer Reduktion der Angriffsfläche. Je weniger Konten es gibt, desto geringer ist die Angriffsfläche. Lokal wird es maximal nur ein Konto geben, ein zweites ist sinnlos. Aber das System speichert die letzten zehn Anmeldungen am System, die Anzahl der Cached Credentials sollte also reduziert werden. Sonst kann es dazu kommen, dass ein Domänenadminkonto, das sich vor Jahren an einem Client angemeldet hat, immer noch lokal in den Cached Credentials zu finden ist.
Eine Reduzierung der Cached Credentials auf "0" oder "1" ist schwierig, denn "0" erzwingt einen verfügbaren DC und "1" wird spätestens bei Notebooks benötigt, an denen sich Benutzer offline anmelden. Bei letztgenannter Einstellung gibt es oft ein Workflow-Problem, wenn sich vor dem Notebook-Anwender noch ein Admin für Wartungsarbeiten angemeldet hat. In dem Moment war dieser der letzte angemeldete Benutzer und der eigentliche Anwender kann sich zuhause nicht einloggen, da seine Credentials nicht mehr zur Verfügung stehen. Es hätte zuvor eine Anmeldung im LAN mit DC-Kontakt für den Anwender ausgeführt werden müssen. Das wird in der Praxis gerne vergessen und aufgrund dieser Prozessproblematik wird eine Einstellung von "2" in den meisten Security Guidelines empfohlen. Sie konfigurieren den Wert unter "Computerkonfiguration / Einstellungen / Windows Einstellungen / Lokale Richtlinien / Sicherheitsoptionen Interaktive Anmeldung: Anzahl zwischenzuspeichernder vorheriger Anmeldungen (für den Fall, dass der Domänencontroller nicht verfügbar ist)". Je weniger Konten sich an einem Rechner anmelden, desto geringer ist das Risiko.
Fazit
Jede genannte Maßnahme stellt für sich einen Baustein gegen Pass-the-Hash dar. Manche unserer Bausteine machen es unbequem und verlangsamen Prozesse und Wege. Aber keine der hier genannten Techniken ist Raketenwissenschaft, die nicht umgesetzt werden kann. Gerade in kleinen Unternehmen sind die meisten der genannten Probleme in zwanzig Minuten gelöst.
Im ersten Teil der Workshopserie beschäftigten wir uns mit dem grundlegenden Ablauf der Attacke und erklärten, warum Admin-Accounts oft nur die erste Anlaufstelle sind. Im zweiten Teil veranschaulichten
wir, warum Angreifer sich im Handumdrehen als Administrator ausgeben
können und warum identische Kennworte tunlichst zu vermeiden sind.
jp/ln/Mark Heitbrink
