MS09-012: Hinweise zum Sicherheitsupdate für die Windows-Dienstisolierung vom April 2009

Hilfe und Support zum Sicherheitsupdate

Privatbenutzer erhalten kostenlosen Support über die Hotline-Nummer 1-866-PCSAFETY (nur USA und Kanada) oder über die örtliche Microsoft-Niederlassung. Weitere Informationen zur Kontaktaufnahme mit der zuständigen Microsoft-Niederlassung bei Problemen mit Sicherheitsupdates finden Sie auf der internationalen Supportwebsite von Microsoft:

http://support.microsoft.com/common/international.aspx?rdpath=4 Kunden in Nordamerika können über die folgende Website von Microsoft auch direkten Zugriff auf unbegrenzten kostenfreien E-Mail-Support oder unbegrenzten Einzelsupport per Chat erhalten:

http://support.microsoft.com/oas/default.aspx?&prid=7552 Unternehmenskunden können bei Problemen mit Sicherheitsupdates ihre üblichen Supportkontakte nutzen.

Bekannte Probleme bei diesem Sicherheitsupdate

• Problembeschreibung
  
  Nach Installation dieses Updates auf einem Server mit mehr als vier CPU-Kernen, auf dem Microsoft ISA Server Standard Edition ausgeführt wird, wird der Microsoft ISA Server-Steuerungsdienst nicht gestartet. Im Anwendungsprotokoll wird darüber hinaus die Ereigniskennung 14109 protokolliert.
  
  Ursache
  
  Dieses Problem kann auftreten, wenn vor der Installation des Sicherheitsupdates ein Hotfix angewendet wurde, das nach dem 7. Februar 2007 veröffentlicht wurde. Das Problem wird durch eine Änderung an der Art und Weise verursacht, wie Windows die Anzahl der verfügbaren CPUs meldet. Die Änderung wurde erstmals in Hotfix 932730 eingeführt und bewirkt, dass Windows Server 2003 diese Informationen exakt wie Windows Vista und Windows Server 2008 meldet. Wenn Windows mehr als vier CPU-Kerne meldet, interpretiert der ISA Server-Steuerungsdienst diese Information wie "mehr als vier CPUs". Dadurch wird eine Warnung ausgelöst, und der Microsoft ISA Server-Steuerungsdienst sowie alle abhängigen Dienste werden heruntergefahren.
  
  Hinweis Hotfix 932730 wurde in kein Windows Server 2003 Service Pack integriert.
  
  Weitere Informationen zu Hotfix 932730 finden Sie im folgenden Artikel der Microsoft Knowledge Base:
  
  

  932370 Unter Windows Server 2003 wird eine falsche Anzahl von physikalischen Prozessoren mit Hyperthreading oder eine falsche Anzahl von Multikernprozessoren gemeldet.Weitere Informationen dazu, wie Sie das Problem umgehen können, finden Sie auf der folgenden Webseite von Microsoft:
  
  

  http://blogs.technet.com/isablog/archive/2009/04/18/ms09-012-and-isa-server-standard-edition-14109-failures.aspxInstallieren Sie das Hotfixrollup 970454, um dieses ISA Server 2004-Problem zu beheben. Weitere Informationen zu diesem Problem finden Sie im folgenden Artikel der Microsoft Knowledge Base:

  970454Beschreibung des ISA Server 2004-Hotfixpakets: 02.06.09Installieren Sie das Hotfixrollup 970441, um dieses ISA Server 2006-Problem zu beheben.
  
  Weitere Informationen zu diesem Problem finden Sie im folgenden Artikel der Microsoft Knowledge Base:

  970441UPDATE: Der ISA Server-Steuerungsdienst kann nicht starten, nachdem Sie das Update MS09-012 auf einem Computer installiert haben, auf dem Windows Server 2003 ausgeführt wird und der mehr als 4 CPU-Kerne hat
  Hinweis Für ISA Server 2000 wurde kein Patch veröffentlicht, da ISA Server 2000 nicht mehr dem Mainstream-Support unterliegt und dieses Problem kein Sicherheitsrisiko darstellt.
  
  

