Author: Jens Wahnes

Die Zwickmühle beim Betreiben von verschlüsselten Netzdiensten aus Betreibersicht

Angesichts der Schwachstellen rund um bestimmte Verschlüsselungsarten (Poodle und Logjam waren die bekanntesten in letzter Zeit) hat man es als Betreiber schwer, die „optimale“ Konfiguration für Netzdienste zu finden, die verschlüsselte Kommunikation anbieten. Auf der einen Seite möchte man nach Möglichkeit Benutzer mit älteren Geräten, die noch nicht die neuesten Verfahren implementiert haben, nicht völlig von der Nutzung ausschließen, auf der anderen Seite gelten bestimmte Verfahren inzwischen als so unsicher, dass man diese als Serverbetreiber auf gar keinen Fall mehr anbieten möchte, um Nutzer nicht in trügerischer Sicherheit zu wägen.

Das gilt insbesondere dann, wenn als Szenario droht, dass ein Angreifer sich in die Verbindung zwischen Server und Client einklinken kann und dann dafür sorgt, dass die beiden eigentlichen Kommunikationspartner sich auf eine Primitiv-Verschlüsselung einlassen, weil der Angreifer vortäuscht, der jeweils andere Partner würde keine starke Verschlüsselung unterstützen („Downgrade-Attack“). In einem solchen Fall braucht der Angreifer dann nur noch die Primitiv-Verschlüsselung zu knacken anstelle der starken Verschlüsselung, die die beiden Kommpunikationspartner im Normalfall untereinander vereinbart hätten.

Webserver und andere Dienste

Weiter verkompliziert wird die Lage dadurch, dass Angriffsszenarien bei verschiedenen Netzdiensten unterschiedlich zu beurteilen sind. So sind Angriffe, die darauf beruhen, dass einer der Kommunikationspartner unfreiwillig dazu gebracht werden kann, häufig Datenpakete mit annähernd gleichem Inhalt zu senden, bei Webseiten bis zu einem gewissen Grad realistisch. Schafft es der Angreifer, das Opfer auf eine Webseite unter seiner Kontrolle zu locken, so sind automatisierte Datenabrufe durch eingebetteten Skriptcode denkbar, ohne dass es direkt auffällt. Bei anderen Diensten, beispielsweise E-Mail mit einem Mailclient, gibt es hingegen kein ernstzunehmendes Szenario, wie ein Angreifer von außerhalb den Computer des Opfers automatisiert dazu bringen kann, selbständig mit gewisser Regelmäßigkeit gleichartige Datenpakete zu verschicken. Das ist umso mehr eine Besonderheit des Webs gegenüber anderen Netzdiensten, weil das Angriffsziel „Session-Cookie“ auch nur im WWW-Bereich wirklich existiert.

Alte Software überall

Als wäre dieses Spannungsfeld nicht schon vertrackt genug, kann als weitere Schwierigkeitsstufe noch dazukommen, dass man nicht nur bei den fremden Kommunikationspartnern nicht die neuesten Verschlüsselungsverfahren voraussetzen kann, sondern dass man auch als Anbieter nicht all das nutzen kann, was theoretisch verfügbar ist. So steht am RRZK für den Betrieb von Webservern i.d.R. als Betriebsystem Red Hat Enterprise Linux 6 (RHEL6) zur Verfügung. Dieses bringt aber nicht die jeweils neuesten Programmversionen mit, sondern im Regelfall diejenigen Versionen, die bei Erscheinen des Betriebssystems aktuell waren, jedoch natürlich um in der Zwischenzeit bekanntgewordene Sicherheitslücken bereinigt.

Für RHEL6 bedeutet das ganz konkret, dass nur die Funktionen von openssl 1.0.1 zur Verfügung stehen (anstelle von openssl 1.0.2) sowie der Apache-Webserver aus der 2.2er Versionslinie (anstatt 2.4). Damit sind einige der Empfehlungen für Serverbereiter, wie Sie beispielsweise von den Entdeckern des Logjam-Problems gegeben werden, nicht umsetzbar. Das Definieren individueller sog. Diffie-Hellman-Parameter etwa ist erst mit den neuesten Versionen des Apache-Webservers (ab 2.4.8) möglich.

Empfehlung für Apache 2.2 unter RHEL6

Um nun unter RHEL6 einen Apache-Webserver zu betreiben, der Webseiten ausschließlich verschlüsselt (per https) ausliefert, und das unter den gegebenen Umständen mit einem als möglichst sicher geltenden Kompromiss, kann man folgende Einstellungen in der allgemeinen Apache-Konfiguration verwenden:


SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite HIGH:MEDIUM:!ADH:!MD5:!RC4
SSLHonorCipherOrder on

