Angriffe auf Schwachstellen in WordPress

Angriffsziel WordPress
Keine Kommentare

Immer wieder gibt es Angriffe auf WordPress-Websites – und oft sind sie erfolgreich. Ist WordPress etwa unsicher? Und wenn ja, wieso? Und wenn nicht, warum sind die Angriffe dann erfolgreich? Und was wollen die Angreifer überhaupt?

Um die Fragen zu beantworten, fangen wir ganz am Anfang an – bei den Angriffen bzw. einigen Beispielen dafür.

August 2017: Ransomware-Angriffe

Im August 2017 haben Entwickler von Wordfence über Angriffe einer „EV ransomware“ genannten Ransomware auf WordPress-Websites berichtet. Als Ransomware wird Schadsoftware bezeichnet, die einen Rechner oder Teile davon lahmlegt und erst nach Zahlung eines Lösegelds wieder freigibt. Dabei kann das Lahmlegen z. B. darin bestehen, dass Dateien verschlüsselt werden oder der Zugriff auf den Rechner gesperrt wird. Im Allgemeinen richten sich die Angriffe gegen Windows-Clients, prinzipiell funktioniert dieses Geschäftsmodell aber natürlich mit allen Arten von Rechnern – also auch mit WordPress-Installationen.

Nicht verschlüsselt werden Dateien, die den folgenden Mustern entsprechen:

Nicht verschlüsselt werden Dateien, die den folgenden
Mustern entsprechen:

Bei der Analyse von an WordPress-Websites gerichteten bösartigem Traffic haben die Wordfence-Entwickler mehrere Versuche beobachtet, Ransomware auf den Server zu installieren. Dabei setzt die Installation der Ransomware voraus, dass der Server bereits kompromittiert wurde. Die installierte Ransomware erlaubt dem Angreifer dann die Ver- und Entschlüsselung aller Dateien bis auf fest vorgegebene Ausnahmen mit einem einzugebenden Schlüssel. Die Startseite der Ransomware sehen Sie in Abbildung 1.

Nicht verschlüsselt werden Dateien, die den folgenden Mustern entsprechen:

  • *.php*
  • *.png*
  • *404.php*
  • *.htaccess*
  • *.lndex.php*
  • *DyzW4re.php*
  • *index.php*
  • *.htaDyzW4re*
  • *.lol.php*

Für jedes abgearbeitete Verzeichnis sendet die Ransomware eine E-Mail an eine vorgegebene E-Mail-Adresse, die den Hostname des infizierten Rechners und den verwendeten Schlüssel enthält. Alle Dateien, die verschlüsselt werden, werden nach der Verschlüsselung gelöscht und durch die verschlüsselte Datei, versehen mit der Dateiendung .EV, ersetzt.

Für die Verschlüsselung wird mcrypt verwendet, als Algorithmus Rijndael 128 und als Schlüssel der SHA-2256-Hash des vom Angreifer gewählten Schlüssels. Nach der Verschlüsselung wird der verwendete Initialisierungsvektor IV dem Schlüsseltext vorangestellt und das Ergebnis dann Base-64-codiert in die .EV-Dateien geschrieben.

Jetzt wird es noch fieser …

Theoretisch könnte man die Dateien wieder entschlüsseln. In der Praxis ist das zumindest mit der Ransomware aber nicht möglich. Bevor sie mit der Verschlüsselung beginnt, erstellt sie in ihrem Installationsverzeichnis zwei Dateien: Das PHP-Skript EV.php mit einem Interface, das aussieht, als würden damit die verschlüsselten Dateien bei Eingabe des richtigen Schlüssels entschlüsselt, und eine .htaccess-Datei, die Requests an das PHPSkript weiterleitet.

