Freigeben über

Wege der Gefährdung

Siebtes Gesetz: Ein gut verwaltetes Netzwerk ist das sicherste Netzwerk. - Zehn unumstößliche Gesetze der Sicherheitsverwaltung

In Organisationen, die schwerwiegende Kompromittierungen erlebt haben, decken Bewertungen in der Regel auf, dass die Organisationen nur eingeschränkten Einblick in den tatsächlichen Zustand ihrer IT-Infrastruktur haben – und dieser kann sich erheblich vom dokumentierten Zustand unterscheiden. Diese Abweichungen führen zu Sicherheitsrisiken, die die Umgebung einer Kompromittierung aussetzen. Angreifer*innen werden häufig erst entdeckt, wenn die Kompromittierung bis zu dem Punkt fortgeschritten ist, an dem die Angreifer*innen die Umgebung effektiv in Besitz genommen haben.

Detaillierte Bewertungen der AD DS-Konfiguration dieser Organisationen, Public Key-Infrastrukturen (PKIs), Server, Arbeitsstationen, Anwendungen, Zugriffssteuerungslisten (Access Control Lists, ACLs) und andere Technologien decken Fehlkonfigurationen und Sicherheitsrisiken auf, die die anfängliche Kompromittierung hätten verhindern können, wenn Sie behoben worden wären.

Die Analyse der IT-Dokumentation, -Prozesse und -Verfahren identifiziert Sicherheitsrisiken, die durch Lücken in administrativen Verfahren verursacht und von Angreifer*innen ausgenutzt wurden, um letztendlich die Berechtigungen zu erhalten, die verwendet wurden, um die Active Directory-Gesamtstruktur vollständig zu kompromittieren. Eine vollständig kompromittierte Gesamtstruktur ist eine Gesamtstruktur, bei der Angreifer*innen nicht nur einzelne Systeme, Anwendungen oder Benutzerkonten kompromittieren, sondern auch ihren Zugriff höherstufen, um eine Berechtigungsstufe zu erhalten, mit der sie alle Aspekte der Gesamtstruktur ändern oder zerstören können. Wenn eine Active Directory-Installation in diesem Maße kompromittiert wurde, können Angreifer*innen Änderungen vornehmen, die ihnen eine dauerhafte Präsenz in der gesamten Umgebung ermöglichen – oder schlimmer noch, das Verzeichnis und die von ihm verwalteten Systeme und Konten zu zerstören.

Obwohl einige der häufig ausgenutzten Sicherheitsrisiken in den folgenden Beschreibungen keine Angriffe auf Active Directory sind, ermöglichen sie es Angreifer*innen, sich in einer Umgebung einzunisten, die verwendet werden kann, um Rechteausweitungsangriffe (auch als Rechteerweiterung bezeichnet) auszuführen und schließlich AD DS anzusteuern und zu kompromittieren.

In diesem Abschnitt des Dokuments werden die Mechanismen beschrieben, die Angreifer*innen in der Regel verwenden, um Zugriff auf die Infrastruktur zu erhalten und schließlich Rechteerweiterungsangriffe zu starten. Lesen Sie auch die folgenden Abschnitte:

Hinweis

Obwohl in diesem Dokument vorrangig Active Directory- und Windows-Systeme behandelt werden, die Teil einer AD DS-Domäne sind, konzentrieren sich Angreifer*innen selten ausschließlich auf Active Directory und Windows. In Umgebungen mit einer Mischung aus Betriebssystemen, Verzeichnissen, Anwendungen und Datenrepositorys ist es üblich, dass auch andere Systeme als Windows-Systeme kompromittiert wurden. Das gilt insbesondere, wenn die Systeme als Brücke zwischen Windows-Umgebungen und anderen Umgebungen fungieren, z. B. Dateiserver, auf die von Windows- und UNIX- oder Linux-Clients zugegriffen wird, Verzeichnissen, die Authentifizierungsdienste für mehrere Betriebssysteme bereitstellen, oder Metaverzeichnisse, die Daten in unterschiedlichen Verzeichnissen synchronisieren.

AD DS wird aufgrund der zentralisierten Zugriffs- und Konfigurationsverwaltungsfunktionen als Ziel gewählt, die der Dienst nicht nur für Windows-Systeme, sondern auch für andere Clients bietet. Jedes andere Verzeichnis oder jede Anwendung, die Authentifizierungs- und Konfigurationsverwaltungsdienste bereitstellt, kann und wird von entschlossenen Angreifer*innen ins Visier genommen. Obwohl sich dieses Dokument auf Schutzmaßnahmen konzentriert, die die Wahrscheinlichkeit einer Kompromittierung von Active Directory-Installationen verringern können, sollte sich jede Organisation, die nicht mit Windows betriebene Computer, Verzeichnisse, Anwendungen oder Datenrepositorys verwendet, auch auf Angriffe auf diese Systeme vorbereiten.

Erste Angriffsziele

Niemand baut absichtlich eine IT-Infrastruktur auf, die die Organisation einer Kompromittierung aussetzt. Wenn eine Active Directory-Gesamtstruktur neu erstellt wird, ist sie in der Regel tadellos und aktuell. Im Laufe der Jahre werden neue Betriebssysteme und Anwendungen erworben, die der Gesamtstruktur hinzugefügt werden. Da die Verwaltbarkeitsvorteile von Active Directory geschätzt werden, werden dem Verzeichnis immer mehr Inhalte hinzugefügt, mehr Benutzer*innen integrieren ihre Computer oder Anwendungen mit AD DS, und Domänen werden upgegradet, damit diese die neuen Funktionen der neuesten Versionen des Windows-Betriebssystems unterstützen. Im Laufe der Zeit kann es jedoch auch passieren, dass beim Hinzufügen einer neuen Infrastruktur andere Teile der Infrastruktur möglicherweise nicht mehr so gut wie ursprünglich gewartet werden, ordnungsgemäß funktionierende Systeme und Anwendungen keine Aufmerksamkeit mehr erhalten und Organisationen vergessen, dass sie ihre Legacyinfrastruktur nicht entfernt haben. Aus der Bewertung kompromittierter Infrastrukturen geht Folgendes hervor: Je älter, größer und komplexer die Umgebung ist, desto wahrscheinlicher ist es, dass es zahlreiche Instanzen von häufig ausgenutzten Sicherheitsrisiken gibt.

