|
  |
 Windows NT/2000/XP/2003: DCOM/RPC Schwachstellen abschotten |
Cerberus 
Chefredakteur
Dabei seit: 23.07.2002
Beiträge: 12.049
Herkunft: Lübeck
 |
|
 Windows NT/2000/XP/2003: DCOM/RPC Schwachstellen abschotten |
     |
Spätestens nach der Attacke des W32.Blaster-Wurms vor beinahe einem Jahr und seiner nicht minder gefährlichen Nachfolger weiß man, wie verwundbar NT-basierte Betriebssysteme sind. Die vorhandenen Sicherheitslücken der DCOM/RPC-Dienste werden dazu genutzt, um ins System einzudringen und unerwünschten Code auszuführen, was zwar in aller Eile durch Patches unterbunden wurde, aber eine zufriedenstellende Lösung boten die Patches nicht an, zumal DCOM/RPC weiterhin offen für Angriffe ist und die werden kommen, soviel ist sicher.
Bevor wir aber zur Abschottung dieser trotz vieler Patches von Microsoft immer noch vorhandenen Angriffspunkte kommen, etwas mehr Hintergrundinformationen.
1. Was ist RPC und wo sind die Schwachstellen?
(Remote Procedure Call oder RPC) ist ein Protokoll, das vom Betriebssystem Windows verwendet wird. RPC bietet eine Methode zur Kommunikation zwischen Prozessen, bei der Programme auf Dienste zugreifen können, die auf einem anderen System ausgeführt werden. Das Protokoll ist vom RPC-Protokoll von OSF (Open Software Foundation) abgeleitet. Es wurden jedoch einige Microsoft-spezifische Erweiterungen hinzugefügt.
Aus einer Racebedingung ergibt sich eine Sicherheitsanfälligkeit bezüglich der Codeausführung von Remotestandorten aus, wenn die RPC-Laufzeitbibliothek speziell gestaltete Nachrichten verarbeitet. Nutzt ein Angreifer diese Sicherheitsanfälligkeit aus, kann er die vollständige Kontrolle über ein betroffenes System erlangen. Im wahrscheinlichsten Fall führt diese Sicherheitsanfälligkeit jedoch zu Denial-of-Service-Angriffen, wie wir sie ja ausführlich erlebt haben.
Der Teil von RPC, der den Nachrichtenaustausch über TCP/IP verarbeitet, weist einen Fehler auf. Der Fehler erfolgt durch falsche Verarbeitung ungültiger Nachrichten. Dieser spezielle Fehler bezieht sich auf eine zugrunde liegende DCOM-Schnittstelle, die TCP/IP-Port 135 abfragt und über die Ports 139 und 445 erreicht werden kann. Durch das Senden einer ungültigen RPC-Nachricht könnte ein Angreifer bewirken, dass der RPC-Dienst auf dem Computer so fehlschlägt, dass willkürlicher Code ausgeführt werden kann.
Ein Angreifer, der diese Sicherheitsanfälligkeit erfolgreich ausnutzt, könnte Code mit der Berechtigung Lokales System auf dem betroffenen System ausführen. Der Angreifer wäre in der Lage, beliebige Aktionen auf dem System auszuführen. Beispielsweise könnte er Programme installieren, Daten anzeigen, ändern bzw. löschen oder neue Konten mit vollständigen Privilegien erstellen.
Jeder Benutzer, der eine TCP-Anforderung an Port 135 auf einem betroffenen Computer übermitteln kann, könnte versuchen, diese Sicherheitsanfälligkeit auszunutzen. Da RPC-Anforderungen in allen Versionen von Windows standardmäßig aktiviert sind, bedeutet dies im Wesentlichen, dass jeder Benutzer, der eine Verbindung mit einem betroffenen Computer herstellen kann, diese Sicherheitsanfälligkeit potenziell ausnutzen kann.
Der Zugriff auf die betroffene Komponente über einen anderen Weg könnte auch möglich sein, indem z. B. durch interaktives Anmelden am System oder durch Verwenden einer anderen Anwendung auf ähnliche Weise, die Parameter lokal oder remote an die gefährdete Komponente übergeben werden.
2. Was ist DCOM und wo sind die Schwachstellen?
DCOM ist die Implementation einer Middleware-Architektur von Microsoft, die auf COM beruht. Sie bildet die Grundlage für OLE, OLE Automation und ActiveX über Rechnergrenzen hinweg. Ursprünglich war DCOM nur für die Windows-Plattform gedacht, wurde von der Software AG aber auch auf einige Unix-Systeme portiert. Die Weiterentwicklung von DCOM wurde inzwischen an die Open Group abgetreten.
DCOM-Objekte können mehrere Schnittstellen implementieren. Die Wiederverwendung erfolgt durch Aggregation auf Binärebene, eine wirkliche Objektorientierung wird aber dabei nicht unterstützt. Jede Schnittstelle bekommt eine eindeutige Identifikation (UUID), einen Naming Service gibt es nicht. Fehlermeldungen müssen als Binärmuster kodiert werden, da kein Exception Handling existiert.
Stub und Skeleton werden von einem IDL-Compiler in eine DLL generiert, auf die Client und Server zugreifen müssen. Die Server werden in der NT-Registry registriert. CORBA-Objekte können in DCOM zugänglich gemacht werden. Umgekehrt sind DCOM-Objekte aber nicht in CORBA-Systemen nutzbar. DCOM unterstützt die Programmiersprachen C, C++, Visual Basic und J a v a (über das properitäre J/Direct).
Auf deutsch übersetzt: per DCOM ist es möglich über mehrere Computer in einem Netzwerk verteilte Anwendungen laufen zu lassen. Nur: Es gibt kaum solche Anwendungen, d.h. diese Schnittstelle wird im Normalfall überhaupt nicht genutzt, nur die schon erwähnten Würmer nutzen sie.
Vielleicht gibt es tatsächlich den einen oder anderen Entwickler, der es in eine Software integrieren konnte, aber das ist sicher die Ausnahme.
Was hindert also uns "normal sterbliche" DCOM abzuschalten?
Nichts...
3. Wie kann ich meinen Rechner schützen?
Zunächst einmal sollte das jeweilige Betriebssystem (Windows NT/2000/XP/2003 Server) auf dem aktuellsten Stand sein, d.h. alle verfügbaren Servicepacks und Patches sollten installiert sein.
Aber reicht allein das schon aus?
Klare Antwort: Nein! aber es unterstützt alle weiteren Maßnahmen, darum sollte man darauf auf keinen Fall verzichten.
Eine gut konfigurierte Firewall ist der nächste Schritt,
um die TCP-Ports 135, 139, 445, 593 und 4444, sowie die UDP-Ports 135, 137, 138 und 69 "stillzulegen" und somit der Attacke ganz gezielt vorzubeugen.
Darüber hinaus sollte man unbedingt die Datei- und Druckerfreigabe abschalten, um beim Surfen z.b. GUI-Angriffe zu verhindern.
Man könnte auch über Start ->Ausführen ->dcomcnfg.exe das Konfigurationstool für DCOM aufrufen und dort unter Komponentendienste -> Computer -> Arbeitsplatz ->Eigenschaften DCOM deaktivieren.
Zu dieser Maßnahme zitieren wir mal "eEye Digital Security":
"We have found that on Windows 2000 with Service Pack levels SP0, SP1, and SP2, disabling DCOM using the DCOMCNFG tool does not actually disable DCOM functionality. As a result, unpatched machines running the affected versions of Windows 2000 are still vulnerable, regardless of whether DCOM is indicated as disabled. We have contacted Microsoft about this problem and they are looking into it."
Mit anderen Worten, diese Vorgehensweise ist auch nur Flickwerk, denn der Rechner bleibt verwundbar.
Trotz alledem gibt es aber Hoffnung,
denn ein sehr gut programmiertes Tool von Gibons Research Corporation hilft hier unterstützend und erfolgreich mit:
DCOM-Bobulator Download
Dieses Tool analysiert zunächst einmal unser System:
Jetzt bewegen wir uns zum Bereich DCOM einschalten/abschalten:
Wir betätigen den Schalter Disable DCOM und starten den Rechner neu:
Nach dem Neustart rufen wir das Tool wieder auf und überprüfen das Resultat:
Das Ergebnis ist das Erhoffte, insofern kehrt doch zumindest so etwas wie Beruhigung ein, denn ein anschließender Versuch über den Port 135 den Redaktionsrechner zu attackieren mißlang nachhaltig.
4. Was sollten Netzwerkadministratoren tun?
Die Situation in einem Netzwerk/Intranet unterscheidet sich sehr von der eines Standalone-Rechners, insofern ist die Vorgehensweise auch eine andere.
Der weitaus wichtigste Faktor beim Beheben dieser Probleme besteht im schnellstmöglichen Installieren von Patches auf allen betroffenen Systemen in eurer Umgebung. Es sind zwar mehrere schadensbegrenzende Strategien verfügbar, diese können jedoch nicht die Patchinstallation ersetzen. Selbst wenn ein System nicht direkt mit dem Internet verbunden ist, kann es Angriffen von Systemen ausgesetzt sein, die unter anderen Umständen vertrauenswürdig sind. Diese Systeme umfassen normalerweise andere Hosts in einem Firmenintranet, Hosts, die sich in ein Organisationsnetzwerk über VPN oder DFÜ einwählen, sowie beliebige andere Hosts, die hinter die Firewall oder die Firewalls gelangen können, welche das Netzwerk vom Internet abschirmen. Schadensbegrenzungen wie z. B. das Deaktivieren von RPC und/oder DCOM in einem Intranet stören die Funktionalität vieler Features erheblich und verhindern, dass Teile des Systems normal betrieben werden können. Aus diesem Grund besteht die bevorzugte Vorgehensweise im schnellstmöglichen Installieren von Patches auf allen Systemen.
Netzwerkadministratoren können das Scanningwerkzeug KB824146scan.exe verwenden, um im Netzwerk Hostcomputer zu identifizieren, auf denen die Sicherheitspatches 823980 (MS03-026) oder 824146 (MS03-039) nicht installiert sind. Ausführliche Informationen zu diesem Werkzeug und den entsprechenden Optionen zum Herunterladen finden wir im Microsoft Knowledge Base-Artikel 827363:
zum Microsoft Artikel
Unter Windows 2000, Windows XP und Windows Server 2003 ist es auch möglich, IPSec zum Blockieren dieser Ports zu verwenden. Um effektiv zu sein, müsste eine Richtlinie jedoch alle gefährdeten Ports vollständig blockieren oder zumindest Sicherheit über diese Ports mit Hosts verlangen, die uneingeschränkt vertrauenswürdig sind und mit Patches versehen wurden. Eine Richtlinie, die allen Computern in einer Domäne vertraut oder nur Sicherheit fordert, nicht jedoch verlangt, ist nur eingeschränkt effektiv. Dies liegt daran, dass eine solche Richtlinie ermöglicht, dass infizierte Computer, die fälschlicherweise für sicher gehalten werden, ungehindert kommunizieren und so den als geschützt geltenden Host angreifen können.
Eine einfache IPsec-Sicherheitsrichtlinie ist zum Download verfügbar. Diese Richtlinie blockiert den gesamten Netzwerkverkehr über den gefährdeten Port. Wenn ihr diese Richtlinie verwenden möchtet, ladet zuerst die Datei IPSecTools.exe an einen bekannten Speicherort auf dem System herunter, und extrahiert sie dann. Öffnen die lokale Sicherheitsrichtlinie, klickt mit der rechten Maustaste auf IP-Sicherheitsrichtlinien auf Lokaler Computer, zeigt auf Alle Tasks, und wählt dann Richtlinien importieren aus. Öffnet anschließend die Richtlinie DCOM.IPSEC, eine der ersten Dateien, die aus dem Archiv IPSecTools.exe extrahiert wurden.
Nachdem die Richtlinie importiert wurde, muss sie zugewiesen werden, denn eine Richtlinie hat erst Auswirkungen, nachdem sie zugewiesen wurde. Dazu klicken wir mit der rechten Maustaste auf die gewünschte Richtlinie, und dann auf Zuweisen. Die Richtliniendatei DCOM.IPSEC enthält zwei Richtlinien. Die eine Richtlinie blockiert den gesamten DCOM-Datenverkehr mit Ausnahme des CIS-Datenverkehrs. Die andere Richtlinie blockiert den gesamten DCOM-Datenverkehr einschließlich des CIS-Datenverkehrs. Verwendet die Richtlinie, die auch den CIS-Datenverkehr blockiert, nicht auf einem System, das HTTP-Datenverkehr verwenden muss, weil diese auch HTTP- und HTTPS-Datenverkehr blockiert.
Beachtet bitte, daß durch diesen Vorgang die Zuweisung aller anderen ggf. zurzeit zugewiesenen Richtlinien aufgehoben wird. Wenn eine Gruppenrichtlinie eine IP-Sicherheitsrichtlinie angibt, besitzt die Gruppenrichtlinie Vorrang vor lokal zugewiesenen Richtlinien. In einer Umgebung, in der eine Gruppenrichtlinie zum Verteilen der IP-Sicherheitsrichtlinie verwendet wird, kann die DCOM-Richtlinie über die Gruppenrichtlinie an alle betroffenen Computer verteilt werden, die Windows 2000 oder höher ausführen.
Wenn ihr detailliertere Steuerungsmöglichkeiten für die IPSec-Richtlinie wünscht, könnt ihr das Werkzeug IPSec_RPC_Blocker verwenden, das im Archiv IPSecTools.exe enthalten ist. Mit diesem Werkzeug können wir eine Richtlinie einrichten, die ein- und ausgehende Anforderungen blockieren und auch einige Ausnahmen festlegen kann. Weitere Informationen zu diesem Werkzeug finden wir in der Datei readme.txt im Verzeichnis IPSec_RPC_Blocker. Beachtet aber, dass die Remoteverwaltung nach dem Anwenden der IPSec-Richtlinien ebenfalls blockiert sein kann. Die Datei readme.txt enthält weitere Informationen zum Entfernen der IPSec-Richtlinien, nachdem ein System mit einem Patch versehen wurde.
Weitere Informationen zum Blockieren von Protokollen und Ports mit Hilfe von IPSec finden Sie im Microsoft Knowledge Base-Artikel 813878:
zum Microsoft-Artikel
Auf einigen Systemen können wir DCOM deaktivieren, um diese Sicherheitsanfälligkeiten zu verhindern. Das Deaktivieren von DCOM beeinträchtigt jedoch auch einige Funktionen, z. B. die Möglichkeit, DCOM remote erneut zu aktivieren. Um DCOM erneut zu aktivieren, benötigen Sie einen physikalischen Zugriff auf das System.
Wenn wir DCOM deaktivieren, sind folgende Funktionen nicht verfügbar:
- Alle COM-Objekte, die remote aktiviert werden können, funktionieren möglicherweise nicht einwandfrei.
- Das lokale COM+-Snap-In kann keine Verbindung zu Remoteservern herstellen, um den COM+-Katalog aufzulisten.
- Die automatische Registrierung von Zertifikaten funktioniert möglicherweise nicht einwandfrei.
- WMI-Abfragen (Windows Management Instrumentation) auf Remoteservern funktionieren möglicherweise nicht einwandfrei.
- Wenn ihr DCOM dennoch deaktivieren möchtet, könnt ihr diesen Vorgang entweder mit Hilfe des Registrierungs-Editors oder des Werkzeugs dcomcnfg.exe durchführen.
Bearbeiten der Registrierung
Startet den Registrierungs-Editor.
Sucht folgenden Pfad:
HKEY_LOCAL_MACHINE\Software\Microsoft\OLE
Ändert den EnableDCOM-Zeichenfolgenwert in N.
Startet das Betriebssystem neu, damit die Änderungen wirksam werden.
Ihr könnt auch folgenden Befehl verwenden:
reg add \\<Hostname>\HKLM\Software\Microsoft\OLE /v EnableDCOM /t REG_SZ /d N /f
Ersetzt <Hostname> durch den Namen des Computers, auf dem DCOM deaktiviert werden soll. Wenn ihr DCOM auf dem lokalen System deaktivieren möchtet, verwendet "localhost" (ohne die doppelten Anführungszeichen).
Verwenden von "DCOMCNFG.EXE"
Führt Dcomcnfg.exe aus.
Wenn ihr Windows XP oder Windows Server 2003 verwendet, führt die folgenden zusätzlichen Schritte durch:
- Klickt unter Konsolenstamm auf den Knoten Komponentendienste.
- öffnet den Ordner Computer.
- Klickt für den lokalen Computer mit der rechten Maustaste auf Arbeitsplatz, und klickt dann auf Eigenschaften.
- Klickt für einen Remotecomputer mit der rechten Maustaste auf den Ordner Computer, zeigt auf Neu, und klickt dann auf Computer.
- Gebt den Computernamen ein.
- Klickt mit der rechten Maustaste auf den Computernamen, und klickt dann auf Eigenschaften.
- Klickt auf die Registerkarte Standardeigenschaften.
- Aktivieren (oder deaktiviert) das Kontrollkästchen DCOM (Distributed COM) auf diesem Computer aktivieren.
Wenn ihr weitere Eigenschaften für den Computer festlegen möchtet, klickt auf Übernehmen, um DCOM zu aktivieren (oder zu deaktivieren). Klickt andernfalls auf OK, um die Änderungen zu übernehmen und Dcomcnfg.exe zu beenden.
Startet das Betriebssystem neu, damit die Änderungen wirksam werden.
Schützen von Systemen, die RPC über HTTP, jedoch nicht DCOM erfordern
In einigen Umgebungen ist DCOM erforderlich, z. B., wenn ein Exchange 2003-Server für Clients außerhalb der Firewall mittels RPC über HTTP veröffentlicht wird. Auch ein solches System kann gegen Angriffe über DCOM geschützt werden, indem der Zugriff auf TCP-Port 593 blockiert wird. Weitere Informationen zur diesbezüglichen Vorgehensweise erhalten wir über Microsoft:
zum Microsoft-Artikel
Wie ihr seht, ist der Einsatz des DCOM-Bobulators in komplexen Netzwerken und Intranets leider nicht das Allheilmittel, hier müßen wir sehr tief in die Materie einsteigen und alles manuell einstellen.
5. Fazit
Diese Thematik wird uns auch weiter auf Trab halten, aber es gibt einige sehr erfreuliche Ansätze, wenn sie auch bisher nicht von Microsoft stammen, denn ob das Servicepack für Windows XP dieses Thema zu den Akten legen wird, darf sehr stark bezweifelt werden. Auf unserer Testplattform mit Windows XP dem Servicepack 2 RC1 waren RPC/DCOM immer noch offen für Attacken, wobei man fairerweise sagen muß, daß die überarbeitete Firewall aus dem Servicepack 2 RC1 Ports nachhaltiger sperren kann. Ein ungutes Gefühl bleibt aber, darum raten wir auch vorerst dazu die vorhandene Firewall entsprechend zu konfigurieren und das Tool DCOM-Bobulator einzusetzen, denn damit ist es derzeit weitestgehenst möglich DCOM/RPC abzuschotten.
Bei unseren Tests fiel uns auf, daß in der Ereignisanzeige abgelegte gelegentliche Fehlermeldungen und Irritationen aus dem DCOM-Bereich nach dem Einsatz des Tools ebenfalls ausblieben, somit bleibt anzumerken:
"it works"
weiterführende Links:
Die W32.Blaster-Wurmattacke...der Workshop !
"Sasser".Wurm-Workaround
Windows 2000/XP: Safer Surfen...der Sicherheitsworkshop
Cerberus
|
|
18.04.2004 19:42 |
|
|
|
|
|
Designed by PC-Experience.de, online seit 06.August 2002
Copyright © 2002 - 2023 PC-Experience.de |
|