Das PHP-Skript enthält zwar ein Formular zur Eingabe eines Schlüssels (Abb. 2), aber keine Entschlüsselungslogik – es ist also im Grunde völlig funktionslos. Das stört die Cyberkriminellen aber nicht bei ihrem Tun, denn für das Opfer sieht es so aus, als könne es seine Dateien retten, wenn es das Lösegeld zahlt. Und nur darauf kommt es den Cyberkriminellen an. Sie brauchen ja keine zufriedenen „Kunden“, die irgendwo gute Bewertungen hinterlassen oder sie weiterempfehlen. Sie wollen ihre Opfer nur dazu bewegen, das Lösegeld zu zahlen. Dazu reicht es ja, ihre Dateien zu „entführen“ und die Freigabe an die Zahlung eines Lösegelds zu binden. Sie müssen sie gar nicht wieder freigeben können, es verlangt ja niemand einen Nachweis, dass das geht, bevor er das Lösegeld zahlt.

Für Windows gab es anfangs sogar Ransomware, die nur so tat, als sei der Rechner gesperrt. Schon das zwangsweise Beenden der Ransomware beseitigte den Schädling – und auch dieser Angriff hat den Cyberkriminellen Geld eingebracht.

Lösegeld bezahlt man nicht!

Nun sollte man generell nie auf die Forderung von Ransomware eingehen. Zum einen, um die Cyberkriminellen nicht zu unterstützen, zum anderen, weil die oft gar nicht in der Lage sind, die Daten wieder zu entschlüsseln, so ja auch in diesem Fall. Unter anderem für solche Angriffe hat man schließlich ein Back-up. Und zwar offline, denn eines auf dem Server o. ä. würde von der Ransomware ebenfalls verschlüsselt werden.

Wer in diesem Fall das Lösegeld bezahlt und das Glück hatte, dafür von den Cyberkriminellen sogar den Schlüssel zu bekommen, gelangte dadurch noch lange nicht an seine Dateien. Er musste danach noch selbst eine Entschlüsselungsfunktion implementieren bzw. von Dritten implementieren lassen, um die Dateien entschlüsseln zu können.

Schutz ist einfach

Schutz vor diesem Angriff bietet laut Wordfence deren Anti-Malware-Lösung, für die man eine passende Signatur entwickelt hat, nachdem die ersten Angriffe beobachtet wurden. Deren Opfer blickten also trotz des Wordfence-Schutzes in die Röhre. Diese Signatur bekamen erst einmal nur die zahlenden Kunden, alle anderen erhielten erst nach 30 Tagen den Schutz. Aber braucht man den? Meines Erachtens nicht, denn eigentlich ist der Schutz sehr viel einfacher: Die Ransomware kann nur installiert werden, wenn der Server zuvor kompromittiert wurde – und das will man ja generell nicht. Egal was auch immer die Angreifer mit dem gekaperten Server anstellen, es wird nie im Interesse des Betreibers sein.

Tools every PHP Developer needs to know

mit Sebastian Bergmann (thePHP.cc)

Learning Machine Learning

mit Joel Lord (Auth0)

Solange Sie also keine Schwachstelle auf Ihrem Server haben, über die die Cyberkriminellen eindringen können, droht Ihnen zumindest von dieser Ransomware keine Gefahr. Bei einem zukünftigen Angriff durch eine andere Ransomware könnte durchaus auch mal eine bisher unbekannte Schwachstelle ausgenutzt werden, sodass auch aktuelle Installationen gefährdet sind. Aber für solche Fälle muss man dann eben ein aktuelles Backup haben.

Woher kommt die Ransomware?

Interessant ist die Herkunft der Ransomware. Diese gibt es seit 2016 auf GitHub, aktuell in Version 2, die auch für den Angriff auf die WordPress-Websites verwendet wurde. Darüber, ob die Entwickler der Ransomware hinter den Angriffen stecken (was m. E. ziemlich unwahrscheinlich ist, denn die Cyberkriminellen wollen ja i. A. nicht erkannt und gefunden werden) oder sie von Dritten genutzt wird, gibt es keine verlässlichen Informationen. Auch das, was die Wordfence-Entwickler sonst noch an Hinweisen auf die Angreifer gefunden haben, lässt m. E. keine brauchbare Identifikation zu. Daten von irgendwelchen Servern laden lassen, kann jeder. Das müssen nicht die aktuellen Angreifer veranlasst haben, und wenn sie es waren, müssen das noch lange nicht ihre Daten bzw. Server sein.

