Nichts ist sicher. Deshalb müssen wir wohl oder übel auch die Diskussion über die WordPress Sicherheit führen. Zum Anlass nehme ich den gerade erschienen Blogpost von Wordfence, der beschreibt woher Sicherheitslücken überhaupt kommen. Und am Ende möchte ich zeigen, dass sich nicht immer der Programmierer schuldig fühlen muss.

Wie erlangen Hacker Zugriff WordPress?

Über Plugins (und über Bruteforce Attacken, aber darauf will ich hier nicht eingehen)! Ja, das ist, was Wordfence uns im aktuellen Blogbeitrag zu sagen versucht. Demnach sind nicht etwa die schlechten Passwörter für WordPress, FTP oder MySQL schuld. Nein. Es liegt mit ca. 55%iger Wahrscheinlichkeit an Plugins.

Da ist natürlich eine brutale Aussage. Gerade für jemanden wie mich der eigentlich Tag für Tag nichts anderes mehr macht als Plugins zu schreiben. Was mich an dieser Stelle also am meisten interessiert sind folgende Fragen:

• Welche Plugins sind das?
• Warum sind es nur Plugins?
• Warum sind Themes nicht so krass betroffen?
• Was kann man dagegen tun?

Dass Plugins am ehesten betroffen sind, steht erst einmal im Raum. Ganz unabhängig ob die Umfrage, an derer lt. Wordfence 1032 Menschen teilgenommen haben, repräsentativ ist. Es lohnt sich dennoch, einen Blick darauf zu werfen. Denn Sicherheit betrifft uns letztlich alle. Egal ob Programmierer oder Benutzer.

Warum trifft es Plugins am häufigsten?

Meines Erachtens gibt es mehrere Möglichkeiten. Diese müssen aber nicht alle immer zutreffen.

• Erstens: Sicherlich ist die schier unendliche Auswahl an Plugins eine Möglichkeit. Das ganze Repository ist sehr unübersichtlich und für den Endbenutzer da draußen ist es nicht sofort ersichtlich, ob ein Plugin sicher ist oder nicht. Letztlich gehen wir sowieso nur her und installieren es ohne den Code vorher zu prüfen, oder?
• Zweitens: es gibt sehr viele alte Plugins die einmal erstellt aber niemals mehr geupdatet worden sind. Aufgrund der guten Abwärtskompatibilität funktionieren diese immer noch und werden letztlich weiter verwendet.
• Drittens: Es ist sicherlich nicht immer nur “guter Code” in den Plugins versteckt. Immerhin kann jeder innerhalb von 60 Sekunden sein eigenes Plugin erstellen.
• Viertens: Nicht immer ist die Schuld beim Programmierer zu suchen. Viele Menschen wollen schlicht oft auch kein Geld für gute Plugins ausgeben und/oder laden diese von nicht vertrauensvollen Websites herunter.
• Fünftens: Der Quellcode ist offen. Jeder kann sich einlesen. Und damit auch Hacker. Sicherheitslücken sind letztlich sofort sichtbar, wenn man ein bisschen danach sucht. Mich würde es nicht wundern, wenn es systematische Methoden gibt, die das Subversion-System des WordPress-Plugin-Repositories durchsuchen. Klar, OpenSource ist klasse, wenn viele Menschen daran gleichzeitig arbeiten (wie am WordPress Core selbst). Das funktioniert aber nicht bei jeder Software so gut.

Welche Plugins trifft es am häufigsten?

Darüber schweigt sich Wordfence leider aus. Ich glaube, dass es natürlich immer die populären Plugins sind. Wir haben ja in der Vergangenheit gesehen, dass Plugins wie VisualComposer oder der Divi Builder darunter waren. Warum sollte ein Hacker sich auf ein Plugin einschießen, welches “nur” 1000 mal installiert wurde? Das macht aus meiner Sicht nicht wirklich Sinn.

Warum sind Themes nicht (so sehr) betroffen?

Das ist eine sehr gute Frage. Letztlich haben sie (meines Erachtens) mit den selben Problemen zu kämpfen. Ist vielleicht die Bereitschaft, für Themes Geld auszugeben, ein möglicher Grund? Oder ist das gar nicht der Fall? Ist die Umfrage von Wordfence hier etwas verfälscht?