• Nach Einspielen dieses Updates und einem anschließenden direkten, d. h. ersetzenden Update eines zuvor veröffentlichten Betriebssystems auf ein neues Betriebssystem bleiben vom Benutzer durchgeführte Änderungen an den folgenden Registrierungsunterschlüsseln ggf. nicht erhalten:

  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM\DefaultSecuredHost
  
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM\CompatibleHostProviders
  
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM\SecuredHostProviders Das Problem kann in den folgenden Upgradeszenarien auftreten:
  
  
  

  • Von Windows XP auf Windows Vista

  • Von Windows Server 2003 auf Windows Server 2008

  • Von Windows 2000 Server auf Windows Server 2003

  
  
  
  Bei den folgenden Upgradeszenarien tritt das Problem nicht auf:
  
  

  • Von Windows Vista auf Windows 7

  • Von Windows Server 2008 auf neuere Service Packs oder künftige serverbasierte Betriebssysteme.

  Erstellen Sie zum Vermeiden dieses Problems eine Sicherung dieser Unterschlüssel, bevor Sie ein direktes Update ausführen. Spielen Sie die Sicherungen der Unterschlüssel nach Abschluss des Updates und der Korrektur des Systems mit Sicherheitsupdates wieder ein.

Von unabhängigen Softwareanbietern (Independent Software Vendors, ISV) häufig gestellte Fragen (COM)

Frage 1: Wie erkenne ich, ob mein Produkt für dieses Problem anfällig ist?

Antwort 1: Klären Sie die folgenden Punkte:

1. Muss Ihr Produkt einen zu einem nicht NT-basierten Dienst gehörenden COM-Serverprozess starten?

2. Wird der von Ihrem Produkt instanziierte COM-Server im Kontext des Kontos NETZWERKDIENST oder LOKALER DIENST ausgeführt?
   

Lautet die Antwort auf beide Fragen ja, ist Ihr COM-Server ggf. anfällig. Führen Sie die folgenden Schritte aus, um die Untersuchung Ihres COM-Servers auf Anfälligkeit für dieses Problem fortzusetzen:

1. Laden Sie Process Explorer von der folgenden Microsoft-Website herunter, und installieren Sie das Programm:

   http://technet.microsoft.com/de-de/sysinternals/bb896653.aspx

2. Führen Sie Process Explorer als lokaler Administrator aus.

3. Zeigen Sie im Menü View auf Lower Pane View, und klicken Sie dann auf Handles.

4. Klicken Sie auf den gewünschten Serverprozess, und suchen Sie im unteren Bereich nach Type = Token.

5. Führen Sie alle Tests für Ihr Produkt aus.

6. Untersuchen Sie den unteren Bereich auf alle Token im Besitz des Prozesses, um zu prüfen, ob ein Systemtoken erfasst wurde.

Wenn Sie feststellen, dass der Serverprozess im Besitz des Systemtokens ist, gehen Sie wie folgt vor:

1. Laden Sie die neueste Version der Debugging Tools für Windows von der folgenden Microsoft-Website herunter, und installieren Sie sie:

   http://www.microsoft.com/whdc/devtools/debugging/default.mspx

2. Führen "WinDBG.exe" als lokaler Administrator aus.

3. Klicken Sie auf File und dann auf Kernel Debug, um den lokalen Kernel-Debugger zu starten.

4. Klicken Sie auf File und anschließend auf Attach to a Process.

5. Klicken Sie auf den gewünschten Serverprozess und dann auf OK für das Zuordnen zum Serverprozess.

6. Legen Sie den Symbolpfad des Debuggers wie folgt fest: Ersetzen Sie Ihren Downstreamspeicherpfad für DownstreamStore, z. B. "C:\Symbols".
   
   SRV*DownstreamStore*http://msdl.microsoft.com/download/symbols

7. Geben Sie die Informationen zum Prozesstoken aus.
   Rufen Sie die Tokenadresse aus der Ausgabe von !process ab, und zeigen Sie anschließend mit dem Befehl dt nt!_TOKEN eine Liste der einzelnen Felder in der Struktur TOKEN an.

8. Achten Sie auf den Wert des Felds ImpersonationLevel des Token.

Sollten Sie feststellen, dass der Serverprozess im Besitz des Systemtokens ist und der "ImpersonationLevel" Ihres Serverprozesses "SecurityImpersonation" oder "SecurityDelegation" lautet, ist ein Kunde, der diese COM-Serveranwendung auf seinem Computer installiert, anfällig für das in MS09-012 beschriebene Sicherheitsrisiko. Sie müssen den COM-Server mithilfe einer speziellen SID absichern. Frage 2: Wie kann ich bestimmen, ob meine Anwendung ein COM-Server vom Typ "Ausführen als" ist?