IT-Angriffe korrekt zuzuordnen, ist eigentlich fast unmöglich. Im Zweifelsfall landet man beim Rückverfolgen irgendwann bei einem Server in einem Staat, dem man nicht vertraut. Ob der Angriff dann aber von diesem Server ausging, oder ob der Angreifer den auch nur kompromittiert hat, um darüber seine Herkunft zu verschleiern, kann man nicht sicher feststellen. Vielleicht erinnern Sie sich noch daran: Vor zig Jahren kam mal der größte Teil der Spam-E-Mails aus Südkorea. Nicht, weil sich alle Spammer der Welt dort versammelt hatten, sondern weil es dort von offenen Mailservern wimmelte, die die Spammer mit Freuden genutzt haben.

Februar 2017: Defacement und Kompromittierung von WordPress-Websites

Wie schon erwähnt, kann obige Ransomware nur installiert werden, nachdem die Angreifer sich bereits Zugriff auf den Server verschafft haben. Auch das ist immer wieder über den WordPress Core selbst oder Plug-ins möglich. Beispiele dafür gab es im Februar 2017. Am 26. Januar wurde von WordPress Version 4.7.2 veröffentlicht. Dabei handelte es sich um ein Securityrelease, in dem laut der ursprünglichen Ankündigung drei Schwachstellen behoben wurden.

Erst am 1. Februar wurde bekannt gegeben, dass mit dem Update außer den drei bereits gemeldeten Schwachstellen auch eine kritische Privilegieneskalation im REST API behoben wurde. Auch die ursprüngliche Ankündigung wurde entsprechend ergänzt – übrigens ohne mit Datum auf die Änderung hinzuweisen. Der Grund für das Zurückhalten der Information für eine Woche: Man wollte den Betreibern von WordPress-Websites Zeit zur Installation der Updates geben. Manche WordPress-Hosts wurden von den Entwicklern vorab über die Schwachstelle informiert und konnten Workarounds implementieren und das Update nach Veröffentlichung sofort installieren. Da man bis zur Veröffentlichung des Updates keine Hinweise auf Angriffe auf die Schwachstelle entdeckte, beschloss man die Verzögerung, um den automatischen Updates Zeit zur Installation zu geben.

Dummerweise hat man nicht bedacht, dass es auch viele Betreiber gibt, die die automatischen Updates aus gutem Grund ausgeschaltet haben, z. B. weil sie selbst entscheiden wollen, was wann installiert wird und das keinem Entwickler egal welcher Software überlassen wollen. Ob bzw. wann ein Update installiert wird, hängt dann auch davon ab, wie kritisch es ist. Dieses sah nicht so extrem kritisch aus, als dass man sofort hätte updaten müssen. So wurde das Risiko aufgrund der ursprünglichen Meldung z. B. vom BSI mit „mittel“ eingestuft, was man nach der Bekanntgabe der zusätzlichen Schwachstelle auf „sehr hoch“ änderte. Ein böser Fehler der WordPress-Entwickler, der sich kurz darauf rächen sollte.

Mögliche Angriffe: Inhalte manipulieren, PHP-Code ausführen

Aber erst einmal zurück zu der Schwachstelle. Sie wurde von Marc-Alexandre Montpas von sucuri entdeckt und an WordPress gemeldet. Außerdem hat er sie parallel zur Bekanntmachung durch WordPress im Blog von sucuri ausführlich beschrieben. Nicht authentifizierte Benutzer konnten über die Schwachstelle den Inhalt jedes Posts und jeder Seite einer WordPress-Website modifizieren. Je nachdem, was für Plug-ins installiert sind, kann über die Schwachstelle auch PHP-Code ausgeführt werden. Das ist nun wirklich kritisch und würde wohl bei den meisten Betreibern, die auf automatische Updates verzichten, zu einer schnellen Installation des Updates führen. Nur wussten die halt eine Woche lang nichts davon, und auch danach hat sich das wohl nicht allzu schnell herumgesprochen.

Am 6. Februar meldete sucuri, dass in weniger als 48 Stunden nach der Bekanntmachung der Schwachstelle Exploits im Internet auftauchten und vier Angriffskampagnen beobachtet wurden, die die Schwachstelle für Defacements ausnutzten. Außerdem wurde die Schwachstelle zur Verbreitung von SEO-Spam ausgenutzt.

