Monat der WordPress-Sicherheit ist beendet

In den letzten Wochen habe ich einige Artikel zur Sicherheit ausgewählter WordPress-Plugins geschrieben. Nun wollte ich abschließend noch einmal ein Fazit ziehen.

Begonnen hatte alles damit, dass auf Golem.de im Abstand von wenigen Wochen über zwei weit verbreitete Plugins mit leicht auffindbaren und dennoch schwerwiegenden Fehlern berichtet wurde. Es hatte mich daher interessiert, wie schlecht es wirklich um die Codequalität bei weit verbreiteten Plugins bestellt ist.

Also begab ich mich zur Liste der beliebtesten Plugins und begann, mir Plugins anzusehen. Dabei habe ich mich auf halbwegs aktuelle Plugins konzentriert, die mindestens 25.000 Downloads hatten. Außerdem sollte die Analyse schnell gehen: Es ging mir nicht darum, Fehler in der Ablauflogik der Plugins zu finden, sondern ich wollte die groben Schnitzer finden - also die Fehler, die einem sofort ins Auge springen. Glücklicherweise verfügt jedes Plugin über ein eigenes Trac-Repository, sodass man direkt online in den Quelltext gucken kann. Damit entfällt das langwierige downloaden, entpacken und im Editor öffnen. So kann man relativ schnell einzelne Plugins abarbeiten.

Ich habe mir etwa 100 Plugins angesehen, die sich vom Namen oder von der versprochenen Funktionalität spannend anhörten. Dabei sind die 12 unten aufgelisteten Plugins aufgefallen, die solche nennenswerten Löcher enthielten (wobei 2 davon Beifang sind - hatte ich ein Plugin mit einer Lücke gefunden, habe ich mir auch die anderen Plugins des gleichen Autors angesehen).

Plugin Angriff Anzahl
WP RSS Aggregator XSS 141.960*
WP CSV Information Leakage 31.675*
WP Advanced Importer Unprivileged File Upload 12.041*
WP Ultimate CSV Importer Unprivileged File Upload 112.793*
Simplr Registration Form Plus+ Information Leakage 105.325*
Form Builder Unprivileged File Upload 88.218*
WordPress File Upload XSS 25.060*
WP Modal Login Privilege Escalation 34.763*
Quick Chat SQL Injection 207,488**
Quick Count SQL Injection 14,268**
Login With Ajax Privilege Escalation 273.635**
FormGet Contact Form XSS 159.545**
Total: 1.206.771
(*Stand vom 16.08.2014)
(**Stand vom 26.08.2014)

Bei der Durchsicht der Plugins sind mir mehrere Dinge aufgefallen:

  1. Viele Plugins sind offenbar eher zufällig "sicher" und nicht etwa, weil der Programmierer das geplant hätte. Oft scheitert ein Angriff nur daran, dass vor einem anfälligen Code eine WordPress-eigene Funktion aufgerufen wird, die (aufgrund ihres Fehlens) zu einer Exception führt, wodurch die Programmausführung beendet wird. Würden solche Aufrufe in eine eigene Funktion gekapselt werden, wären viel mehr Angriffe möglich.
  2. Nur wenige Plugins schützen sich gegen Cross-Site-Request-Forgeries ab. Sie enthalten derzeit eventuell keine Lücken, sollten diese jedoch durch eine Codeänderung eingeführt werden, ließen sie sich dadurch wesentlich leichter ausnutzen.
  3. Die Punkte 1.) und 2.) rühren oftmals daher, dass die Entwickler sich nicht darum sorgen, ob ihre PHP-Scripte direkt aufgerufen werden dürfen. Vielen Entwicklern ist offenbar nicht bewusst, dass sie ihre Entrypoints und Codepfade kennen und absichern sollten. Dies war die häufigste Fehlerkorrektur, die von mir angeschriebene Plugin-Entwickler umgesetzt haben.
  4. Viele Plugin-Entwicklern verlassen sich darauf, dass eingeloggte Nutzer gutartig sind. Während sie den Eingaben von nicht-eingeloggten Besuchern meist gänzlich misstrauen, werden Eingaben von eingeloggten Nutzern häufig weniger oder gar nicht geprüft. Daher sollte man sich beim Einsatz von Plugins gut überlegen, ob man "Subscriber" in seiner WordPress-Installation zulässt.
  5. WordPress bietet Entwicklern viele fertige Funktionen an, mit denen sie ihre Plugins sicherer machen können - das reicht bis zu fertigen Referer- und Nonce-Prüfungen gegen XSRF-Angriffe. Mir ist jedoch auch aufgefallen, dass WordPress-Nonces relativ lange gültig sind, sich nur an der Zeit orientieren, statt an nutzergebundenen Werten und damit potentiell mehrfach und von verschiedenen Nutzern verwendet werden könnten (was dazu führt, dass ein Angreifer sich regelmäßig einen neuen Nonce holen und diesen für laufende Attacken verwenden könnte).

Die Kommunikation mit den einzelnen Plugin-Entwicklern war bisher durchweg positiv. Viele haben sich gefreut, dass sich jemand tiefer mit ihren Plugins auseinandersetzt und sie über die Probleme informiert. Die meisten haben in weniger als einer Woche das Problem behoben, bei anderen Plugins warte ich darauf hingegen immernoch - dort wurde ein Fix lediglich in Aussicht gestellt. Überrascht hat mich die Reaktion eines Entwicklers, der sein Plugin aufgrund von Zeitmangel aus dem Plugin-Repository entfernt hat. Ich fand, dass dies ein mutiger Schritt war.

Ich fand es spannend, mich in die verschiedenen Programmierstile der einzelnen Plugin-Entwickler einzuarbeiten. Ich habe mich deshalb dazu entschlossen, solche Aktionen in den nächsten Monaten mit den Plugins anderer Content-Management-Systeme zu wiederholen.

Für Leute und Firmen, die WordPress professionell einsetzen, kann ich aufgrund der Ergebnisse eigentlich nur den Rat geben: Wenn Fremdplugins eingesetzt werden, empfiehlt es sich, wenigstens kurz in deren Quelltext zu blicken. Guckt euch an, ob sichergestellt wird, dass die PHP-Scripte nicht direkt aufgerufen werden können. Damit ist bereits viel gewonnen, da der Plugin-Entwickler so viel mehr Kontrolle über den Programmablauf hat.

WordPress-Grüße, Kenny

Schreibe einen Kommentar

Um Ihnen beim weiteren Kommentieren auf dieser Webseite die erneute Eingabe Ihrer Daten zu ersparen, wird beim Absenden Ihres Kommentars ein Cookie an Ihren Browser gesendet und von diesem gespeichert. Mit dem Absenden eines Kommentars auf dieser Webseite stimmen Sie der Speicherung und Übertragung dieses Cookies explizit zu.

Pflichtfelder sind mit * markiert.