Plugin- und Theme-Entwickler: Das können Sie aus der Sicherheitslücke unseres SDK lernen

Diese Woche war ziemlich intensiv für unser Team, da wir uns mit einer Sicherheitslücke auseinandersetzen mussten. Sicherheit hat für uns oberste Priorität, und dies ist die erste größere Schwachstelle, die seit vier Jahren in unserem SDK gefunden wurde. Leider sind Entwickler wie bei jeder Software auch Menschen, also passieren Fehler, egal ob Sie ein Indie-Entwickler, ein Themenshop mit 20 Leuten oder Google sind. Der Zweck dieses Artikels ist in erster Linie Transparenz, aber auch, Ihnen einen Einblick zu geben, wie wir mit dem Vorfall umgegangen sind und was Sie daraus lernen können.

Am Montag, den 25. Februar 2019, erhielten wir eine Support-E-Mail von einem hilfreichen Entwickler, der über ein GitHub-Problem im WooCommerce-Repository stolperte. Das Problem wurde von einem Vertreter eines kleinen Hosting-Unternehmens verursacht, das verdächtige Aktivitäten auf seinen Servern bemerkte. Der Vertreter fügte die relevanten Aktivitätsprotokolle hinzu, die auf zwei potenzielle Angriffe hindeuteten, und einer davon zielte auf ein Plugin ab, auf dem das Freemius SDK ausgeführt wurde.

Da wir Sicherheit sehr ernst nehmen, haben wir sofort eine gründliche Untersuchung durchgeführt und bestätigt, dass die Schwachstelle tatsächlich in unserem SDK liegt.

Aufgrund der Schwere der Schwachstelle haben wir sofort mit der Arbeit an einer Lösung begonnen. Nach nur wenigen Stunden veröffentlichten wir ein gepatchtes Tag und benachrichtigten alle Entwickler, die eine anfällige SDK-Version verwendeten, um das SDK für alle ihre Produkte so schnell wie möglich zu aktualisieren. Wir haben auch das ursprüngliche GitHub-Problem aktualisiert, um das WooCommerce-Team darüber zu informieren (das GH-Problem haben wir nach ein paar Stunden entfernt, um die Gefährdung zu verringern).

Um die Gefährdung zu mindern und allen eine „Gnadenfrist“ für die Aktualisierung auf die gefixte Version zu geben, haben wir die Entwickler um zwei Dinge gebeten:
(a) Wenn dieses Sicherheitsupgrade in Ihr Änderungsprotokoll aufgenommen wird, verwenden Sie bitte nur allgemeine Formulierungen wie „Sicherheitsfix“.
(b) Bitte geben Sie dieses Problem auch nach dem Update und der Veröffentlichung der gepatchten Versionen nicht in den nächsten 30 Tagen bekannt, damit alle unsere Partner und ihre Benutzer genügend Zeit für die Aktualisierung haben.

Nur einen Tag später veröffentlichte eine Website, die Schwachstellen von Plugins abdeckt (absichtlich nicht auf sie verlinkt oder ihren Namen erwähnt), einen Beitrag über die Schwachstelle, einschließlich Informationen darüber, wie sie ausgenutzt werden kann, und nannte einige der betroffenen Plugins. Dies hat uns überrascht, da wir die Plugin- und Theme-Entwickler weniger als 24 Stunden zuvor über das Problem informiert haben. Sie haben sich weder mit uns in Verbindung gesetzt noch sind sie der Marktpraxis der verantwortungsbewussten Offenlegung gefolgt, was wir für ziemlich unverantwortlich und unethisch halten.

Ich habe mich an sie gewandt und darum gebeten, den Bericht vorübergehend nicht zu veröffentlichen, um die Gefährdung zu verringern und unseren Entwicklern und ihren Benutzern die Möglichkeit zu geben, auf die gepatchten Versionen zu aktualisieren, bevor sie die unerwünschte Aufmerksamkeit von mehr Hackern auf sich ziehen. Aber die Person, mit der ich kommuniziert habe, die ihren Namen nie preisgegeben hat (ich habe sie gefragt), hat ihre eigene aufrichtige Ideologie und scheint, als ob der gesunde Menschenverstand sie nicht wirklich anspricht. Ich habe versucht, die problematische Situation und das erhöhte Risiko, dem sie vielen Entwicklern und Benutzern ausgesetzt sind, zu erklären, aber meine Bemühungen stießen auf taube Ohren, und mir wurde klar, dass mein E-Mail-Austausch nur Zeitverschwendung war.

Als die Community unserer Entwickler ihre Plugins und Themes auf das neu gepatchte SDK, das wir veröffentlicht haben, aktualisierte, entdeckten wir zwei Probleme:

1. Mehrere Entwickler haben unsere Benachrichtigungs-E-Mail nicht erhalten, weil sie sich bei Freemius mit einer E-Mail-Adresse registriert haben, die sie nicht überprüfen.
2. Wir haben das gepatchte GitHub-Tag absichtlich nicht als offizielle Version gekennzeichnet, um Aufmerksamkeit zu vermeiden. Wir haben jedoch erfahren, dass Entwickler, die Composer zum Aktualisieren ihrer Bibliotheken verwendeten, nicht das neueste Update erhielten, da packgist nur Releases abruft, es sei denn, es wurde explizit ein Tag angegeben.

Um diese Probleme zu überwinden:

1. Da die Schwachstelle bereits öffentlich veröffentlicht wurde, haben wir die gepatchte Version vor zwei Tagen als offizielle Version gekennzeichnet, damit Entwickler, die sich auf Packgist verlassen, aktualisieren können.
2. Heute früh haben wir eine weitere Reihe von Nachrichten per E-Mail an Entwickler gesendet, die das SDK für alle ihre Produkte noch aktualisieren müssen. Dieses Mal haben wir die Nachrichten an ihre offiziellen Support-Kanäle gesendet, um die Chancen zu erhöhen, dass alle die E-Mails richtig erhalten.

Obwohl wir die Veröffentlichung dieser Schwachstelle um mindestens zwei Wochen verschieben wollten, erhielten wir eine weitere Anfrage von WP Tavern mit der Bitte um unseren Input, bevor sie einen eigenen Artikel zu dem Thema veröffentlichten, was das Fass zum Überlaufen brachte.

Die Fehler, die wir gemacht haben und was Sie daraus lernen können

Wenn wir auf den Vorfall zurückblicken, haben wir mehrere Fehler gemacht, die wir leicht hätten vermeiden können und die das Leben aller viel einfacher gemacht hätten.

Gehen Sie in den stillen Modus und benachrichtigen Sie nur diejenigen, die es wissen müssen

Da wir so sehr darauf bedacht waren, das Problem so schnell wie möglich zu beheben, machte ich persönlich einen „Anfänger“-Fehler, der zu früh unerwünschte Aufmerksamkeit erregte. Ich ging weiter und übergab den Fix an das GitHub-Repository, das wir zur Verwaltung des SDK verwenden. Das Repository ist nicht nur öffentlich, sondern ich habe den Fix erklärt und das Wort „Sicherheit“ darin verwendet.

Der bessere Ansatz war, eine private/geschlossene Version des Repositorys zu erstellen, das Sicherheitsproblem dort zu patchen und es nur den relevanten Entwicklern anzuzeigen, anstatt es öffentlich zu machen. Dies würde die Aufmerksamkeit von „Vulnerability Hunters“ nicht auf sich ziehen.

Verschwende deine Energie nicht an „Sicherheitstrolle“

Der zweite Fehler war der Versuch, mit dem Unternehmen hinter der Website zu interagieren, die die Schwachstelle veröffentlicht hat. Es war eine totale Zeit- und Energieverschwendung und löste nur noch mehr Antagonismus aus, der mit einem weiteren Beitrag über die Schwachstelle endete. Ich würde sagen, dass ein guter Indikator, um zu entscheiden, ob es sich lohnt, einen Autor eines Beitrags zu kontaktieren, der Ihre Plugin- oder Theme-Benutzer gefährdet, darin besteht, ob hinter dem Beitrag/der Website/dem Unternehmen ein Name steht. Wenn sie sich hinter Stellvertretern verstecken und irrational handeln, ist die Chance, dass Sie mit ihnen vernünftig reden können, praktisch null.

Das ist also mein Rat – wechseln Sie in den Silent-Modus und benachrichtigen Sie nur die Personen, die von der Schwachstelle wissen müssen. Im Falle eines Plugins/Themes sind das Ihre Benutzer. Dies ist auch eine gute Gelegenheit, die Wichtigkeit des Sammelns der E-Mails Ihrer Benutzer hervorzuheben. Wenn Sie keine Möglichkeit haben, privat mit Ihren Benutzern zu kommunizieren, haben Sie keine effektive Möglichkeit, sie privat über Sicherheitsprobleme zu benachrichtigen.

Der aktuelle Status des Vorfalls

Mehr als 60 % der Entwickler, die unser SDK verwenden, haben bereits auf die gepatchte Version aktualisiert. Darüber hinaus verfügt das SDK über einen speziellen Mechanismus, der es mehreren von Freemius unterstützten Plugins oder Themes ermöglicht, die auf derselben WordPress-Website installiert sind, die neueste Version des SDK zu verwenden, wenn eines der Produkte bereits aktualisiert wurde. Das ist gut.

Allerdings gibt es immer noch viele Websites, die anfällig sind. Aus diesem Grund habe ich weder technische Details zur Schwachstelle selbst noch zu den betroffenen Produkten erwähnt. Wir möchten unseren Entwicklern weiterhin die Möglichkeit bieten, ihre Produkte zu patchen und ihren Benutzern zu ermöglichen, auf die sicheren Versionen zu aktualisieren.

Wie reduziere ich Sicherheitsrisiken in deinem WordPress-Plugin/-Theme?

Wenn Sie keinen Sicherheitshintergrund haben, googeln Sie „Best Practices für die Websicherheit“ und Sie werden unzählige Artikel und Praktiken finden. Lesen Sie einige davon, um sich der modernen und typischen potenziellen Risiken und Fehler bewusst zu werden. Berücksichtigen Sie diese während der Entwicklungs- und Testprozesse. Eine weitere gute Praxis besteht darin, regelmäßige Sicherheitsüberprüfungen durchzuführen, indem ein Sicherheitsforscher eingestellt wird. Es kostet ein paar hundert Dollar, aber wenn Sie sich auf Ihr Produkt als Haupteinnahmequelle verlassen, ist es ein Kinderspiel.

Leider können, wie in unserem Fall, immer noch schlimme Dinge passieren. Obwohl wir über einen sehr starken Sicherheitshintergrund verfügen, führen wir gründliche Code-Reviews durch und arbeiten mit einem erfahrenen Sicherheitsforscher aus der HackerOne-Community zusammen, doch diese Schwachstelle ist uns dennoch durch die Lappen gegangen. 😔

Ich denke, einer der Gründe dafür ist, dass der anfällige Code tatsächlich hinzugefügt wurde, um Grenzfälle zu debuggen, und nicht Teil der Kernfunktionalität des SDK ist. Wenn es hier also eine Lektion gibt, behandeln Sie jeden Code in Ihrem Produkt auf die gleiche Weise, unabhängig davon, ob er Teil der eigentlichen Geschäftslogik oder irgendetwas anderem ist.

Rekapitulieren

Sicherheitsprobleme sind in der Softwarewelt unvermeidlich. Ob es uns/Ihnen gefällt oder nicht, eines Tages wird Ihr Plugin oder Theme ein Sicherheitsproblem haben. Das Problem kann in Ihrem Code, einer Bibliothek/einem Framework, das Sie verwenden, einer WordPress-Kernmethode, die unerwartete Ergebnisse liefert, und vielen weiteren Szenarien liegen.

Wenn es passiert (ich hoffe es wird nicht), machen Sie sich keinen Stress (wir haben es definitiv getan) und handeln Sie impulsiv – es wird nur mehr Schaden anrichten. Entwerfen Sie einen methodischen Wiederherstellungsplan, benachrichtigen Sie die betroffenen Parteien und helfen Sie Ihren Benutzern, ihre Websites zu sichern. Jeder weiß, dass Sicherheitsprobleme passieren, wichtiger ist, wie Sie mit der Situation umgehen.

Vor diesem Hintergrund entschuldigen wir uns im Namen des gesamten Freemius-Teams wirklich für die Unannehmlichkeiten und werden das ganze Wochenende über hier sein, um Unterstützung, Beratung oder andere Hilfe in Bezug auf das Problem anzubieten. Und für unsere neuen Benutzer weiß ich, wie wichtig der erste Eindruck ist, und dieser ist definitiv kein guter. Ich hoffe, dass Sie Freemius eine weitere Chance geben und mit der Zeit die erstaunlichen Funktionen sehen, die wir für Ihre WordPress-Plugins und -Themen anbieten.