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.

“Ältere WordPress-Versionen Ziel von Angriffen” (blog.wordpress-deutschland.org)

Daher sei gesagt: Nur die aktuellste Version von WordPress ist die sicherste!

Das liest sich wie: “Das beste Windows aller Zeiten.” :O)

In meinem Blog konnte ich bisher keinen Angriff auf die Lücken der WP-Versionen vor 2.8.4 feststellen. Was wohl daran liegen mag, dass mein Blog eher unbedeutend und unbekannt ist, aber evtl. auch damit zusammenhängt, dass man bei mir nicht sehen kann welche Version hier aktuell läuft.

In “WordPress für C64” hatte ich bereits darüber geschrieben wie man die Ausgabe der Versionsnummer ändert.


Ich behaupte mal: Die Ausgabe der Versionsnummer einer Software zieht Angreifer an.

Wenn bekannt wird das in der Version 0.8.1.5 einer Software eine Lücke steckt, dann werden natürlich alle Scriptkiddies dieser Welt genau nach dieser Version suchen. Da ist es dann sehr dumm, wenn die Software die Versionsnummer ausplaudert und diese, wie bei CMS, Foren, Blogs, etc. üblich, auch über Suchmaschinen auffindbar ist.


Gestern meinte jemand in einem Kommentar auf meinen vorletzten Eintrag:

Ich warte sehnsüchtig auf eine kostenpflichtige WordPress-Version, die wirklich sicher ist.

Also, wirklich sichere Software gibt es nicht. Es gibt nur Software, bei der bisher keine Lücke bekannt geworden ist und nur deshalb als sicher gilt, was aber nicht ausschließt, dass unbekannte Lücken bereits ausgenutzt werden.

Warum findet man in einem Script, welches Downloads ermöglichen soll, folgendes?
Select Case strFileType
(...)
Case ".asp"
ContentType = "text/asp"
(...)
End Select
Und warum kann man auch noch den Pfad auf alle Verzeichnisse ändern, bis hoch zum Root?

Nicht weil jemand für seine Arbeit kein Geld bekommt, sondern weil er sein mitgeliefertes Hirn nicht benutzt hat.

Man soll es kaum glauben, aber auch in Software die 20.000 € und mehr kostet, findet man genau solche Lücken. Also kann man nicht davon ausgehen, dass die Sicherheit einer Software davon abhängig ist, wie viel oder ob sie etwas kostet.


Was für das Betriebssystem gilt gilt auch für die Blogsoftware – immer auf den neuesten Stand halten und updaten.