Unabhängig von den Beweggründen der Angreifer*innen beginnen die meisten Verletzungen der Informationssicherheit damit, dass jeweils ein oder zwei Systeme kompromittiert werden. Bei diesen ersten Ereignissen bzw. Einstiegspunkten in das Netzwerk werden häufig Sicherheitslücken ausgenutzt, die hätten behoben werden können. Aus dem Bericht Data Breach Investigations Report 2012 (DBIR), einer jährlich vom Verizon RISK Team durchgeführten Studie, die in Zusammenarbeit mit einer Reihe von nationalen Sicherheitsbehörden und anderen Unternehmen erfolgt, geht Folgendes hervor: 96 % der Angriffe waren nicht hochgradig komplex, und 97 % der Sicherheitsverletzungen wären durch einfache Schutzmaßnahmen oder zwischenzeitliche Kontrollen vermeidbar gewesen. Diese Erkenntnisse könnten eine direkte Konsequenz der folgenden häufig ausgenutzten Sicherheitsrisiken sein.

Lücken in Antiviren- und Antischadsoftwarebereitstellungen

Achtes Gesetz: Ein veralteter Schadsoftwarescanner ist nur unwesentlich besser als gar keiner. - Zehn unumstößliche Sicherheitsgesetze (Version 2.0)

Aus der Analyse der Antiviren- und Antischadsoftwarebereitstellungen von Organisationen geht häufig hervor, dass die meisten Arbeitsstationen in der Umgebung mit aktivierter und aktueller Antiviren- und Antischadsoftware konfiguriert sind. Ausnahmen sind in der Regel Arbeitsstationen, die selten eine Verbindung mit der Unternehmensumgebung oder Mitarbeitergeräten herstellen, und für die Antiviren- und Antischadsoftware daher schwierig bereitzustellen, zu konfigurieren und zu aktualisieren ist.

Serverpopulationen sind jedoch in vielen kompromittierten Umgebungen tendenziell weniger konsistent geschützt. Wie aus dem Bericht Data Breach Investigations Report 2012 hervorging, sind bei 94 % aller Datenkompromittierungen Server involviert, was eine Steigerung um 18 % im Vergleich zum Vorjahr bedeutet. An 69 % der Angriffe war Schadsoftware beteiligt. Bei Serverpopulationen ist es nicht ungewöhnlich, dass Antiviren- und Antischadsoftwareinstallationen inkonsistent konfiguriert, veraltet, falsch konfiguriert oder sogar deaktiviert sind. In einigen Fällen wird die Antiviren- und Antischadsoftware von Administrator*innen deaktiviert, aber in anderen Fällen deaktivieren Angreifer*innen diese Software, nachdem sie einen Server durch andere Sicherheitsrisiken kompromittiert haben. Wenn die Antiviren- und Antischadsoftware deaktiviert ist, installieren die Angreifer*innen Schadsoftware auf dem Server und konzentrieren sich auf die Ausweitung der Kompromittierung auf die gesamte Serverpopulation.

Es ist nicht nur wichtig, dafür zu sorgen, dass Ihre Systeme mit aktuellem, umfassendem Schadsoftwareschutz ausgestattet sind, sondern diese auch auf die Deaktivierung oder Entfernung von Antiviren- und Antischadsoftware zu überwachen und den Schutz automatisch zu reaktivieren, wenn er manuell deaktiviert wird. Obwohl keine Antiviren- und Antischadsoftware die Prävention und Erkennung aller Infektionen garantieren kann, kann eine ordnungsgemäß konfigurierte und bereitgestellte Antiviren- und Antischadsoftwareimplementierung die Wahrscheinlichkeit einer Infektion verringern.

Unvollständiges Patching

Drittes Gesetz: Wenn Sie nicht regelmäßig Sicherheitsfixes anwenden, gehört Ihr Netzwerk nicht lange Ihnen. - Zehn unumstößliche Gesetze der Sicherheitsverwaltung

Microsoft veröffentlicht Sicherheitsbulletins am zweiten Dienstag jedes Monats. In seltenen Fällen können Sicherheitsupdates jedoch auch zwischen den monatlichen Sicherheitsupdates veröffentlicht werden (diese werden auch als „Out-of-Band-Updates“ bezeichnet), wenn festgestellt wird, dass das Sicherheitsrisiko ein dringendes Risiko für Kundensysteme darstellt. Unabhängig davon, ob ein kleines Unternehmen seine Windows-Computer so konfiguriert, dass Windows Update zum Verwalten von System- und Anwendungspatches verwendet wird, oder eine große Organisation Verwaltungssoftware wie Microsoft Endpoint Configuration Manager verwendet, um Patches gemäß detaillierten, hierarchischen Plänen bereitzustellen, patchen viele Kunden ihre Windows-Infrastrukturen relativ zeitnah.

