Passwörter mit Dashlane aufbewahren, einsetzen und synchronisieren

Meine Ausgangspunkt

Mein digitales Leben ist “geschützt” durch gefühlt Zillionen von Passwörtern – faktisch sind es einige Hundert, aber mit Erinnerungsvermögen ist da nichts mehr zu machen. Bisher nutzte ich meinen Browser sowie eine lokale Anwendung auf meinem Smartphone zur Verwahrung dieser Credentials. Das war mehr schlecht als recht, denn mein Gerätebestand umfasst OS X, Android, Windows7 und iOS — alles in allem ein mittlerer Alptraum.

Dashlane “betritt” mein digitales Leben

Ein Artikel von David Pogue [1][2] machte mich auf Dashlane aufmerksam. Das Tool behebt mein Problem inzwischen wirklich recht gut. Der “Migrationsaufwand” war bei mir nicht wirklich vernachlässigbar, weil die Import-Funktion bei mir nicht so genial funktioniert hat – also knapp unter “Do What I Think”-Niveau. Auch das Sortieren der einzelnen Records nach Kategorien nervt (auch wenn es vernünftig ist).

Nach dieser Einstiegshürde ist Dashlane aber wirklich nützlich. Ich nutze die Anwendung nicht lokal, sondern synchronisiere darüber mein gutes halbes Dutzend Devices. Das funktioniert kostenlos für 30 Tage, danach nur mit einer kostenpflichtigen Subscription – Eine schwierige Abwägung zwischen Geiz und Komfort!

Meine Konfiguration ist nun so, dass ich Dashlane auf meinem Notebook, Arbeitsplatzrechner, Android-Smartphone, iPad und den privaten Rechnern nutze. Das Smartphone nutze ich auch als One-Time-Password-Generator (Google Authenticator).

Erfahrungen

Dashlane ist schon sehr pfiffig darin, Formulare richtig auszufüllen, aber David Pogues Beschreibung erscheint mir etwas zu euphorisch. Mir sind schon etliche Seiten untergekommen, bei denen die Logik nicht funktioniert. Bei englischsprachigen Seiten funktioniert das Auto-Ausfüllen aber gut.

Wirklich cool ist, dass man das Ausfüllen auf “Subdomains” ausdehnen bzw. einschränken kann und die Möglichkeit mit mehreren Accounts für eine Website umgehen zu können. Nett ist auch die Möglichkeit, sichere Passwörter erzeugen zu lassen; nützlich sind die Hinweise auf vermutliche kompomitierte Web-Site, bei denen man Accounts hat. Das Wallet habe ich bisher wenig (aber erfolgreich) genutzt. Die anderen Features wie Nachrichten-Austausch und so nutze ich nicht.

Risiken und Nebenwirkungen

Ach ja, das Synchronisieren geht natürlich über die Server von Dashlane. Das Sicherheitsmodell scheint mir wasserdicht zu sein, solange man auf keinem seiner Endgeräte einen Keylogger eingefangen hat oder sonst irgendwie das Masterpasswort verliert. Im Normalfall geht also “unbrauchbarer” AES256-Datenschrott über den Austauschpunkt. Für die Sicherheit von AES256 gibt es sogar eine Zusicherung der NSA – super!

Um etwas Schutz gegen die Keylogger-Problematik zu haben, nutze ich die Zwei-Faktor-Authentifizierung. Dann kann niemand ein Endgerät mit meinem Dashlane-Datenaustausch-Account verknüpfen. Wenn ich mein Android-Smartphone UND mein Masterpasswort verliere, wäre das natürlich ganz schlecht.

Nun gut, die Prism-Tempora-Sonstwas-Maschinen wissen nun wirklich ganz genau, welche Endgeräte ich nutze. Vermutlich ist dies ja auch für jene Leute die wirklich interessante Information – Passwörter von Individuen brauchen die eh nicht so dringend. Also: “Ja, man gibt Futter für diese Maschinen”, damit das Korrelieren im Big-Data-Wust dann besser geht.