Das ist zunächst einmal wenig spektakulär und kaum anders als das, was von den Logjam-Entdeckern empfohlen wird. In der Praxis läuft es darauf hinaus, dass die hier vorgeschlagene Konfiguration keine Präferenz für AES-128-Verschlüsselung enthält, so dass von den meisten heutigen Clients eine AES-256-Verschlüsselung verwendet werden wird. Ob man in dem gegebenen Kontext (Abruf von Webseiten) nun AES-128 oder AES-256 den Vorzug geben sollte ist für mich nicht zu beurteilen und wird in der Praxis wohl auch kaum eine Rolle spielen. Die theoretische Angreifbarkeit von AES-256 gegenüber AES-128 (hier ein alter und bekannter Blogartikel von Bruce Schneider dazu) bezieht sich auf mögliche Related-Key-Angriffe und ist in dieser Frage von untergeordneter Bedeutung.

Lässt man die oben genannte Einstellung SSLHonorCipherOrder hingegen auf dem Standardwert off, statt sie wie empfohlen auf on zu setzen, so ändert sich in der Praxis bei den meisten Browsern wenig. Durch das Setzen von SSLHonorCipherOrder on sorgt man de facto nur dafür, dass Benutzer mancher Versionen des Internet Explorers unter Windows 7 zu ihrem Glück gezwungen werden und auch bei ihnen eine Verbindung mit Forward Secrecy aufgebaut wird. Auf die Belange von Nutzern, die auch heute noch die extrem veraltete und per se unsichere Kombination von Internet Explorer 6 und Windows XP einsetzen, wird hier keine Rücksicht mehr genommen. Diese früher nicht ganz kleine Gruppe an Webseitenbesuchern machte in der Vergangenheit viele faule Kompromisse notwendig.

Dem Browser den Weg zur Verschlüsselung weisen

Legt man Wert darauf, in dem beliebten SSL-Servertest von Qualys besonders gut abzuschneiden, ist SSLHonorCipherOrder on unbedingt notwendig. Jedoch reicht das Setzen dieser und der anderen allgemeinen Verschlüsselungseinstellungen nicht aus. Für ein gutes Testergebnis muss man auch dafür sorgen, dass Besucher ausschließlich verschlüsselt mit dem Server kommunizieren. Solange unverschlüsselte Kommunikation im Web der Normalfall ist, sind dazu noch ein paar weitere Anstrengungen in der Apache-Konfiguration notwendig.

Webseitenbesucher, die – aus welchem Grund auch immer – eine unverschlüsselte Verbindung zum Server aufbauen möchten, müssen also von diesem Vorhaben abgehalten werden. Verwendet man dazu virtuelle Hosts in der Apache-Konfiguration, so kann man die Besucher, die keine Verschlüsselung verwenden, per


<VirtualHost *:80>
  RedirectMatch permanent (.*) https://meinhostname.uni-koeln.de$1
</VirtualHost>

umlenken. Für Named Virtual Hosts wäre hier natürlich noch eine weitergehende Konfiguration nötig. Gezeigt werden soll anhand dieses Konfigurationsschnipsels eigentlich nur, dass man die Besucher am besten mit einer dauerhaften Umleitung (permanent) auf die verschlüsselte Version der Website lenkt.

https und nur https, in guten wie in schlechten Zeiten

Als Kür sendet man dann noch die Information an die Browser der Webseitenbesucher, es in Zukunft gar nicht erst über eine unverschlüsselte Verbindung zu probieren, sondern ausschließlich per https mit dem Server zu kommunizieren:


<VirtualHost *:443>
  # hier stehen normalerweise Einstellungen wie ServerName, DocumentRoot etc.
  
  # vvv Einschalten von HSTS aka HTTP Strict Transport Security, RFC 6797
  Header always set Strict-Transport-Security: max-age=31536000
  # ^^^ Strict Transport Security, funktioniert mit Apache 2.2.15
</VirtualHost>

In diesem Beispiel wird der abrufende Browser instruiert, dass die Information, mit diesem Server nur verschlüsselt zu kommunizieren, ca. ein Jahr lang (31536000 Sekunden) gültig ist. Dies kann man zum Glück auch schon mit dem bei RHEL6 mitgelieferten Webserver Apache 2.2.15 so einstellen.

Mit den auf diese Weise optimierten Einstellungen erhält der Webserver dann von dem erwähnten SSL-Test die Bestnote A+ attestiert, vorausgesetzt die übrigen Einstellungen (zum Zertifikat und der Kette der Zwischenzertifizierungsstellen etc.) sind ebenfalls in Ordnung. Diese Einstellungen sind aber nicht spezifisch für RHEL6, daher soll hier darauf nicht weiter eingegangen werden.

Viele Wege führen nach Rom – oder zur automatischen Konfiguration

Seit geraumer Zeit bietet das RRZK eine automatische Konfiguration des Mailkontos für Thunderbird und Outlook an. Damit entfällt für Smail- und UNI-Accounts im Regelfall das lästige Nachschlagen von zu verwendeten Servernamen und -einstellungen. Welche Schritte hinter den Kulissen notwendig sind, um diesen Service zu erbringen, und welche Fallen Microsoft den Implementieren ihres Verfahrens in den Weg gelegt hat, ist Gegenstand dieses Artikels.

