»Was machen gegen Firesheep (Hijacking) / SSL Alternative

mgutt · 13.10.2011, 16:57

Der Fall ist ja weitgehend durch die Presse gegangen. Wenn sich jemand in einem Netzwerk befindet, kann jeder andere, der ebenfalls in diesem Netzwerk unterweg ist "mitlesen", sofern die Website kein SSL einsetzt.

Deswegen sind ein paar Entwickler hingegangen und haben ein Addon entwickelt, dass innerhalb eines Netzes nach fremden Cookies sucht.

Publik wurde das ganze, weil das Addon hauptsächlich auf Facebook und Twitter abzielt:
http://en.wikipedia.org/wiki/Session_hijacking#Firesheep
Zitat:

Recently a firefox extension called Firesheep has exploited and made it easy for public wifi users to be attacked by session hijackers. Websites like Facebook, Twitter, and any that the user adds to their preferences allow the firesheep user to easily access private information from cookies and threaten the public wifi users personal property.

Jetzt aus technischer Sicht die Frage:
Was kann man machen, wenn man eben nicht auf jeder Seite SSL einsetzen möchte?

Denn SSL macht eine Seite recht lahm.

Cookie an Unique-Daten binden
Eine Cookie Session kann man z.B. an bestimmte Daten binden:
- IP-Adresse
- Browser / Version / Betriebssystem etc.
- Bildschirmauflösung

Allerdings hat der Angreifer die gleiche IP und er kann die Browserkennung ebenfalls auslesen. Nur die Bildschirmauflösung hat er nicht, aber das dürfte jetzt nicht so schwer sein. Probiert man eben alle durch und schon wars das.

Aus der Nutzung mit der IP ergibt sich auch das Problem, dass manche Provider diese regelmäßig wechseln (AOL) und damit auch der Logout droht.

Session ID bei jedem Aufruf wechseln
Eine andere Alternative, die ich von phpBB kenne ist das ständige Wechseln der Session ID bei jedem Seitenaufruf. Damit habe ich allerdings keine guten Erfahrungen gemacht. Auch heute werde ich noch regelmäßig aus phpBB2 Foren ausgeloggt (früher dachte ich, dass es ein Internet Explorer Problem sei, ist es aber nicht). Sobald in irgendeine Richtung ein Übertragungsproblem stattgefunden hat, ist man ausgeloggt.

Außerdem kann der Angreifer das letzte Cookie nehmen und damit den eigentlichen Besucher ausloggen und selbst online bleiben.

Referer voraussetzen
Nur wer einen Referer sendet bleibt eingeloggt. Das ist allerdings nicht sicher, wenn man keine Logik dahinter baut (von der Startseite kann man nicht direkt auf die Seite einer privaten Nachricht). Das hat allerdings viele Nachteile. z.B. könnte man Links nicht aus einer Email heraus öffnen. Und wenn der Angreifer davon Kenntnis hat, war der Aufwand eh sinnlos. Denn dann schickt dieser einfach den passenden Referer.

Verschlüsselung mit Javascript
Egal was man vor hat. Es ist unsicher, da der Angreifer auch den Schlüssel kennt, um die Daten wieder zu entschlüsseln (der muss ja auch zum Nutzer). Außerdem hilft es nicht, wenn die verschlüsselte Session an die Website abfangen und vom Angreifer selbst gesendet wird (MITM). Wobei ich das als "Stufe 2" bezeichnen würde.

HTML5
Hier setze ich große Hoffnungen rein. Es gibt z.B. die Funktion Daten lokal beim Besucher zu speichern:
http://www.html5rocks.com/en/features/storage

Also wie ein Cookie, das aber nicht zurückgesendet wird. Nun könnte man hingehen und bei einem Login fragen, ob sich der Nutzer sicher ist, dass sein aktuelles Netzwerk nicht abgehört werden kann. Wenn ja speichert man eine RAS/AES Ver-/Entschlüsselungsfunktion beim Besucher und einen Key. Diesen Key packt man sich zusätzlich in die Datenbank auf den Server.

Auf die Art könnte man den Login nach wie vor "unsicher" per Session Cookie machen, aber die sensiblen Daten (Profildaten, Private Nachrichten, etc.) könnte man verschlüsselt an den Besucher senden. Das ganze geht dann auch andersherum. Also wenn jemand eine private Nachricht schreibt und absendet wird sie erstmal per Javascript verschlüsselt und dann erst versendet.

Das geile daran ist aber, dass man es grundsätzlich integrieren kann ohne den Besucher zu "stören". Wenn der Browser das lokale Speichern unterstützt, so werden die Daten verschlüsselt, ansonsten eben nicht.