Antwort 2: Für COM-Server vom Typ "Ausführen als" enthält der Registrierungsunterschlüssel AppID den folgenden RunAs-Eintrag:

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{APPIDGUID}\"RunAs"="NT Authority\NetworkService"Insbesondere wenn der Wert des RunAs-Eintrags "NT Authority\NetworkService" oder "NT Authority\LocalService" lautet, ist der COM-Server ggf. anfällig für das in MS09-012 beschriebene Sicherheitsrisiko. Befolgen Sie die Schritte unter "Antwort 1", um zu bestimmen, ob das Produkt anfällig ist.

Frage 3: Wie sichere ich den COM-Server ab, der von meiner Produktpalette installiert wird?

Antwort 3: Für die Testphase in Testumgebungen: Wenn Sie Ihre COM-Serveranwendungen absichern, die im Aktivierungsmodus "Ausführen als" ausgeführt werden, muss es auf sowohl dem COM-Client als auch allen COM-Servern Steuerelemente geben, die abgesichert werden müssen. Es folgen die Schritte, die Sie ausführen können, um COM-Anwendungen vom Typ "Ausführen als" bei internen Tests abzusichern:

• Installieren Sie das MSRC-Paket.
  

• Nehmen Sie folgende Konfigurationsänderung für Ihren COM-Server vor:

  HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{APPIDGUID} REG_DWORD AppIDFlags 0x2 /* Beispiel der Verwendung des Registrierungswerts "AppIDFlags" HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{60EE1F45-C0DD-4A1F-AA44-D97424600A16} REG_DWORD AppIDFlags 0x2 */ Hinweis Für diese Änderung sind lokale Administratorberechtigungen erforderlich.
  
  Falls ein COM-Server, der als Netzwerkdienst oder lokaler Dienst ausgeführt wird und berechtigte Token enthält, kein NT-Dienst oder COM-Server vom "RunAs" ist, muss dieser in eine dieser Konfigurationen umgewandelt werden, um das Sicherheitsrisiko zu vermeiden.

Antwort 3: Für vorhandene Installationen: Für Kunden mit vorhandenen Installationen der anfälligen COM-Server muss der unabhängige Softwareanbieter ein Update bereitstellen, durch das diese Änderungen auf dem Computer des Kunden ermöglicht werden.

Antwort 3: Für Neuinstallationen: Der unabhängige Softwareanbieter muss ein intelligentes Installationsprogramm bereitstellen, das erkennen kann, ob das Sicherheitsupdate 956572 auf dem System installiert ist, und den Registrierungsschlüssel "AppIDFlags" aktivieren kann. Ist das Update nicht installiert, sollte das Installationsprogramm eine Fehlermeldung zu Systeminkompatibilitäten anzeigen und dann beendet werden.

Über die folgende Vorgehensweise kann ein Kunde feststellen, ob das Sicherheitsupdate 956572 unter Windows Server 2003 bzw. Windows XP installiert ist:

• Das Installationsprogramm muss feststellen, ob der folgende Registrierungsschlüssel existiert:

  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\HotFix\KB956572Ist dies der Fall, wurde das Sicherheitsupdate 956572 auf den Computer gespielt.

Eine weitere Methode für alle Versionen der Windows-Plattform ist das Verwenden von WMI-Abfragen. Mithilfe der folgenden Abfrage können Sie überprüfen, ob das Sicherheitsupdate 956572 auf dem Computer installiert ist:

SELECT * FROM WIN32_QUICKFIXENGINEERING WHERE HotfixID like ‘KB956572’Hinweis Windows Vista SP2 und Windows Server 2008 SP2 enthalten standardmäßig eine Korrektur für dieses Sicherheitsrisiko.

Von Systemadministratoren häufig gestellte Fragen (COM)

Frage 1: Wie stelle ich fest, ob Dienste in meinem Unternehmen anfällig sind oder nicht?

Antwort 1: Klären Sie die folgenden Punkte:

1. Muss Ihr Produkt einen zu einem nicht NT-basierten Dienst gehörenden COM-Serverprozess starten?

2. Wird der von Ihrem Produkt gestartete COM-Server im Kontext des Kontos NETZWERKDIENST oder LOKALER DIENST ausgeführt?
   