Ein Mailprogramm für den Abruf eines bestimmten Mailkontos zu konfigurieren ist nicht immer leicht, besonders in Zeiten, in denen die Verwendung mehrerer unterschiedlicher Mailadressen für verschiedene Zwecke fast schon zum guten Ton gehört. Da ist es mitunter schwierig, den Überblick zu behalten über die an den verschiedenen Stellen erforderlichen oder möglichen Einstellungen und man ist schon sehr froh, dies typischerweise nur genau einmal machen zu müssen. Die auf den RRZK-Webseiten abrufbaren ausführlichen Anleitungen zur Konfiguration verschiedener Mailclients sind ein Zeugnis dieser vielfach als zu kompliziert empfundenen Prozedur.

Diesem Umstand haben verschiedene Anbieter von Mailclients in letzter Zeit Rechnung getragen, indem sie eine erleichterte Konfiguration ermöglichen – wenn auch leider jeder auf seine eigene Art. In jedem Fall wird damit die Einrichtung eines Mailkontos zum Kinderspiel: die gleichen Angaben, die man üblicherweise auch zur Anmeldung in einem Webmailer verwendet, also Mailadresse und Passwort, reichen aus, und schon funktioniert alles wie von Geisterhand. Doch damit das so einfach klappt, sind natürlich im Hintergrund einige dienstbare Geister erforderlich. Für die technisch Interessierten beschreibe ich daher im Folgenden, wie die seit einer Weile am RRZK verfügbare automatische Konfiguration für die weit verbreiteten Mailprogramme Thunderbird (ab Version 3.1) und Outlook (ab Version 2007) funktioniert. Wie nicht anders zu erwarten gibt es darüberhinaus natürlich noch weitere Ansätze zur automatischen Konfiguration von Mailkonten, z.B. auf dem iPod/iPad/iPhone, um die es hier aber nicht gehen soll.

Autoconfig für Thunderbird

Im Mozilla-Umfeld ist die automatische Konfiguration unter dem Begriff Autoconfiguration (oder kurz Autoconfig) bekannt. Ursprünglich mit Thunderbird 3.0 eingeführt, hat sich die Spezifikation mit Thunderbird 3.1 weiterentwickelt und dabei inzwischen ein nach meiner Ansicht recht brauchbares Stadium erreicht. Zwar wird weiterhin an Erweiterungen gearbeitet, die die Software in bestimmten Umfeldern noch besser einsetzbar machen, und der eine oder andere Fehler steckt auch noch im Konfigurationsassistenten, aber insgesamt macht diese nützliche Funktion schon einen sehr brauchbaren Eindruck.

Doch wie funktioniert die automatische Konfiguration bei Thunderbird überhaupt? Zunächst einmal wird aus der eingegebenen Mailadresse der Domainname, also der Teil rechts vom @-Zeichen, extrahiert. Dieser kann dann verwendet werden, um in einer vom Mozilla-Projekt betriebenen Datenbank nachzuschlagen, ob dort ein Eintrag mit Konfigurationsdaten für diesen Mailanbieter vorhanden ist. Das ist natürlich typischerweise nur bei sehr großen, weltweit tätigen Mailanbietern der Fall. Mit den so gewonnenen Informationen kann Thunderbird dann die Mailservereinstellungen von alleine vornehmen und versuchen sich mit dem eingegebenen Passwort beim Server anzumelden. Voraussetzung dafür ist jedoch, dass zum Login auf dem Server ebenfalls die Mailadresse (oder der sog. Localpart, der Teil links vom @ in der Mailadresse) verwendet wird. Das ist jedoch am RRZK nicht immer der Fall. Hier erfolgt die Anmeldung stets mit dem Benutzerkennzeichen und dieses kann – jedenfalls dann, wenn für den Account ein Alias angelegt wurde – nicht direkt aus der Mailadresse abgeleitet werden.

In diesem Fall ist es also etwas komplizierter. Um die automatische Konfiguration dennoch zu ermöglichen, betreibt das RRZK einen Server speziell für diesen Zweck, der von Thunderbird abgefragt werden kann. Über passende DNS-Einträge wird der Server von Thunderbird gefunden, und mittels der bei der Abfrage übermittelten Mailadresse ist der Konfigurationsserver seinerseits in der Lage, das hierzu passende Benutzerkennzeichen herauszufinden und dies – zusammen mit den zu verwendenden Servernamen und den Sicherheitseinstellungen – zurück an Thunderbird zu schicken. Auf diese Weise erhält also jeder Benutzer eine individuell für sein Benutzerkennzeichen angepasste XML-Datei vom Konfigurationsserver, wodurch diese komfortable Einrichtung des Mailkontos ermöglicht wird. (Neben den beiden zuvor genannten Möglichkeiten versucht Thunderbird im Notfall übrigens auch noch, die Servernamen zu erraten, indem bei einer Mailadresse foobar@example.com einfach häufig genutzte Namen wie mail.example.com ausprobiert werden, jedoch kann dieser Ansatz systembedingt beim RRZK-Mailservice nicht zuverlässig funktionieren.)

Autodiscover für Outlook

Auch Microsoft möchte es den Benutzern seiner Software besonders leicht machen und hat bereits seit der Version 2007 in Outlook eine automatische Konfiguration von Mailkonten vorgesehen, die den Namen Autodiscover trägt. Nicht nur Verbindungen zu den Microsoft-eigenen Exchange-Servern können damit automatisiert konfiguriert werden, sondern auch solche zu „normalen“ Mailservern nach den gängigen Internet-Standards (SMTP, POP, IMAP). Liest man die von Microsoft hierzu publizierte Spezifikation durch und vergleicht sie mit der des Mozilla-Projekts, so denkt man auf den ersten Blick „Hut ab!“, denn das Microsoft-Dokument erscheint wesentlich durchdachter. Beispielsweise wird auch das Thema Fehlerbehandlung darin genau abgehandelt, was bei dem Mozilla-Ansatz eher schlicht-pragmatisch nach dem Motto „wenn der Login nicht klappt merkt man ja, dass ein Fehler vorliegt“ gehandhabt wird.

Leider verflüchtigt sich dieser gute Eindruck schnell, wenn man sich intensiver mit dem Thema befasst. So ist es beispielsweise bei Outlook 2007 nicht mit Hilfe der Autodiscover-Funktion möglich, das Programm dazu zu bewegen, eine mittels StartTLS verschlüsselte Verbindung zum Postausgangsserver aufzubauen, obwohl das Programm diese Funktionalität sehr wohl beinhaltet (über die normale Benutzeroberfläche kann dies mit wenigen Mausklicks eingestellt werden). Während bei anderen Softwareherstellern ein solch offensichtlicher Fauxpas sicherlich bald mit einem Update auskuriert würde, hält man dies bei Microsoft offenbar nicht für nötig und behebt diesen Fehler erst in der kostenpflichtigen Nachfolgerversion Outlook 2010. Aus Programmierersicht lästig ist sicherlich auch der Ansatz, für die Übergabe eines einzelnen Parameters, nämlich der Mailadresse, gleich eine ganze XML-Datei mitzuschicken (darüber haben sich andere bereits ausgelassen), wenn auch letztlich nur konsequent, da Microsoft damals offenbar ganz und gar auf dem HTTPS-XML-Trip war – inzwischen bevorzugt man in Redmond offenbar SOAP.

Fast noch ärgerlicher als dieser Fehler ist jedoch die Art und Weise, wie die Verfügbarkeit von StartTLS bei der XML-Konfiguration von Microsoft kommuniziert wird. Liest man sich die Hinweise auf dieser Microsoft-Webseite durch, die von sich selbst behauptet, für die Version 2010 überarbeitet worden zu sein, so erfährt man nichts über die neu hinzugekommene Möglichkeit mittels des Encryption-Tags eben doch StartTLS angeben zu können. Erst an anderer Stelle sind die hoffentlich richtigen Informationen dann zu finden. Und weil zwei verschiedene Varianten noch nicht reichen, gibt es auch noch eine dritte Website bei Microsoft, die den Informationen auf den ersten beiden widerspricht, denn hier wird in diesem Beispiel das Error-Element als Kind des Account-Elements beschrieben, was es gemäß des veröffentlichten XML-Schemas (oder auch des Beispiels für eine XML-Antwort im Fehlerfall) hingegen nicht ist. Microsoft wäre jedoch nicht Microsoft, wenn man dort drei Dokumente bräuchte, um sich selbst zu widersprechen: Nein, schon innerhalb eines Einzelnen findet man zum Thema Autodiscover widersprüchliche Aussagen. So ist im Abschnitt 2.2.3.2.2 der zuvor genannten zweiten Spezifikation die Rede davon, Unterstützung für das RedirectUrl-Tag sei zwingend vorgeschrieben (MUST-Requirement), während wenige Zeilen später im Abschnitt 2.2.3.2.4 daraus ein SHOULD-Requirement wird.

Übertroffen wird diese Schlamperei nur noch durch die Implementierung der Spezifikation in Outlook selbst. Denn die zuvor lobend erwähnten Informationen im Fehlerfall, etwa wenn aufgrund eines Tippfehlers in der vom Benutzer angegebenen Mailadresse der Konfigurationsserver signalisiert, dass für diese Adresse keine automatische Konfiguration erfolgen kann, wertet Outlook nicht etwa aus oder zeigt die Fehlermeldung dem Benutzer an, nein, stattdessen wird einfach versucht die richtigen Einstellungen per Guessmart zu raten, was in diesem Fall natürlich zum Scheitern verurteilt ist und dem Benutzer stattdessen eine unklare Fehlermeldung beschert. Dass das Microsoft-Produkt im Gegensatz zu praktisch jeder anderen Mailsoftware auch nicht in der Lage ist, den Realm für eine DIGEST-MD5-Authentifizierung korrekt auszuhandeln (in Microsofts eigenem Jargon unter „SPA“ subsumiert) ist dann nur noch das Tüpfelchen auf dem i.

