Kategorie: Security

Sicherheitsrelevante Themen

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.

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.

Passwortmanager in Browsern sind unsicher

Heise berichtet über einen Browser-Test mit erschreckenden Ergebnissen. Ich habe den Test selbst mit Safari und Firefox 3 durchgespielt. Wenn man das sieht, sollte man eigentlich auf die Verwendung dieser Manager verzichten. Andererseits verwende ich viele unterschiedliche Passwörter (auch aus Sicherheitserwägungen) und kann mir kaum für jede Website das jeweilige Passwort merken …
Man muss hoffen, dass die Browserhersteller hier reagieren.

Phishers Fritz

… fängt frische Phishe.

Derzeit sind wieder Phishing-Mails im Umlauf, die gezielt Passwörter von Nutzern der Uni Köln abphishen wollen. Hintergrund ist, dass mit Hilfe der Passwörter Spamkampagnen geskriptet über das Webmail-System der Uni gefahren werden können. Das ist kürzlich bereits einmal gelungen. Wir haben das Problem recht schnell erkannt und den geknackten Account temporär gesperrt, aber die Gefahr ist damit nicht grundsätzlich gebannt. Und es beweist, dass es immer wieder leichtgläubige Opfer gibt. Ein einziges reicht ja schon, um potenziell viel Schaden anzurichten.

Das größte Problem bei solchen Spam-Wellen ist aus unserer Sicht, dass die Reputation der Uni sinkt – sowohl die reale als auch die virtuelle. Mit Letzterem meine ich, dass Mailserver der Provider nur noch gedrosselt von uns Mail annehmen, bzw. wir im schlimmsten Fall auf sog. Blacklists landen und gar keine Mail mehr von uns angenommen wird. Beides ist in der Vergangenheit schon vorgekommen.