Zusammenfassung

Angesichts des Nutzens finde ich das Werkzeug sehr interessant und werde es weiterhin einsetzen. Unberührt von der technischen Coolness ist der Umstand, dass beispielsweise eine Unternehmspolicy das Hinterlegen bestimmter Credentials in Password-Manager-Anwendungen untersagen kann.

Prüfung von Sicherheitszertifikaten

Die Prüfung der von Servern verwendeten Zertifikate hinsichtlich ihrer Gültigkeit  und Vertrauenswürdigkeit ist heutzutage ein elementarer Bestandteil der persönlichen Sicherheit im Internet. Viel zu oft werden solche Hinweise zwar einfach weggeklickt, spätestens bei Shops, die die Angabe der Konto- oder Kreditkartendaten erfordern, und erst recht beim Online-Banking sollten aber wirklich alle Internetnutzer misstrauisch werden, sobald der Browser eine entsprechende Warnung anzeigt.

Aus diesem Grund ist auch die Uni Köln seit Jahren einer Certificate Authority angeschlossen, die in allen gängigen Browsern und Mailclients als vertrauenswürdig bekannt ist, namentlich der Root-CA der Deutschen Telekom. Denn auch an der Uni müssen z.T. sehr vertrauliche Daten über das Netz geschickt werden, z.B. Prüfungsergebnisse, Accountdaten oder auch E-Mails.

Umso wichtiger ist es, dass die entsprechende Prüfung der gemeldeten Sicherheitszertifikate möglichst automatisiert und zuverlässig erfolgt. Hierfür gibt es ein eigenes Netzprotokoll, das “Online Certificate Status Protocol” (OCSP). Es prüft automatisch die Gültigkeit des vom aufgerufenen Server gesendeten Zertifikates. Dies ist leider nicht bei allen Browsern und Mailclients korrekt voreingestellt. Zum Teil wird nur auf den Servernamen geprüft, zum Teil aber auch gar nicht. Wir möchten daher hier für die wichtigsten Programme kurz beschreiben, wo die korrekten Einstellungen vorzunehmen sind.

Mozilla Firefox / Mozilla Thunderbird
Bei den beiden Mozilla-Programmen finden sich die Einstellung in einem übersichtlichen Menü unter “Einstellungen” → ”Zertifikate” → ”Validierung”.

Google Chrome
In Chrome muss unter “Einstellungen” → ”Erweiterte Einstellungen anzeigen” → ”HTTPS/SSL” ein Häkchen bei “Serverzertifikate auf Sperrung prüfen” gesetzt werden.

Internet Explorer / Windows Mail / Outlook
Alle drei sind fest mit dem Windows-Zertikatspeicher verbunden, den man im Internet Explorer unter “Extras” → “Internetoptionen” → “Inhalte” → “Zertifikate” erreicht (die Menüfolge mag in den verschiedenen Versionen etwas anders sein). OCSP wird von Windows erst seit Vista – und damit auch in Windows 7 und 8 – unterstützt, für XP fehlt die Funktion leider. Die Aktivierung erfolgt in “Extras” → “Internetoptionen” → “Erweitert” und umfasst die Einstellungen “Auf gesperrte Zertifikate überprüfen” und “Auf gesperrte Zertifikate von Herausgebern überprüfen”.

Apple Safari
Safari nutzt den zentralen Schlüsselbund von MacOSX. Diesen erreicht man in der Regel über das Anwendungsmenü im Bereich “Utilities” oder “Werkzeuge”. Innerhalb des Schlüsselbunds kann man im Menü “Einstellungen”, Karteireiter “Zertifikate” die passenden Einstellungen wählen. In aller Regel ist dies bei OCSP und CRL jeweils “Bester Versuch”, die Priorität sollte auf OCSP liegen.

