WordPress-REST-API-Schwachstellen-Exploits gehen weiter

Es ist fast zwei Wochen her, seit das WordPress-Sicherheitsteam eine nicht authentifizierte Sicherheitsanfälligkeit bezüglich der Eskalation von Berechtigungen in einem REST-API-Endpunkt in 4.7 und 4.7.1 offengelegt hat. Die Schwachstelle wurde stillschweigend gepatcht und die Offenlegung um eine Woche verzögert, um den Besitzern von WordPress-Sites einen Vorsprung bei der Aktualisierung auf 4.7.2 zu verschaffen. In der vergangenen Woche wurden bereits Hunderttausende gefährdeter Websites unkenntlich gemacht, und die Schadensmeldungen trudeln immer noch ein.

Über das Wochenende nahmen die Angriffe zu und WordPress-Sicherheitsfirmen haben gesehen, dass mehr Versuche von ihren Firewalls blockiert wurden. Sucuri, die Website-Sicherheitsfirma, die WordPress die Schwachstelle gemeldet hat, verfolgte letzte Woche die Kampagne „Hacked by w4l3XzY3“ und schätzte 66.000 Defacements. Diese spezielle Kampagne hat nun 260.000 von Google indexierte Seiten durchlaufen. Es ist eine von fast zwei Dutzend Defacement-Kampagnen, die auf die Schwachstelle abzielen.

„Während der letzten 24 Stunden haben wir ein durchschnittliches Wachstum von unkenntlich gemachten Seiten pro Kampagne von 44 % festgestellt“, sagte Mark Maunder, CEO von Wordfence, am Freitag. „Die Gesamtzahl der unkenntlich gemachten Seiten für all diese Kampagnen, wie von Google indiziert, ist von 1.496.020 auf 1.893.690 gestiegen. Das ist eine 26-prozentige Steigerung der gesamten unkenntlich gemachten Seiten in nur 24 Stunden.“

Maunder verwies auf ein Diagramm von Google Trends, das den Erfolg der Verunstaltungskampagnen in der vergangenen Woche zeige. Der Anstieg begann an dem Tag, an dem WordPress die Schwachstelle bekannt gab.

White Fir Design, ein weiteres Unternehmen, das Sicherheitsdienste anbietet, bestreitet jedoch die Behauptung von Wordfence, dass 1,8 Millionen Seiten gehackt wurden. Die Zahl von rund 2 Millionen Seiten wird in Berichten von BBC, The Enquirer, Ars Technica, CIO.com und anderen Publikationen zitiert. White Fir Design behauptet, dass die gehackten Seiten, die von Google indexiert wurden, keine genaue Darstellung sind.

Auch Sucuri-CTO Daniel Cid stimmt der Einschätzung der Situation durch Wordfence nicht ganz zu. Nach einigen Recherchen über das Wochenende schätzt Sucuri, dass mehr als 50.000 Websites gehackt wurden, wobei 20 bis 30 Seiten pro Website unkenntlich gemacht wurden. Dies wäre ungefähr eine Million am unteren Ende der Schätzung und reicht bis zu 1,5 Millionen.

Sucuri sieht auch ernsthaftere Versuche zur REST-API-Schwachstelle in Form von Remote Code Execution (RCE)-Angriffen auf Websites, die Plugins verwenden, die die PHP-Ausführung aus Beiträgen und Seiten heraus ermöglichen. Eine solche Kampagne versucht, ein PHP-Include einzufügen, um Inhalte von einer kompromittierten Website hinzuzufügen, und dann eine Hintertür einzufügen, die in /wp-content/uploads versteckt ist.

„Verunstaltungen bieten keine wirtschaftlichen Erträge, also wird das wahrscheinlich bald sterben“, sagte Cid. „Was bleiben wird, sind Versuche, Befehle auszuführen (RCE), da dies den Angreifern die volle Kontrolle über eine Website gibt – und mehrere Möglichkeiten zur Monetarisierung bietet – und SPAM-SEO / Affiliate-Links / Anzeigeninjektionen. Wir sehen allmählich, dass sie auf einigen Websites versucht werden, und das wird wahrscheinlich die Richtung sein, in die diese Schwachstelle in den kommenden Tagen, Wochen und möglicherweise Monaten missbraucht wird.“

Hacker zielen auf Websites ab, die nicht auf 4.7.2 aktualisiert wurden – es scheint kein Muster zwischen ihnen zu geben. Ein kurzer Blick auf die Google-Ergebnisse für die aktivsten Kampagnen zeigt, dass zu den kompromittierten Websites Blogs, Medien, Regierungs-, Bildungs-, Sport-, Medizin- und Technologie-Websites gehören.

Warum die REST-API standardmäßig aktiviert ist

Die WordPress-REST-API ist standardmäßig aktiviert, da geplant ist, dass in Zukunft mehr Verwaltungs- und Plug-in-Funktionen auf die REST-API angewiesen sind. Nach den jüngsten Angriffen haben mehrere Benutzer die Offenlegung der Schwachstelle kommentiert, um zu fragen, warum sie standardmäßig aktiviert ist.

„Das Sicherheitsproblem liegt in einer Funktion, die ich auf keiner meiner Seiten verwende (REST-API), und dennoch ist diese Funktion erstens standardmäßig aktiviert und zweitens braucht man seit WordPress 4.7 sogar ein Plugin – was weitere Sicherheitsprobleme verursachen könnte – um die Funktion zu deaktivieren?“ Ein Benutzer (@helios2121) hat den Beitrag kommentiert. „Bitte überdenken Sie Ihren Sicherheitsansatz. Erstellen Sie Funktionen, für die nicht jeder Opt-in benötigt. Oder geben Sie zumindest eine Möglichkeit, sich abzumelden, ohne dass zusätzliche Plugins erforderlich sind.“

Morten Rand-Hendriksen hat ein Trac-Ticket eröffnet, um die standardmäßige Deaktivierung der REST-API zu besprechen und sie nur dann zu aktivieren, wenn der Site-Administrator dies anfordert oder ein Design oder Plugin davon abhängig ist.

Core Committer Sergey Biryukov bestätigte, dass geplant sei, weitere Kernfunktionen einzuführen, die auf der REST-API basieren. „Das Deaktivieren der REST-API ist wie das Deaktivieren von admin-ajax.php – beides wird Ihre Website beschädigen“, sagte Biryukov.

Rand-Hendriksen fragte, warum die Inhaltsendpunkte nicht standardmäßig geschützt werden können, während die REST-API für Administratorzwecke standardmäßig aktiviert ist. Ein anderer Benutzer fragte, warum der Benutzerendpunkt nicht standardmäßig geschützt ist (dh https://news.microsoft.com/wp-json/wp/v2/users oder https://www.obama.org/wp-json/wp /v2/users), wodurch es „einfacher als je zuvor ist, alle Benutzernamen zu erhalten“ auf jeder Website mit 4.7+.

„Wenn Sie die REST-API auf Ihren Seiten wirklich deaktivieren möchten, ist dies unsere aktuelle Empfehlung: Beschränken Sie sie auf authentifizierte Benutzer“, sagte Core Committer James Nylen. „Wir wollen jedoch die Akzeptanz und Nutzung der REST-API weiter steigern, und ich gehe davon aus, dass selbst diese Änderung im Laufe der Zeit immer mehr WP-Funktionen beeinträchtigen wird, wie z. B. API-gesteuerte Themen und Einbettungen.“

Nylen empfiehlt das Plugin „Disable JSON API“ für diejenigen, die dieser Empfehlung auf Websites mit WordPress 4.7+ folgen möchten. Das Plugin hat derzeit mehr als 10.000 aktive Installationen.

Das WordPress-Sicherheitsteam arbeitete fleißig daran, die Angriffe einzudämmen, indem es Hosts und Sicherheitsfirmen dabei half, Schutzmaßnahmen zu ergreifen, bevor das Problem veröffentlicht wurde. Die vollständige Offenlegung der Schwachstelle wurde jedoch im Make/Core-Blog begraben, einer Website, die unter normalen WordPress-Website-Besitzern nicht sehr gelesen wird. Der Link zur Offenlegung wurde eine Woche später als Nachtrag zum vorherigen Beitrag im WordPress-Newsblog veröffentlicht.

„Obwohl ich die verantwortungsbewusste Offenlegung dieses Problems und die Bemühungen, es zu lösen, zu schätzen weiß, hoffe ich, dass Sie zukünftige Ankündigungen über einen neuen Beitrag auf der WordPress News-Site machen, anstatt nur ein Update an einen früheren Beitrag anzuhängen“, kommentierte Benutzer @johnrork auf die offizielle Offenlegung. „Ich bin wahrscheinlich nicht der einzige, der eine Kompromittierung hätte vermeiden können, wenn dies am Mittwoch als neuer Artikel in meinem RSS-Reader aufgetaucht wäre.“

Diejenigen, die die Make-Blogs gelesen haben, hatten einen Vorsprung bei der Reparatur ihrer eigenen Sites und/oder der Sites ihrer Kunden. Diejenigen, die sich auf den WordPress-Newsblog verlassen, um Informationen zu Sicherheitsupdates zu erhalten, haben den Beitrag wahrscheinlich gelesen, als er ursprünglich veröffentlicht wurde, und eine Woche später nicht mehr zurückgekehrt, um das Update zu sehen. Ein so schwerwiegendes Problem garantierte die Transparenz von WordPress in einem neuen Beitrag in seinem News-Blog. Dies hätte auch automatisch einen Tweet an mehr als eine halbe Million Follower auf dem offiziellen WordPress-Konto und dem Facebook-Konto gesendet, das mehr als eine Million Likes hat.

Glücklicherweise ist die Zahl der anfälligen Websites, die auch Plugins haben, die es Angreifern ermöglichen könnten, diese Schwachstelle zu nutzen, viel kleiner. Verunstaltete Websites sind peinlich, aber leicht zu beheben. In den meisten Fällen müssen Administratoren nur auf 4.7.2 aktualisieren und die unkenntlich gemachten Posts auf die neueste Version zurücksetzen. Die meisten Websitebesitzer haben keine Ahnung, wie schnell Exploits nach der Veröffentlichung auftauchen, aber diese Situation war eine sanfte Erinnerung daran, wie wichtig es ist, WordPress zu aktualisieren, und den Vorteil, automatische Updates eingeschaltet zu lassen.