Wenige Infrastrukturen bestehen jedoch nur aus Windows-Computern und Microsoft-Anwendungen, und in kompromittierten Umgebungen wird häufig festgestellt, dass die Patchverwaltungsstrategie der Organisation lückenhaft ist. Windows-Systeme in diesen Umgebungen werden inkonsistent gepatcht. Nicht-Windows-Betriebssysteme werden sporadisch gepatcht, wenn überhaupt. COTS-Anwendungen (Commercial off-the-Shelf, kommerzielle Standardanwendungen) enthalten Sicherheitsrisiken, für die Patches vorhanden sind, die jedoch nicht angewendet wurden. Für Netzwerkgeräte werden häufig die Anmeldeinformationen aus den Werkseinstellungen verwendet, und selbst Jahre nach der Installation werden keine Firmwareupdates aufgespielt. Anwendungen und Betriebssysteme, die von ihren Anbietern nicht mehr unterstützt werden, werden häufig weiter ausgeführt, obwohl sie nicht mehr gegen Sicherheitsrisiken gepatcht werden können. Jedes dieser nicht gepatchten Systeme stellt einen weiteren potenziellen Einstiegspunkt für Angreifer*innen dar.

Die Consumerization von IT-Geräten hat zusätzliche Herausforderungen mit sich gebracht, da mitarbeitereigene Geräte für den Zugriff auf unternehmenseigene Daten verwendet werden und die Organisation möglicherweise wenig bis gar keine Kontrolle über das Patchen und die Konfiguration der persönlichen Geräte der Mitarbeiter*innen hat. Hardware für Unternehmenszwecke wird in der Regel mit entsprechenden Konfigurationsoptionen und Verwaltungsfunktionen bereitgestellt, die jedoch einen geringeren Spielraum bei der individuellen Anpassung und Geräteauswahl mit sich bringt. Für Mitarbeiter*innen vorgesehene Hardware ist mit einer breiteren Palette an Herstellern, Anbietern, Hardwaresicherheitsfeatures, Softwaresicherheitsfeatures, Verwaltungsfunktionen und Konfigurationsoptionen verbunden. Viele Unternehmensfeatures sind möglicherweise gar nicht vorhanden.

Verwaltungssoftware für Patches und Sicherheitsrisiken

Wenn ein effektives Patchverwaltungssystem für die Windows-Systeme und Microsoft-Anwendungen vorhanden ist, wurde ein Teil der Angriffsfläche beseitigt, die nicht gepatchte Sicherheitsrisiken erzeugen. Sofern die nicht mit Windows betriebenen Systeme, nicht von Microsoft stammenden Anwendungen, Netzwerkinfrastruktur und Mitarbeitergeräte jedoch nicht durch Patches und andere Fixes auf dem neuesten Stand gehalten werden, bleibt die Infrastruktur anfällig. In einigen Fällen kann der Anbieter einer Anwendung automatische Updatefunktionen anbieten. In anderen kann es erforderlich sein, einen Ansatz auszuarbeiten, um regelmäßig Patches und andere Fixes abzurufen und anzuwenden.

Veraltete Anwendungen und Betriebssysteme

„Sie können nicht erwarten, dass ein sechs Jahre altes Betriebssystem Sie vor einem sechs Monate alten Angriff schützt.“ – IT-Experte mit zehn Jahren Erfahrung im Schutz von Unternehmensinstallationen

Obwohl „stets aktuell bleiben“ sich nach einem Marketingausdruck anhören mag, stellen veraltete Betriebssysteme und Anwendungen ein Risiko in den IT-Infrastrukturen vieler Organisationen dar. Ein Betriebssystem, das 2003 veröffentlicht wurde, wird möglicherweise weiterhin vom Anbieter unterstützt und mit Updates zur Behebung von Sicherheitsrisiken versorgt, doch dieses Betriebssystem enthält möglicherweise keine Sicherheitsfeatures, die in neueren Versionen des Betriebssystems hinzugefügt wurden. Veraltete Systeme können sogar eine Abschwächung bestimmter AD DS-Sicherheitskonfigurationen erfordern, um den geringeren Funktionsumfang dieser Computer zu unterstützen.

Anwendungen, die für die Verwendung von Legacyauthentifizierungsprotokollen von Anbietern geschrieben wurden, die die Anwendung nicht mehr unterstützen, können in der Regel nicht auf stärkere Authentifizierungsmechanismen umgerüstet werden. Die Active Directory-Domäne einer Organisation kann jedoch weiterhin so konfiguriert sein, dass LAN-Manager-Hashes oder reversibel verschlüsselte Kennwörter zur Unterstützung solcher Anwendungen gespeichert werden. Anwendungen, die vor der Einführung neuerer Betriebssysteme geschrieben wurden, funktionieren unter aktuellen Betriebssystemen möglicherweise nicht gut oder gar nicht, sodass Organisationen immer ältere Systeme und in einigen Fällen sogar überhaupt nicht unterstützte Hardware und Software verwalten müssen.

Selbst in Fällen, in denen Organisationen ihre Domänencontroller auf Windows Server 2012, Windows Server 2008 R2 oder Windows Server 2008 aktualisiert haben, ist es typisch, dass ein erheblicher Anteil der Mitgliedsserverpopulation noch Windows Server 2003, Windows 2000 Server oder Windows NT Server 4.0 (die allesamt gar nicht mehr unterstützt werden) ausführt. Je länger eine Organisation an alternden Systemen festhält, desto größer wird die Diskrepanz zwischen Featuresets, und desto wahrscheinlicher wird es, dass Produktionssysteme nicht unterstützt werden. Je länger eine Active Directory-Gesamtstruktur verwaltet wird, desto häufiger kommt es vor, dass Legacysysteme und -anwendungen nicht in Upgradeplänen berücksichtigt werden. Das kann bedeuten, dass ein einzelner Computer, auf dem eine einzelne Anwendung ausgeführt wird, zu domänen- oder gesamtstrukturweiten Sicherheitsrisiken führen kann, da Active Directory für die Unterstützung der älteren Protokolle und Authentifizierungsmechanismen konfiguriert ist.

