“Ä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.

“Wordpress: Eine Studie in Scharlachrot” (computec.ch)
Marc Ruef hat sich den Quellcode von WordPress angeschaut, meint dieser wäre schon vom Ansatz her nicht sehr sicher und die von ihm genannte Stelle würde in Zukunft zu Problemen führen.

Es geht um die wp-login.php und die Zeile 188:
$key = preg_replace('/[^a-z0-9]/i', '', $key);

Was macht denn nun diese eine Zeile PHP? Eigentlich nicht viel, sie wandelt nur alle Zeichen die nicht Buchstaben (a-z) oder Ziffern (0-9) sind in das Zeichen zwischen den Hochkommas '' um, löscht sie also. Ja, das war schon alles. Diese eine Zeile Code macht nun WordPress nicht unsicher, zeigt aber, wie Herr Ruef es nennt, eine “Art der defensiven Programmierung”.

Da $key (laut Ruef) nur ein MD5-Hash sein darf,

• Buchstaben von a bis f
• Ziffern von 0 bis 9
• Länge: 32 Zeichen

ist ganz klar festgelegt, was vom Script verarbeitet werden darf und was sofort als Fehlfunktion bzw. Angriff eines Hackers gewertet und abgebrochen werden muss.

Hätten sich die WP-Entwickler ähnliche Gedanken über die Sicherheit gemacht wie Herr Ruef, so würden alle Prüfungen die nach der Zeile 188 vorgenommen werden, auch wenn es kein MD5-Hash ist, nicht ausgeführt – die weitere Verarbeitung würde mit einer Fehlermeldung abgebrochen werden – aber dem ist leider nicht so.

Genau solche vermeintlichen Kleinigkeiten, führen in der Summe eines Projektes (WP hat 276 PHP-Dateien), im Zusammenspiel unzähliger Scripte, sehr schnell zu Fehlern, die dann eben doch kritisch sein können.


Ich habe es ja auch immer wieder mit Entwicklern zutun, die eher darauf schauen das ihr Code schnell ausgeführt wird und möglichst wenig Zeilen verbraucht (sic!). Sie wollen oft nicht einsehen, dass es immer besser ist, sich den Code auch von der Seite des Hackers her anzuschauen und zum Beispiel alle Benutzereingaben abzufangen und auszuschließen, die nicht benötigt werden.


Warum muss z.B. ein Feld für deutsche Postleitzahlen mehr als 5 Ziffern aufnehmen, Buchstaben und Sonderzeichen erlauben und in der Datenbank 255 Zeichen speichern können? Damit sich der Entwickler keine Arbeit machen muss, wenn ein nicht-Deutscher sich verlaufen hat. ;O)

Bisschen ergoogelt (ext:sql dump blz|plz):

`plz` varchar(64)
…
`PLZ` int(11)
…
`plz` decimal(10,0)
…
`plz` varchar(255)
…
`blz` text
…
`blz` varchar(64)

Passend zu mehr Sicherheit in WP dies:
“Mehr Sicherheit für WordPress 2.8.5” (entwickler.de)

Da soll der Admin in Zukunft nur noch bestimmte Datei-Typen in die Mediathek hochladen können und ein gehackter Admin-Account von WordPress wird damit sicherer?!

entwickler.de bezieht die Info von Robert Wetzlmayr:
“Neu in WordPress 2.8.5: Sichere Mediathek” (talkpress.de)

Und auch der offizielle deutsche WordPress-Blog schreibt:
“Neue Sicherheitsbestimmung für die Mediathek in 2.8.5” (blog.wordpress-deutschland.org)

Was hindert den Hacker daran, der nun Admin ist, ein Plugin zu installieren, mit dem er die MIME-Typen der Whitelist wieder aufbohrt? Und was hindert ihn daran, einfach im Theme eine Datei zu editieren, um dort eine R57-Shell einzufügen?

Ich kann nur hoffen das die WP-Entwickler diese Änderung nicht wirklich als Beitrag zu mehr Sicherheit in WordPress einstufen.