Während der grundsätzliche Ablauf der automatischen Ermittlung bei beiden Verfahren gleich ist (Ermitteln des Konfigurationsservers, Anfrage mit der zu konfigurierenden Mailadresse abschicken, XML-Datei empfangen), so besteht ein gewichtiger Unterschied zwischen der Autoconfig-Funktion von Thunderbird und dem Autodiscover von Outlook darin, dass beim Autodiscover standardmäßig eine per SSL verschlüsselte Verbindung zum Einsatz kommt. Dies macht es erforderlich, für jede Maildomain einen eigenen Webserver mit passendem Zertifikat zu betreiben, wenn nicht bei jedem Aufruf erst einmal eine Warnmeldung erscheinen soll. Aus diesem Grund ist die automatische Konfiguration für Outlook am RRZK auch nur für uni-koeln.de und smail.uni-koeln.de verfügbar, im Gegensatz zur automatischen Konfiguration von Thunderbird, die darüberhinaus auch für virtuelle Maildomänen verfügbar ist. Seitdem am RRZK auch Let’s Encrypt zur Verfügung steht, um Websites mit Zertifikaten für SSL/TLS auszustatten, steht der Autodiscover-Dienst nun auch für nahezu alle virtuellen Mail-Domänen bereit. Somit funktioniert auch für solche Mailadressen des Typs 

name@einrichtung.uni-koeln.de

die Einrichtung der Mailadresse in Outlook – zumindest den Desktop-Versionen – automatisch. Allerdings ist Outlook als IMAP-Client auch nicht unbedingt zu empfehlen.

2.2.3.2.2

Wenn Windows weiß waschen nicht reicht

Daß die IT-Branche ein schnelllebiges Geschäft ist, weiß eigentlich jeder. Ein Bereich, für den das ganz besonders gilt, sind allerdings Schädlingsprogramme aller Art (Viren, Trojaner, Rootkits, Scareware, etc.). Auf die Veröffentlichung von Sicherheitslücken hin vergehen inzwischen oft nur mehr Stunden anstatt Tage, bis Exploits dafür auftauchen oder auch gleich in Frameworks wie Metasploit eingebaut werden.

Das Resultat sind, trotz verbesserter Abwehrmaßnahmen, weiterhin haufenweise infizierte PCs, auch oder gerade hier an der Uni. Daher möchte ich zu meinen früheren Veröffentlichungen rund um das Thema Virenbefall einmal ein aktuelles Update geben und etwas ausführlicher auf die Abhilfe bei einem derzeit sehr häufigen Problem bei virenbefallenen PCs mit Windows XP eingehen.

Gefahrenherde

Wie auch schon beim letzten Mal erwähnt,  ist die beste Methode, um einen mit Schädlingsprogrammen infizierten Rechner zu säubern, immernoch eine Datensicherung der selbst erstellten Dateien und eine anschließende Neuinstallation (oder natürlich das Zurückspielen eines hoffentlich vorhandenen Images des Systems in einem sicheren Zustand). Leider zeigt die Erfahrung, daß von denjenigen Benutzern, die immer wieder von Schädlingsprogrammen betroffen sind, die wenigsten daran gedacht haben, rechtzeitig Images und Backups anzufertigen. Wer sich beim Lesen dieser Zeilen selbst ertappt fühlt, den Aufwand eines „richtigen“ Images aber weiterhin scheut, dem kann ich auf alle Fälle den XP-eigenen Assistenten für das „Übertragen von Dateien und Einstellungen“ ans Herz legen. Man findet ihn im Startmenü unter Zubehör, Systemprogramme. Hiermit lässt sich zumindest einmal schnell, einfach und kostenlos das „Look und Feel“ der eigenen Arbeitsumgebung sichern, das man sich nach einer Neuinstallation ansonsten mühsam und langwierig zusammenklicken müsste (aus meiner Sicht einer der nervigsten Punkte bei einer Neuinstallation, der die Freude über ein sauberes und schnelles System viel zu schnell vergehen lässt).

Eine Neuinstallation ist zwar die sinnvollste Methode, nicht immer ist sie aber auch gangbar. Nach wie vor wird es Fälle geben, in denen man eine Reinigung des infizierten Systems durchführen muß oder möchte. Wer mit derartigen Problemen häufiger zu tun hat, wie etwa die Beratung des RRZK, wird sich im Laufe der Zeit dafür sicherlich eigene Tools, z. B. auf Basis von BartPE, zurechtgelegt haben. Wer hingegen zum ersten Mal vor einem solchen Problem stand, hatte es in der Vergangenheit schwer. Zum Zeitpunkt ihrer Veröffentlichung war die Sicherheits-CD der Beratung daher ein ganz besonders wertvolles Werkzeug, da sie es ermöglichte, mit einem aktuellen Virenscanner von CD zu starten und so den Rechner auf vertrauenswürdige Weise nach Schädlingsprogrammen zu durchsuchen.

Tools für alle

