Sollten verwaltete Plugins aus dem WordPress-Repository gesperrt werden, wenn ein Sicherheitsproblem vorliegt?

Am 27. Februar 2020 um 21:34 Uhr (MEZ) erhielten wir eine E-Mail, die uns darüber informierte, dass unser Plugin WP Activity Log „aufgrund eines Exploits vorübergehend aus dem WordPress.org-Plugin-Verzeichnis zurückgezogen“ wurde.

Wir haben am Freitag, den 28. Februar 2020 um 16:08 Uhr einen Fix eingereicht. Wir haben nur 16,5 Stunden gebraucht, um den Fix zu veröffentlichen. Wir hätten das Problem viel früher behoben, wenn dies während unserer normalen Arbeitszeiten passiert wäre (wir sind in Europa ansässig), da wir eine sehr gute Support-Reaktionszeit haben (Referenz).

Unser Plugin wurde am Montag, den 2. März 2020 um 13:00 Uhr wiederhergestellt. Das sind 69 Stunden, nachdem wir den Fix übermittelt haben. Es ist wichtig zu beachten, dass das Team wegen des Wochenendes so lange gebraucht hat, um das Plugin wieder einzusetzen.

Warum schreibe ich das?

Ich möchte darauf hinweisen, dass ich der Meinung bin, dass nicht gepflegte Plugins, die Sicherheitsprobleme aufweisen, aus dem WordPress-Repository gesperrt werden sollten. Außerdem habe ich großen Respekt vor der Arbeit, die die Freiwilligen des Plugin-Review-Teams leisten, und ich übernehme auch die volle Verantwortung für das gemeldete Sicherheitsproblem.

Ich glaube jedoch, dass gemeldete Sicherheitsprobleme in gepflegten Plugins besser gehandhabt werden könnten. Aufgrund der Art und Weise, wie sie derzeit gehandhabt werden, erleidet der Ruf des Plugins einen großen negativen Schlag, und seine Benutzer und ihre Websites werden gefährdet. Daher hebe ich am Ende dieses Beitrags einige mögliche Verbesserungen hervor, die hilfreich sein können, und ich denke, sie sollten berücksichtigt werden. Die Idee ist, immer weniger Benutzer einem Risiko auszusetzen und die Auswirkungen auf das Plugin und die Entwickler zu verringern.

In diesem Beitrag dokumentiere ich auch alle Details dessen, was passiert ist, und erkläre die in unserem Plugin gemeldete Schwachstelle im Grenzfall mit niedrigem Schweregrad.

Wie ist das Verfahren zum Melden eines WordPress-Plugin-Sicherheitsproblems?

Aus den offiziellen Richtlinien im Plugin-Handbuch:

Jeder Versuch, den Entwickler direkt zu kontaktieren, sollte unternommen werden, bevor Sie uns das Plugin gemeldet haben (obwohl wir verstehen, dass dies schwierig sein kann – überprüfen Sie zuerst den Quellcode des Plugins, viele Entwickler listen ihre E-Mails auf). Wenn Sie sie nicht privat erreichen können, kontaktieren Sie uns bitte direkt und wir helfen Ihnen weiter.

Was ist in unserem Fall passiert?

Wir machen im Plugin sehr deutlich, wer das Plugin entwickelt. Schauen Sie sich einfach die Plugin-Seite im Repository an und Sie werden sich ein Bild machen! Wir machen es Ihnen auch sehr einfach, mit uns in Kontakt zu treten.

Allerdings hat uns niemand das Sicherheitsproblem gemeldet, bevor das Plugin vorübergehend aus dem Plugin-Repository entfernt wurde. Also hat jemand das Problem dem Überprüfungsteam für WordPress-Plugins gemeldet und sie haben unser Plugin vorübergehend ohne vorherige Benachrichtigung aus dem Repository zurückgezogen.

Bevor wir in das Warum und Was eintauchen und was gut, schlecht und was verbessert werden kann, werfen wir einen Blick auf die Plugin-Schwachstelle und eine kurze Erklärung, wer wir sind.

Was war die Plugin-Schwachstelle?

Wir haben einen Installationsassistenten im WP-Aktivitätsprotokoll, um Benutzern bei der Konfiguration des Plugins zu helfen. Eine der Einstellungen im Assistenten ermöglicht es Ihnen, Nicht-Administratoren zu erlauben, die Aktivitätsprotokolle zu lesen.