Was kann man tun um sich zu schützen?

Keine alten Plugins mehr nutzen

Wordfence empfiehlt, keine Plugins zu installieren, die seit mehr als 6 Monate nicht mehr aktualisiert wurden. Ich sehe da zwei Probleme:

• Wie kann der User da draußen das erkennen? Nur weil im Plugin-Verzeichnis steht, dass es aktualisiert wurde, heißt das nicht, dass es wirklich aktualisiert wurde. Ein sehr schönes Beispiel ist das W3Total Cache Plugin, welches mehr als 5,5 Millionen mal heruntergeladen wurde. Wie WP-Tavern berichtete, wurde es schon seit 7 Monaten nicht mehr geupdatet. Das einzige, was gemacht wurde, ist die readme.txt-Datei anzupassen. Im Plugin-Verzeichnis steht dann, dass das Plugin aktualisiert wurde.
• Muss ein Programmierer immer so oft updaten? Sind wirklich die Programmierer schuld? Aus meiner Sicht läuft ein Plugin, wenn es mal läuft. Ohne großen Feature-Zuwachs gibt es oft keinen Grund, ein Plugin weiter anzupassen.

Keine Plugins von dubiosen Quellen herunterladen

Ich glaube, dieser Schritt ist ziemlich klar. Aber auch hier gilt: wie kann der User da draußen das erkennen? Eine wirkliche Sicherheit gibt es nie. Auch wenn man noch so aufmerksam ist. Wordfence empfiehlt einen “Augentest”. Fragen wie: “Ist die Seite professionell designt?” oder “Gibt es ein gültiges Impressum?” sind hier sehr hilfreich. Auch eine Suche mit “{Plugin Name} +vulnerability” kann mitunter helfen in Kürze herauszufinden, ob ein Plugin schon einmal von einer Sicherheitslücke betroffen war. Ob das ganze natürlich einen Benutzer davon abhält, den VisualComposer oder den Divi-Builder zu nutzen, weiß ich nicht. Gerade diese zwei Plugins sind unter den Webseiten-Betreibern sehr beliebt.

Updaten, update, updaten!

Ein simpler aber oft sehr wirkungsvoller Schritt. Und trotzdem funktioniert er oft einfach nicht. Ist es die Angst, dass es irgendwas “zerschießt” oder geht irgendwann einfach das Interesse an der eigenen Seite verloren? Dazu gab es vor ein paar Tagen einen sehr schönen Tweet zum Thema, der schier unglaublich erscheint:

Aus dem Alltag einer Webagentur… Heute: Welche Version ist das? #WordPress #OldieButGoldie pic.twitter.com/CIXAthkSIv

— Birgit Olzem (@CoachBirgit) March 22, 2016

Da war doch glatt Version 2.0.11 noch im Einsatz.

Fazit

Ja. Schön zu wissen, dass nicht nur Programmierer an diesem Schlamassel Schuld sind, oder? 😉 Was kann man dafür, wenn Plugins für von dubiosen Quellen geladen werden? Scherz beiseite. Letztlich kann man niemanden direkt die Schuld geben. Sicherlich ist nicht jeder Code einwandfrei und ich habe bei weitem auch schon schlechten Code gesehen (ja, auch von mir selbst). Aber mit jedem Tag kann man ein Stückchen besser werden. Wie Tom McFarlin in seinem letzten Blogpost so schön geschrieben hat:

“(…) the first thing to note is that everyone’s work sucks at first. Everyone’s. I don’t know a single programmer who looks back at the things they were working on early in their career and thinks: Man, I can’t believe I wrote such fantastic code when I first started out.”

Und:

“(..) humans are also incredibly well at adapting.”

Sicher ist, dass nichts sicher ist. Die Benutzer draußen müssen mehr sensibilisiert werden. Und der Programmierer muss besser werden. Deswegen sollten wir – richtig – einfach die Augen offen halten und uns Gedanken machen, wenn wir das Gefühl haben, wenn etwas nicht stimmt.