Dipl.-Inform. Carsten Eilers

So wird die Veröffentlichung z.B. von ZEIT ONLINE mit

"Außerdem steht das Werkzeug nun auch all jenen offen, die keine lauteren Absichten haben und die Unwissenheit derer ausnutzen können, die von seiner Existenz und den Gegenmaßnahmen nichts wissen."

kritisiert. Ähnliche Kommentare gibt es auch anderswo, die Zeit liefert hier nur ein willkürlich herausgegriffenes Beispiel. Wobei das "willkürlich" noch durch einen weiteren Faktor beeinflusst wurde, denn die Zeit hat die Kritik durch die folgende Aussage

"Für Butlers Weg spricht die Theorie der Transparenz. Die Angriffsart ist lange bekannt und wird von jenen, die kriminelle Ansichten haben, im Zweifel sowieso genutzt. Sein Instrument verringert dagegen den Kreis der Unwissenden drastisch und so im Zweifel auch das Risiko, getreu dem Grundsatz: Eine erkannte Gefährdung ist keine Gefahr."

relativiert (was anderswo oft nicht der Fall ist) und ist daher im Grunde ein schlechtes Beispiel. Ganz im Gegenteil, der Text ist insgesamt für eine Nicht-IT-Seite und das entsprechende Publikum sehr gut. Denn eigentlich ist der zweiten Aussage sowie dem Fazit des ZEIT-Artikels wenig hinzuzufügen:

"Nur einsetzen und damit fordern müssen die Nutzer es [die HTTPS-Verschlüsselung] noch, also "mit den Füßen" abstimmen. Dann steigen die Chancen, dass generelle Verschlüsselung per HTTPS sich durchsetzt."

Statt vollständig auf HTTPS zu setzen kann man auch nur für die schützenswerten Bereiche der Website HTTPS verwenden, wichtig ist, dass für den Session-Cookie das 'Secure'-Flag gesetzt ist. Das wird bei den Berichten oft übersehen, denn HTTPS in Verbindung mit einem Session-Cookie ohne 'Secure'-Flag ist ebenfalls unsicher.

Es spricht aber auch nichts dagegen, generell HTTPS zu verwenden. Denn so "teuer" wie oft gedacht ist das gar nicht (mehr), wie Google am Beispiel von Google Mail gezeigt hat. Allerdings ist es doch ziemlich übertrieben, z.B. die Seiten eines öffentlichen Forums oder eines öffentlichen Katalogs verschlüsselt zu übertragen.

Firesheep - dringend nötige Warnung!

Die Veröffentlichung von Firesheep, bzw. eines entsprechenden allgemein verständlichen Proof of Concept war dringend notwendig. Ian Gallagher nennt in einem Artikel im Blog von Eric Butler folgende Daten:

• 2004 - Veröffentlichung des Konzepts des Session Hijacking
• 2007 - Veröffentlichung der Tools "Ferret" und "Hamster" zum Durchführen von "SideJacking"-Angriffen - dem Ausspähen von ungeschützt übertragenen Session-Cookies
• 2008 - Veröffentlichung des Tools "CookieMonster" für den gleichen Zweck
• 2009 - Veröffentlichung des Tools "FBConTroller" für (erraten) den gleichen Zweck, spezialisiert auf Facebook, inzwischen gibt es davon schon Version 3.0

Da die Schwachstelle seit langem bekannt und auch bereits Tools verfügbar waren, war die Veröffentlichung von Firesheep keineswegs unverantwortlich, sondern im Gegenteil längst überfällig.

Alle diese Tools brauchen zwar mehr oder weniger umfangreiche Anpassungen und sind nicht gerade trivial zu bedienen, aber das dürfte Cyberkriminelle kaum davon abgehalten haben, sie zu nutzen oder auch eigene Tools für den gleichen Zweck zu entwickeln. Die Gefahr war also seit langem bekannt, auch und gerade den Betreibern prominenter Websites. Mike Perry, der Entwickler des CookieMonster, hat 2008 eine (unvollständige) Liste betroffener Websites veröffentlicht, von denen ein Teil kein Interesse am Beheben der Schwachstelle hatte. Das dürfte sich jetzt hoffentlich ändern, wenn die Benutzer sehen, wo sie gefährdet sind und dann den Betreibern ihre Meinung kund tun. Entweder, indem sie HTTPS erzwingen (sofern das möglich ist) und damit für entsprechende Einträge in den Logfiles sorgen, oder indem Sie den Support mit Fragen löchern. Die Alte Taktik "Wir antworten solange mit nichtssagenden und allenfalls halbwegs passenden Textbausteinen, bis der Benutzer aufgibt" dürfte diesmal schon an den fehlenden halbwegs passenden Textbausteinen scheitern.

"Bin ich gefährdet?"

Die Antwort auf diese Frage hängt davon ab, was Sie sind. Als Betreiber einer unsicheren Website lautet die Antwort generell "Ja". Wie groß die Gefahr ist, hängt davon ab, wie lohnend ein Angriff für einen Cyberkriminellen bzw. wie gross der potentielle Schaden ist. Wenn z.B. in einem Webshop die Authentifizierung zwar durch einen ausgespähten Cookie umgangen werden kann, danach aber trotzdem keine Bankverbindung oder Kreditkartendaten angezeigt werden und vor der Änderung des Passworts oder der Aufgabe einer Bestellung eine erneute Passworteingabe nötig ist, gibt es für einen Angreifer relativ wenig zu holen. Er kann sich vielleicht die Adresse des Benutzers und die bisherigen Bestellungen ansehen, aber davon hat er direkt erst mal nichts. Völlig wertlos sind natürlich auch solche Informationen nicht, sie erleichtern z.B. einen folgenden Phishing-Angriff ungemein. Und mit dem abgephishten Passwort kann dann natürlich auch eine Bestellung aufgegeben werden.

Als Benutzer einer unsicheren Website hängt die Antwort davon ab, wo sie das Internet nutzen. In einem offenen WLAN sind Sie prinzipiell gefährdet. Ob irgend einer der Benutzer im WLAN Firesheep laufen lässt, können Sie nicht feststellen, und ebensowenig wissen Sie, ob diese angenommene Firesheep-Version an die von Ihnen genutzten Websites angepasst ist. Sicherheitshalber sollten Sie also davon ausgehen, dass ihre Session-Cookies Freiwild sind und auf die Nutzung unsicherer Websites verzichten. Unsicher sind in diesem Fall alle Websites, für deren Session-Cookie nicht das 'Secure'-Flag gesetzt ist, unabhängig davon, ob die Seiten über HTTP oder HTTPS übertragen werden.

Das gleiche gilt für WEP-"geschützte" WLANs, der Aufwand zum Berechnen des WEP-Schlüssels ist minimal und fällt nicht weiter ins Gewicht. In einem WPA2-geschützten WLAN oder einem drahtgebundenen Netz ist ein Angriff bedeutend schwieriger und außerdem vom Vorhandensein weiterer Schwachstellen abhängig. Prinzipiell ist er aber auch dort möglich. Wie sicher Sie sich fühlen können, hängt also davon ab, wer die anderen Benutzer ihres lokalen Netzes sind. Wenn Sie denen bedingungslos vertrauen, können Sie auch unsichere Websites nutzen. Denken Sie nur daran, dass im Zweifelsfall einer dieser Benutzer Zugriff auf diese unsichere Website erlangen kann.

Ich persönlich nutze in offenen WLANs, also z.B. auf Konferenzen, möglichst gar keine Websites, auf denen ich mich einloggen muss. Und wenn ich mich irgendwo einloggen muss, dann nur, wenn ab der Seite mit der Login-Maske durchgehend HTTPS genutzt wird und für den Session-Cookie das 'Secure'-Flag gesetzt ist.

HTTPS allein ist nicht genug!

Zur Erinnerung nochmals eine Zusammenfassung eines trotz HTTPS-Verschlüsselung möglichen Angriffs, wenn das 'Secure'-Flag nicht gesetzt ist: Ein Cyberkrimineller möchte den Session-Cookie für www.webshop.example ausspähen. Die Website nutzt durchgehend HTTPS, das 'Secure'-Flag für den Session-Cookie ist aber nicht gesetzt. Cyberkrimineller und Opfer nutzen das gleiche offene WLAN.

Der Cyberkriminelle schleicht sich zuerst als "Man in the Middle" in die Verbindung des Opfers ein. Danach fügt er in irgend eine vom Opfer besuchte Website ein img-Tag mit einem Link zu einem Bild auf www.webshop.example ein, z.B.

<img src="http://www.webshop.example/bilder/logo.jpg" eight="o" width="0">

Der Browser des Opfers lädt dieses Bild und sendet dabei den Session-Cookie mit. Der Cyberkriminelle kopiert den Cookie und kann sich damit gegenüber der Website als das Opfer ausgeben.

Warum geht das? Wenn das 'Secure'-Flag, wie in diesem Fall, nicht gesetzt ist, schickt der Webbrowser den Cookie mit jedem Request mit, unabhängig davon, ob der Request über HTTP oder HTTPS geschickt wird.

Mit gesetztem 'Secure'-Flag ist der Angriff nicht möglich, da der Cookie dann nur bei HTTPS-Requests mitgeschickt wird. Der Cyberkriminelle könnte den Link zum Bild zwar in einen HTTPS-Link ändern, so dass der Cookie im Request übertragen würde, hätte aber nichts davon: Den verschlüsselt übertragenen Cookie kann er nicht ausspähen.

Fazit

Auch wenn eine Website durchgehend HTTPS verwendet, kann sie angreifbar sein. Wichtig ist, dass für den Session-Cookie das 'Secure'-Flag gesetzt ist. Ob das der Fall ist, kann man im Browser leider nicht einfach prüfen. Die meisten Browser zeigen in der Cookie-Verwaltung zwar auch das 'Secure'-Flag an, aber da den unbekannten Session-Cookie einer bestimmten Website raus zu suchen ist alles andere als komfortabel. Vielleicht sollten die Browser-Hersteller dafür mal eine bessere Lösung suchen.

Wünschenswert wäre sicher eine Verknüpfung der Information über sichere bzw. unsichere Cookies mit dem Symbol zur Markierung von über HTTPS übertragenen Seiten. Das Problem ist dabei nur, dass man einem Cookie nicht unbedingt ansieht, ob er zur Session-Verwaltung gehört oder z.B. nur dem Benutzer-Tracking dient. Wollte man einer Unterscheidung zwischen HTTPS-Seiten mit sicheren Session-Cookies und solchen mit unsicheren Session-Cookies ermöglichen, müsste man erst mal ein Flag einführen, an dem Session-Cookies erkannt werden können. Und den Aufwand wird wohl kaum jemand auf sich nehmen wollen, immerhin wären dafür Standards und etliche Implementierungen zu ändern.

Carsten Eilers