Am 9. Februar meldete sucuri dann, dass die Schwachstelle nun zum Einschleusen von Code ausgenutzt wird. Die Angriffe richten sich gegen Word-Press-Websites, die Plug-ins wie „Insert PHP“ (mehr als 100 000 Installationen), „Exec-PHP“ (mehr als 100 000 Installationen) und ähnliche installiert haben. Diese Plug-ins erlauben den Benutzern das direkte Einfügen von PHP-Code in ihre Posts, um Anpassungen zu vereinfachen. In Verbindung mit der Schwachstelle im REST API kann ein Angreifer darüber eigenen Code einschleusen. Dabei handelte es sich i. A. um Code zum Öffnen einer Backdoor.

Februar 2017: Angriff auf BlogVault-Anbieter oder -Nutzer

Parallel zu den obigen Angriffen, aber auch unabhängig davon gab es auch einen Angriff auf die Website des WordPress-Plug-ins BlogVault. Zuerst sah es so aus, als ob die Angreifer dabei auch Benutzerdaten ausgespäht und danach unbefugt auf die Websites von BlogVault-Benutzern zugegriffen hätten. Dabei wurde nicht näher beschriebene Schadsoftware installiert. Genauere Untersuchungen ergaben dann, dass die Ursache für die Angriffe eine Schwachstelle im eigenen Plug-in war und keine Daten ausgespäht wurden. In Version 1.40 bis 1.44 nutzte das Blog-Vault-Plug-in die unserialize()-Funktion von PHP mit ungeprüften Daten, sodass darüber Code eingeschleust werden konnte. Eine gründliche Untersuchung des gesamten Systems ergab, dass keine Daten ausgespäht wurden und diese Schwachstelle die einzige Möglichkeit war, Malware auf WordPress-Websites mit dem BlogVault-Plug-in zu installieren. Die von BlogVault gespeicherten Kundendaten waren den Untersuchungen zu Folge nicht gefährdet.

In einem Punkt sind die ganzen Berichte etc. unklar: Wurde nun der Server von BlogVault kompromittiert oder „nur“ die Websites der Kunden? Wenn der Blog-Vault-Server kompromittiert wurde, sind zum einen die ausgewerteten Logfiles etc. wertlos, da sie möglicherweise manipuliert wurden, zum anderen könnten dann doch Daten ausgespäht worden sein. Allerdings ist das hier nicht wirklich wichtig, denn der Angriff steht hier vor allem als Beispiel für einen tatsächlichen Angriff „in the wild“ über eine Schwachstelle in einem Plug-in.

Mai 2015: Angriffe über Theme und XSS

Am 6. Mai 2015 hat sucuri Angriffe über eine DOMbasierte XSS-Schwachstelle im genericons-Package berichtet. Jedes WordPress-Plug-in oder -Theme, das dieses Package verwendet, ist von der Schwachstelle betroffen. Zumindest das JetPack-Plug-in (mehr als eine Million Installationen) und das per Default installierte TwentyFifteen-Theme waren betroffen. Die Angriffe wurden als 0-Day-Exploits entdeckt, also vor dem Bekanntwerden der ausgenutzten Schwachstelle. Ist das Opfer des Angriffs als Administrator eingeloggt, kann der Angreifer die WordPress-Website übernehmen. Soviel also zur oft geäußerten Einstellung, dass XSS ja harmlos sei und keinesfalls den Server gefährden könnte …

Updates sind der wichtigste Schutz

Die dargestellten Beispiele zeigen: Angriffe können über alle möglichen Bestandteile einer WordPress-Website erfolgen. Egal ob WordPress Core selbst, Plugins oder Themes – gibt es eine Schwachstelle, kann sie ausgenutzt werden und wird es auch. Nicht immer, aber immer öfter.