Lautet die Antwort auf beide Fragen ja, sind diese COM-Server ggf. anfällig. Wenden Sie sich zwecks Absicherung dieser COM-Serveranwendungen an den unabhängigen Softwareanbieter, der das Produkt bereitgestellt hat. Wurde diese Anwendung intern entwickelt, befolgen Sie die Schritte unter Antwort 1 des Abschnitts "Von unabhängigen Softwareanbietern (Independent Software Vendors, ISV) (COM) häufig gestellte Fragen".

Von ISVs häufig gestellte Fragen (Services.exe)

Frage 1: Wie bestimmen Sie, ob Ihre Produktpalette von der in MS09-012 beschriebenen Anfälligkeit betroffen ist?

Antwort 1: Klären Sie die folgenden Punkte:

1. Installiert Ihr Produkt Dienste, die im Framework des Dienststeuerungs-Managers gestartet werden?

2. Werden die von Ihrem Produkt installierten Dienste im Kontext des Kontos NETZWERKDIENST oder LOKALER DIENST ausgeführt?
   

3. Wenn Ihr Dienst unter Windows Vista oder Windows Server 2008 ausgeführt wird, führen Sie zum Bestimmen des Kontexts den folgenden Befehl an einer Eingabeaufforderung mit erhöhten Rechten aus:

   SC.EXE QSIDTYPE <Dienstname> Lautet der SERVICE_SID_TYPE-Wert NONE?
   
   Ausgabe:

   [SC] QueryServiceConfig2 SUCCESS SERVICE_NAME: <Dienstname> SERVICE_SID_TYPE: NONE 

   Lautet die Antwort auf diese drei Fragen ja, ist Ihr Dienst ggf. anfällig. Befolgen Sie zum Fortsetzen der Untersuchung, ob Ihr Dienst anfällig ist, die auf den Process Explorer bezogenen Schritte unter Antwort 1 des Abschnitts "Von unabhängigen Softwareanbietern (Independent Software Vendors, ISV) (COM) häufig gestellte Fragen".

Frage 2: Wie sichere ich die Dienste ab, die von meiner Produktpalette installiert werden?

Antwort 2:

Testphase in Testumgebungen
Es folgen die Schritte, die Sie ausführen können, um Ihren Dienst bei internen Tests abzusichern, bevor Sie ihn für die Kunden freigeben.

• Installieren Sie das MSRC-Paket.
  

• Führen Sie den folgenden Befehl an einer Eingabeaufforderung mit erhöhten Berechtigungen aus:

  SC.exe SIDTYPE <Dienstname> UNRESTRICTED

• Starten Sie den Dienst im Dienststeuerungs-Manager neu.

• Prüfen Sie durch Ausführen des folgenden Befehls, ob Ihr Dienst eine Dienst-SID erhalten hat:

  SC.exe QSIDTYPE <Dienstname>Ausgabe:
  

  [SC] QueryServiceConfig2 SUCCESS SERVICE_NAME: <Dienstname> SERVICE_SID_TYPE: UNRESTRICTED 

• Wird SERVICE_SID_TYPE = UNRESTRICTED angezeigt, hat Ihr Dienst eine SID erhalten.

• Führen Sie alle Testanordnungen aus, um sicherzustellen, dass der Dienst sämtliche Funktionalität uneingeschränkt bereitgestellt.

• Mit der folgenden Befehlsfolge können Sie die Dienst-SID vom Dienst entfernen:

  SC.exe SIDTYPE <Dienstname> NONE
  SC.exe STOP <Dienstname>
  SC.exe START <Dienstname>

Vorhandene Installationen
Für Kunden mit vorhandenen Installationen der anfälligen Dienste muss der unabhängige Softwareanbieter ein Update bereitstellen, durch das eine Dienst-SID auf dem Computer des Kunden aktiviert werden kann. Das Update umfasst idealerweise die folgenden Schritte:

1. Ändern Sie den folgenden Registrierungsschlüssel:

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<ServiceName>\ServiceSidType = 1

2. Nach diesem Update sollte das Installationsprogramm das System neu starten.

Dadurch wird der Dienst-SID-Typ des Diensts <Dienstname> in UNRESTRICTED geändert.

Neuinstallationen
Der unabhängige Softwareanbieter muss ein intelligentes Installationsprogramm bereitstellen, das erkennen kann, ob das Sicherheitsupdate 956572 auf dem System installiert ist, und den Registrierungsschlüssel "ServiceSidType" aktivieren kann. Ist das Update nicht installiert, sollte das Installationsprogramm eine Fehlermeldung zu Systeminkompatibilitäten anzeigen und dann beendet werden.