Diese Situation hat sich inzwischen gewandelt: Mittlerweile bieten eine ähnliche Funktion auch die kostenlos herunterladbaren Rescue-CDs der Antivirushersteller Avira, Bitdefender, F-Secure oder Kaspersky an. Und eine DVD, mit der ein betroffener Windows-PCs „offline“ (also korrekterweise vor dem erneuten Kontakt mit dem Netzwerk) aktualisiert werden kann, kann inzwischen auch jeder mit etwas Geduld und Bandbreite nach wenigen Mausklicks selbst zusammenstellen.

Während man – was die Werkzeuge zur Virensuche angeht – inzwischen also auf ein reichhaltiges Arsenal an kostenfrei verfügbaren Lösungen durückgreifen kann, ohne selbst sehr viel Zeit investieren zu müssen, bleibt neben dem Aspekt der Unvollständigkeit sämtlicher Virensuchprogramme noch das ebenfalls sehr große Problem der „Hinterlassenschaften“ von Schädlingsprogrammen. Die Virenscanner, von einer Rescue-CD gestartet zumal, beschränken sich im Regelfall darauf, Dateien zu entfernen, die einen als schädlich bekannten Code beinhalten (eine lobenswerte Ausnahme ist hier das kostenlose Anti-Spyware-Programm Spybot Search and Destroy, welches auch unerwünschte Registry-Einstellungen erkennen und korrigieren kann). Wie schon früher erwähnt, können verstellte Einstellungen in Windows eine erneute Infektion begünstigen, so daß es oft nur eine Frage der Zeit ist, bis ein lediglich von infektiösen Dateien befreites System erneut befallen ist. Und im ungünstigsten Fall, um den es hier im Folgenden gehen soll, sind die Einstellungen in Windows so geändert worden, daß man sich nach der Virensäuberung per Rescue-CD noch nicht einmal mehr am Windows-System anmelden kann.

Auf die Anmeldung folgt die sofortige Abmeldung

Die Symptome dieses Problems sind stets die gleichen: nach der Virenreinigung wird Windows XP normal hochgefahren, man meldet sich an, der Desktophintergrund erscheint, doch wenige Sekunden später heißt es nur noch „Einstellungen werden gespeichert“  – man wird sofort wieder abgemeldet und sieht wenige Sekunden später erneut den Anmeldebildschirm. Der Hintergrund dieses Vorgangs ist ebenso perfide wie clever (das muß man den Malware-Autoren einfach neidlos zugestehen): Ein Teil des Schädlingsprogramms wird in Windows als Debugger des für den Anmeldevorgangs zuständigen Programms userinit.exe deklariert. Das führt dann dazu, daß das Schädlingsprogramm bei jedem Anmeldevorgang mit gestartet wird, in den üblichen Listen von Autostartprogrammen, wie sie etwa msconfig oder RunAlyzer anzeigen, aber nicht auftaucht. Außerdem führt diese Vorgehensweise eben dazu, daß nach dem Löschen der Schädlingsdatei diese beim nächsten Anmeldeversuch nicht mehr gefunden wird und die Anmeldung fehlschlägt, weil der von Windows als obligatorisch betrachetete „Debugger“ fehlt. Wem das nach einer Virenentfernung auf eigene Faust einmal passiert ist, wird beim nächsten Mal vermutlich auch eher bereit sein, den Anbietern von Scareware-Programmen Geld für eine „Lösung“ dieses Problems hinterherzuwerfen, wenn ansonsten nur die Möglichkeit bleibt, nochmals vor einem „verschlossenen“ Windows zu stehen.

Problem erkannt, Problem gebannt?

Selbstverständlich sollte man nicht die Machenschaften von Kriminellen unterstützen und irgendwelche dubiosen Programme erwerben, um sich nach einem Virenbefall wieder an seinem Windows-System anmelden zu können (im harmlosesten Fall sind diese überteuerten Programme einfach nur nutzlos, mit etwas Pech lädt man sich freiwillig ein weiteres Spionageprogramm auf den PC). Die Lösung ist vielmehr eigentlich ganz einfach: Man muß „nur“ in der Registry des betroffenen Systems den Schlüssel

HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionImage File Execution Optionsuserinit.exe

inklusive aller seiner Unterschlüssel löschen (und darauf achten, daß man auch wirklich unter …Windows NT… sucht, nicht bei einem anderen, ähnlich lautenden Schlüssel in der Nähe). Doch wie stellt man das an, wenn man sich noch nicht einmal mehr im abgesicherten Modus anmelden kann? Dazu gibt es mehrere denkbare Möglichkeiten. Ich schlage im folgenden gleich mehrere davon vor, die alle den gleichen Effekt haben, aber unterschiedliche Voraussetzungen mit sich bringen und in ihrer Komplexität steigend angeordnet sind. Da dies eine Beschreibung für IT-Profis ist, beschränke ich mich zudem darauf, die groben Schritte zu erklären und nicht jedes Detail, und weise auch nur an dieser Stelle noch einmal darauf hin, daß man natürlich eine Sicherungskopie anlegen sollte, bevor man Änderungen an einer so wichtigen Systemdatei vornimmt.

  1. Änderung unter Windows PE durchführen

    Voraussetzungen: Man verfügt über eine beliebige Installations-DVD bzw. -CD von Windows Vista oder Windows 7, es reicht sogar die eines Release Candidate. Alternativ geht natürlich auch eine funktionierende BartPE-CD.
    Vorgehensweise:
    Von der Windows-DVD bzw. -CD starten.

    Bei der Installations-DVD von Windows 7 kann direkt nach Erscheinen des Willkommensbildschirms mit der Tastenkombination Shift+F10 eine Eingabeaufforderung gestartet werden, bei dem Installer von Vista muß man erst noch so tun, als wolle man tatsächlich Vista installieren und ein paar Schritte der Installation durchklicken, bevor das Drücken von Shift+F10 die gewünschte Wirkung zeigt (alternativ kann man sich dort aber auch durch die Computerreparaturoptionen klicken, dort kann man schlußendlich auch eine Eingabeaufforderung aufrufen).

    In der Eingabeaufforderung regedit eingeben.

    Im Registrierungseditor den Zweig HKEY_LOCAL_MACHINE auswählen und über den Punkt Datei, Struktur laden die Datei C:WindowsSystem32ConfigSoftware laden (wenn C: die Festplatte mit dem betroffenen Windows ist, ansonsten natürlich die Pfadangabe anpassen). Bei der Frage nach dem Namen eine sinnvolle Bezeichnung wie etwa Software_auf_C eingeben.

    Nun in leichter Abwandlung des zuvor genannten Pfades sich durchklicken zum Schlüssel HKEY_LOCAL_MACHINESoftware_auf_CMicrosoftWindows NTCurrentVersionImage File Execution Options und dabei wie erwähnt auf das …Windows NT…  achten. Hier den Schlüssel userinit.exe unter Bestätigung der Rückfrage löschen.

    Ganz nach oben scrollen und den Schlüssel Software_auf_C auswählen. Über Datei, Struktur entfernen den Registryzweig wieder entfernen und die Rückfrage dazu bestätigen.

    Regedit beenden, die Eingabeaufforderung schließen und den Computer neu starten.

  2. Registry remote über das Netzwerk ändern

    Voraussetzungen: Der Rechner war vor dem Vorfall schon in ein lokales Netzwerk eingebunden (ist also entsprechend konfiguriert), man hat Zugang zu einem anderen Windows-PC im gleichen Subnetz, die Windows-Firewall auf dem betroffenen PC enthält eine entsprechende Ausnahme und die notwendigen Dienste laufen auf dem PC (Remote-Registrierung, RPC).

    Vorgehensweise:
    Den betroffenen PC an das Netzwerk anschließen und einschalten.

    Auf dem zweiten PC regedit starten.

    Über den Menüpunkt Datei, Mit Netzwerkregistrierung verbinden die Registry des fremden PCs öffnen und den o. g. Schlüssel HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionImage File Execution Optionsuserinit.exe samt seiner Unterschlüssel löschen.

    Zum Schluß noch Von Netzwerkregistrierung trennen und Regedit beenden.

  3. Mit Hilfe einer Linux-Live-CD die benötigte Datei kopieren

    Voraussetzungen: Eine aktuelle Live-CD, die vernünftig mit dem NTFS-Dateisystem umgehen kann, z. B. Ubuntu 9.10, ein USB-Stick sowie Zugang zu einem funktionierenden Windows-System.

    Vorgehensweise:
    Von der Live-CD starten.

    Das Dateisystem mit der problembehafteten Windows-Installation lokalisieren. Von dort die Datei Windows/System32/Config/Software auf den USB-Stick kopieren. Den Stick „auswerfen“, vom PC abziehen und das Linux weiterlaufen lassen.

    Mit dem USB-Stick zu einem normalen Windows-PC gehen, dort regedit starten.

    Auf dem anderen Windows-PC im Prinzip so vorgehen wie bei der Alternative (1) beschrieben, nur beim Struktur laden natürlich die Datei „Software“ vom USB-Stick öffnen. Dann wie dort beschrieben den Schlüssel userinit.exe löschen und die Struktur wieder entfernen. Regedit beenden und den USB-Stick „sicher entfernen“.

    Mit dem Stick zurück zum betroffenen PC gehen. Vom USB-Stick die bearbeitete Datei „Software“ zurück in das Verzeichnis Windows/System32/Config kopieren (also die gleichnamige Datei dort überschreiben). Den Stick und das Windows-Dateisystem „auswerfen“ und den Computer neu starten.

Hat man eine dieser drei Alternativen erfolgreich durchgeführt, sollte die Anmeldung unter Windows auf dem PC nun wieder normal funktionieren, d. h. man sollte nun nicht mehr wenige Sekunden nach der Anmeldung wieder automatisch abgemeldet werden.

Knoten im Taschentuch