Der beste Schutz davor besteht in erster Linie darin, immer alle Komponenten aktuell zu halten. Und das ist – mal ganz abgesehen davon, dass man für Word- Press selbst die Updateautomatik einschalten kann – gar nicht so einfach. Die Updateautomatik sorgt nämlich nur dafür, dass man bei Bekanntwerden eines Angriffs oder auch nur einer Schwachstelle im WordPress Core selbst von den i. A. sehr schnell bereitgestellten Updates profitiert. Das Problem, dass Plug-ins und Themes oft nicht oder nur verspätet gepatcht werden, wird dadurch aber nicht gelöst.

Wenn man bedenkt, dass zumindest bei individuell

angepassten Websites bei jedem Update die Gefahr besteht, dass danach irgendetwas nicht funktioniert, ist eine automatische Installation eigentlich auch keine ideale Lösung. Eigentlich möchte man ja schon wissen, was man da gerade installiert. Das REST API wird von vielen Websites gar nicht benötigt, wird aber seit Word-Press 4.7.0 per Default installiert und lässt sich nur über ein zusätzliches Plug-in ausschalten. Das fanden diejenigen unter den Opfern der Angriffe auf die Schwachstelle darin, die das API gar nicht benötigen, wahrscheinlich nicht so toll.

Wenn Sie WordPress-Updates manuell installieren wollen und sich bei der Dringlichkeit auf die Security-Advisories von Word-Press verlassen, kann das schnell nach hinten losgehen.

Es gibt noch einen Punkt, der gegen die automatische Installation von Updates spricht: Was ist, wenn der Updateserver oder -prozess kompromittiert wurde? Im November 2016 gab Wordfence bekannt, dass ein Angreifer eine Schwachstelle im zentralen Serversystem von WordPress zur automatischen Installation eines manipulierten Updates hätte ausnutzen können. Über die Schwachstelle hätte der Server api. WordPress.org kompromittiert werden können, über den die automatischen Updates abgewickelt werden. Jede WordPress-Installation fragt stündlich bei diesem Server nach, ob es Updates gibt. Der Server antwortet mit den zu aktualisierenden Versionen von WordPress Core, Plug-ins und Themes, einschließlich der URLs für das Update. Es gibt keine Signaturprüfung; dem von api.WordPress.org gelieferten URL wird blind vertraut und die angegebene Software geladen und installiert. Hätte ein Angreifer die URLs durch URLs zu präparierten Updates ersetzt, wären diese automatisch installiert und dadurch die WordPress-Websites kompromittiert worden.

Gibt es ein Update? Und welche Updates brauche ich?

Aber kommen wir zurück zu den Updates. Wenn die Aktualisierungen Schwachstellen beheben, wird sicher jeder Websitebetreiber sie schon aus Eigennutz möglichst zügig installieren. Jedenfalls sollte das im Idealfall so sein. Dass viele Leute eine Webanwendung installieren und danach nicht mehr anfassen, steht auf einem anderen Blatt.

Sie gehören ja sicher nicht dazu und stehen damit vor einem anderen Problem: Sie müssen erst einmal wissen, dass es überhaupt ein Update gibt, damit sie es installieren können. Das ist nicht selbstverständlich, denn wissen Sie genau, welche Plug-ins, Themes und auch Packages sich auf Ihrem Server tummeln? Im Allgemeinen gibt es immer ein paar Softwarekomponenten, die Drittherstellerkomponenten enthalten, von denen man nichts weiß. Wie wäre es z. B. mit dem oben erwähnten genericons-Package – wissen Sie genau, ob das auf Ihrem Server vorhanden ist oder nicht? Und wenn ja, in welcher Version?

Oder nehmen wir als weiteres Beispiel die viel genutzte WebMail-Bibliothek PHPMailer, in der im Dezember 2016 eine kritische Schwachstelle gefunden wurde, über die ein Angreifer Code einschleusen konnte. Der Entdecker der Schwachstelle veröffentlichte sein Advisory samt Proof-of-Concept am 26. Dezember 2016, nachdem einer der betroffenen Hersteller (hoffentlich versehentlich) zu früh Details veröffentlicht hat, die einem Angreifer die Arbeit hätten erleichtern können. Die Schwachstelle war zu dem Zeitpunkt zwar bereits im PHPMailer behoben, die korrigierte Version hatte aber noch nicht alle Dritthersteller erreicht. PHPMailer wird u. a. von WordPress verwendet. Ob es unabhängig davon auch von Plug-ins verwendet und installiert wird, hätte man damals eigentlich zwischen Weihnachten und Neujahr auf die Schnelle prüfen müssen. Aber fassen wir die Probleme in den folgenden Abschnitten noch einmal zusammen.