Über die folgende Vorgehensweise kann ein Kunde feststellen, ob das Sicherheitsupdate 956572 unter Windows Server 2003 bzw. Windows XP installiert ist:

• Das Installationsprogramm muss feststellen, ob der folgende Registrierungsschlüssel existiert:

  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\HotFix\KB956572Ist dies der Fall, wurde das Sicherheitsupdate 956572 auf den Computer gespielt.

Eine weitere Methode für alle Versionen der Windows-Plattform ist das Verwenden von WMI-Abfragen. Die folgende Abfrage dient zum Erkennen, ob das Sicherheitsupdate 956572 auf dem Computer installiert ist:

SELECT * FROM WIN32_QUICKFIXENGINEERING WHERE HotfixID like 'KB956572'Hinweis Die veröffentlichten Versionen von Windows Vista und Windows Server 2008 enthalten bereits die Korrektur für "Services.exe", weshalb keine Erkennung erforderlich ist.

Hinweis Wenn die DACLs Ihres Produkts über Ressourcen mit der SID des Dienstkontos verfügen, stellen Sie sicher, dass allen diesen Ressourcen (Dateien, Registrierungsschlüssel usw.) die DACLs mit der Dienst-SID wieder zugeordnet werden. Erfolgt dies nicht, kann die Funktionalität Ihres Produkts leiden, wenn versucht wird, auf diese Ressourcen zuzugreifen.

Mit dem folgenden Befehl können Sie die Ihrem Dienst zugewiesene SID anzeigen:

SC.EXE SHOWSID <Dienstname>Die SID des Diensts wird mithilfe einer Hashzeichenfolge des Dienstnamens generiert und bleibt unverändert, solange sich der Name des Diensts nicht ändert.

Von Systemadministratoren häufig gestellte Fragen (Services.exe)

Frage 1: Wie stelle ich fest, ob in meinem Unternehmen genutzte Dienste anfällig sind oder nicht?

Antwort 1: Klären Sie die folgenden Punkte:

1. Installiert Ihr Produkt Dienste, die im Framework des Dienststeuerungs-Managers gestartet werden?

2. Werden die von Ihrem Produkt installierten Dienste im Kontext des Kontos NETZWERKDIENST oder LOKALER DIENST ausgeführt?
   
   Hinweis Wenn Ihr Dienst unter Windows Vista oder Windows Server 2008 ausgeführt wird, führen Sie zum Bestimmen des Kontexts den folgenden Befehl an einer Eingabeaufforderung mit erhöhten Rechten aus:

   SC.exe QSIDTYPE <Dienstname>Ausgabe:
   

   [SC] QueryServiceConfig2 SUCCESS SERVICE_NAME: <Dienstname> SERVICE_SID_TYPE: UNRESTRICTED 

   Lautet die Antwort auf diese drei Fragen ja, sind diese Dienste ggf. anfällig. Wenden Sie sich zwecks Absicherung dieser Dienste an den unabhängigen Softwareanbieter, der den Dienst bereitgestellt hat. Wurde der Dienst intern entwickelt, befolgen Sie die Schritte unter Antwort 1 des Abschnitts "Von unabhängigen Softwareanbietern (Independent Software Vendors, ISV) (COM) häufig gestellte Fragen".

Von unabhängigen Softwareanbietern (Independent Software Vendors, ISV) häufig gestellte Fragen (WMI)

Frage 1: Wie kann ich feststellen, ob der von unserem Produkt genutzte WMI-Anbieter im sicheren Modus gestartet wird oder nicht?

Antwort 1:

1. Öffnen Sie die MOF-Dateien der WMI-Anbieter, und prüfen Sie, ob die Anbieter eines der folgenden Hostingmodelle aufweisen:
   

   • NetworkServiceHost

   • NetworkServiceHostToSelfHost

   • LocalServiceHost

   • NULL (nur unter Windows Vista und Windows Server 2008)

2. Als Teil des Token Kidnapping-Pakets sind nur "inbox" ausgelieferte WMI-Anbieter standardmäßig abgesichert. Ist Ihr Anbieter ein "Inbox"-Anbieter, sollte er idealerweise nach Installation des Token Kidnapping-Pakets abgesichert sein. Überprüfen Sie hierzu die Registrierungswerte unter dem Unterschlüssel HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM\SecuredHostProviders. Falls ein Anbieter abgesichert ist, wird ein Eintrag ähnlich dem Folgenden angezeigt:

   <Namespace>:_Win32Provider.Name ="<Anbietername>" REG_SZ 0. 

