Es ist eine alte Wahrheit: Was Computern leicht fällt, fällt Menschen oftmals sehr schwer und umgekehrt. Und ein Web Vulnerability Scanner kann, wie auch ein Virenscanner, nur etwas finden wenn ihm ein entsprechendes Muster für Vergleiche vorliegt.

Kevin Beaver behauptet: Weil kommerzielle Schwachstellen-Scanner mit dem Aufspüren von CSRF-Lücken Probleme haben, so hätten auch Menschen Probleme beim Auffinden solcher Lücken. Und es wäre auch schwer eine gefundene Lücke auszunutzen. Seine Schlussfolgerung daraus: Man solle dieser Art von Schwachstelle weniger Beachtung schenken und lieber die offensichtlichen, leicht auffindbaren Lücken suchen und schließen.

Erst über den Blogeintrag “CSRF Isn’t A Big Deal – Duh!” (ha.ckers.org) von Robert “RSnake” Hansen bin ich auf Kevin Beaver gekommen.

Kevin Beaver hat angeblich 20 Jahre Erfahrung in der Branche. Und erzählt so etwas seinen Kunden? Wieder ein spezieller Experte. ;O)


Ich weiß nicht wie der Algorithmus eines Web Vulnerability Scanner aufgebaut ist um Lücken zu Cross-Site Request Forgery (de.wikipedia.org) zu finden, aber für mich als Human Web Vulnerability Scanner ist das Auffinden recht einfach.

Wenn eine CSRF-Lücke vorliegt besteht kaum ein Problem ein funktionierenden Exploit zu erstellen, etwas HTML- und JavaScript-Kenntnisse reichen vollkommen aus. Der Angreifer muss sein Opfer nur noch auf eine präparierte Website locken, um zum Ziel zu kommen.


Wenn beispielsweise das Anlegen eines neues Users in einem CMS über ein Formular erfolgt welches folgende Daten versendet:

http://wordpress/wp-admin/user-new.php
[POST]
action=adduser
&user_login=tester
&email=name@mail.tld
&pass1=12345678
&pass2=12345678
&role=administrator


So kann man davon ausgehen das eine CSRF-Lücke vorliegt.

In WordPress gibt es aber noch den Parameter _wpnonce der CSRF verhindert:

http://wordpress/wp-admin/user-new.php
[POST]
_wpnonce=abc123xyz789
&action=adduser
&user_login=tester
&email=name@mail.tld
&pass1=12345678
&pass2=12345678
&role=administrator


Der Wert hinter _wpnonce ist für eine bestimmte Aktion und einen bestimmten Blog immer derselbe. Sollte es, evtl. über eine Sicherheitslücke, möglich sein diesen Wert aus einem fremden Blog auszulesen oder ihn zu berechnen, so täte sich eine CSRF-Lücke auf.

Vor neun Wochen habe ich die “Hessische Zentrale für Datenverarbeitung” (HZD) auf Sicherheitslücken aufmerksam gemacht. Es ging mal wieder um Cross-Site Scripting und der Möglichkeit, Inhalte verschiedener Websites miteinander zu kombinieren.

Alle hessischen Ministerien, aber auch Justizbehörden oder Schulämter, scheinen Teil des “SAP NetWeaver Portal” zu sein, wodurch sehr viele Seiten von den Lücken betroffen sind — und wenn ich “sehr viele” schreibe, dann meine ich hunderte Websites.

Ich hatte damals ein Proof of Concept erstellt, welches beide Lücken zeigte und nachvollziehbar machte. Per Kontaktformular gab ich der HZD den Link zum PoC. Am nächsten Tag registrierte ich den Zugriff auf meine Beispiele, also war der Hinweis angekommen. Einen weiteren Tag später rief mich dann jemand von der HZD an, bedankte sich für die Hinweise und bat mich den PoC von meinem Server zu löschen, weil er Bedenken hatte, Google könnte es in den Index aufnehmen. Da ich solche Links niemals selber weiterverbreite und Directory Listing standardmäßig deaktiviert ist, kann keine Suchmaschine die Links indexieren, es sei denn — jemand ist mit einem mit einer Toolbar (Alexa, Yahoo, etc.) verseuchten Browser unterwegs, die alle aufgerufenen URLs nach Hause melden. Ich löschte alles sofort und nahm an das man nun in Wiesbaden tätig werden würde und die HZD sich der Tragweite der Lücken bewusst ist, da sie ja selber am besten wissen wie viele Websites auf deren Servern laufen.

Da nach neun Wochen nichts von Seiten der HZD unternommen wurde, kann Ich nur zu dem Schluss kommen: Die HZD ist der Meinung, Cross-Site Scripting ist harmlos und das Vertauschen von Inhalten ist auch nur ein Schönheitsfehler. Ok, ich teile diese Meinung bekanntlich nicht, aber die HZD kann dann auch nicht verärgert sein, wenn ich nun darüber schreibe.


Zuerst der Schönheitsfehler in der Software von SAP.

Was hat das “Hessisches Ministerium für Umwelt, Energie, Landwirtschaft und Verbraucherschutz” mit “„Mittelstufenschule” soll Jugendliche gemeinsam fördern” zutun? Mittelstufenbaumschule? (hmuelv.hessen.de)

Der Kopf der Seite und die Domain in der Adresszeile des Browsers gehören zu hmuelv.hessen.de, aber der Text und das Bild kommen von kultusministerium.hessen.de.

Nur ein Schönheitsfehler, sieht aber trotzdem nicht so gut aus. Ich weiß nicht ob es ein Fehler in der Software von SAP ist oder ob die Jungs der HZD, oder wer auch immer dafür verantwortlich ist, das System einfach nur falsch konfiguriert haben.


Nun zu meinem Steckenpferd, Cross-Site Scripting.

Per XSS kann man fremde Seiten einbinden oder auch Inhalte so manipulieren, das sie zu dem Design der Seite passen.

Aber wie ich schon in “Passwort-Manager im Firefox sofort abschalten” beschrieben habe, tun sich mit XSS Sicherheitslücken auf, die mit “normalem” Defacement nichts gemein haben. Hier mal wieder ein Video als Beispiel.

Auch hier kann ich nicht abschließend beurteilen ob es ein Fehler in der Software von SAP ist. Es sieht sehr nach Fehlern in den Templates aus, denn es gibt auch ansonsten sehr viele HTML-Fehler im Quellcode.


Bei der Suche nach Domains in denen *.hessen.de (searchdns.netcraft.com) zu finden ist, bekommt man 114 Ergebnisse angezeigt. Diese Liste ist bei weitem nicht vollständig, kann aber durchaus für eine Stichprobe herhalten.

Nach Bereinigung von nicht mehr vorhandenen Domains bzw. Weiterleitungen auf andere, blieben noch 107 Seiten übrig. In 87% der Seiten findet man Lücken zu Cross-Site Scripting. Die hohe Zahl rührt daher, das alleine 60% der untersuchten Seiten die Software von SAP benutzen. In 19% aller Seiten wird jeweils eine andere anfällige Software benutzt, bei der der Fehler eindeutig in der Software liegt und nicht in fehlerhaften Templates. 8% der Seiten weisen individuelle XSS-Lücken auf. Das 13% der Seiten keine offensichtliche, schnell zu findende Lücke aufweist, bedeutet nicht das diese fehlerfrei wären. Ich bin sicher, würde man eine genauere Untersuchung durchführen, so würde man sehr nah an 100% für Cross-Site Scripting anfällige Websites herankommen. Es ist schon erschreckend wie schlecht die Seiten unterhalb der Domain *.hessen.de gestrickt sind.

Ich weiß es nicht genau, aber es sieht so aus, als ob die Portal-Software von SAP mehrere Domains und deren Inhalte verwaltet. Ist dies so, so wird es auch eine zentrale Stelle für Templates geben, die für jede Domain verwendet werden. Würde man nun an den entsprechenden Templates eine Fehlerbereinigung vornehmen, so könnte man mit einem Schlag 60% der untersuchten Websites sicherer machen.


Mein kleiner Test und die Meinung der HZD zu Cross-Site Scripting, bestärkt mich mal wieder darin, das meine Vorbehalte gegenüber der IT-Kompetenz staatlicher Stellen begründet sind.