Problem 1: WordPress-Core-Schwachstellen und -Updates

WordPress selbst behebt bekannt gewordene Schwachstellen i. A. sehr zügig. Wenn Sie das automatische Update aktiviert haben, ist Ihre WordPress-Website dadurch ziemlich schnell geschützt. Wenn Sie die Updates aber manuell installieren wollen und sich bei der Einschätzung der Dringlichkeit auf die Security-Advisories von WordPress verlassen, kann das nach hinten losgehen. Wie das Beispiel der Schwachstelle im REST API gezeigt hat, verschweigt WordPress manchmal Schwachstellen. Natürlich nur mit den besten Absichten, aber das Gegenteil von „gut gemacht“ ist nun mal bekanntlich „gut gemeint“.

Problem 2: Plug-in-Schwachstellen und -Updates

Bei den Plug-ins und Themes sieht es mit Updates nicht so gut aus. Mal abgesehen vom oben schon angesprochenen Problem, dass man manchmal gar nicht weiß, dass man ein bestimmtes Plug-in/Theme/Package installiert hat, kommt noch dazu, dass manche Plug-ins nur sehr langsam oder auch gar nicht aktualisiert werden. Ein Beispiel für Letzteres ist das Plugin „Event-Registration“, in dem im Mai 2016 sowohl eine SQL-Injection- als auch eine XSS-Schwachstelle gefunden wurden. Über die XSS-Schwachstelle ist die Kompromittierung der Website möglich. So kann z. B. eine Webshell auf dem Server eingeschleust werden. Die Schwachstellen wurden von den Entwicklern nicht behoben, stattdessen wurde das Plug-in vom WordPress Security Team aus dem WordPress Plugin Directory entfernt.

Dann gibt es noch das Problem des wiederverwendeten Codes, durch den eine bestimmte Schwachstelle mehrere Plug-ins betrifft, die dann womöglich erst nach und nach gepatcht werden. Das führt dazu, dass die noch nicht gepatchten Plug-ins in der Zwischenzeit für Angriffe auf eine Schwachstelle anfällig sind, die öffentlich bekannt ist.

Beispiel 1: Missverständnis mit der Dokumentation

Ein zugegebenermaßen nicht ideales Beispiel dazu ist eine XSS-Schwachstelle aufgrund eines Missverständnisses der Dokumentation, von der 2015 eine ganze Reihe von Plug-ins betroffen waren. Die offizielle Entwicklerdokumentation von WordPress war bei der Beschreibung der Funktionen add_query_arg() und remove_query_arg() etwas unklar. Das führte dazu, dass manche Entwickler der Meinung waren, dass die Eingabe der Funktionen von WordPress bereinigt werde. Das ist aber nicht der Fall, sodass darüber aufgrund der fehlenden Bereinigung XSS-Angriffe möglich waren.

Alle bekanntermaßen betroffenen Plug-ins wurden von ihren Entwicklern gepatcht und die Updates im Rahmen einer koordinierten Veröffentlichung alle gleichzeitig veröffentlicht. Die Plug-ins, die bei der Suche nach betroffenen Plug-ins möglicherweise übersehen wurden, waren danach weiterhin angreifbar. Zum Glück dürften das nicht sehr viele gewesen sein, denn um zu prüfen, ob ein Plug-in betroffen ist oder nicht, muss der Sourcecode nur im ersten Schritt nach Aufrufen der betroffenen Funktionen durchsucht werden, um dann im zweiten Schritt zu prüfen, ob die Eingaben gefiltert werden (= nicht betroffen) oder nicht (= betroffen). Dabei waren die Sicherheitsforscher hoffentlich so erfolgreich, dass für die Cyberkriminellen nichts mehr übrig blieb.

Beispiel 2: Das Plug-in „Slider Revolution“