Opera
In Opera (ab Version 9) muss man den Umweg über die Seite “about:config” im Browser gehen. In den “Security Prefs” kann man den Eintrag bei “OCSP Validate Certificates” ändern. Da dieser aber standardmäßig aktiviert ist, muss man in der Regel nichts ändern.

Zwei-Faktor-Verifikation für Google-Accounts

Ob das RRZK-Blog ein guter Platz ist, um über ein Feature von Google-Accounts zu schreiben? Ich bin nicht sicher, aber viele an der Uni nutzen ja die Google-Angebote und daher ist es vielleicht für ein paar Leute von Interesse.

Ich selbst nutze einen Google-Account seit 2006 für mein “persönliches digitales Leben”. Die Datenschutz-Problematik ist mir durchaus bewusst, aber die Funktionen sind einfach zu verführerisch, um widerstehen zu können. Schon lange hat mich gestört, dass meine Daten nur durch ein kleines Passwort von der Welt getrennt sind. In einer globalen Cloud können merk- und tippbare Passwörter praktisch nie ein geeigneter Schutzmechanismus sein.

Seit einigen Monaten bietet Google nun eine Authentifizierungsmethode an, die “Two Step Verification” genannt wird. Das klingt verdächtig nach der klassischen Zwei- bzw. Mehr-Faktor-Authentifizierung. Dies legt auch die Intro-Page nahe, die sagt “Sign in will require something you know and something you have”. Klingt sehr gut.

Der Start ist auch recht simpel; eine kleine Änderung in den Account-Einstellungen und man erhält Einmal-Zugriff-PINs über SMS, Voice Call oder eine recht nette Authenticator-App (für Android, iOS usw.), die zusammen mit dem traditionellen Passwort den Zugriff auf das Konto ermöglichen. Außerdem kann man Geräte nach eigenem Ermessen als “vertrauenswürdig” einstufen; dann entfällt dort die Eingabe der zusätzlichen PIN. Auch der Desaster-Fall ist bedacht: dafür gibt es Backup-PINs zum Ausdrucken (Natürlich nicht ausdrucken, falls der Drucker ein Gerät mit Festplatte oder Netzwerk-Anschluss ist ;) ).

Wie immer gibt es in der schönen neuen Welt auch ein paar Relikte aus der hässlichen alten Welt; in diesem Fall sind das die “anwendungsspezifischen Passwörter“. Diese sind zwar nicht “anwendungsspezifisch”, aber Passwörter mit fast allen schlechten Eigenschaften, die Passwörter haben können. Sie sind nicht anwendungsspezifisch, weil sie den Zugriff auf das komplette Google-Konto ermöglichen. Die Terminologie bedeutet, dass sie nur für eine bestimmte Anwendung eingesetzt werden sollen.

Ein zusätzlicher Schutz (im Vergleich zum klassischen Passwort) besteht neben der Länge darin, dass es weniger Risiken gibt, das Passwort zu verlieren oder unabsichtlich offenzulegen (revealing). Faktisch wird es einmal angezeigt und dann nie wieder; schreibt man es nicht auf, sondern kopiert es sofort in die Anwendung der Wahl und vergisst es, so kann man es selbst nicht mehr verlieren. Trotzdem kann in der rauen Wirklichkeit das eigene Google-Konto über diesen Mechanismus “geknackt” werden. Also: Der Provider kann es noch “für einen verlieren” – quasi “RaaS, Revealing as a Service”.

Klar, die “anwendungssprezifischen Passwörter” sind eben Passwörter und daher ist der Authentifizierungsmechanismus auch keine echte Zwei-Faktor-Authentifizierung. Ich vermute, dass Google daher auch von einer “Two Factor Verification” spricht. Zu dem Mechanismus und seinen potenziellen Schwachstellen gibt es diverse mehr oder weniger technische Erläuterungen.

Alles sinnlos also? Falls das eigene digitale Leben spartanisch ist und sich auf die Browser-Schnittstelle bzw. moderne Android-Systeme (wohl >2.3) beschränkt, sind anwendungsspezifische Passwörter verzichtbar. Dann ist das Niveau des Zugriffschutzes mit Zwei-Faktor-Verifikation deutlich besser als ohne.