3. Ist Ihr Anbieter hier aufgeführt, wird dieser bestimmte Anbieter im sicheren Modus gestartet.

4. Wenn der Name des Anbieters nicht unter dem Registrierungsschlüssel aufgeführt ist und das Hostingmodell einem der in Schritt 1 angegebenen Modelle entspricht, wird dieser Anbieter in einem unsicheren "Wmiprvse.exe"-Kontext gestartet, wodurch der Computer anfällig für die Token Kidnapping-Sicherheitslücke wird.

Frage 2: Wie kann ich prüfen, ob der von unserem Produkt genutzte WMI-Anbieter im sicheren Modus gestartet wird oder nicht?

Antwort 2:

1. Melden Sie sich als Administrator an einem Computer an, auf dem Ihr Produkt installiert ist.

2. Laden Sie Process Explorer von der folgenden Microsoft-Website herunter, und installieren Sie das Programm:

   http://technet.microsoft.com/de-de/sysinternals/bb896653.aspx

3. Führen Sie Process Explorer als lokaler Administrator aus.

4. Zeigen Sie im Menü View auf Lower Pane View, und klicken Sie dann auf Handles.

5. Öffnen Sie den Task-Manager, und bestimmen und schließen Sie alle "Wmiprvse.exe"-Prozesse, die unter dem Kontext von NETZWERKDIENST oder LOKALER DIENST ausgeführt werden.

6. Führen Sie einen Test Ihrer Anwendung aus, bei dem eine WMI-Abfrage mittels eines bestimmten WMI-Anbieters erfolgt. Dadurch wird ein neuer "WMIPrvSE.exe"-Prozess zum Erfüllen der kurz zuvor ausgeführten WMI-Abfrage erzeugt.

7. Stellen Sie sicher, dass Sie auf der Process Explorer-Symbolleiste View DLLs ausgewählt haben.

8. Prüfen Sie im unteren Bereich, ob Ihre DLL in den neu erstellten "WMIPrvSE.exe"-Prozess geladen wurde.

9. Doppelklicken Sie auf "WMIPrvSE.exe", um das Dialogfeld Properties zu öffnen.

10. Klicken Sie auf die Registerkarte Security, und vergewissern Sie sich, dass die folgenden Informationen ordnungsgemäß sind:
    

    • Die Anmelde-SID hat das Format (S-1-5-5-****).

    • Die Anmelde-SID ist außerdem als Besitzer markiert.

    • Die WMI-SID für "ServiceAccount {Local Service|Network Service}" ist als Besitzer markiert.
      

      • WMI-SID für Local Service:
        
        S-1-5-86-1544737700-199408000-2549878335-3519669259-381336952

      • WMI-SID für Network Service:
        
        S-1-5-86-615999462-62705297-2911207457-59056572-3668589837

11. Klicken Sie auf Permission, und stellen Sie sicher, dass weder Network Service noch Local Service in der Liste angezeigt werden. Dies gewährleistet, dass Ihr Anbieter nun im sicheren Modus gestartet wird.

Frage 3: Wie kann ein unabhängiger Softwareanbieter den von seinem Produkt genutzten WMI-Anbieter absichern?

Antwort 3: Als Teil des Token Kidnapping-Pakets haben wir drei Registrierungsschlüssel bereitgestellt, mit deren Hilfe unabhängige Softwareanbieter ihre WMI-Anbieter absichern können.

• HKLM\SOFTWARE\Microsoft\WBEM\CIMOM\SecuredHostProviders
  
  
  Alle Anbieter unter diesem Schlüssel werden stets im abgesicherten Modus ausgeführt.

• HKLM \SOFTWARE\Microsoft\WBEM\CIMOM\CompatibleHostProviders
  
  Ist ein Anbieter unter diesem Schlüssel aufgeführt, wird er stets im nicht abgesicherten Modus ausgeführt. Dieser Schlüssel wird bereitgestellt, damit ein unabhängiger Softwareanbieter eine Ausnahme für einen bestimmten Anbieter hinzufügen kann, der bei Ausführung im sicheren Modus Kompatibilitätsprobleme aufweist. Dieser Schlüssel enthält standardmäßig keine Einträge.

• HKLM \SOFTWARE\Microsoft\WBEM\CIMOM\DefaultSecuredHost
  
  
  Ist dieser globale Registrierungsschlüssel auf 1 festgelegt, startet er alle WMI-Anbieter auf dem Computer im abgesicherten Modus, und zwar unabhängig davon, ob sie unter einem der vorherigen Registrierungsschlüssel aufgeführt sind. Microsoft hat diesen Schlüssel nicht standardmäßig auf 1 festgelegt, da wir nicht das Verhalten aller möglichen Anwendungen anderer Anbieter mit Festlegung dieses Registrierungsschlüssels auf 1 getestet haben.

Fügen Sie zum Absichern von WMI-Anbietern "HKLM\SOFTWARE\Microsoft\WBEM\CIMOM\SecuredHostProviders" den folgenden Registrierungswert hinzu:

<Namespace>:_Win32Provider.Name ="<Anbietername>" REG_SZ 0. 

Stellen Sie nach Durchführung dieser Änderung sicher, dass alle Ihre Testszenarien wie erwartet funktionieren.

Von Systemadministratoren häufig gestellte Fragen (WMI)

Frage 1: Wie kann ich feststellen, ob ein in meinem Unternehmen genutzter WMI-Anbieter im nicht abgesicherten Modus ausgeführt wird?

Antwort 1:

1. Melden Sie sich als Administrator an einem Computer an, auf dem Ihr Produkt installiert ist.

2. Laden Sie Process Explorer von der folgenden Microsoft-Website herunter, und installieren Sie das Programm:

   http://technet.microsoft.com/de-de/sysinternals/bb896653.aspx

3. Führen Sie Process Explorer als lokaler Administrator aus.

4. Zeigen Sie im Menü View auf Lower Pane View, und klicken Sie dann auf Handles.

5. Öffnen Sie den Task-Manager, und bestimmen und schließen Sie alle "Wmiprvse.exe"-Prozesse, die unter dem Kontext von NETZWERKDIENST oder LOKALER DIENST ausgeführt werden.

6. Führen Sie einen Test Ihrer Anwendung aus, bei dem eine WMI-Abfrage mittels eines bestimmten WMI-Anbieters erfolgt. Dadurch wird ein neuer "WMIPrvSE.exe"-Prozess zum Erfüllen der kurz zuvor ausgeführten WMI-Abfrage erzeugt.

7. Stellen Sie sicher, dass Sie auf der Process Explorer-Symbolleiste View DLLs ausgewählt haben.

8. Prüfen Sie im unteren Bereich, ob Ihre DLL in den neu erstellten "WMIPrvSE.exe"-Prozess geladen wurde.

9. Doppelklicken Sie auf "WMIPrvSE.exe", um das Dialogfeld Properties zu öffnen.

10. Klicken Sie auf die Registerkarte Security, und vergewissern Sie sich, dass die folgenden Informationen ordnungsgemäß sind:
    

    1. "Network Service" bzw. "Local Service" hat vollständige Berechtigungen für den "Wmiprvse.exe"-Prozess.

    2. Stellen Sie sicher, dass die Anmelde-SID (im Format S-1-5-5-****) nicht als Besitzer markiert ist.

    3. Stellen Sie sicher, dass die WMI-SID für "ServiceAcccount {Local Service|Network Service}" nicht generiert wird. Sorgen Sie dafür, dass sie nicht unter "Group" angezeigt wird.

       • WMI-SID für Local Service: S-1-5-86-1544737700-199408000-2549878335-3519669259-381336952

       • WMI-SID für Network Service: S-1-5-86-615999462-62705297-2911207457-59056572-3668589837

Frage 2: Wie kann ich einen anfälligen WMI-Anbieter absichern?

Antwort 2:

1. Öffnen Sie den Registrierungs-Editor.

2. Wechseln Sie zum folgenden Unterschlüssel:

   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM\SecuredHostProviders

3. Fügen Sie für den abzusichernden WMI-Anbieter einen Registrierungswert hinzu. Wählen Sie das folgende Format:

   <Namespace>:_Win32Provider.Name ="<Anbietername>" REG_SZ 0 

4. Starten Sie den WMI-Dienst durch Ausführen der folgenden Befehle neu.
   

   • Sc stop winmgmt

   • Sc start winmgmt