Auch wenn es an anderen Stellen schon dutzende Male erwähnt wurde, auch hier nochmal einige Punkte, an die man unbedingt denken sollte, wenn man es mit einem solcherart „gereinigten“ Rechner zu tun hat:

  • Neben dem Browser (also Firefox, Opera, Safari, Chrome oder was immer man anstatt des Internet Explorers verwendet) müssen auch alle browsernahen Programme auf den aktuellen Stand gebracht werden. Zu den zu aktualisierenden Komponenten zählen zumindest mal der Adobe Reader, Flash und Java, wobei bei Java auch unbedingt alle alten Versionen deinstalliert werden müssen.
  • Nach weiteren veralteten Versionen von Anwendungsprogrammen Ausschau halten, z. B. mit Hilfe des Online-Scan-Tools von Secunia
  • Mit einer Software wie dem oben erwähnten SpybotSD nach unerwünschter Software und daraus resultierenden Systemänderungen suchen. Auch der MBSA kann hilfreiche Dienste leisten (vorausgesetzt, man weiß dessen Hinweise zu interpretieren).
  • Endlich mal ein Backup anlegen.

Und eben weil die Wiederholung so wichtig ist, schließe ich einfach mit den Worten: Neuinstallation ist immernoch die sicherste Methode.

Wurmbefallenes Windows weiß waschen

Mit Schädlingsprogrammen befallene Windows-Systeme sind eine echte Pest. Auch im Uninetz tauchen solche Systeme immer wieder auf.

Die richtige Methode zur Problembehebung ist natürlich eine Neuinstallation. Leider gibt es aber auch Situationen, in denen das – zumindest temporär – nicht möglich ist. Hier wird man dann versuchen müssen, das System mit Hilfe von Virenscannern und Anti-Spyware-Programmen zu säubern. Angesichts der heutigen Vielfalt von Malware und der Frequenz, mit der immer neue Varianten erscheinen, hat man dabei jedoch häufig selbst bei der Verwendung mehrerer unterschiedlicher Programme schlechte Karten, wirklich alle unerwünschten Komponenten zu erwischen. Daß man dazu ein von Live-CD gestartetes Rettungssystem verwenden muß, ist ja ohnehin klar.

Eine weiteres Problem sind Hinterlassenschaften, die auch nach dem Löschen von als infiziert eingestuften Dateien zurückbleiben. Da wird dann beispielsweise die Windows-Firewall deaktiviert und eine Gruppenrichtlinie gesetzt, die ein einfaches Reaktivieren verhindert, oder die Einstellungen für die automatischen Updates von Windows werden unbrauchbar gemacht, so daß das System spätestens beim Entdecken der nächsten Windows-Sicherheitslücke gleich wieder infiziert werden kann.

Das häufigste Problem in dieser Hinsicht sind jedoch Manipulationen an den Netzwerkeinstellungen, um die Benutzer infizierter Rechner auf irgendwelche Phishing-Sites umzuleiten. Der Klassiker sind dabei sicherlich Manipulationen an der Datei %windir%system32driversetchosts. Da wurden dann gerne mal die Update-Server und Websites von Antivirenherstellern geerdet oder auch beliebte Angebote wie ebay.de umgeleitet. Diese Änderungen werden von Anti-Virus-Programmen mittlerweile aber meist erkannt. Sehr beliebt waren eine Zeit lang auch Eingriffe in den Netzwerkverkehr über Winsock-LSPs, wogegen aber zum Glück auch ein Kraut gewachsen ist. Inzwischen werden gleich ganz andere Geschütze aufgefahren.

Etwas weniger versiert, aber nach meiner Beobachtung derzeit weitaus weiter verbreitet, sind direkte Manipulationen an den Windows-eigenen Netzwerkverbindungen (also z.B. der „LAN-Verbindung“ oder der „Drahtlosen Netzwerkverbindung“). Da wird dann in den Eigenschaften von TCP/IP konfiguriert, daß zwar die IP-Adresse per DHCP bezogen werden soll, aber die Adresse des DNS-Servers wird manuell eingestellt – auf einen manipulierten DNS-Server der Phishing-Banden, versteht sich. Diese Vorgehensweise ist schon ziemlich clever: Bei einem einfachen ipconfig sieht alles OK aus, denn dort sieht man die Adresse des DNS-Servers nicht, und zunächst scheint im Netzwerk auch alles normal zu funktionieren. Nur die Webseiten, die man zu Gesicht bekommt, sind halt oft genug nicht die Originalseiten, sondern von den Phishern nachgemachte Seiten, bei denen die eingegebenen Paßwörter gestohlen werden. Statt eines einfachen ipconfig muß man also ipconfig /all verwenden und kontrollieren, ob die eingestellten DNS-Server die richtigen sind (im UKLAN sind das diese hier).

Natürlich gibt es noch viel mehr Dinge, die man auf einem einmal kompromittierten System kontrollieren müsste – von Backdoorprogrammen über Rootkits oder manipulierte Dienste bis zu geänderten Passwörtern oder neu angelegten Benutzerkonten. Die eingangs erwähnte Neuinstallation ist daher auf jeden Fall die beste Variante, die man wenn irgend möglich auch beherzigen sollte. Aber für die Fälle, in denen eben nicht neu installiert werden kann, sollte man zumindest die hier genannten Manipulationsmöglichkeiten kennen und überprüfen, ob Sie auf dem „gereinigten“ System vorliegen.