Andernfalls muss man halt mit dem kleinen Schönheitsfehler leben. Ein Sicherheitszuwachs bleibt: Falls man doch einmal das gute alte Passwort verlieren sollte oder falls es ein Service-Provider “für einen selbst” verliert, kann nicht ohne weiteres von jedem Rechner im Internet auf das Konto zugegriffen werden.

Was man auch noch im Auge behalten sollte:

  1. Gut auf die Backup-Codes aufpassen.
  2. Einen kritischen Blick auf die Liste der Sites, Apps und Dienste, denen Zugriff auf die eine oder andere Information des Google-Kontos eingeräumt wird. Sicherheitsvorfälle in diesen Bereichen können auf das Google-Konto übergreifen.

VPN-Unterstützung für Android-Endgeräte – Konfiguration der Klienten

Die letzten Tage habe ich mit der Integration von VPN für Android-Geräte verbracht. An dieser Stelle entschuldige ich mich vorab für mehrere Verbindungsabbrüche bei den Nutzern, die den IPSec-Klienten verwenden, denn durch die Umstellung der Verschlüsselungskonfiguration musste ich mehrmals morgens die IPSec-Verbindungen trennen.

Einige der Android-Smartphones von Samsung haben schon vor einigen Monaten VPN-Unterstützung in Form des AnyConnect-Klienten erhalten. Dieser verwendet als Protokoll SSL-VPN und sollte somit die wenigsten Probleme mit Firewalls etc. haben, da die Kommunikation nur über den Port 443 (TCP und UDP) und alle Sessions nur vom Klienten aufgebaut werden. Ich empfehle daher, diesen weiterhin zu verwenden, wo dieser verfügbar ist.

Um die restlichen Android-Endgeräte ua. auch  Tablets mit VPN zu versorgen, musste ein völlig anderer Typ von VPN aktiviert werden, L2TP-IPSec.  Dabei wird zuerst eine IPSec-Verbindung aufgebaut, in der wiederum ein L2TP-Tunnel erstellt wird.

Wie dies auf den Endgeräten konfiguriert wird habe ich exemplarisch unter http://rrzk.uni-koeln.de/vpnandroid.html dokumentiert. Da die Hersteller teilweise die Bezeichnungen und Menüstruktur verändern, können diese unter Umständen abweichen.

Bei der Verschlüsselung habe ich mich für mehr Sicherheit und damit für AES gegenüber 3DES entschieden. In der Literatur wird AES oft als ressourcenlastiger bezeichnet, was gerade bei den leistungsschwächeren Mobilgeräten in einem höheren Energiebedarf und somit einer kürzeren Batterielaufzeit resultieren könnte. Dazu habe ich aber keine Informationen gefunden und kann die Problematik daher nicht bewerten.

Ich bin gespannt, wie hoch die Nutzung von VPN über Android sein wird. Leider dauert es ja oft, bis sich die Nachricht über die neue Unterstützung von Endgeräten herumspricht.

 

Anleitung zur Einrichtung von L2TP-IPSec unter Android: http://rrzk.uni-koeln.de/vpnandroid.html

Enabling VPN for Android devices – configuration of Cisco ASA

With the new ASA versions 8.3.2.12 or 8.4.1 Cisco announced the support for native VPN on Android devices. Implementing the configuration changes in an existing and running environment can be quite tricky.

For the Android devices the ASA has to offer a L2TP/IPSec tunnel. The IPSec tunnel has to be in transport mode. Since normally the IPSec tunnels are configured in tunnel mode you will encounter the problems of having a mixture of tunnel and transport mode.

The document https://supportforums.cisco.com/docs/DOC-17798 gives a good example on how to configure the tunnel in a new environment.

If you already have an existing crypto-map or dynamic-map for the other IPSec clients and try to add a second one with a higher or lower priority you will end up with an IPSec phase 2 that fails with the error message “All IPSec SA proposals found unacceptable!” for clients using the map with the lower priority.

You can solve this problem only through implementing the two modes via two transform-sets using one single dynamic map.

Example:

crypto ipsec ikev1 transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac

crypto ipsec ikev1 transform-set l2tptransform-set esp-aes esp-md5-hmac

crypto ipsec ikev1 transform-set l2tptransform-set mode transport

crypto dynamic-map public_dyn_map 30 set ikev1 transform-set ESP-AES-256-SHA l2tptransform-set

The order of the transform-sets in the dynamic-map defines their priority with the highest from the left.

Have in mind that changing the dynamic-map results in disconnection of all IPSec sessions.

OpenAFS 1.7.1 und die Windows-Firewall

Seit heute gibt es die neue OpenAFS-Version 1.7.1, die insbesondere für neuere Windows-Versionen dringend empfohlen ist. Allerdings gab es direkt nach der Installation noch ein paar Probleme:

Man muss leider noch von Hand die Windows-Firewall passend konfigurieren, wenn man als Netzwerkumgebung *nicht* public/öffentlich konfiguriert hat:

Systemsteuerung->
System und Sicherheit->
Windows Firewall->
Ein Programm oder Feature durch die Windows-Firewall zulassen

Dort muss für “AFS CacheManager Callback (UDP)” das Häkchen bei “Heim/Arbeit (Privat)” gesetzt sein.

Wenn der lokale Username und das Passwort nicht mit dem im AFS übereinstimmen, muss man sich außerdem auf anderem Weg ein Token besorgen. Dazu öffnet man die Eingabeaufforderung und gibt dort

klog username

an, wobei “username” durch den Usernamen im AFS zu ersetzen ist.

Perl-Modul SAVI-Perl mit aktueller Sophos-Version für Linux verwenden

Wir betreiben neben Ironport für die zentralen Mailserver noch eine weitere Anti-Spam- und Anti-Viren-Infrastruktur als “Altlast” für Institute, die keinen LDAP-Server betreiben. Dort wird als Anti-Virus-Software seit vielen Jahren ClamAV und Sophos Antivirus eingesetzt. Für Letzteres musste jetzt ein Update installiert werden, weil die alte Version demnächst nicht mehr unterstützt wird. Sophos wird bei uns mit dem Perl-Modul SAVI-Perl in amavisd-new eingebunden. Das ging nach dem Update zunächst nicht mehr, obwohl ich das Modul gegen die neue Sophosversion gebaut hatte. Die Ursache ist, dass sich der Pfad der .vdl- und .ide-Dateien geändert hat. Zwar kann man SAVI-Perl beim Kommando load_data diesen Pfad übergeben, aber (unsere Version von) amavisd-new unterstützt das nicht. Die einfachste Lösung war deshalb ein symbolischer Link vom aktuellen Pfad /opt/sophos/lib/sav auf den bisherigen Pfad /opt/sophos/sav.

Intranettes Symbian – Nokia Handys mit Cisco VPN verbinden

Dienstag abend, in einem verspäteten Regionalexpress in der Pampa zwischen Pulheim und Stommeln: Ein netter kleiner RRZK-Mitarbeiter nutzt sein hypermodernes Präzisionsinstrument aus Finnland (a.k.a. Nokia E72), um die E-Mails zu lesen, die ihn nach der Bürozeit erreicht haben. Aha, der Herr Professor Hänneschen hat Probleme mit dem Zugriff auf seinen Webspace und hat daraufhin ein Ticket bei uns eröffnet. Der nette kleine RRZK-Mitarbeiter erkennt das Problem und möchte dem armen Professor den Abend retten, also schnell auf das OTRS zugegriffen und – BÄM… “Zugriff verweigert”. Ach ja, das Ticketsystem ist nur aus dem Uninetz erreichbar. Toll, dass die Uni dafür VPN anbietet. Blöd, dass Nokia Handys sich damit nicht verbinden können.

