Authenticode

Es war bei einem Kunden, der den Zugang zum Internet nicht offen gestaltet hat. Man musste nur die Adresse des Proxy Servers kennen und konnte ohne weitere Anmeldung surfen. Allerdings hat selbst diese Umgebung das Exchange 2007 Rollup5 Fix dafür gesorgt, dass nach der Installation die Exchange Dienste nicht mehr gestartet sind.

Empfohlene Lösung für Exchange 2007
944752 Exchange 2007 managed code services do not start after you install an update rollup for Exchange 2007

Was war passiert ?

Das Symptom

Programme können schon seit längerem mit einer digitalen Unterschrift (Codesigning) versehen werden. Anscheinend wurden durch das Rollupfix 5 für Exchange 2007 einige Dateien nun digital signiert, so dass das .NET Framework die Gültigkeit dieser Signatur überprüfen möchte.

Kann der PC nun nicht die ausstellende Zertifizierungsstelle erreichen, um die Gültigkeit des Zertifikats zu prüfen, dann passiert, es, dass der Windows Dienstmanager lapidar meldet, dass der Dienst nicht rechtzeitig auf eine Anforderung reagiert hat und der Dienst wird einfach nicht gestartet.

Fatal dabei ist, dass de Exchangecode selbst noch gar nicht ausgeführt wurde und Sie daher im Eventlog natürlich auch lange nach Fehlern seitens Exchange suchen können. Sie werden keine finden. Letztlich können die Exchange Dienste nicht mehr starten. Auch ein wiederholter Versuch schläft fehl.

Exchange Rollup-Installationen dauern dann seht lange. Im Exchange 2010 SP1 Rollup1 habe ich dazu sogar das erste Mal eine Warnung gesehen

Es ist natürlich Schade, dass es vom Jan 2008 (2007RU5) bis Okt 2010 (2010SP1RU1) gedauert hat, um die Administratoren darauf aufmerksam zu machen. Auf der anderen Seite muss sich eine Firma natürlich auch fragen lassen, warum sie dem Thema CRL bislang so wenig Aufmerksamkeit geschenkt hat.

PCs, Internet Explorer und Internet Zugriff mit WinHTTP

Im Hintergrund versucht der PC selbst nämlich die Webseite hhttp://crl.microsoft.com zu erreichen, um die Gültigkeit zu prüfen. Wer nu glaubt, er könne doch mit seinem PC im Internet surfen und trägt im Internet Explorer die korrekten Proxy Einstellungen ein, der irrt. Windows ist ein MultiUser System und nur weil Sie als Administrator auf der Konsole "surfen" können  (ob das gut ist, muss jeder selbst für sich klären), können noch lange nicht alle Programme und Dienste auf das Internet zugreifen. Besonders der Computer selbst und Dienste, die als "LocalSystem" arbeiten, können nicht von den Proxy Einstellungen und Authentifizierungstokens des angemeldeten Benutzers profitieren.

Aber auch für "LocalComputer" gibt es Proxyeinstellungen, die aber nicht per GUI durchgeführt werden können. Anstatt aber nun in der Registrierung unter "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\" Einträge direkt vorzunehmen, sollten Sie statt dessen das Hilfsprogramm "PROXYCFG.EXE" verwenden. Starten Sie ProxyCFG einfach in einer CMD-Box. Ein einfacher Aufruf zeigt die aktuellen Einstellungen an : (Beispiel mit "direkter Zugriff")

ProxyCFG

Mit dem Aufruf "Proxycfg -u" übernimmt man die aktuellen Proxy-Einstellungen des angemeldeten Benutzers für das System: (Hier am Beispiel von NetatWork):

ProxyCFG mit Proxy

Man sieht dass hier z.B. einige URLs nicht über den Proxy geleitet werden. Ein einfacher Aufruf von "Proxycfg" zeigt die aktuellen Einstellungen an. "Proxycfg -d" stellt wieder den direkten Zugang ein. Man muss allerdings lokaler Administrator sein, um die Einstellungen durchführen zu können.

Proxy mit Windows 2008

Das Programm ProxyCFG gibt es nicht mehr auf Windows 2008. Die Registrierungsschlüssel sind natürlich die gleichen. Aber hier hilft dann NETSH:

REM Setzen
netsh winhttp set proxy 192.168.100.21:8080 bypass-list=lokaler_Domänenname

REM Anzeigen
netsh winhttp show proxy

Unabhängig von den Einstellungen per Kommandozeile, der immer wieder vergessen wird, gefällt mir als Administrator natürlich der Weg besser, diese Einstellungen entweder per Gruppenrichtlinie oder WPad durchzuführen. Einige Applikationen ignorieren aber sogar diese Einstellung. Speziell für .NET Programme gibt es eventuell abweichende Einstellungen in der jeweiligen Application.config/Web.config

Hintergründe

Wenn man einige KB-Artikel und die MSDN liest, dann ist Authenticode im Prinzip natürlich etwas Gutes. Schon sehr lange werden z.B. ActiveX-Controls, die von Webseiten geladen werden, digital signiert. Damit können Sie als Anwender prüfen, dass der Code unterändert ist und der Hersteller bekannt ist. Die Installation von nicht signierten Controls oder Controls unbekannter Hersteller sollten Sie nicht akzeptieren. Wer heute professionell Software entwickelt und verteilt, sollte diese auch digital signieren können. Leider sind offizielle Codesigning-Zertifikate nicht gerade "günstig".