Wir haben jedoch einen Fehler gemacht; Wir haben nicht überprüft, ob der Benutzer, der den Assistenten ausführt, authentifiziert wurde. Daher könnten nicht authentifizierte Benutzer den Assistenten ausführen und einem anderen Benutzer oder einer anderen Rolle Zugriff auf die Einstellungen des Plugins gewähren. Dies ist jedoch ein Randfall mit niedrigem Schweregrad.

Warum ist dies ein Randfall-Sicherheitsproblem mit niedrigem Schweregrad?

Die Angreifer könnten dies nur ausnutzen, wenn:

• der Installationsassistent wurde vom Installationsprogramm nie abgeschlossen,
• die Angreifer hatten bereits einen Benutzer / hatten Zugriff auf einen Benutzer auf der Website,
• Die Angreifer können nur auf die Einstellungen und das Aktivitätsprotokoll des Plugins zugreifen.

Durch die Ausnutzung dieser Sicherheitsprobleme erhalten die Angreifer keinen Zugriff auf andere Privilegien auf der WordPress-Website. Daher hat dieser Exploit keine negativen Auswirkungen auf das Verhalten und die Funktionalität der Website selbst.

Konzeptioneller Beweiß

Der POC ist sehr einfach. Besuchen Sie diese Seite als nicht authentifizierter Benutzer:

http://example.com/wp-admin/admin-post.php?page=wsal-setup&current-step=access

Dies ist der Schritt des Assistenten, mit dem Sie angeben können, wer die Protokolle sehen kann. Suchen Sie in der Quelle der HTML-Seite nach der Nonce „_wpnonce“, kopieren Sie sie und fügen Sie sie in den folgenden Curl-Befehl ein:

$ curl 'http://example.com/wp-admin/admin-post.php?page=wsal-setup&current-step=access' -d '_wpnonce=INSERT-NONCE-HERE&wsal-access=yes&editors%5B%5D= Subscriber&save_step=Weiter'

Sobald Sie sich als Abonnent anmelden, haben Sie vollen Zugriff auf die Plugin-Einstellungen.

Warum glauben wir, dass dieser Fall falsch behandelt wurde?

In der E-Mail, die wir erhalten haben, stand folgendes:

Wir schließen Plugins nicht leichtfertig, und wenn es um Sicherheitsprobleme geht, versuchen wir, die Anzahl der Benutzer und die Geschichte der Entwickler mit der Schwere und dem Schadenspotenzial des Berichts in Einklang zu bringen.

Ich denke jedoch, dass unser Plugin zu früh zurückgezogen wurde. Bis jetzt;

1. Wenn wir in der Vergangenheit Probleme hatten, haben wir sie immer innerhalb weniger Stunden behoben. Das haben wir diesmal auch gemacht.
2. Wir haben immer pünktlich geantwortet, wenn sich das Plugin-Überprüfungsteam gemeldet hat.
3. Das Sicherheitsproblem betraf nur unser Plugin (niedriger Schweregrad) und war ein Grenzfall.
4. Das Sicherheitsproblem konnte nicht automatisch ausgenutzt werden.
5. Der einzige Schaden, den der Angreifer anrichten konnte, bestand darin, die Plugin-Einstellungen zu ändern, die Aktivitätsprotokolle zu lesen oder sie zu löschen.

Was halten andere Entwickler von solchen Situationen?

Die meisten von uns haben bereits einen Artikel, Tweet oder eine Nachricht in den sozialen Medien zu ähnlichen Themen gelesen. Ich wollte jedoch selbst herausfinden, was andere Leute, insbesondere Entwickler, darüber denken. Ich denke, das ist wichtig, weil es einige Dinge geben könnte, die ich nicht sehe.

Zunächst schickte ich eine E-Mail an die Person, die das Problem identifiziert hatte, und dankte ihr für die verantwortungsvolle Offenlegung. Seine Antwort war:

„Ich freue mich, dass Sie das Problem im Plugin schnell behoben haben. Übrigens, mir ist aufgefallen, dass die Leute von wordpress.org es für ein paar Tage geschlossen haben, das war ein bisschen hart und war nicht wirklich nötig.“ – Jerome Bruandet.

Ich habe auch eine kleine Umfrage in der Facebook-Gruppe Selling WordPress Products durchgeführt. Obwohl diese Gruppe klein ist, sind die meisten ihrer Mitglieder Plugin- und Theme-Entwickler. Aus der Umfrage können wir ersehen, dass die Entwickler einstimmig zustimmen, dass im Falle von Problemen mit geringem bis mittlerem Schweregrad die Entwickler kontaktiert werden sollten und ihnen die Möglichkeit gegeben werden sollte, eine Lösung bereitzustellen und das Plugin nicht zurückzuziehen:

Wie können diese Verfahren verbessert werden?

Meines Wissens gibt es keine dokumentierten Verfahren, wenn jemand ein Sicherheitsproblem in einem Plugin meldet. Wenn dies der Fall ist, könnten Verfahren wie das folgende den Entwicklern helfen und auch weniger Menschen gefährden.

Kontaktieren Sie die Entwickler und einigen Sie sich auf einen Aktionsplan, bevor Sie das Plugin schließen

Das Plugin-Überprüfungsteam kann versuchen, die Entwickler zu kontaktieren und die Schwachstelle zu bestätigen, bevor das Plugin geschlossen wird. Entwickler sollten mit einem Aktionsplan antworten, einschließlich eines angemessenen Datums für die Behebung.

Bei Bedarf kann das Plugin-Überprüfungsteam eine Frist setzen. Beispielsweise sollten Entwickler zwischen 12 und 24 Stunden Zeit haben, um das Problem zu beheben. In einigen Fällen benötigen sie jedoch möglicherweise mehr Zeit, abhängig von der Zeitzone, in der sie sich befinden usw. Sollten die Entwickler nicht antworten, sollte das Plugin aus dem Repository entfernt werden.

Bestimmen Sie den Schweregrad und die Art des Sicherheitsproblems

Dies könnte offen für Diskussionen sein. Jemand mit ein wenig Sicherheitserfahrung kann jedoch anhand des gemeldeten Proof of Concept (POC) leicht erkennen, ob ein gemeldetes Sicherheitsproblem automatisch ausgenutzt werden kann, ob es sich um einen Grenzfall handelt oder nicht, und welche Auswirkungen es hat.

Überprüfen Sie, ob sich die Entwickler an den Aktionsplan halten

Es sollte eine Art Prüfung vorhanden sein, um zu bestätigen, dass die Entwickler den Fix rechtzeitig einreichen und sich an alle anderen Aufgaben halten, die im Aktionsplan enthalten sind.

Das Zurückziehen gepflegter Plugins aus dem Repository hilft nicht

Bei gewarteten Plugins schadet das Zurückziehen aus dem Repository mehr als es nützt. Beispielsweise;

1. Sie machen öffentlich, dass das Plugin ein Problem hat, höchstwahrscheinlich ein Sicherheitsproblem. Dies löst viele Alarme aus und rückt das Plugin ins Rampenlicht. Dies ist auch so, als würde man Angreifer einladen und ihnen sagen, dass etwas im Plugin möglicherweise ausnutzbar ist.
2. Es enthüllt die aktuelle Plugin-Benutzerbasis, weil ihre Websites plötzlich zum Ziel wurden. Die meisten Benutzer haben keine Ahnung, was sie tun sollen, insbesondere wenn die Funktionalität des Plugins der Kern ihrer Website und ihres Geschäfts ist.
3. Sie erhöhen die Wahrscheinlichkeit, dass der Fix verzögert wird. Dies wird normalerweise durch mangelnde Kommunikation oder durch Feiertage und Wochenenden verursacht.

Man könnte argumentieren, dass Sie durch das Zurückziehen eines Plugins aus dem Repository die Ausbreitung der Infektion stoppen . Wenn das Sicherheitsproblem jedoch von geringem Schweregrad ist, die Ausnutzung nicht automatisiert werden kann und die Offenlegung verantwortlich ist, sind keine Risiken damit verbunden oder die Risiken sind äußerst gering.

Haftungsausschluss: Dies ist kein Angriff

Ich möchte darauf hinweisen, dass dies kein Angriff auf das Überprüfungsteam für WordPress-Plugins oder irgendjemanden ist, der an diesen Prozessen beteiligt ist. Ich respektiere ehrlich ihre Arbeit und ich weiß, dass das, was sie tun, in gutem Glauben getan wird. Es gibt jedoch sicherlich Raum für Verbesserungen, wie in jedem anderen System und Prozess.

Viele werden mir wahrscheinlich sagen, dass ich mich freiwillig melden sollte, anstatt diesen Beitrag zu schreiben, wenn ich eine Veränderung möchte.

Ich versuche schon seit geraumer Zeit mitzumachen; Ich habe mit mehreren Leuten auf verschiedenen WordCamps gesprochen, um mich zu beteiligen, und ich habe auch die Seite „WordPress-Plugins erstellen“ auf Aufrufe für Freiwillige überwacht. In den letzten Jahren hatten sie jedoch keine offenen Stellen. Wenn sie Hilfe brauchten, fügten sie neue Mitglieder nur auf Einladung hinzu.