Um Legacysysteme und -anwendungen abzuschaffen, sollten Sie sich zunächst darauf konzentrieren, diese zu ermitteln und zu katalogisieren und dann zu bestimmen, ob die Anwendung oder der Host upgegradet oder ersetzt werden soll. Obwohl es schwierig sein kann, Ersatz für hochspezialisierte Anwendungen zu finden, für die es weder Unterstützung noch einen Upgradepfad gibt, können Sie mit dem Konzept „kreative Zerstörung“ möglicherweise die Legacyanwendung durch eine neue Anwendung ersetzen, die die erforderliche Funktionalität bereitstellt. Die Vorkehrungen gegen Kompromittierung werden im Abschnitt „Vorkehrungen gegen Kompromittierung“ dieses Dokuments ausführlicher beschrieben.

Fehlkonfiguration

Viertes Gesetz: Es bringt nicht viel, Sicherheitsfixes auf einem Computer zu installieren, der von Anfang an nicht geschützt war. - Zehn unumstößliche Gesetze der Sicherheitsverwaltung

Selbst in Umgebungen, in denen Systeme im Allgemeinen auf dem neuesten Stand gehalten und gepatcht werden, finden wir häufig Lücken oder Fehlkonfigurationen im Betriebssystem, in Anwendungen, die auf Computern ausgeführt werden, und in Active Directory. Einige Fehlkonfigurationen setzen nur den lokalen Computer einer Kompromittierung aus, aber nachdem ein Computer übernommen wurde, konzentrieren sich Angreifer*innen in der Regel darauf, die Kompromittierung auf andere Systeme und schließlich auf Active Directory auszuweiten. Im Folgenden werden einige der Bereiche erläutert, in denen häufig risikobehaftete Konfigurationen vorgefunden werden.

In Active Directory

Die Konten in Active Directory, die am häufigsten von Angreifer*innen angesteuert werden, sind diejenigen, die Mitglieder der Gruppen mit den höchsten Berechtigungen sind, z. B. Mitglieder der Gruppen für Domänenadministrator*innen (DAs), Unternehmensadministrator*innen (Enterprise Administrators, EAs) oder integrierte Administrator*innen (Built-in Administrators, BAs) in Active Directory. Die Mitglieder dieser Gruppen sollte auf die kleinstmögliche Anzahl an Konten reduziert werden, damit diese Gruppen möglichst wenig Angriffsfläche bieten. Es ist sogar möglich, die dauerhafte Mitgliedschaft in diesen privilegierten Gruppen zu deaktivieren. Das heißt, dass Sie Einstellungen implementieren können, durch die Mitglieder nur temporär zu diesen Gruppen hinzugefügt werden, wenn die domänen- und gesamtstrukturweiten Berechtigungen benötigt werden. Konten mit hohen Berechtigungen sollten nur auf dafür vorgesehenen, sicheren Systemen wie Domänencontrollern oder sicheren Verwaltungshosts verwendet werden. Ausführliche Informationen zur Implementierung dieser Konfigurationen finden Sie unter Reduzieren der Angriffsfläche von Active Directory.

Wenn wir die Mitgliedschaft in den Gruppen mit den höchsten Berechtigungen in Active Directory auswerten, stellen wir häufig eine übermäßige Mitgliedschaft in allen drei Gruppen mit den höchsten Berechtigungen fest. In einigen Fällen finden sich in Organisationen Dutzende, sogar Hunderte von Konten in DA-Gruppen. In anderen Fällen fügen Organisationen Konten direkt zu integrierten Administratorgruppen hinzu, da sie denken, dass die Gruppe weniger privilegiert als die DA-Gruppe sei. Dies ist nicht der Fall. Wir finden oft eine Handvoll dauerhafter Mitglieder der EA-Gruppe in der Stammdomäne der Gesamtstruktur, obwohl EA-Berechtigungen selten und nur vorübergehend erforderlich sind. Es kommt ebenfalls häufig, dass das alltägliche Administratorkonto eines IT-Benutzers oder einer IT-Benutzerin in allen drei Gruppen Mitglied ist, obwohl das nicht notwendig ist. Wie unter Reduzieren der Angriffsfläche von Active Directory beschrieben wird, spielt es keine Rolle, ob ein Konto ein dauerhaftes Mitglied in einer dieser oder allen Gruppen ist: Das Konto kann verwendet werden, um die AD DS-Umgebung und die von dieser verwalteten Systeme und Konten zu kompromittieren oder sogar zu zerstören. Unter Reduzieren der Angriffsfläche von Active Directory finden Sie auch Empfehlungen für die sichere Konfiguration und Verwendung von privilegierten Konten in Active Directory.

Auf Domänencontrollern

Bei der Bewertung von Domänencontrollern stellen wir häufig fest, dass sie nicht anders konfiguriert und verwaltet werden als Mitgliedsserver. Domänencontroller führen manchmal dieselben Anwendungen und Hilfsprogramme aus, die auf Mitgliedsservern installiert sind – und das nicht, weil sie auf den Domänencontrollern benötigt werden, sondern weil die Anwendungen Teil eines Standardbuilds sind. Diese Anwendungen bieten möglicherweise nur wenige Funktionen auf den Domänencontrollern, vergrößern die Angriffsfläche jedoch erheblich, da sie eine Konfigurationseinstellung erfordern, die Ports öffnet, Dienstkonten mit umfassenden Berechtigungen erstellt oder Benutzer*innen Zugriff auf das System erteilt, die nur zum Authentifizieren oder Anwenden von Gruppenrichtlinien eine Verbindung mit dem Domänencontroller herstellen müssen. Bei einigen Sicherheitsverletzungen haben Angreifer*innen die Tools, die bereits auf Domänencontrollern installiert waren, nicht nur verwendet, um Zugriff auf die Domänencontroller zu erhalten, sondern auch, um die AD DS-Datenbank zu ändern oder zu beschädigen.

Wenn wir die Internet Explorer-Konfigurationseinstellungen auf Domänencontrollern extrahieren, stellen wir fest, dass sich Benutzer*innen mit Konten angemeldet haben, die in Active Directory über hohe Berechtigungsgrade verfügen und diese Konten verwendet haben, um über die Domänencontroller auf das Internet und Intranet zuzugreifen. In einigen Fällen haben die Konten Internet Explorer-Einstellungen auf den Domänencontrollern konfiguriert, um das Herunterladen von Internetinhalten zu ermöglichen, und Freewarehilfsprogramme wurden von Websites heruntergeladen und auf den Domänencontrollern installiert. Die erweiterte Sicherheitskonfiguration von Internet Explorer ist standardmäßig für Benutzer*innen und Administrator*innen aktiviert. Häufig stellen wir jedoch fest, dass sie für Administrator*innen deaktiviert wurde. Wenn ein Konto mit hohen Berechtigungen auf das Internet zugreift und Inhalte auf einen beliebigen Computer herunterlädt, ist dieser Computer einem gravierenden Risiko ausgesetzt. Wenn der Computer ein Domänencontroller ist, ist die gesamte AD DS-Installation gefährdet.

Schützen von Domänencontrollern

Domänencontroller sollten als kritische Infrastrukturkomponenten behandelt, strikt geschützt und starrer konfiguriert werden als Datei-, Druck- und Anwendungsserver. Domänencontroller dürfen keine Software ausführen, die für die Funktion des Domänencontrollers oder dessen Schutz vor Angriffen nicht erforderlich ist. Domänencontroller dürfen nicht auf das Internet zugreifen, und Sicherheitseinstellungen sollten durch Gruppenrichtlinienobjekte (Group Policy Objects, GPOs) konfiguriert und erzwungen werden. Ausführliche Empfehlungen für die sichere Installation, Konfiguration und Verwaltung von Domänencontrollern finden Sie unter Schützen von Domänencontrollern vor Angriffen.

Innerhalb des Betriebssystems

Zweites Gesetz: Wenn ein*e Angreifer*in das Betriebssystem Ihres Computers ändern kann, ist es nicht mehr Ihr Computer. - Zehn unumstößliche Sicherheitsgesetze (Version 2.0)

Obwohl einige Organisationen Baselinekonfigurationen für unterschiedliche Servertypen erstellen und nur eine begrenzte Anpassung des Betriebssystems nach der Installation zulassen, wird bei der Analyse kompromittierter Umgebungen häufig eine große Anzahl von Servern ermittelt, die ad hoc bereitgestellt und manuell und unabhängig konfiguriert werden. Die Konfigurationen von zwei Servern, die dieselbe Funktion erfüllen, können völlig unterschiedlich sein. Es kann auch vorkommen, dass keiner der Server sicher konfiguriert ist. Umgekehrt können Serverkonfigurationsbaselines konsistent erzwungen, aber auch konsistent falsch konfiguriert werden. Das heißt, dass Server so konfiguriert werden, dass auf allen Servern eines bestimmten Typs dasselbe Sicherheitsrisiko entsteht. Zu Fehlkonfigurationen zählen Aktionen wie das Deaktivieren von Sicherheitsfeatures, das Erteilen übermäßiger Rechte und Berechtigungen für Konten (insbesondere Dienstkonten), die Verwendung identischer lokaler Anmeldeinformationen für alle Systeme und das Zulassen der Installation nicht autorisierter Anwendungen und Hilfsprogramme, die eigene Sicherheitsrisiken mit sich bringen.

Deaktivieren von Sicherheitsfeatures

Organisationen deaktivieren manchmal Windows Firewall with Advanced Security (WFAS), weil sie der Überzeugung sind, dass WFAS schwierig oder aufwändig zu konfigurieren sei. Ab Windows Server 2008 gilt jedoch: Wenn Rollen oder Features auf einem Server installiert werden, werden diese standardmäßig mit den geringsten Berechtigungen konfiguriert, die für die ordnungsgemäße Ausführung der Rolle oder des Features erforderlich sind. Windows Firewall wird automatisch für die Unterstützung der Rolle oder des Features konfiguriert. Wenn WFAS deaktiviert und keine andere hostbasierte Firewall stattdessen verwendet wird, vergrößern Organisationen die Angriffsfläche der gesamten Windows-Umgebung. Umkreisfirewalls bieten einen gewissen Schutz vor Angriffen, die direkt über das Internet auf eine Umgebung erfolgen, aber nicht vor Angriffen, die andere Angriffsvektoren ausnutzen, z. B. Drive-by-Downloadangriffe oder Angriffe, die von anderen kompromittierten Systemen im Intranet stammen.

Einstellungen für die Benutzerkontensteuerung (User Account Control, UAC) sind manchmal auf Servern deaktiviert, da Administrator*innen die Eingabeaufforderungen als störend empfinden. Obwohl im Microsoft-Support-Artikel 2526083 Szenarien beschrieben werden, in denen UAC unter Windows Server möglicherweise deaktiviert ist, sollten Sie die UAC auf Servern nicht ohne sorgfältige Überlegungen und Recherche deaktivieren, es sei denn, Sie führen eine Server-Core-Installation aus (bei der UAC standardmäßig deaktiviert ist).

In anderen Fällen werden Servereinstellungen mit weniger sicheren Werten konfiguriert, da Organisationen veraltete Serverkonfigurationseinstellungen auf neue Betriebssysteme anwenden, z. B. Windows Server 2003-Baselines auf Computer, auf denen Windows Server 2012, Windows Server 2008 R2 oder Windows Server 2008 ausgeführt wird, ohne die Baselines an die Änderungen im Betriebssystem anzupassen. Anstatt alte Serverbaselines auf neue Betriebssysteme zu übertragen, sollten Sie bei der Bereitstellung eines neuen Betriebssystems die Sicherheitsänderungen und Konfigurationseinstellungen überprüfen, um sich zu vergewissern, dass die implementierten Einstellungen für das neue Betriebssystem anwendbar und geeignet sind.