Kaum ein Entwickler eines Trojaners, Virus oder sonst wie schädlichen Programms wird seinen Code signieren, da er dann ja nicht mehr anonym ist. Weiterhin verhindert der Einsatz von digitalen Signaturen in Verbindung mit Programmcode, dass dieser nachträglich auf der Festplatte des Computers verändert wird. Es verhindert natürlich auch, das jemand den Code in seinem Sinne verändert (z.B.: Textbausteine austauscht etc.)

Achtung
Wenn der Administrator die Überprüfung von Codesignaturen abschaltet, ist der Schutz nicht mehr gegeben, d.h. Code kann unbemerkt verändert werden.

Windows prüft nun nicht nur die Signatur des Codes, sondern möchte auch wissen, ob das Zertifikat vielleicht zurückgezogen wurde. Daher verbindet es sich mit der "Certificate Revocation List" (CRL). Das passiert in zwei Fällen:

Sicher gibt es noch weitere Fälle, aber diese beiden Beispiele sind für Exchange 2007 relevant.

Verhalten je nach Verbindung

Kann der Aufruf an http://crl.microsoft.com nicht erfolgen, dann hängt es auch davon ab, wie die Netzwerkverbindung auf die versuchte Anfrage reagiert.

Es ist also zu erkennen, dass das Problem um so offensichtlicher wird, umso schlechter das eigene Netzwerk konfiguriert ist. hat man früher in Firewall sehr gerne Verbindungen einfach "versickern" lassen, so sollte man heute zumindest Verbindungsversuche von intern nach extern aktiv blockieren und den Client auch darüber informieren, dass es nicht weiter geht. Die Zeiten, als man als Administrator sogar ICMP (PING) aus Sicherheitsaspekten geblockt hat, sind schon länger vorbei.

Lösung

Mit dem Wissen um die Hintergründe und das Verhalten ist auch die Beschreibung der verschiedenen Lösungsmöglichkeiten einfach:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\ EncodingType 0\CertDllCreateCertificateChainEngine\Config]
"ChainUrlRetrievalTimeoutMilliseconds"=dword:00015000
"ChainRevAccumulativeUrlRetrievalTimeoutMilliseconds"=dword:00020000

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control]
"ServicesPipeTimeout"=dword:00015000

<configuration>
	<runtime>
		<generatePublisherEvidence enabled="false"/> 
	</runtime>
</configuration>

Mein Favorit ist natürlich eine Konfiguration bei der die Programme im Netzwerk sicher und zuverlässig Zertifikate überprüfen können. In diesem Fall also die Konfiguration eines Proxy-Servers auf jedem Server (z.B.: per Gruppenrichtlinie) und die Erreichbarkeit bestimmter Webseiten ohne weitere Authentifizierung oder für die gruppe "Domänen Computer".

Server und Internetzugriff ?

Natürlich lässt es sich wunderbar streiten, ob Server Verbindungen zum Internet (und insbesondere Microsoft) aufbauen dürfen, oder ob Server überhaupt solche Verbindungen benötigen. Andererseits gibt es heute sehr leistungsfähige Filter und Proxy-Server, die einen gesicherten Zugriff auf bestimmte URLs erlauben können. Das ist natürlich nicht mit einem Router und NAT zu vergleichen.

Der Zugriff per HTTP ist für Server auch noch aus anderen Aspekten ganz hilfreich, z.B.

Aus meiner Sicht ist es leichtsinnig, einen Server "einfach so" per HTTP in das Internet zu lassen. Aber mit der passenden Konfiguration des Internet Explorers und einem Proxy, der für Server nur bestimmte URLs zulässt (die natürlich zu pflegen sind), ist eine Verbindung aus meiner Sicht problemlos und eher ein Vorteil. Normale Anwender können ja weiterhin über einen Proxy und eine Anmeldung auf andere Ziele zugreifen.

Wenn Sie aber ein Problem mit ihrem Server haben und Sie für eine schnelle Recherche im Internet oder beim Hersteller immer erst Fehlermeldungen abschreiben müssen, dann geht kostbare Zeit verloren.

Fusion Log Viewer

Wenn ihr Exchange dann immer noch "träge" startet, könnten es auch andere Probleme beim Laden, Kompilieren und Binden von DLLs sein. Dann hilft eventuell folgendes:

Hier die erforderliche REG-Datei, um das Logging zu aktivieren.

Windows Registry Editor 5.0

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion]
"LogPath" = "C:\fusionlogs"
"LogFailures" = 1
"ForceLog" = 1
"LogResourceBinds" = 1

Dieses Werkzeug protokolliert die relevanten Vorgänge im .NET Framework.

Code Access Security Policy Tool (Caspol.exe)

Auch beim Einbindung von anderen Codeteilen wird über einen Vertrauenslevel gesteuert. Das ist zum einem über die Signatur der Datei aber auch über den Pfad bestimmt. Lokale Dateien sind eher vertrauenswürdig als Dateien über einen Netzwerkshare oder gar aus dem Internet.

Sie sehen schon, wie .NET und auch Windows by Default versucht immer "sicherer" zu werden, indem man nicht erst Programme auf ihre Verhalten oder Schadhaftigkeit überprüft (wie es Virenscanner machen), sondern von vorneherein über einen Vertrauenslevel die Ausführung von "unbekannten" und damit unsicheren Programmteilen unterbindet. Und das kann manchmal auch gewollte Prozesse stoppen.

Weitere Links

Tags:Authenticode, Signatur, .NET