Schwachpunkte bei dieser Idee:
- wenn zum Zeitpunkt der Key-Übertragung ein Angreifer mitliest hat man verloren
- evtl. MITM

Bei MITM bin ich aktuell nicht sicher. Der Angreifer kann zwar die Daten durch sein System schleusen und damit eingeloggt sein, aber er kann ja die Daten nicht lesen, weil er den Key nicht kennt. Was passiert allerdings, wenn der Angreifer den Key selbst neu setzt. D.h. er tut so als wäre er der Server, der den Key neu setzt und überschreibt den lokalen Key gegen einen eigenen.

Da müsste man eine zusätzliche Sicherheitsbarriere schaffen. Ich weiß nicht, ob man eine Art Schreibschutz realisieren kann. Dazu muss ich mich erstmal einlesen.

Wobei ich vermute, wenn man die Verschlüsselungsfunktion so anpasst, dass sie bei jedem Besucher nach einem Key mit einem anderen Indexnamen sucht, so müsste es ja eigentlich sicher sein. Außer man kann bestehende local Storage Arrays wie normale Arrays durchlaufen.

EDIT: Ne ich glaube doch nicht, dass das funktioniert. Der MITM kann ja den ausgegeben Javascript Code der Seite so anpassen, dass er sich einfach den local Storage als String über einen URL Parameter zusenden lassen könnte. Dann hätte er die Funktion und den Key.

Man müsste in local Storage Funktionen abspeichern können, die man nur aufrufen, aber nicht auslesen kann. Dann würde es gehen.

EDIT2: Ne würde denke ich auch nichts bringen. Weil sobald die Ausgabe steht kann der MITM ja theoretisch den gesamten DOM auslesen. Also gegen MITM hilft es nicht, aber gegen WiFi Sniffer. Also Noobs, die Firesheep einsetzen.

Andere Ideen habe ich aktuell nicht.

maxrev.de · Gast

Mach mit!

Wenn Dir die Beiträge gefallen haben oder Du noch Fragen hast oder Ergänzungen machen möchtest, solltest Du Dich gleich bei uns anmelden:

» Anmelden

Registrierte Mitglieder genießen die folgenden Vorteile:
✔ kostenlose Mitgliedschaft
✔ keine Werbung
✔ direkter Austausch mit Gleichgesinnten
✔ neue Fragen stellen oder Diskussionen starten
✔ schnelle Hilfe bei Problemen
✔ Bilder und Videos hochladen
✔ und vieles mehr...

Autor	Nachricht
mgutt Beiträge & PNs ignorieren Administrator Name: Marc Geschlecht: Anmeldedatum: 28.08.2004 Beiträge: 40913 Chats: 11134 Wohnort: Hennef Meine eBay-Auktionen:	13.10.2011, 16:57 zitieren Der Fall ist ja weitgehend durch die Presse gegangen. Wenn sich jemand in einem Netzwerk befindet, kann jeder andere, der ebenfalls in diesem Netzwerk unterweg ist "mitlesen", sofern die Website kein SSL einsetzt. Deswegen sind ein paar Entwickler hingegangen und haben ein Addon entwickelt, dass innerhalb eines Netzes nach fremden Cookies sucht. Publik wurde das ganze, weil das Addon hauptsächlich auf Facebook und Twitter abzielt: http://en.wikipedia.org/wiki/Session_hijacking#Firesheep Zitat: Recently a firefox extension called Firesheep has exploited and made it easy for public wifi users to be attacked by session hijackers. Websites like Facebook, Twitter, and any that the user adds to their preferences allow the firesheep user to easily access private information from cookies and threaten the public wifi users personal property. Jetzt aus technischer Sicht die Frage: Was kann man machen, wenn man eben nicht auf jeder Seite SSL einsetzen möchte? Denn SSL macht eine Seite recht lahm. Cookie an Unique-Daten binden Eine Cookie Session kann man z.B. an bestimmte Daten binden: - IP-Adresse - Browser / Version / Betriebssystem etc. - Bildschirmauflösung Allerdings hat der Angreifer die gleiche IP und er kann die Browserkennung ebenfalls auslesen. Nur die Bildschirmauflösung hat er nicht, aber das dürfte jetzt nicht so schwer sein. Probiert man eben alle durch und schon wars das. Aus der Nutzung mit der IP ergibt sich auch das Problem, dass manche Provider diese regelmäßig wechseln (AOL) und damit auch der Logout droht. Session ID bei jedem Aufruf wechseln Eine andere Alternative, die ich von phpBB kenne ist das ständige Wechseln der Session ID bei jedem Seitenaufruf. Damit habe ich allerdings keine guten Erfahrungen gemacht. Auch heute werde ich noch regelmäßig aus phpBB2 Foren ausgeloggt (früher dachte ich, dass es ein Internet Explorer Problem sei, ist es aber nicht). Sobald in irgendeine Richtung ein Übertragungsproblem stattgefunden hat, ist man ausgeloggt. Außerdem kann der Angreifer das letzte Cookie nehmen und damit den eigentlichen Besucher ausloggen und selbst online bleiben. Referer voraussetzen Nur wer einen Referer sendet bleibt eingeloggt. Das ist allerdings nicht sicher, wenn man keine Logik dahinter baut (von der Startseite kann man nicht direkt auf die Seite einer privaten Nachricht). Das hat allerdings viele Nachteile. z.B. könnte man Links nicht aus einer Email heraus öffnen. Und wenn der Angreifer davon Kenntnis hat, war der Aufwand eh sinnlos. Denn dann schickt dieser einfach den passenden Referer. Verschlüsselung mit Javascript Egal was man vor hat. Es ist unsicher, da der Angreifer auch den Schlüssel kennt, um die Daten wieder zu entschlüsseln (der muss ja auch zum Nutzer). Außerdem hilft es nicht, wenn die verschlüsselte Session an die Website abfangen und vom Angreifer selbst gesendet wird (MITM). Wobei ich das als "Stufe 2" bezeichnen würde. HTML5 Hier setze ich große Hoffnungen rein. Es gibt z.B. die Funktion Daten lokal beim Besucher zu speichern: http://www.html5rocks.com/en/features/storage Also wie ein Cookie, das aber nicht zurückgesendet wird. Nun könnte man hingehen und bei einem Login fragen, ob sich der Nutzer sicher ist, dass sein aktuelles Netzwerk nicht abgehört werden kann. Wenn ja speichert man eine RAS/AES Ver-/Entschlüsselungsfunktion beim Besucher und einen Key. Diesen Key packt man sich zusätzlich in die Datenbank auf den Server. Auf die Art könnte man den Login nach wie vor "unsicher" per Session Cookie machen, aber die sensiblen Daten (Profildaten, Private Nachrichten, etc.) könnte man verschlüsselt an den Besucher senden. Das ganze geht dann auch andersherum. Also wenn jemand eine private Nachricht schreibt und absendet wird sie erstmal per Javascript verschlüsselt und dann erst versendet. Das geile daran ist aber, dass man es grundsätzlich integrieren kann ohne den Besucher zu "stören". Wenn der Browser das lokale Speichern unterstützt, so werden die Daten verschlüsselt, ansonsten eben nicht. Schwachpunkte bei dieser Idee: - wenn zum Zeitpunkt der Key-Übertragung ein Angreifer mitliest hat man verloren - evtl. MITM Bei MITM bin ich aktuell nicht sicher. Der Angreifer kann zwar die Daten durch sein System schleusen und damit eingeloggt sein, aber er kann ja die Daten nicht lesen, weil er den Key nicht kennt. Was passiert allerdings, wenn der Angreifer den Key selbst neu setzt. D.h. er tut so als wäre er der Server, der den Key neu setzt und überschreibt den lokalen Key gegen einen eigenen. Da müsste man eine zusätzliche Sicherheitsbarriere schaffen. Ich weiß nicht, ob man eine Art Schreibschutz realisieren kann. Dazu muss ich mich erstmal einlesen. Wobei ich vermute, wenn man die Verschlüsselungsfunktion so anpasst, dass sie bei jedem Besucher nach einem Key mit einem anderen Indexnamen sucht, so müsste es ja eigentlich sicher sein. Außer man kann bestehende local Storage Arrays wie normale Arrays durchlaufen. EDIT: Ne ich glaube doch nicht, dass das funktioniert. Der MITM kann ja den ausgegeben Javascript Code der Seite so anpassen, dass er sich einfach den local Storage als String über einen URL Parameter zusenden lassen könnte. Dann hätte er die Funktion und den Key. Man müsste in local Storage Funktionen abspeichern können, die man nur aufrufen, aber nicht auslesen kann. Dann würde es gehen. EDIT2: Ne würde denke ich auch nichts bringen. Weil sobald die Ausgabe steht kann der MITM ja theoretisch den gesamten DOM auslesen. Also gegen MITM hilft es nicht, aber gegen WiFi Sniffer. Also Noobs, die Firesheep einsetzen. Andere Ideen habe ich aktuell nicht.
Nach oben	profil pn email