Ein besseres Beispiel ist eine Schwachstelle im Plug-in „Slider Revolution“, über die ein Angreifer auf die Konfiguration zugreifen und dort die Zugangsdaten für die WordPress-Datenbank ausspähen konnte. Die Schwachstelle wurde im Februar 2014 behoben, das aber nicht ausreichend bekannt gemacht – aus Sicherheitsgründen, denn man wollte den automatischen Updates mehr Zeit verschaffen und die Cyberkriminellen nicht auf die Angriffsmöglichkeit aufmerksam machen. Kommt Ihnen das nicht auch bekannt vor?

Das Plug-in wird von vielen WordPress Themes verwendet und ist dort im Allgemeinen fest integriert, sodass es im Theme aktualisiert werden muss. Diese Aktualisierung ist oft aber nicht vorgenommen worden, sodass im September 2014 noch viele Websites eine verwundbare Version des Plug-ins verwendeten. Sie wurden dann Opfer von Angriffen, da Exploits für die Schwachstelle in Untergrundforen kursierten. Das führte dann im Dezember 2014 zu einer Schadsoftwarewelle, in der über 100 000 WordPress-Websites für Drive-by-Infektionen präpariert wurden.

Problem 3: Bösartige Plug-ins

Plug-ins mit Schwachstellen sind schlecht. Aber Plugins, die von Haus aus Schadfunktionen enthalten, sind noch viel schlimmer. Im September 2017 warnte sucuri vor einem gefakten Sicherheits-Plug-in, das eine Hintertür enthält. Das Plug-in mit dem Namen „X-WP-SPAM-SHIELD-PRO“ ist nicht im offiziellen Plug-in-Bereich von WordPress enthalten; woher es stammt, haben die Forscher sicherheitshalber nicht verraten. Generell sollten Sie Plug-ins nur aus einem offiziellen Verzeichnis laden. Das schützt aber auch nicht immer vor einem bösartigen Plug-in, wie das zweite Beispiel zeigt. Ebenfalls im September 2017 warnte Wordfence vor dem offiziellen Plug-in „Display Widgets“, das in der aktuellen Version sowie in den zwei Versionen davor eine Hintertür enthält. Doch auch zuvor ist es schon negativ aufgefallen, weshalb es auch aus dem Plug-in-Verzeichnis von Word-Press flog.

Fazit

WordPress ist gefährdet. Nicht, weil es besonders unsicher ist, sondern weil es zum einen extrem weit verbreitet ist und das zum anderen dazu führt, dass es immer veraltete und damit unsichere Installationen gibt. Diese sind dann ein leichtes und verlockendes Ziel für die Cyberkriminellen. Und was die wollen, ist klar: Geld verdienen. Entweder direkt, indem sie über Ransomware die Websitebetreiber erpressen, oder indirekt, indem sie die WordPress-Websites für Driveby-Infektionen, bösartige SEO oder Ähnliches nutzen und darüber Geld verdienen. Was kann man dagegen tun?

Nun, zunächst mal WordPress Core, Themes und Plug-ins immer aktuell halten, damit man nicht Opfer eines Angriffs auf eine eigentlich schon behobene Schwachstelle wird. Das schützt natürlich nicht vor Angriffen auf bisher unbekannte Schwachstellen wie z. B. die XSS-Schwachstelle im genericons-Package. Deshalb ist es wichtig, den Server zu härten, wie es z. B. von WordPress selbst oder sucuri beschrieben wird. Und wenn es zum Äußersten kommt und der Server kompromittiert wurde, gilt es, besonnen, aber zügig zu handeln. Wie, beschreibt z. B. WordPress selbst. Sehr hilfreich ist es dann, ein möglichst aktuelles Backup zur Verfügung zu haben – und zwar nicht auf dem Server, auf dem es womöglich auch kompromittiert oder beschädigt wurde.

PHP Magazin

Entwickler MagazinDieser Artikel ist im PHP Magazin erschienen. Das PHP Magazin deckt ein breites Spektrum an Themen ab, die für die erfolgreiche Webentwicklung unerlässlich sind.

Natürlich können Sie das PHP Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -