Warum WordPress unsicher ist – am Beispiel von Contact Form 7

Die Zeiten ändern sich.

Dieser Beitrag scheint älter als 3 Jahre zu sein – eine lange Zeit im Internet. Der Inhalt ist vielleicht veraltet ...

WordPress ist nicht unsicherer als andere CMS. Vor allem, wenn mit eingerechnet wird, dass WordPress einen unglaublich viel höheren Marktanteil hat. WordPress hat aber ein Problem mit unsicheren Plugins (keine Sorge Contact Form 7 ist nicht wirklich unsicher!). Das ist zum einen der Aufstellung der offiziellen Verzeichnisse geschuldet, die im Prinzip jeden Schwachsinn Versuch zulassen, solange es nicht gegen die Regeln verstößt. Und zum anderen der Macher:innen dieser Plugins, die vor allen in den Anfangstagen aus enthusiastischen Hobby-Blogger:innen bestand. Mit der Zeit professionalisierte sich die gesamte Community und auch die Programmiersprachen und WordPress-Versionen wurden immer mehr. Und nun gibt es ganz neue Probleme und sehr unsinnige Lösungen.

Das Problem auf was ich hier anspiele ist eigentlich ein gut gemeintes Feature mit dem Plugins anzeigen können mit welcher PHP-Version oder WordPress-Version sie funktionieren. Das alleine ist natürlich kein Problem, aber was passiert, wenn ein Plugin eine Sicherheitslücke schließt und Warnungen aufploppen, aber die notwendige WP- bzw. PHP-Version nicht zur Verfügung steht? Gar nichts.

Und genau das ist ein Problem. Ein großes Problem.

Für den Laien stellt sich das Ganze so dar: Ein Blick in das Backend zeigt, alles ist auf dem aktuellen Stand. Keine Updates notwendig. Weil sie zum Beispiel noch auf WordPress 5.3 oder kleiner sind, wie im aktuellen Fall mit der „Contact Form 7“-Sicherheitslücke. Kollegen warnen ihre Kunden und erklären zwar, dass es sich nicht direkt um einen Virus handelt, aber der einzige Rat ist, das Plugin zu aktualisieren. Was aber, wenn die Kundin oder der Kunde das Update gar nicht angezeigt bekommt?

Der Grund dafür ist diese Zeile in der readme.txt:

Requires at least: 5.4

WordPress in Version 5.4 wird also vorausgesetzt. In kleineren Versionen wird das Update einfach stillschweigend nicht angezeigt. Bei einer Suche im Verzeichnis nach dem Plugin auf einer solchen WordPress-Version zeigt nur einen sehr kleinen unscheinbaren Hinweis, dass darüber informiert, dass es inkompatibel ist mit der WP-Version:

Wesentlich auffälliger und mit hilfreichem Link ist die Warnung, wenn die PHP-Version nicht ausreichend ist:

Update: Das wurde wohl inzwischen schon gefixt. Der Screenshot stammt von einer älteren Version, aber wohl schon mit WordPress 5.4 wird auch bei nicht ausreichender WP-Version ein roter Warnhinweis mit hilfreichem Link angezeigt.

Aber all diese Warnungen helfen natürlich gar nichts, wenn das Plugin schon installiert ist und das Update nicht angezeigt wird.

Eine Lösung für das Problem ist übrigens das „Plugin Report“-Plugin von Roy Tanck, es zeigt seit Version 1.6 nicht nur die neuere Version an, sondern auch die Info, warum es ggf. nicht installiert werden kann:

Click here to display content from WordPress.org.
Erfahre mehr in der Datenschutzerklärung von WordPress.org.

Aber das Plugin muss explizit aufgerufen werden, es ändert auch nichts an der Pluginliste oder den Badges, daher nur bedingt eine Lösung für den Unbedarften, denn der weiß ja nicht, warum er das Plugin installieren und starten müsste …

Gerade das Beispiel mit Contact Form 7 ist besonders ungünstig. Bei mehr also 5 Millionen aktiven Installationen dürften da einige dabei sein, die (noch) nicht auf WordPress 5.4 oder höher sind. Die Lücke wurde in der Vorweihnachtszeit gefunden und die Informationspolitik der Sicherheitsfirma ist sehr fragwürdig. In dem ersten Artikel zur Lücke wurde ein Proof of Concept nach 14 Tagen angekündigt. Das wäre am 30.12. oder am 31.12. gewesen. Dann kam aber nichts.

Erst am 10. Januar kam dann das Update:

Update:

Checking the statistics of the plugin, it can be seen that a large number of WordPress websites are still using older versions. We’ve also been getting multiple requests asking for an exploit which has been worrisome. Hence, taking into consideration the millions of websites on older versions and the interest of black hat community, we won’t be releasing a PoC.

Further, we can confirm that WordPress websites not using the upload functionality in Contact Form 7, running the latest version, or using any good security tool are protected from this. We haven’t tracked any active exploitation in the wild until now.

Es wird also kein Proof of Concept gezeigt, weil zu viele Plugins noch nicht aktualisiert wurden (oh, wunder!) und man den „bösen“ keine Anleitung geben möchte. Auf der anderen Seite können die auch schnell einen Diff zwischen den beiden letzten Versionen machen und wissen, was geändert wurde. Ich vermute eher, dass es ihnen nicht möglich war den PoC zu zeigen, denn es gibt einige Vorbedingungen, die nötig sind, damit die Lücke ausgenutzt werden kann.

Laut dem Wordfence-Artikel dazu ist ein „File Upload“-Inputfeld im Formular notwendig. Soweit so klar, es gibt aber noch mehr:

  • Any uploaded files are stored temporarily in a folder with a random name, and removed immediately after the file is sent to the form recipient. This means the attacker would need to be able to find the random folder name, which would likely require Directory Indexing to be enabled, and they would need to do so before the randomized directory and uploaded file was removed.
  • Contact Form 7 uses an .htaccess file to disallow direct access to uploaded files which would be necessary to execute code. While this would only work on sites running Apache, it would prevent execution of any uploaded files unless a separate vulnerability was present.
  • The filename must end in an acceptable file extension. This means that only certain Apache configurations would assign a PHP handler to any uploaded file using a double extension.

Es müssen also diverse andere Sicherheitslücken oder Fehlkonfigurationen vorliegen, damit die Lücke ausgenutzt werden könnte. Insbesondere vor diesem Hintergrund ist es fast schon fahrlässig, wenn heise eigentlich nur den Ursprungsartikel ins Deutsche überträgt ohne nennenswerte Gegenrecherche oder Zusatzinfos hinzuzufügen. Hoster wie all-inkl.com reagieren dann auf solche schlecht recherchierten Artikel und warnen vor diesen unsicheren Pluginversionen dann in deren Backend und via E-Mail:

Sie erhalten diese automatische E-Mail von unserem Wartungscenter.

Ihre E-Mail-Adresse wurde von Ihnen als Kontakt für den betreffenden Account hinterlegt.

* VIRENFUND / SICHERHEITSLÜCKE *

Bei einem routinemäßigen Scan wurden in Ihrem Account w[…] (example.de) problematische Dateien gefunden. Um die Besucher Ihrer Webseite zu schützen, haben wir diese Dateien nach Möglichkeit umbenannt und gesperrt.

* URSACHEN *

Häufige Ursachen sind Sicherheitslücken in nicht aktualisierten Systemen wie zum Beispiel CMS (WordPress, Joomla, etc), Shops, usw.

* MASSNAHMEN *

Loggen Sie sich bitte umgehend in die technische Verwaltung Ihres Accounts ein und folgen Sie den Anweisungen im Menüpunkt „Wartungscenter“.

(English version)

You are receiving this automated email from our Action Center.

Your email address had been entered as the primary contact address for the respective account.

* SECURITY ISSUE FOUND *

During a routine scan, our system has detected files containing malicious code on your account w[…] (example.de). In order to protect the visitors of your website, we have renamed and blocked these files.

* REASONS *

In the most cases the causes of malware are security breaches in outdated systems like CMS (WordPress, Joomla, etc.), shops, etc.

* ACTIONS TO BE TAKEN *

Please log in immediately to the technical administration of your account and follow the instructions in the menu item „Action Center“.

Mit freundlichen Grüßen
Ihre Support-Abteilung

Heidewitzka! Virenfund – Sicherheistlücke und das schon im Betreff. Als Laie wäre ich auch in Aufruhr. Aber es gibt keine Möglichkeit das Ganze auszunutzen, wenn der Hoster alles richtig konfiguriert hat. Warum also dieser riesige Buhei? Ganz schön viel Wind für eine sehr theoretische Lücke.

Das viel größere Problem liegt hier in meinen Augen bei den schlechten beziehungsweise zu wenig Informationen vom Entdecker der Lücke und der weiteren verkürzten Weitergabe durch News-Seiten plus die schlechte technische Umsetzung innerhalb von WordPress.

Habe ich was übersehen? Oder möchtest du etwas ergänzen? Dann freue ich mich über einen Kommentar!

8 Antworten auf Warum WordPress unsicher ist – am Beispiel von Contact Form 7

  1. Diese Mail von all-inkl.com hat mir ein aufgeregter Kunde auch weitergeleitet 🤷‍♀️
    Nur: Die von mir betreute Website hat CF7 gar nicht installiert. Und so stellt sich raus: Da schimmelte noch eine alte WP-Installation auf dem Server herum. Also: In meinem Fall war das ganze hilfreich, aber ansonsten stimme ich dir sehr zu!

    • Ja, manchmal kann das ganz hilfreich sein. Die Spamwelle Ende des letzten Jahres hat mir gezeigt bei welchen Sites ich vergessen hatte den Beispiel-Artikel zu löschen.

      Wobei veraltete Installationen tatsächlich auch ein enormes Sicherheitsproblem darstellen.

  2. Ich hatte auch in mindestens einer Facebook-Gruppe eine solch aufgeregte Meldung zur der Sicherheitslücke, die „Millionen Seiten angreifbar macht“. Leider das der Titel des Beitrags reinstes Clickbaiting, denn damit die Lücke wirklich hätte ausgenutzt werden können, müssten schon sehr viele recht unwahrscheinliche Dinge zurecht kommen. Daher konnte ich auch erst einmal beruhigen.

    Aber das Problem, dass ein Sicherheitsupdate durch eine hochgesetzte Mindestanforderung an WordPress viele nicht erreichen wird, ist tatsächlich ein riesiges Problem. Vor allem dann, wenn nicht einmal eine solche neue Anforderung wirklich notwendig oder bestenfalls nur für bestimmte neue Funktionen benötigt wird.

    • Mich würde ja interessieren, ob es im Plugin-Verzeichnis möglich ist einen Branch weiterzuführen. Was wäre, wenn CF7 jetzt für die kleineren Versionen mit geringeren erforderlichen WP-Versionen den Patch nachbauen würde und als z.B. 5.1.10 (statt 5.1.9) zur Verfügung zu stellen (also per SVN taggen). Geht das? Würde das so ausgeliefert werden? Oder ist das durch die „Stable“-Version immer mit nur einer Version fest verdrahtet? Und andere können nicht ausgeliefert werden?

      • Ich weiß nicht, warum das nicht funktionieren sollte. Das wp.org-Repo soll sowieso nur den Releases dienen und nicht der Entwicklung. D. h., in der Realität hat die Entwickler*in ohnehin noch eine andere Entwicklungsversionskontrolle, wahrscheinlich git.

        Das größere Problem ist, dass die meisten Einzelentwickler*innen keine Kapazitäten haben, die Sicherheitslücke rückwirkend zu schließen. Ernsthaftes Semantic Versioning könnte hier Abhilfe schaffen, wird aber von fast keinem Plugin eingesetzt.

        Angenommen, ich als Plugin-Entwickler würde den Patch sogar rückwirkend liefern, wird er trotzdem nicht im WP-Backend angezeigt, da ja nur „the latest the greatest“ ist.

        • Technisch funktioniert es ja, sonst könnte das Security-Team das ja nicht einsetzen. Ich glaube, die offizielle Erklärung war, dass sie den Entwickler:innen nicht trauen, dass sie es alle korrekt hinbekommen SVN so zu benutzen. Vielleicht ist aber auch eine Frage der Anzahl von Request, die dann noch hinzukommen. Ich habe damals nachgefragt und nach der negativen Antwort nicht weiter nach dem „Warum“ gefragt.

          • Da würden mich mal die tatsächliche Anfrage und Antwort interessieren. Das hört sich in meinen Ohren unsinnig an. Wenn mir zugetraut wird, dass ich Tags erstellen und löschen kann, dann wird mir doch getraut, dass ich Tags erstellen kann… 🤔

  3. Pingback: Können WordPress-Plugins eigentlich mehrere Zweige unterstützen? › Torsten Landsiedel

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert