DCOM (Distributed Component Object Model ) ist eine von Microsoft entwickelte Softwarekomponente, mit der COM-Objekte über das Netzwerk miteinander kommunizieren können. Mit diesem Programmierungsmodell, kann ein Computer Programme über das Netzwerk auf einem anderen Computer so ausführen, als würde das Programm lokal ausgeführt.
Entdecken Sie Ihre Schwachstellen und stärken Sie Ihre Resilienz: Führen Sie einen kostenlosen Ransomware-Bereitschaftstest durch
Als Erweiterung von COM löst DCOM einige inhärente Probleme des COM-Modells, um den Einsatz über das Netzwerk zu erleichtern:
Marshalling: Marshalling hilft bei der Anforderung, Daten von einer COM-Objektinstanz auf einen anderen Computer zu übertragen – in Programmierungsterminologie nennt man das „Argumente übergeben“. Wenn ich beispielsweise Zaphods Nachnamen haben möchte, würde ich das COM-Objekt Nachname mit dem Argument Zaphod aufrufen. Die Funktion Nachname würde einen Remote Procedure Call (RPC) ausführen, um vom anderen COM-Objekt auf dem Zielserver den Ausgabewert von Nachname(Zaphod) anzufordern, der dann die Antwort – Beeblebrox – an das erste COM-Objekt zurücksenden würde.
Verteilte Garbage Collection: Die verteilte Garbage Collection wurde entwickelt, um DCOM für hohen Internet-Datenverkehr zu skalieren, und bietet außerdem eine Methode, um abgeschlossene oder nicht mehr genutzte DCOM-Objekte zu löschen oder zurückzuführen. Damit soll eine Überlastung der Webserver-Speicher verhindert werden. Sie kommuniziert der Reihe nach mit den anderen Servern in der Transaktionskette, um ihnen mitzuteilen, dass sie die mit einer Transaktion verbundenen Objekte verwerfen können.
Verwendung von DCE/RPC als zugrunde liegender RPC-Mechanismus: Um die vorstehend genannten Punkte möglich zu machen und zu versuchen, den Webverkehr zu skalieren, hat Microsoft DCE/RPC als die zugrundeliegende Technologie für DCOM implementiert – woher das D in DCOM stammt.
Wie funktioniert DCOM ?
Damit DCOM funktionieren kann, muss das COM-Objekt auf beiden Computern korrekt konfiguriert sein – unserer Erfahrung nach ist das selten der Fall, und wir mussten die Objekte mehrere Male deinstallieren und erneut installieren, bis sie funktionierten.
Die Windows Registry enthält die DCOM-Konfigurationsdaten unter 3 Identifikatoren:
- CLSID – Der Class Identifier (CLSID) ist ein Global Unique Identifier (GUID). Windows speichert einen CLSID für jede in einem Programm installierte Klasse. Wenn Sie eine Klasse ausführen möchten, müssen Sie die korrekte CLSID kennen, um Windows mitzuteilen, wo das Programm zu finden ist.
- PROGID – Der Programmatic Identifier (PROGID) ist ein optionaler Identifikator, mit dem ein Programmierer die kompliziertere und striktere CLSID ersetzen kann. PROGIDs sind üblicherweise einfacher zu lesen und zu verstehen. Eine einfache PRODID könnte in unserem vorherigen Beispiel Anhalter.Nachname sein. Es gibt eine Beschränkung, wie viele PROGIDs denselben Namen haben können, was manchmal Probleme verursacht.
- APPID – Der Application Identifier (APPID) kennzeichnet alle Klassen, die Teil desselben ausführbaren Programms sind, und die für den Zugriff erforderlichen Berechtigungen. DCOM kann nicht funktionieren, wenn die APPID falsch ist. Meiner Erfahrung nach werden Sie wahrscheinlich bei dem Versuch, das Remote-Objekt zu erstellen, Berechtigungsfehler erhalten.
Eine einfache DCOM-Transaktion sieht folgendermaßen aus:
- Der Client-Computer fordert den Remote-Computer auf, ein Objekt mit seiner CLSID oder PROGID zu erstellen. Wenn der Client die APPID übergibt, schlägt der Remote-Computer die CLSID mit der PROGID nach.
- Der Remote-Rechner prüft die APPID und verifiziert, dass der Client zum Erstellen des Objekts berechtigt ist.
- Mit DCOMLaunch.exe (bei einer exe) oder DLLHOST.exe (bei einer dll) wird eine Instanz der vom Client-Computer angeforderten Klasse erstellt.
- Die Kommunikation war erfolgreich!
- Der Client kann nun auf alle Funktionen in der Klasse auf dem Remote-Computer zugreifen.
Wenn die APPID nicht korrekt konfiguriert ist, der Client nicht über die erforderlichen Berechtigungen verfügt, die CLSID auf eine alte Version der exe verweist oder ein anderes von zahlreichen Problemen vorliegt, erhalten Sie voraussichtlich die gefürchtete „Can‘t Create Object“-Benachrichtigung.
DCOM vs. CORBA
Common Object Request Broker Architecture (CORBA) ist eine JAVA-basierte Anwendung, die im Grunde dieselbe Funktion hat wie DCOM. Im Unterschied zu DCOM ist CORBA nicht an ein bestimmtes Betriebssystem (OS) gebunden und kann auf UNIX, Linux, SUN, OS X und anderen UNIX-basierten Plattformen verwendet werden.
Keines der beiden hat sich als sicher oder skalierbar genug erwiesen, um sich als Standard für umfangreichen Webverkehr durchzusetzen. DCOM und CORBA arbeiteten nicht gut mit Firewalls zusammen, weshalb HTTP als Standardprotokoll für das Internet übernommen wurde.
Wozu wird DCOM benötigt?
DCOM hat sich im Wettbewerb das Standardprotokoll für das Internet zu werden nicht durchgesetzt, ist aber weiterhin in das Windows-OS integriert und wird für die Kommunikation zahlreicher Windows-Dienste verwendet – zum Beispiel von der Microsoft Management Console (MMC).
Weil mit DCOM Programme auf anderen Computern ausgeführt werden können, wird es von Hackern für Angriffe über laterale Bewegungen in Ihrem Netzwerk genutzt, um Zugriff auf mehr Daten zu erlangen. Diese Aktivitäten können schwierig zu erkennen sein, weil keine Malware oder Hacker-Tools eingesetzt werden: Für den Zugriff auf DCOM benötigt der Angreifer nur PowerShell.
Die gute Nachricht ist: Selbst wenn der Hacker mit DCOM auf Ihre sensiblen Daten zugreifen kann, hilft Varonis Ihnen dabei, den versuchten Datenzugriff zu entdecken (und zu stoppen). Varonis überwacht die Aktivitäten in Ihren Kerndatenspeichern und analysiert diese Aktivitäten auf anormales Benutzerverhalten und verdächtige Aktivitäten. Sehen Sie selbst, wie Varonis in Ihre Datensicherheitsstrategie passt, mit einer individuellen 1:1-Demo.