Nun stehen zur Lösung dieses Problems im Netz diverse kostenpflichtige VPN-Clients zur Verfügung. Aber das Schöne: Es geht sogar kostenlos! Eine ganz allgemeine Anleitung dazu findet man auf den Seiten von Mobilfunk-FAQ. Hier beschränke ich mich daher auf eine etwas kürzere Anleitung für diejenigen, die sich speziell mit dem VPN der Uni Köln verbinden möchten. Vorab: Die Nutzung erfolgt auf eigene Gefahr und ohne Support oder Gewährleistung, falls etwas schief geht!

Zunächst benötigt man diese SIS-Datei, also ein Symbian-Installationspaket. Eigentlich wäre das sogar schon alles, aber leider muss die Datei für jedes Handy einzeln signiert werden. Es besteht über die Seite Symbiansigned die Möglichkeit, ein Programm zu signieren. Wichtig ist dabei die IMEI (die Seriennummer des Handys), die über die Eingabe von *#06# auf dem Handy angezeigt werden kann. Nach dem Upload der Datei erhält man per Mail das signierte Programm als Download.

Sobald Sie über die nun signierte SIS-Datei verfügen, laden Sie diese einfach auf Ihr Handy (per OVI, Bluetooth, Speicherkarte etc.) und installieren Sie das Paket. Je nach Handymodell müssen Sie nun einen neuen VPN- oder Intranetzugangspunkt einrichten und dabei die VPN-Richtlinie bzw. -Policy “VPN-Policy” auswählen. Der Name des Zugangspunktes selbst ist beliebig. Bei der Einrichtung des Zugangspunktes müssen Sie zudem noch auswählen, über welche Netzverbindung Sie sich mit dem VPN verbinden möchten (neuere Modelle bieten praktischerweise den generischen “Internet”-ZP hierfür an). Künftig können Sie sich dann direkt über den erstellten Zugangspunkt im Uninetz anmelden. Anmerkung: Dies funktioniert *nicht* im WLAN der Uni, ist dort ja auch völlig unnötig.

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.

Snow Leopard enthält Cisco IPSec VPN

Obwohl Apple angekündigt hatte, dass Snow Leopard keine neuen Features aufweisen würde, hat sich doch so manches getan, allerdings zumeist unter der Oberfläche. Eine dieser etwas versteckten Neuerungen ist integrierte Unterstützung für Ciscos Variante eines IPSec VPNs. Da iPhone und iPod Touch das seit Firmwareversion 2.0 schon konnten, ist die Integration in Snow Leopard keine ganz große Überraschung. Es fällt aber auf, dass im Ggs. zum iPhone bei OS X keine Spur des offiziellen Cisco-Logos zu erkennen ist. Und die Implementierung erfolgt auf Basis von racoon, eines Open Source VPN-Clients aus FreeBSD.

Wir propagieren hier an der Uni zwar mittlerweile vornehmlich die Verwendung des Cisco AnyConnect-Clients, der anstelle von IPSec DTLS verwendet, aber durch die direkte OS-Integration ist Apples Variante mglw. noch einen Tick komfortabler und robuster.

Wer’s probieren möchte, muss entweder im alten “tsunami”-WLAN oder außerhalb des UKLAN sein. Dann öffnet man Systemeinstellungen, dort Netzwerk, klickt auf das + oberhalb des Schlosses, wählt dort als Anschluss VPN, wählt als VPN-Typ Cisco IPSec, und bestätigt die Eingabe. Nun trägt man als Serveradresse vpngate.uni-koeln.de ein, Accountname und Passwort, klickt auf “Identifizierungseinstellungen …”, trägt dort als Gruppenname uklan-full ein, als Schlüssel uklan und klickt auf OK. Dann noch Anwenden und Verbinden, und fertig. Eine ausführlichere Doku mit Screenshots folgt evtl. später.