maxrev.de Beiträge & PNs ignorieren Gast	13.10.2011, 16:57 zitieren Mach mit! Wenn Dir die Beiträge gefallen haben oder Du noch Fragen hast oder Ergänzungen machen möchtest, solltest Du Dich gleich bei uns anmelden: » Anmelden Registrierte Mitglieder genießen die folgenden Vorteile: ✔ kostenlose Mitgliedschaft ✔ keine Werbung ✔ direkter Austausch mit Gleichgesinnten ✔ neue Fragen stellen oder Diskussionen starten ✔ schnelle Hilfe bei Problemen ✔ Bilder und Videos hochladen ✔ und vieles mehr...
Nach oben

	Re:	Hits	Letzter Beitrag
was machen gegen rost? Moin, Ich habe etwas Rost am meinen wagen. Jetzt wollte ich diesen weg machen. Was muss ich den genau machen. zb. -Rost abschleifen - korrosionsschutz drauf - warte - Lack drauf pinseln... [Allgemein]von Hondissimo	5	523	24.05.2008, 19:15 Hondissimo
was machen gegen rausrutschende tachowelle.... :wall: :wall: hi mein sicherungsring an der welle ist am getriebe wohl so logger gewesen das sie immer hochrutscht ...jetzt kommt sie immer hoch....tacho geht nicht und nach ein paar hundert metern fehlercode weil das getriebe kein tachosignal bekommt... [CRX]von BaldoPanus	4	320	17.01.2010, 17:47 Oli&Eddy
Was machen gegen hagelschaden(motorhaube) hey leute wie gesagt habe ein problem mit mkeiner motorhaube:D die hat ordentliche kleine hagelkörner-dellen, habt ihr n paar tricks auf lager? danke... [Allgemein]von Chrisso1989	5	2605	18.12.2010, 14:09 Chrisso1989
Lack-/Alcantarapflege.... was machen gegen Teerprenkel ???? Hi... der Winter kommt ... und man sieht so langsam was der Wagen den Sommer über mitmachen musste... 1. Alcantarapflege ... wie pflegt ihr eure Innenausstattung bzw. Sitze.. 2. Das wichtigstes.... mittlerweile sieht mein silber-blitz wie ein... Seite 2 [Type-R]von Subwoofer	14	1320	25.09.2007, 18:55 der-gep
X82 dreht wieder am RAD:-) Machen oder nicht machen ? Also es handelt sich hier bei nur noch um die fragen ob ich den AUfkleber machen soll oder nicht ,die Datei habe cih schon fertig , aber bin mir noch nciht schlüßig felgen sollen dann auch rot werden mit poliertem Rand. Typisch GT3 Style halt , denke... Seite 2, 3 [Civic 92-95]von Honda_x82	23	4501	21.10.2008, 21:44 Ryuujin
KFZ-Verzollung: Selber machen oder machen lassen? Hallo! Ich habe eben einen Anruf von einer Logistikfirma aus Bremen bekommen, dass mein Fahrzeug bald am Hafen in Bremerhaven ankommt. Nun habe ich folgendes Angebot per Email erhalten: Hafenabfertigung - D/O Fee: € ... [Allgemein]von mgutt	3	719	09.08.2010, 10:25 mgutt
Ej9 Rückbank Selber machen oder Machen lassen? Moing, ich möcht die Rückbank von meim Ej9 beziehen (lassen). Ich würds gerne selber versuchen bin mir nur net ganz sicher ob das so hinhaut ohne große Erfahrung ion dem Gebiet. Meine Mutter kann gut nähen daran dürfts nicht scheitern aber wie beziehn... [Sattlerarbeiten]von kläusinger	8	419	02.06.2011, 19:56 Black-Undercover
Tönungsfolie machen lassen oder selber machen ? hi leude hab die sufu benutzt aber nich so wirklich was gefunden sollte man die scheiben tönen lassen oder selbst machen ? ist es wirklich so das die folie von innen abkratzbar ist ...d.h. wenn ich irgendwas teransportiere und da meinetwegn ne... Seite 2, 3 [Aufkleber & Folie]von alextv01	26	3952	09.01.2012, 23:08 Dörney
[Umfrage] Machen oder nicht machen?! [URL=http://imageshack.us] [/URL] Haube in der Wagenfarbe lassen?! oder gegen eine schwarze eintauschen!? hab ich letztens erst wieder gesehen auf nem Treffen! sieht doch schon ganz ok aus! Haken dabei: hat fast jeder 3te!!!! :suspekt: :!:... [Civic 92-95]von >>>Cortez<<<	6	503	24.01.2008, 23:37 Mac-Ten
10-04-10 \| SSL Proxies (53) 53 fresh scanned SSL Proxies. Checked & filtered with ProxyFire MasterSuite (Timeout 5) >>Download Lists ... von extremeboy	0	49	10.04.2010, 04:59 extremeboy