Freigaben - Das Tor zur Domäne

Freigaben

Das Tor zur Domäne

Michael Schneider
von Michael Schneider
Lesezeit: 8 Minuten

Keypoints

So können Freigaben ihre Domäne kompromittieren lassen

  • Freigaben stellen ein beliebtes Angriffsziel dar
  • Freigaben enthalten oftmals sensitive Informationen wie Zugangsdaten im Klartext
  • Regelmässige Kontrollen helfen Informationsabfluss zu verhindern
  • Mit UNC Hardened Access können Sicherheitsanforderungen für Freigaben definiert werden
  • Monitoring und Honeypots helfen Angriffe zu erkennen

Ein Angreifer im internen Netzwerk, der über Rechte eines Domänen-Benutzers verfügt, versucht in einem nächsten Schritt seine Rechte zu erweitern. Oft ist dazu keine zusätzliche Software oder gar ein Zero-Day-Exploit notwendig. Der Angreifer braucht Spürsinn und ein wenig Geduld. In der Umgebung eines Unternehmens findet ein Angreifer für gewöhnlich viele offene Freigaben, welche Zugangsdaten, technische Details und sensitive Informationen wie Personal- oder Kundendaten beinhalten.

Rechteerweiterung leicht gemacht

Beliebte Ziele sind die Dateien wie unattend.xml und Groups.xml. Die Datei unattend.xml wird für die unbeaufsichtigte Installation von Windows-Systemen verwendet. Die für die Installation benötigten Zugangsdaten für lokale Administratoren-Accounts oder Domänen-Benutzer zur Verbindung eines Systems mit der Domäne werden in dieser Datei hinterlegt. Passwörter liegen dabei entweder im Klartext oder Base64-kodiert vor.

Die Datei Groups.xml ist Bestandteil einer Gruppenrichtlinie, die beispielsweise einen Task einrichtet und enthält die Zugangsdaten des dazugehörigen Benutzers. Das Passwort ist in diesem Fall zwar verschlüsselt, aber es wird immer der gleiche AES-Schlüssel verwendet.

Weitere Möglichkeiten für das Finden von Zugangsdaten sind Batch-, PowerShell- oder VB-Skripte sowie Konfigurationsdateien. Ein Angreifer kann Freigaben manuell oder automatisiert nach solchen Dateien durchsuchen. Die gefundenen Zugangsdaten ermöglichen dann dem Angreifer seine Rechte zu erweitern und er kann so auf weitere Systeme innerhalb der Domäne zugreifen.

Minimierung des Risikos

Obwohl diese Beispiele seit langer Zeit bekannt sind, finden wir bei internen Assessments weiterhin Zugangsdaten in solchen Dateien. Zugegeben, bei einer Vielzahl von Windows-Servern ist es auch kein leichtes Unterfangen dies vollständig zu unterbinden. Vor allem dann, wenn die Freigaben nicht zentral an einer Stelle verwaltet werden. Was muss unternommen werden, um dieses Sicherheitsrisiko minimieren zu können?

Regelmässige Kontrolle

Als erster Schritt geht es darum sich eine Übersicht der Lage zu verschaffen. Um überhaupt die Kontrolle über vorhandene Freigaben zu erlangen, müssen diese bekannt sein. Dabei kann eine IT-Abteilung die gleichen Mittel wie die Angreifer verwenden und untersucht regelmässig die gesamte Domäne nach offenen Freigaben und deren zugänglichen Daten. Das Resultat der Überprüfung sollte anschliessend analysiert, dokumentiert und im Anschluss mit den jeweiligen Applikationsverantwortlichen besprochen werden.

Danach können allfällige Massnahmen, wie das Einschränken der Zugriffsrechte oder das Entfernen der Freigabe, eingeleitet werden. Freigaben sollten an sich nur für Benutzer zugänglich sein, die auch Zugriff auf die Informationen benötigen. Dabei gilt es zu beachten, dass auch Administratoren keinen Zugriff auf solche Freigaben haben müssen. Wird ein operativer Eingriff notwendig, kann sich ein Administrator die notwendigen Rechte selbst erteilen.

Beim Erstellen von Skripten und Konfigurationsdateien sollte darauf geachtet werden, dass keine Passwörter im Klartext gespeichert werden. Entweder werden Passwörter während der Ausführung angegeben oder sind verschlüsselt gespeichert. Wenn beim Durchsuchen der Freigaben Zugangsdaten gefunden werden, sollten diese geändert und die entsprechenden Accounts zusätzlich überwacht werden. Ein allfälliger Missbrauch kann nach Ändern des Passworts entdeckt werden, wenn sich jemand danach versucht mit den nun ungültigen Zugangsdaten anzumelden.

Technische Massnahmen

Neben den Freigaben sollte auch die Konfiguration der Server kontrolliert werden. Das alte Protokoll SMBv1 ist unsicher und muss auf allen Systemen deaktiviert werden. Microsoft beschreibt das Deaktivieren von SMBv1 in einem Support-Artikel. Bevor SMBv1 deaktiviert wird, sollte jedoch noch geprüft werden, ob sämtliche Systeme den Einsatz von SMBv2 und SMBv3 unterstützen. Ned Pyle, Principal Program Manager der Microsoft Windows Server High Availability and Storage Group, führt die Liste SMB1 Product Clearinghouse, welche Hersteller und Produkte enthält, die SMBv1 weiterhin benötigen.

Mit der Funktion UNC Hardened Access können Sicherheitsanforderungen für Freigaben oder Server definiert werden. Die Einstellungen für UNC Hardened Access können über Gruppenrichtlinien für den ganzen Server \\<server> oder einzelne Freigaben \\<server>\<share> definiert werden. Dabei können die Sicherheitseinstellungen unterschiedlich ausgeprägt werden, je nach Schutzbedarf der darauf verfügbaren Informationen. Zurzeit können die drei Sicherheitseinstellungen konfiguriert werden:

Das Protokoll Server Message Block (SMB) selbst kann keine Prüfung auf gegenseitige Authentisierung (Mutual Authentication) durchführen und delegiert diesen Task daher an den Security Support Provider des Betriebssystems. Wenn der Security Support Provider keine erfolgreiche Prüfung durchführen kann, verhindert der SMB-Client den Zugriff auf die Freigabe. Eine gegenseitige Authentisierung kann nur durchgeführt werden, wenn Domänen-Zugangsdaten mittels Kerberos-Authentisierung verwendet werden – die NTLM-Authentisierung wird nicht unterstützt.

Für die Sicherstellung der Integrität aktiviert SMB die Funktion SMB Signing for I/O requests. Wenn die Signierung der SMB-Kommunikation nicht aktiviert werden kann, wird der Zugriff wiederum unterbunden. Idealerweise werden Server und Client standardmässig so konfiguriert, dass SMB Signing immer eingesetzt wird.

Der SMB-Client unterstützt ab Windows 8 und Windows Server 2012 die Funktion SMB Encryption for I/O requests, welche eingesetzt wird um die Privacy-Anforderung zu erfüllen. SMB-Clients, die SMB Encryption nicht unterstützen, können keine Verbindung zur jeweiligen Freigabe aufbauen.

Microsoft empfiehlt für die Freigaben NETLOGON und SYSVOL die Sicherheitseinstellungen RequireMutualAuthentication und RequireIntegrity zu aktivieren. Damit können unter anderem Gruppenrichtlinien-Objekte gegen Spoofing- und Tampering-Angriffe abgesichert werden. Aus Sicher der Sicherheit werden idealerweise auch weitere Freigaben durch UNC Hardened Access geschützt.

Monitoring und Honeypots

Neben regelmässigen Kontrollen und technischen Massnahmen sollten weitere Vorkehrungen getroffen werden. Die Zugriffe auf Datei-Server und Freigaben sollten überwacht und ausgewertet werden. Wenn eine definierte Anzahl von Zugriffversuche festgestellt wird, sollte ein Alarm ausgelöst werden. Zudem können in den Logs der Datei-Server fehlerhafte Zugriffe aufgrund fehlender Berechtigungen ausgewertet werden. Diese stellen ein Indiz dar, dass versucht wird auf vorhandene Freigaben zuzugreifen und zu eruieren, ob der jeweilige Benutzer über die passenden Berechtigungen verfügt.

Als weiterer Schritt können Honeypots für potentielle Angreifer eingerichtet werden. Dabei werden an exponierten Stellen Dateien hinterlegt, die vorgeben legitime Zugangsdaten zu enthalten. So können beispielsweise in Transfer-Verzeichnissen Skripte mit Zugangsdaten hinterlegt werden. Oder es wird eine Gruppenrichtlinie erstellt, die vermeintliche AD-Zugangsdaten enthält. Danach wird der Zugriff auf diese Dateien überwacht, sowie eine Überwachung der Zugangsdaten durchgeführt. Sobald jemand versucht, sich mit diesen Zugangsdaten an ein System anzumelden, wird ein Alarm ausgelöst. Mit diesem Mittel können Angriffe bereits während der Phase der Informationsbeschaffung erkannt werden.

Fazit

Offene Freigaben im Netzwerk stellen ein Risiko für Informationsabfluss von sensitiven Daten wie Zugangsdaten dar. Mit den vorgestellten Massnahmen kann dieses Risiko jedoch eingeschränkt und besser kontrolliert werden. Zudem wird durch die Überwachung der Zugriffe und das Nutzen von Honeypots ein Instrument zur Erkennung von internen Angriffen eingeführt. Damit kann ein vorherrschender Nachteil auch zum Vorteil in der Verteidigung der IT-Infrastruktur genutzt werden – analog zur Kontrolle von PowerShell.

Über den Autor

Michael Schneider

Michael Schneider arbeitet seit dem Jahr 2000 in der IT. Im Jahr 2010 hat er sich auf die Informationssicherheit spezialisiert. Zu seinen Aufgaben gehören das Penetration Testing, Hardening und das Aufspüren von Schwachstellen in Betriebssystemen. Er ist bekannt für eine Vielzahl in PowerShell geschriebener Tools zum Finden, Ausnutzen und Beheben von Schwachstellen. (ORCID 0000-0003-0772-9761)

Links

Werden auch Ihre Daten im Darknet gehandelt?

Wir führen gerne für Sie ein Monitoring des Digitalen Untergrunds durch!

×
Bericht und Dokumentation

Bericht und Dokumentation

Michael Schneider

Einführung von CVSS v4.0

Einführung von CVSS v4.0

Michael Schneider

Rogue Device

Rogue Device

Michael Schneider

Windows LAPS

Windows LAPS

Michael Schneider

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv