Vor langer Zeit, als das Gras grüner und das Internet sicherer war, wurde die Initiative Web Based Enterprise Management (WBEM) in der IT geboren. Ursprünglich 1996 von Unternehmen wie Cisco Systems, Intel und Microsoft gesponsert, wurde es auf allen Plattformen von MAC OS bis Redhat weit verbreitet und implementiert. WBEM ist klar dokumentiert, basiert auf Internetstandards und bietet einen anderen Ansatz für das Systemmanagement als beispielsweise SNMP.
Die Anpassung von WBEM für Windows heißt WMI (Windows Management Interface) und wurde erstmals in Windows XP eingeführt. Wir wissen, dass Systeme schneller aktualisiert werden als ihre Komponenten, und viele Schwachstellen, die zuvor ein praktisches Verwaltungstool waren, werden von Version zu Version migriert. In diesem Artikel möchte ich beschreiben, wie WMI-Aufgaben ausgeführt werden und wie potenzielle Risiken vermieden werden können.
Aufgrund seiner Leistungsfähigkeit ermöglicht WMI die Verwendung spezieller Dienstprogramme oder Skripte, um verschiedene potenziell gefährliche Aktionen auf einem PC auszuführen, einschließlich des Stoppens kritischer Dienste und sogar des Herunterfahrens des Computers. Beispiel:
(Get-WmiObject Win32_OperatingSystem -EnableAllPrivileges) .Win32Shutdown (5)
(GWMI -Class Win32_Service -Filter "name = 'WinRM'" -ComputerName Server) .StopService () Führen Sie
außerdem dieselben Aktionen auf dem Remotecomputer aus Schreiben Sie einfach wie bei einem lokalen Computer den Namen des gewünschten Computers in den Pfad zum WMI-Objekt.
Der WMI-Namespace ist ein Abschnitt des WMI-Repositorys, in dem WMI-Klassen und -Objekte nach Zweck gruppiert und Sicherheitsattribute für den Zugriff auf Klassen und Objekte in jedem dieser Container definiert werden. Alle Namespaces beginnen mit einem Stamm, der in WMI durch das Schlüsselwort root gekennzeichnet ist. Auf den Namespace folgt ein Schrägstrich nach dem Stammnamen. Namespaces können verschachtelt werden. Die meisten interessanten Klassen und Objekte befinden sich im Stamm- / CIMv2-Namespace.
Einer der vorhandenen Windows WMI-Namespaces kann als Standard ausgewählt werden. Wenn Sie also versuchen, eine Verbindung zu diesem Host herzustellen, ohne einen Namespace anzugeben, werden Sie automatisch mit dem standardmäßig ausgewählten verbunden. In einer Standard-Windows-Installation lautet der Standardbereich root \ cimv2.
Die WMI-Technologie wurde für Windows-Administratoren entwickelt, und das gesamte Sicherheitssystem in WMI ist so konzipiert, dass ein Benutzer auf einem bestimmten PC mithilfe von WMI-Skripten nur die Aktionen ausführen kann, für die ihm Berechtigungen / Berechtigungen erteilt wurden. Dies sind die sogenannten Standardrechte. So wird die WMI-Sicherheit auf Betriebssystemebene implementiert: Wenn der Benutzer auf Betriebssystemebene nicht die Berechtigung zum Neustart des Computers erhält, kann er dies auch mit WMI nicht tun.
Zusätzliche Sicherheitsrichtlinien in WMI werden auf der Ebene des DCOM-Protokollnamespace (Distributed COM) implementiert, einem Objektmodell für verteilte Komponenten. Um diese Arten der WMI-Sicherheit genauer zu betrachten, möchte ich kurz auf die grundlegenden allgemeinen Konzepte zur Sicherheit in Windows eingehen. Und diese Sicherheit basiert auf Benutzernamen und deren Passwörtern.
Informationen zu WMI-Berechtigungen
Wenn ein Benutzer in Windows erstellt wird, wird seinem Systemkonto eine eindeutige Sicherheitskennung (Security IDentifier oder SID) zugewiesen. Basierend auf der SID wird ein Zugriffstoken für den Benutzer generiert, zu dem auch die Liste der Gruppen, zu denen der Benutzer gehört, und die Liste der Berechtigungen, über die er verfügt (z. B. Beenden von Diensten oder Herunterfahren des Computers), hinzugefügt werden. Dieses Zugriffstoken wird auch allen Prozessen zugewiesen, die der Benutzer startet. Zu diesem Zeitpunkt verfügt jedes Objekt des Betriebssystems, auf das das Sicherheitssystem zugreift - eine Datei, ein Prozess, ein Dienst oder etwas anderes - über einen Security Descriptor (SD). Dieser Deskriptor speichert wiederum die Zugriffssteuerungsliste (Access Control List, ACL) für dieses Objekt.
Wenn also ein Benutzer oder ein von ihm gestarteter Prozess auf ein Objekt zugreift, wird das Zugriffstoken dieses Benutzers mit der Zugriffssteuerungsliste verglichen. Abhängig von den Ergebnissen wird die Berechtigung / Berechtigung erteilt oder verweigert, die angeforderten Aktionen für das Objekt auszuführen.
Auf der Namespace-Ebene folgt der WMI-Sicherheitsmechanismus dem allgemeinen Windows-Sicherheitsmodell. Jeder Namespace kann über eine eigene Sicherheitsbeschreibung verfügen, in der eine Zugriffssteuerungsliste (ACL) gespeichert ist.
Jeder ACE-Eintrag (Access Control Entry) enthält Informationen darüber, über welche Berechtigungen ein bestimmter Benutzer verfügt, wenn er verschiedene Vorgänge in diesem Namespace ausführt.
Und hier ist die Liste der Berechtigungen für die Arbeit mit dem Namespace:
Execute Methods. Ermöglicht das Aufrufen von Methoden von Klassen aus einem bestimmten Namespace. Ob die Methode erfolgreich ist oder fehlschlägt, hängt davon ab, ob der Benutzer die Berechtigung hat, den Vorgang auf dem System auszuführen.
Vollständiges Schreiben. Ermöglicht das Erstellen und Ändern von Subnamespaces, Systemklassen und Klasseninstanzen.
Teilweises Schreiben. Öffnet die Möglichkeit, statische Klassen und Instanzen von Nicht-Systemklassen zu erstellen und zu ändern.
Anbieter schreiben.Hiermit können Sie WMI-Anbieterklassen und Instanzen dieser Klassen im CIM-Repository auschecken.
Konto aktivieren. Gewährt Lesezugriff auf den WMI-Namespace. Benutzer mit dieser Berechtigung können Skripte auf dem lokalen Computer ausführen, die WMI-Daten lesen.
Remote aktivieren (Remote aktivieren). Ermöglicht Benutzern den Zugriff auf den WMI-Namespace auf einem Remotecomputer. Standardmäßig verfügen nur Administratoren über diese Berechtigung. Standardbenutzer können WMI-Daten nicht von Remotecomputern abrufen.
Lesen Sie die Sicherheit. Gibt das Recht, die Sicherheitsbeschreibung für den WMI-Namespace ohne Änderung zu lesen.
Sicherheitsregeln ändern (Sicherheit bearbeiten). Ermöglicht das Ändern der Sicherheitsbeschreibung für den WMI-Namespace.
Alle diese ACL-Einträge werden im WMI-Repository gespeichert. WMI-Berechtigungen für einen bestimmten Namespace gelten für alle Subnamespaces und Klassen, die in diesem Namespace definiert sind (geerbt von). Sie können keine eigenen Sicherheitsberechtigungen für eine einzelne WMI-Klasse definieren.
Informationen zur Standardeinstellung
Unter Windows verfügt die Gruppe Administratoren über alle Berechtigungen aus der obigen Tabelle. Für die übrigen Benutzer ist das Konto aktiviert ( Konto aktivieren ). Sie können Methoden aufrufen (Methoden ausführen ) und Instanzen von Anbieterklassen in das CIM schreiben ( Anbieter schreiben ).
Ein Administrator kann die Berechtigungen für bestimmte Benutzer mithilfe des Dienstprogramms "WMI-Einstellungen" (MMC Management Console-Snap-In "wmimgmt.msc") ändern.
Screenshot 1.
Das obige DCOM-Protokoll wird verwendet, um auf die WMI-Infrastruktur eines Remotecomputers zuzugreifen. Der Benutzer führt ein Skript aus oder stellt mithilfe spezieller Dienstprogramme eine Verbindung zu WMI her und fungiert als Client. Das WMI-Objekt, auf das zugegriffen wird, ist der Server. Standardmäßige DCOM-Identitätswechselebenen werden verwendet, um zu bestimmen, welches Zugriffstoken bei der Arbeit mit WMI auf einem Remotecomputer verwendet wird.
Informationen zum Identitätswechsel oder zum Identitätswechsel
Auf Russisch klingt es etwas ungeschickt. Was ist Identitätswechsel und warum wird er benötigt? Dies ist eine Technik, bei der ein Prozess oder System die Anmeldeinformationen eines anderen Sicherheitsprinzips anstelle seines eigenen Sicherheitskontexts verwenden muss, um eine Verbindung zu einer Ressource herzustellen.
Stellen Sie sich vor, ein bestimmter Dienst, der im Sicherheitskontext von LocalSystem gestartet wurde, muss eine Aktion für ein anderes Konto ausführen (z. B. für den aktuellen Benutzer, der am Computer angemeldet ist). In diesem Fall muss der Dienst ein spezielles Zugriffstoken erstellen, das den Sicherheitskontext des Kontos beschreibt, unter dem die angegebene Aktion ausgeführt werden soll.
Um ein solches Zugriffstoken zu erstellen, muss der Dienst die Anmeldeinformationen dieses Benutzers kennen. Wenn dieser Prozess auf dem lokalen Computer ausgeführt wird, erhalten Sie eine Kopie des Zugriffstokens des zuvor registrierten lokalen Benutzers.
Dies erfordert auch, dass der Dienstsicherheitskontext das Recht hat, Zugriffstoken zu erstellen.
Es gibt eine komplexere Version des Identitätswechsels - die Delegierung. Diese Option ist erforderlich, wenn die Verbindung zur Zielressource nicht vom Sicherheitsprinzipal selbst (im obigen Beispiel vom Dienst im Namen des Benutzers), sondern über einen Vermittler (z. B. einen Zwischenserver) hergestellt wird.
Stellen Sie sich vor: Ein Benutzer stellt keine direkte Verbindung zur Datenbank her, sondern über eine Webanwendung auf einem dritten Server. Um eine solche Verbindung herzustellen, muss die Webanwendung vom Sicherheitsprinzipal (unserem Dienst) ein Delegiertenzugriffstoken erhalten. Auf diese Weise kann die Webanwendung das Zugriffstoken des Sicherheitsprinzipals verwenden, wenn eine Verbindung zur Datenbank hergestellt wird.
Im Fall von WMI kann die Delegierung folgendermaßen aussehen: Wir arbeiten an der Administratorstation, stellen über WMI eine Verbindung zu einem bestimmten Server her und starten einen Prozess darauf mit der Execute-Methode der Win32_Process-Klasse. Dieser Prozess ist nichts anderes als ein anderes WMI-Skript, das eine Verbindung zu einem anderen Host im Netzwerk herstellt, um eine Aktion auszuführen. Wenn wir keine Delegierung verwenden, wird das Skript auf dem Zielcomputer im Sicherheitskontext des Zwischenserverkontos gestartet, was bei weitem nicht immer wünschenswert ist. Auf der anderen Seite kommt eine ähnliche Situation mit Delegation im wirklichen Leben ziemlich selten vor.
Informationen zu Identitätswechselstufen
Anonymer Zugriff (anonym). Das Serverobjekt hat kein Recht, Informationen über den Benutzer oder den Prozess abzurufen, der auf dieses Objekt zugreift (mit anderen Worten, das Objekt kann sich nicht als Client ausgeben). Diese Identitätswechselstufe wird in WMI nicht verwendet.
Identifizierung. Das Serverobjekt kann ein dem Client zugeordnetes Zugriffstoken anfordern, sich jedoch nicht als Benutzer ausgeben.
Diese Identitätswechselstufe wird in WMI-Skripten selten verwendet. In diesem Fall können Sie WMI-Skripts nicht auf Remotecomputern ausführen.
Imitieren.Das Serverobjekt kann alle Rechte und Privilegien des Clients verwenden. Es wird empfohlen, diese Identitätswechselstufe in WMI-Skripten zu verwenden, da das WMI-Skript auf dem Remotecomputer dann alle Aktionen ausführen kann, die der Benutzer, der das Skript ausführt, ausführen darf.
DelegierenEin Objekt auf einem Server, auf das ein Client zugreift, kann im Namen des Clients auf ein anderes Objekt auf einem anderen Server verweisen. Durch die Delegierung kann ein Skript das Zugriffstoken des Benutzers verwenden, der es auf dem Remotecomputer ausführt. Das gleiche Token wird für den Zugriff auf WMI-Objekte auf anderen Arbeitsstationen verwendet. Bei diesem Identitätswechsel besteht ein potenzielles Risiko. Die Delegierung in WMI-Skripten sollte nur verwendet werden, wenn dies unbedingt erforderlich ist.
Die Standard-Identitätswechselstufe hängt von der Version von WMI auf dem Zielcomputer ab. In Versionen von WMI unter 1.5 ist die Standardstufe Identifizieren, in Versionen von WMI 1.5 und höher - Identitätswechsel. Bei Bedarf können Sie die Standard-Identitätswechselebene ändern, indem Sie den Namen der erforderlichen Ebene (z. B. Identitätswechsel oder Delegieren) in den Registrierungsschlüssel
HKEY_LOCAL_MACHINE \ Software \ Microsoft \ Wbem \ Scripting \ Standard-Identitätswechselebene eingeben .
Screenshot 2.
Das DCOM-Protokoll bietet auch die Möglichkeit, eine bestimmte Authentifizierungsstufe (Authentifizierung) und Datenschutz für eine WMI-Verbindung anzufordern:
Keine. Keine Authentifikation.
Standardmäßig (Standard). Standard-Sicherheitseinstellungen werden verwendet, um die Authentifizierungsstufe auszuwählen. Dies ist die empfohlene Stufe, da dem Client die vom Server angegebene Authentifizierungsstufe zugewiesen wird.
Verbindungen (Verbinden). Der Client wird nur authentifiziert, wenn er eine Verbindung zum Server herstellt. Nachdem die Verbindung hergestellt wurde, werden keine zusätzlichen Überprüfungen durchgeführt.
Anrufe. Der Client wird zu Beginn jedes Anrufs authentifiziert, während der Server Anforderungen akzeptiert. In diesem Fall werden die Paket-Header signiert, aber die zwischen dem Client und dem Server übertragenen Daten selbst (der Inhalt der Pakete) werden nicht signiert oder verschlüsselt.
Paket (Pkt).Alle Datenpakete, die von Clients an den Server gesendet werden, werden authentifiziert. Wie bei der Authentifizierung auf Anrufebene werden Paket-Header signiert, aber nicht verschlüsselt. Die Pakete selbst sind nicht signiert oder verschlüsselt.
Paketintegrität (Pktlntegrity). Alle Datenpakete werden auf Authentizität und Integrität überprüft. Es wird überprüft, dass der Inhalt des Pakets während der Übertragung vom Client zum Server nicht geändert wurde. In diesem Fall werden die Daten signiert, aber nicht verschlüsselt.
Berechtigungen (PktPrivacy). Alle Datenpakete werden auf Authentizität und Integrität überprüft und die Daten werden signiert und verschlüsselt, um die Vertraulichkeit der übertragenen Daten zu gewährleisten.
Windows-Administratoren kennen die Systemsicherheitseinstellungen, die in den Richtlinien zur Systemsicherheitskonsole und zur Domänengruppe sowie im Abschnitt Zuweisungen von Benutzerrechten verfügbar sind. Eine Reihe von Aktionen mit dem Betriebssystem kann nur ausgeführt werden, wenn der Benutzer oder die Gruppe, zu der er gehört, über das eine oder andere Privileg verfügt. Zu diesen Aktionen gehören beispielsweise: Neustart des Systems (Herunterfahren der Arbeit), Wiederherstellen des Systemstatus aus einer Sicherung oder Ändern der Systemzeit.
Da WMI alle diese Aktionen ausführen kann, haben die WMI-Entwickler einen zusätzlichen Sicherheitsmechanismus bereitgestellt: Selbst wenn ein Benutzerkonto über die für den Betrieb auf dem System erforderlichen Berechtigungen verfügt, kann es diese Aktion erst ausführen, wenn es die Berechtigungen vor dem Ausführen der Aktion explizit aktiviert. Insbesondere wenn ein Administrator ein WMI-Skript ausführt, das einen Systemneustart anfordert, geschieht dies immer noch nicht, bis diese Berechtigung im Skript explizit aktiviert wird.
Zusammenfassung
Was wird empfohlen, um die Sicherheit von WMI-Verbindungen zu gewährleisten:
- Ändern Sie den Identitätswechsel für kritische Dienste (Screenshot 2).
- Konfigurieren Sie die Berechtigungen wmimgmt.msc (Screenshot 1).
- Ändern Sie das Standard-Repository. Dies kann das Musterangriffsszenario unterbrechen.
4. Ändern Sie Personengruppen mit Remote-Start- und WMI-Aktivierungsfunktionen über das DCOMCNFG-Dienstprogramm.
5. Um WMI zu starten, muss ein Benutzer Mitglied der Administratorgruppe oder der DCOM-Benutzer sein. Der Remote-Registrierungsdienst muss ebenfalls verfügbar sein.
6. Firewall konfigurieren - eingehende Verbindungen zu DCOM werden über TCP-Port 135 und (haben?) RPC-Dynamikbereich ausgeführt.
Abschließend möchte ich Folgendes sagen: WMI bietet Geschwindigkeit, Leistung und einfache Ausführung von Befehlen auf Remote-Hosts, und die SQL-basierte Befehlssemantik erleichtert das Erlernen.
Im Internet gibt es viele Informationen zu Hacking- und WMI-Angriffen, da diese zusammen mit Telnet-NTP und DNS in den aktuellen Angriffstrend passen - die Verwendung nativer System-Hacking-Tools. Unsere Aufgabe ist es, diesen Trend zu erfassen und bereits im System eingebettete Gegenmaßnahmen zu finden.
Verfasser: Galiulin Timur GTRch