Wer hatte davon noch nicht gehört? Firesheep. Ein BrowserplugIn für Firefox, das aus unverschlüsselten Netzwerken SessionIds fischt und mit den zugehörigen URLs Http-Requests eingeloggter Nutzer nachbaut. In einer Seitenleiste hat man dann schön die Twitter- und Facebook-Accounts aufgelistet, die so im Netz herumschwirren. Ein Klick und man befindet sich in der Innenansicht und kann schalten und walten, wie der Besitzer. (Ja, ich weiß, die Sicherheitslücke ist eigentlich uralt, Firesheep hat sie nur komfortabel geinterfacet. Aber damit auch allgegenwärtig gemacht.)
Heute klappte ich mal nach langer Zeit wieder meinen Laptop im Oberholz auf, die ein unverschlüsseltes W-Lan betreiben – erinnerte mich an die Existenz von Firesheep und schloss vorsichtshalber das Facebook-Tab. Erster Shock: zu spät. Im Firesheep erschien nach einem Firesheep-Scan mein Facebookprofil. Hatte das jemand schon auf einem anderen Rechner geöffnet? (Facebook war bei mir immerhin wenige Minuten offen)
Egal. Facebook ausgeloggt. Danach war die Session in Firesheep ungültig.
Exkurs: Eine Session ist eine Identifizierung eines Nutzers, die Serverseitig verwaltet wird. Durch URL-Bestandteile, POST-Parameter oder eben immer häufiger Cookies (bei Twitter und Facebook zb.) wird der Browser des Nutzers vom Server erkannt und ein bereits erfolgter LogIn wird zugeordnet. So braucht man sich nicht immer neu anmelden.
Nach dem expliziten LogOut bei Facebook wurde also die in Firesheep angezeigte Session auf dem Facebookserver für ungültig erklärt und man konnte sie nicht mehr benutzen. So weit, so unspektakulär.
Einige Minuten später erschien auf einmal mein Twitterprofil in Firesheep. Ich habe keine Ahnung, wie es da hinkam, denn ich hatte Twitter eigentlich nicht im Browser offen, ich benutze beinahe ausschließlich Clients. Ich bin aber ständig per Browser eingeloggt, auch wenn die Session nicht aktiv ist, wenn ich die Seite nicht offen habe.
Allerdings gibt es noch die Tweetbuttons von Twitter auf vielen externen Websites, die mich ebenfalls anhand der TwitterSession identifizieren. Auf diese Weise kann es sein, dass die eigene SessionId im Netz herumfliegt, ohne, dass man dafür Twitter aufrufen muss.
Jedenfalls dachte ich mir: kein Problem! Ich logge mich auch einfach bei Twitter aus. Zack. Aber was musste ich da feststellen? Trotz des Ausgeloggtseins funktionierte die von Firesheep angezeigte Session immer noch! Mehrere Ausloggversuche scheiterten, jedesmal kam ich per firesheep zurück auf meine Timeline, als hätte ich mich nie ausgeloggt.
Ich hab das Problem gleich auf Twitter gepostet, worauf hin ich erstmal einen ganzen Haufen überflüssiger „Lösch doch deine Cookies„-Antworten zurück bekam. Aber nach einigem hin und her auch die Lösung.
Man muss auf Twitter einfach sein Passwort ändern (keine Angst, geht eh nur per https, also SSL-verschlüsselt) und dann werden alle Sessions ungültig. Puh!
Zwischendrin hat das Oberholz dankenswerter Weise wieder auf Verschlüsselung umgestellt (mit WPA-II hat wohl jeder seine eigene Verschlüsselung).
Es ist nichts passiert, aber es war eine ziemlich creepy Erfahrung, seine Session öffentlich zu sehen, ohne daran etwas ändern zu können.
Was ich persönlich für Lehren aus dem Erlebnis ziehen werde, weiß ich noch nicht. Ich weiß auch nicht, was das für die offene W-Lankultur bedeutet, die ich eigentlich unterstütze. Aber eines steht fest:
Dass die Session nach dem Ausloggen bei Twitter nicht ungültig wird, ist eine Riesenschweinerei! Ich bin wirklich nicht der Sicherheitsfanatiker aber sowas geht gar nicht! Das ist eine Sicherheitslücke schlimmen Ausmaßes. (Vielleicht hab ich ja was übersehen, konnte das Verhalten aber reproduzieren. Kann das vielleicht jemand noch mal verifizieren?)
Allgemein würde ich sogar sagen, dass das Ende von Http für Nutzerprofile gekommen ist. Firesheep hat deutlich gemacht, dass man eigentlich nicht mehr irgendwo ohne SSL (also https) eingeloggt rumsurfen möchte. Insbesondere im Zusammenhang mit der Kolonialisierung des Netzes mit den Like- und Tweet-Buttons muss man da dringend umdenken.
Für weiteren Spott und Häme („HÖHÖ, Kontrollverlust und so, HÖHÖ!“) können gerne die Kommentare verwendet werden.
UPDATE: Die beschriebene Sicherheitslücke war wohl auch schon bekannt. Habe ich mir beinahe gedacht, kannte sie aber nicht (Danke @xbg). Jedenfalls bekommt sie mit Firesheep eine ganz neue Dimension und erhöht den Druck auf Twitter, diese zu schließen. Hoffentlich.
Was ist denn ein Oberholz?
Mich würde tatsächlich interessieren, wie du die hier erlebte Praxis näher mit deiner Theorie verbindest.
Zumindest bist du hier ja direkt persönlich von einem konkreten Kontrollverlust betroffen gewesen, der potentiellen, wenn wohl auch nur maximal temporären, Einfluss auf deine Privatsphäre hat. Das ist ja etwas, dass dir als weißer Mittelklassemann, um mal Linus Neumann zu referenzieren, in deiner sicheren Gesellschaftsblase nicht so oft passiert wie anderen Gesellschaftsgruppen. 🙂
Marcel – ich habe den Kontrollverlust nie verharmlost oder verniedlicht. Das alles hat seine Gefahren mit denen man umgehen muss. Das habe ich immer schon gesagt.
Da man bei Facebook und Twitter das alte Passwort wissen muss, um das Passwort zu ändern, war meine größte Sorge schlicht Vandalismus. Um Datenschutz hatte ich weniger Sorgen. Klar, wär nicht so toll, wenn jemand meine gesammelten Direct-Messages leakt, aber auch kein Untergang. Ich versuche mit meiner Welt in aufrichtiger Eintracht zu leben und achte darauf, dass mir keine meiner Lügen den Kopf kosten würde 😉
Tjoa, und schon haben wir wieder (zumindest im uebertragenen Sinn) ein Netzneutralitaetsproblem. Ich waere voll dabei, ueberall nur noch HTTPS einzusetzen, und haette das gerne auch auf einem hier lokal viel benutzten Service. Problem ist, dass wegen der CPU-intensiven SSL-Handshakes dafuer mal eben vier oder fuenf neue Server mit viel CPU-Leistung noetig waeren, um das fuer alle (Peak bis 14k gleichzeitig angemeldete Nutzer) anbieten zu koennen. Kann man sich vielleicht nicht unbedingt leisten, wenn man praktisch auf Nullbudget arbeitet.
Fuer offene Funknetze kaeme dann wieder VPN in Frage, was sich aber nicht immer ganz so elegant verhaelt, etc.
Vielleicht wäre es eine gute Idee, auf dieses vergiftete Geschenk – nämlich die Möglichkeit (Häkchen), eingeloggt zu bleiben – konsequent zu verzichten?
Ich würde gerne ein plausibles Argument hören, welches dafür spricht, diese Funktion zu benutzen!? Natürlich die willentliche Entscheidung „dafür“ voraussetzt, und dass diese hinterlistige Browser-Standardeinstellung, Inhalte von Formularfeldern zu merken, ebenfalls wissentlich aktiviert ist.
Die größte Sicherheitslücke ist meist immer noch die Bequemlichkeit der Benutzer.
MasterGoba – von den unfassbaren Ausmaß meine Faulheit hat du noch nie etwas gehört?
Im Übrigen würde es das Problem auch nur wenig vermindern. Eine Session muss es auch so geben, es sei denn du willst dich bei jedem Reload neu einloggen.
Pingback: YuccaTree Post + » Twitter: Unverzeihliche Sicherheitslücke
Örm, ja und?
Du hast gemerkt, dass
1. unverschlüsselt rumsurfen seine Probleme bringt
2. Webseiten schlampig programmiert sein können und zusammen mit 1. noch größere Problem bringen
3. Du trotz all Deiner theoretischen Denkansätze Du instinktiv erschrocken bist ob des Kontrollverlustes.
Punkte 1 und 2 sind seit ca. 357 Jahren bekannt. Warum wunderst Du Dich? Du hast ja sogar die richtige Schlußfolgerung gezogen (SSL nutzen)
Punkt 3 ist ein schöner Realitätscheck 😉
reinerwein – ich hätte das alles nicht verbloggt, wäre da nicht die ausloggtlücke bei Twitter. Die ist neu und für alle von Interesse. Wenns dich nicht interessiert, guck weg.
Ach Kinder! Jetzt tut doch nicht so, als ob diese Lücke erst seit heute bekannt ist:
http://seclists.org/fulldisclosure/2010/Apr/430
Und fefe hat die ja auch schon gehabt: http://blog.fefe.de/?ts=b521b061
Danke für den Hinweis. Ich wusste das jedenfalls nicht. Lese Fefe nicht.
Bei Techcrunch haben sie einen Weg gezeigt das Schaf auszutricksen:
http://techcrunch.com/2010/10/25/firesheep/
Achso, das ist ja blöde. Die Lösung ist HTTPS zu erzwingen. Sorry, hätte doch genauer lesen sollen.
Ich gebe zu, mein Vorschlag oben passt nicht ganz zu dem Problem, das Twitter in diesem speziellen Fall hat. Dennoch halte ich ihn für wichtig und folgenswert.
Und @mspro, das ist richtig, leider sind es eben die mitgesendeten, kinderleicht entschlüsselbaren Cookiedaten, die das Problem hier hervorrufen. Cookies zu deaktivieren geht nicht, macht Twitter gänzlich unbenutzbar.
Bleibt als Fazit, Twitter möglichst nicht in unsicheren Netzwerken zu verwenden, es sei denn man spielt gern Russisches Roulette. Ansonsten schließe ich mich gerne dem Vandalismus-Argument an, ansonsten wüsste ich diese außergewöhnliche Mühe zu schätzen, die sich jemand macht, um meine Tweets mitzulesen.
Also ich fand‘ das ganze interessant vor allem weil’s live war. Ich dachte eigentlich das gleich wie Marcel und hoffe auf einen ausführlicheren Beitrag zu reinerweins Punkt 3.
Wieso diese Angst vor Vandalismus?! Wenn tatsächlich jemand ohne kommerzielle Interessen rumtrollen wollen sollte, so what? Könnte das irgendwie so schlimm ausfallen, dass man fortan freies WLAN meidet?! Bestünde da die Gefahr eines Machtgefälles oder ..was genau ist die Gefahr? Etwas Peinlichkeit auf FB?
Gibt’s hierfür nicht unzählige RL-Anologien, welche man halt in Kauf nimmt? In der Schule einen Brief in falschem Namen durch die Klasse gehen lassen?
Ich finds irgendwie auch spannend zu sehen wie Du auf einen vielleicht erstmals so konkreten aber letztlich doch kleinen Kontrollverlust fast hysterisch reagiert hast, stimme insofern bella banana zu. Was war jetzt nochmal genau so schlimm? Dass jemand in Deinem Namen ein Wallposting hätte auslösen können?
Ok dass sowas geht wusste ich erstmal noch gar nich. wenn man das macht um einen freund zu ärgern, und nichts schlimmes anstellt ist das ja vielleicht ganz witzig. aber ganz ehrlich wenn ich dann bei mcdonalds ins free wlan gehe is das eher unglücklich…
Auch ein (mit shared-key) verschlüsseltes WLAN schützt dich nicht, verwende am besten entweder ein VPN, einen ssh-proxy (-D ) oder halt https-only Seiten.