Erteilen übermäßiger Berechtigungen

In fast jeder von uns bewerteten Umgebung werden lokalen und domänenbasierten Konten auf Windows-Systemen übermäßige Berechtigungen gewährt. Benutzer*innen werden lokale Administratorrechte auf ihren Arbeitsstationen erteilt, Mitgliedsserver führen Dienste aus, die mit Rechten konfiguriert sind, die über die benötigten hinausgehen, und lokale Administratorgruppen in der Serverpopulation enthalten Dutzende oder sogar Hunderte von lokalen Konten und Domänenkonten. Die Kompromittierung von nur einem privilegierten Konto auf einem Computer ermöglicht es Angreifer*innen, die Konten aller Benutzer*innen und Dienste, die sich beim Computer anmelden, zu kompromittieren und die Anmeldeinformationen zu sammeln und zu nutzen, um die Kompromittierung auf andere Systeme auszuweiten.

Pass-the-Hash-Angriffe (PTH) und andere Angriffe zum Diebstahl von Anmeldeinformationen sind heute allgegenwärtig. Das liegt daran, dass frei verfügbare Tools gibt, die das Extrahieren von Anmeldeinformationen anderer privilegierter Konten vereinfachen, wenn ein*e Angreifer*in Zugriff auf Administrator- oder Systemebene auf einem Computer erlangt hat. Auch ohne Tools, die das Sammeln von Anmeldeinformationen aus Anmeldesitzungen ermöglichen, kann ein*e Angreifer*in mit privilegiertem Zugriff auf einen Computer genauso einfach Keylogger installieren, die Tastaturanschläge, Screenshots und Zwischenablageinhalte erfassen. Ein*e Angreifer*in mit privilegiertem Zugriff auf einen Computer kann Antischadsoftware deaktivieren, Rootkits installieren, geschützte Dateien ändern oder Schadsoftware auf dem Computer installieren, die Angriffe automatisiert oder einen Server in einen Host für Drive-by-Downloads verwandelt.

Es werden immer wieder neue Taktiken verwendet, um eine Sicherheitsverletzung über einen einzelnen Computer hinaus zu erweitern, aber der Schlüssel für die Ausweitung der Kompromittierung ist der Erwerb von hochgradig privilegiertem Zugriff auf zusätzliche Systeme. Indem Sie die Anzahl der Konten mit privilegiertem Zugriff auf ein System verringern, verringern Sie nicht nur die Angriffsfläche dieses Computers, sondern auch die Wahrscheinlichkeit, dass ein*e Angreifer*in wertvolle Anmeldeinformationen vom Computer sammelt.

Standardisieren lokaler Administratoranmeldeinformationen

Unter Sicherheitsexpert*innen wird schon lange darüber diskutiert, ob die Umbenennung lokaler Administratorkonten auf Windows-Computern von Nutzen ist. Bei lokalen Administratorkonten ist vor allem wichtig, ob sie auf mehreren Computern mit demselben Benutzernamen und Kennwort konfiguriert sind.

Wenn das lokale Administratorkonto serverübergreifend gleich benannt ist und das dem Konto zugewiesene Kennwort ebenfalls identisch ist, können Angreifer*innen die Anmeldeinformationen des Kontos auf einem Computer extrahieren, auf dem Zugriff auf Administrator- oder Systemebene erlangt wurde. Ein*e Angreifer*in muss nicht zwingend zuerst das Administratorkonto kompromittieren. Es muss nur das Konto eines Benutzers oder einer Benutzerin kompromittiert werden, der oder die Mitglied der lokalen Administratorgruppe ist, oder eines Dienstkontos, das für die Ausführung als LocalSystem oder mit Administratorrechten konfiguriert ist. Der oder die Angreifer*in kann dann die Anmeldeinformationen für das Administratorkonto extrahieren und diese bei Netzwerkanmeldungen auf anderen Computern im Netzwerk verwenden.

Solange ein anderer Computer über ein lokales Konto mit demselben Benutzernamen und Kennwort (oder Kennworthash) wie die angezeigten Kontoanmeldeinformationen verfügt, ist der Anmeldeversuch erfolgreich, und der oder die Angreifer*in erhält privilegierten Zugriff auf den Zielcomputer. In aktuellen Versionen von Windows ist das integrierte Administratorkonto standardmäßig deaktiviert, aber in älteren Betriebssystemen ist es standardmäßig aktiviert.

Hinweis

Einige Organisationen haben lokale Administratorkonten absichtlich aktiviert, in der Annahme, eine Art doppelten Boden zu schaffen, falls alle anderen privilegierten Konten aus einem System ausgesperrt werden. Selbst wenn das lokale Administratorkonto deaktiviert ist und keine anderen Konten verfügbar sind, die das Konto aktivieren oder sich mit Administratorrechten beim System anmelden können, kann das System im abgesicherten Modus gestartet und das integrierte lokale Administratorkonto wie im Microsoft-Support-Artikel 814777 beschrieben reaktiviert werden. Wenn das System darüber hinaus Gruppenrichtlinienobjekte anwendet, kann ein Gruppenrichtlinienobjekt geändert werden, um das Administratorkonto (vorübergehend) zu reaktivieren, oder eingeschränkte Gruppen können so konfiguriert werden, dass der lokalen Administratorgruppe ein domänenbasiertes Konto hinzugefügt wird. Reparaturen können ausgeführt werden, und das Administratorkonto kann wieder deaktiviert werden. Um eine Lateral-Movement-Kompromittierung effektiv zu verhindern, die integrierte Anmeldeinformationen für lokale Administratorkonten verwendet, müssen eindeutige Benutzernamen und Kennwörter für lokale Administratorkonten konfiguriert werden. Informationen zum Bereitstellen eindeutiger Kennwörter für lokale Administratorkonten über ein Gruppenrichtlinienobjekt finden Sie auf TechNet unter Lösung für die Kennwortverwaltung des integrierten Administratorkontos über GPO.  

Zulassen der Installation nicht autorisierter Anwendungen

Erstes Gesetz: Wenn ein*e Angreifer*in Sie dazu bringen kann, sein oder ihr Programm auf Ihrem Computer auszuführen, ist es nicht mehr nur Ihr Computer. - Zehn unumstößliche Sicherheitsgesetze (Version 2.0)

Unabhängig davon, ob eine Organisation serverübergreifend konsistente Baselineeinstellungen bereitstellt, sollte die Installation von Anwendungen, die nicht Teil der definierten Serverrolle sind, nicht zugelassen werden. Wenn Sie die Installation von Software zulassen, die nicht Teil der vorgesehenen Funktion eines Servers ist, werden Server dem Risiko einer versehentlichen oder böswilligen Installation von Software ausgesetzt, die die Angriffsfläche des Servers vergrößert, Sicherheitsrisiken durch Anwendungen ermöglicht oder Systeminstabilität verursacht.

Anwendungen

Wie bereits beschrieben, werden Anwendungen häufig installiert und so konfiguriert, dass Konten mit höheren Berechtigungen als tatsächlich benötigt verwendet werden. In einigen Fällen wird in der Dokumentation der Anwendung angegeben, dass Dienstkonten Mitglieder der lokalen Administratorgruppe eines Servers sein oder für die Ausführung im Kontext von LocalSystem konfiguriert werden müssen. Das liegt häufig nicht daran, dass die Anwendung diese Rechte benötigt, sondern daran, dass es zusätzlich Zeit und Aufwand kostet, die Rechte und Berechtigungen zu bestimmen, die die Dienstkonten einer Anwendung tatsächlich benötigen. Wenn eine Anwendung nicht mit den geringstmöglichen Berechtigungen installiert wird, die für die Funktion der Anwendung und ihrer konfigurierten Features erforderlich sind, wird das System Angriffen ausgesetzt, die Anwendungsberechtigungen nutzen, ohne dass das Betriebssystem selbst angegriffen wird.

Mangel an sicheren Methoden der Anwendungsentwicklung

Die Infrastruktur ist für Geschäftsworkloads vorgesehen. Wenn diese Workloads in benutzerdefinierten Anwendungen implementiert werden, müssen Sie sich davon überzeugen, dass die Anwendungen mit sicheren Best Practices entwickelt werden. Die Analyse der Grundursachen unternehmensweiter Incidents zeigt häufig, dass die erste Kompromittierung durch benutzerdefinierte Anwendungen ausgelöst wird, insbesondere durch solche, die mit dem Internet verbunden sind. Die meisten dieser Kompromisse erfolgen durch bekannte Angriffsmuster wie die Einschleusung von SQL-Befehlen (SQLi) und Cross-Site Scripting (XSS).

Die Einschleusung von SQL-Befehlen stellt ein Sicherheitsrisiko für Anwendungen dar, bei dem eine SQL-Anweisung durch benutzerdefinierte Eingaben abgeändert und zur Ausführung an die Datenbank übergeben wird. Diese Eingabe kann über ein Feld in der Anwendung, einen Parameter (z. B. eine Abfragezeichenfolge oder ein Cookie) oder andere Methoden erfolgen. Das Ergebnis dieser Einschleusung ist, dass die SQL-Anweisung, die an die Datenbank übergeben wird, sich grundlegend von der von Entwickler*innen beabsichtigten unterscheidet. Hier sehen Sie eine häufige Abfrage, mit der eine Kombination aus Benutzernamen und Kennwort ausgewertet wird:

SELECT userID FROM users WHERE username = 'sUserName' AND password = 'sPassword'

Wenn diese vom Datenbankserver empfangen wird, wird der Server angewiesen, die Benutzertabelle zu durchsuchen und jeden userID-Eintrag zurückzugeben, bei dem der Benutzername und das Kennwort mit den von dem oder der Benutzer*in angegebenen übereinstimmen (meistens über ein Anmeldeformular). Entwickler*innen beabsichtigen natürlich in einem solchen Fall, dass nur dann ein gültiger Datensatz zurückgegeben wird, wenn der oder die Benutzer*in einen korrekten Benutzernamen und ein korrektes Kennwort angeben kann. Wenn eine der Angaben falsch ist, kann der Datenbankserver keinen übereinstimmenden Datensatz finden und gibt ein leeres Ergebnis zurück.

Ein Problem tritt ein, wenn ein*e Angreifer*in unerwartete Aktionen ausführt, z. B. die Einschleusung eigener SQL-Anweisung anstelle gültiger Daten. Da SQL vom Datenbankserver direkt interpretiert wird, wird der eingefügte Code so verarbeitet, als hätte ein*e Entwickler*in ihn selbst eingegeben. Wenn ein*e Angreifer*in beispielsweise administrator als Benutzer-ID und xyz OR 1=1 als Kennwort eingegeben hat, würde die folgende Anweisung von der Datenbank verarbeitet werden:

SELECT userID FROM users WHERE username = 'administrator' AND password = 'xyz' OR 1=1

Wenn diese Abfrage vom Datenbankserver verarbeitet wird, werden alle Zeilen der Tabelle in der Abfrage zurückgegeben, da 1=1 immer als zutreffend ausgewertet wird. Daher spielt es keine Rolle, ob der richtige Benutzername und das richtige Kennwort bekannt oder angegeben sind. Das Endergebnis ist in den meisten Fällen, dass der oder die Benutzer*in als erster Benutzer in der Benutzerdatenbank angemeldet wird. Meistens handelt es sich dabei um einen Administratorbenutzer.

Zusätzlich zur Anmeldung können falsch formatierte SQL-Anweisungen wie diese verwendet werden, um Daten hinzuzufügen, zu löschen oder zu ändern oder sogar ganze Tabellen aus einer Datenbank zu löschen. In den extremsten Fällen, in denen die Einschleusung von SQL-Befehlen mit übermäßigen Berechtigungen kombiniert wird, können Betriebssystembefehle ausgeführt werden, um die Erstellung neuer Benutzer zu ermöglichen, Angriffstools herunterzuladen oder andere Aktionen nach Wahl des Angreifers oder der Angreiferin auszuführen.

Beim Cross-Site Scripting liegt das Sicherheitsrisiko in der Ausgabe einer Anwendung. Ein Angriff beginnt damit, dass ein*e Angreifer*in falsch formatierte Daten für die Anwendung bereitstellt. In diesem Fall handelt es sich jedoch um falsch formatierte Daten in Form von Skriptcode (z. B. JavaScript), der vom Browser des Opfers ausgeführt wird. Der Missbrauch eines XSS-Sicherheitsrisiko kann es einem oder einer Angreifer*in ermöglichen, alle Funktionen der Zielanwendung im Kontext des Benutzers oder der Benutzerin auszuführen, der oder die den Browser gestartet hat. XSS-Angriffe werden in der Regel durch eine Phishing-E-Mail initiiert, die den*die Empfänger*in animiert, auf einen Link zu klicken, der eine Verbindung mit der Anwendung herstellt und den Angriffscode ausführt.

XSS-Exploits werden häufig in Onlinebanking- und E-Commerce-Szenarios genutzt, in denen ein*e Angreifer*in im Kontext des oder der ausgenutzten Benutzer*in Einkäufe tätigen oder Geld überweisen kann. Im Falle eines gezielten Angriffs auf eine benutzerdefinierte webbasierte Identitätsverwaltungsanwendung kann es einem oder einer Angreifer*in gelingen, eigene Identitäten zu erstellen, Berechtigungen und Rechte zu ändern und eine systemischen Kompromittierung zu verursachen.

Eine umfassende Erläuterung von Cross-Site Scripting und der Einschleusung von SQL-Befehlen geht über den Umfang dieses Dokuments hinaus. Das Open Web Application Security Project (OWASP) hat jedoch eine Top-10-Liste mit ausführlichen Erläuterungen zu Sicherheitsrisiken und Gegenmaßnahmen veröffentlicht.

Unabhängig von den Investitionen in die Infrastruktursicherheit wird die Umgebung anfällig für Angriffe, wenn schlecht entworfene und geschriebene Anwendungen in der Infrastruktur bereitgestellt werden. Selbst gut geschützte Infrastrukturen können häufig keine effektiven Gegenmaßnahmen für diese Anwendungsangriffe bieten. Erschwerend kommt hinzu, dass schlecht entworfene Anwendungen möglicherweise nur funktionieren, wenn Dienstkonten übermäßige Berechtigungen für die Anwendung erteilt werden.

Der Microsoft Security Development Lifecycle (SDL) besteht aus einer Reihe struktureller Prozesskontrollen, die zur Verbesserung der Sicherheit beitragen – beginnend bei der Erfassung von Anforderungen über den Lebenszyklus der Anwendung bis zur Außerbetriebnahme. Diese Integration effektiver Sicherheitskontrollen ist nicht nur aus Sicherheitsperspektive von entscheidender Bedeutung, sie ist auch wichtig, um sicherzustellen, dass die Anwendungssicherheit kosteneffektiv und auf den Zeitplan ausgerichtet ist. Wenn eine Anwendung erst auf Sicherheitsprobleme bewertet wird, wenn der Code praktisch fertiggestellt ist, muss die Organisation Entscheidungen zur Anwendungssicherheit treffen, wenn die Anwendung kurz vor der Bereitstellung steht oder bereits bereitgestellt wurde. Eine Organisation kann die Anwendungsfehler beheben, bevor die Anwendung in der Produktion bereitgestellt wird, was Kosten und Verzögerungen verursacht, oder die Anwendung kann mit den bekannten Sicherheitslücken in der Produktion bereitgestellt werden, wodurch die Organisation der Kompromittierung ausgesetzt wird.

Manche Organisationen benennen die Kosten für die Behebung eines Sicherheitsproblems in Produktionscode auf 10.000 USD pro Problem – und Anwendungen, die ohne einen effektiven SDL entwickelt wurden, enthalten durchschnittlich mehr als zehn Probleme mit hohem Schweregrad pro 100.000 Codezeilen. Bei großen Anwendungen können die Kosten sprunghaft ansteigen. Viele Unternehmen legen für die letzte Code-Review-Phase des SDL hingegen eine Benchmark von weniger als einem Problem pro 100.000 Codezeilen fest. Bei hochgradig risikobehafteten Anwendungen in der Produktion werden sogar null Fehler angestrebt.

Durch die Implementierung eines SDL wird die Sicherheit verbessert, indem sicherheitsrelevante Anforderungen frühzeitig in die Anforderungserfassung und den Entwurfsprozess einer Anwendung einbezogen werden. Ein SDL ermöglicht die Bedrohungsmodellierung für hochgradig risikobehaftete Anwendungen, erfordert die effektive Schulung und Überwachung der Entwickler*innen und setzt eindeutige, konsistente Codestandards und Programmiermethoden voraus. Die Auswirkung eines SDL ist eine erhebliche Verbesserung der Anwendungssicherheit bei gleichzeitiger Senkung der Kosten für die Entwicklung, Bereitstellung, Wartung und Außerbetriebnahme einer Anwendung. Eine ausführliche Erläuterung des Entwurfs und der Implementierung eines SDL über den Umfang geht über dieses Dokument hinaus. Ausführliche Anleitungen und Informationen finden Sie jedoch unter Microsoft Security Development Lifecycle.