Meine Schwachstelle, für alle Welt sichtbar!

Samstagmorgen hatte ich eine Mail im Postfach bei der ich zuerst dachte, dass es sich um Spam handelt. Sah ein wenig komisch aus und hatte auch noch einen für mich unbekannten Anhang. Sie stammte angeblich von Open Bug Bounty (eine mir bislang völlig unbekannte Seite) und wies mich darauf hin, dass für www.beimchristoph.de eine Sicherheitslücke gemeldet wurde. Zu allem Überfluss von jemandem, der sich “Cyber_India” nennt. Alles sehr verdächtig.

Nach etwas Recherche stellte sich diese Mail aber tatsächlich als legitim heraus. Die Seite ist echt, der Inhalt ebenfalls. Cyber_India hatte tatsächlich bei mir und >15.000 anderen deutschen Webseiten eine oder mehrere Sicherheitslücken gefunden. Vermutlich hat er irgendeinen Bot benutzt und auf Seiten mit WordPress losgelassen, um altbekannte und relativ einfach zu findende Lücken zu prüfen. Dieser Eindruck bestätigte sich, als ich ihn nach den Problemen bei Beim Christoph fragte. Gefunden hatte er drei Sachen:

Debug-Log

Wenn der Debug-Modus von WordPress angeschaltet ist, dann erzeugt dieser eine Log-Datei. Die hat einen vordefinierten Namen und einen allseits bekannten Ablageort. Sie enthält interne Informationen wie z.B. das Server-Verzeichnis, die ggf. jemand mit unlauteren Absichten missbrauchen könnte.

In meinem Fall hatte ich diesen Debug-Modus scheinbar am 29. November 2014 mal über die wp-config.php kurz aktiviert. Entsprechend lag eine (sehr kurze) Log-Datei im Verzeichnis wp-content rum. Die Lösung des Problems war also simpel: Datei gelöscht, Sicherheitslücke geschlossen.

REST-API

Hier muss der Code hin, um den Zugriff zu unterbinden.

Die REST-API ermöglicht die Kommunikation mit der von WordPress genutzten MySQL-Datenbank und ist grundsätzlich wohl wichtig für die Funktionen des Content Management Systems. Standardmäßig ist diese API nach außen für jeden offen (https://ihredomain.de/wp-json/), was scheinbar schon so einige Diskussionen im WordPress-Forum nach sich gezogen hat. Technisch gesehen ist es aber wohl keine Sicherheitslücke, weil alle Informationen, die man darüber abfragen kann auch ganz normal über die jeweilige Webseite zu finden sind.

Im konkreten Fall hat Cyber_India mich darauf hingewiesen, dass man sich über den Link “https://www.beimchristoph.de/wp-json/wp/v2/users” alle auf der Seite registrieren User anzeigen lassen kann, die schon einmal einen Beitrag veröffentlicht haben (inkl. ihrer ID und ihrem Icon). Sah ich grundsätzlich erstmal nicht als so kritisch an, da es eben alles nur Autoren sind und die Informationen entsprechend über die Einträge sowieso sichtbar sind. Aber im Sinne des Datenschutzes muss man es ja den Leuten nicht allzu einfach machen.

Am schnellsten ist das Problem durch die Installation eines der vielen Plugins zu lösen. Aber da ich schon mehr als genug Plugins auf der Seite nutze, habe ich stattdessen den Code angepasst – der hoffentlich nicht beim nächsten Core-Upgrade wieder ersetzt wird…

Die Anleitung dazu gibt es ganz offiziell hier. Den dort hinterlegten Code einfach in der Datei wp-includes/rest-api/class-wp-rest-server.php im Abschnitt “public function check_authentication()” einfügen. Das führt dazu, dass die API nur noch für angemeldete Nutzer zur Verfügung steht. Alle anderen bekommen einen 401 (=fehlende Autorisierung) ausgespuckt. “Sicherheitslücke” 2 geschlossen.

XML-RPC

Während die REST-API für interne WordPress-Prozesse gebraucht wird, ist die XML-RPC eine Schnittstelle nach außen. Sie erlaubt es Dritten mit einer WordPress-Seite zu interagieren z.B. einen Beitrag zu veröffentlichen oder Dateien hochzuladen. Das ist mitunter praktisch, wenn man beispielsweise seine Einträge wie ich nicht direkt auf der Seite schreibt, sondern eine andere Art von Editor nutzt. Dank der XML-RPC-Schnittstelle kann man dann direkt aus dem jeweiligen Programm heraus den Beitrag online bringen. Kein Copy & Paste notwendig. Microsoft Word hat diese Möglichkeit meines Wissens nicht andererseits will ich gar nicht wissen welcher HTML-Code entstehen würde, wenn ich Word direkt auf WordPress loslassen würde…

Nachteil dieser Schnittstelle ist allerdings, dass sie als Eingangstor für diverse Attacken dienen kann. Darunter klassische Denial-of-Service (DDoS)-Angriffe, um den Server in die Knie zu zwingen. Aber auch so Sachen wie Cloudflare Protection Bypass, die es ermöglichen eigentlich geschützte IP-Adressen zu finden oder Cross Site Port Angriffe (XSPA) mit denen man offene Ports entdeckt. Also tatsächlich nicht ganz ohne die Sache und leider ist in einer WordPress-Standard-Installation für jeden diese Schnittstelle offen zugänglich. Zwar nur im lesenden Modus aber eben exponiert und bereit von Anfragen überwältigt zu werden.

Wie bei der REST-API ist die Lösung schlicht und einfach das Ding zu deaktivieren, wenn man es tatsächlich nicht braucht. Das funktioniert über einen zusätzlichen Eintrag in der .htaccess:

# BEGIN protect xmlrpc.php
<files xmlrpc.php>
order allow,deny
deny from all
</files>
# END protect xmlrpc.php

Wenn jetzt jemand versucht die API anzusprechen wird er gnadenlos mit einem 403 (Verboten) abgespeist. Eine andere Variante wäre denjenigen, der die API anfragt, einfach auf die Webseite umzuleiten.

Die Interaktion

Cyber_India hat mich also auf meine Nachfrage über drei Probleme informiert (inkl. Lösungsvorschläge) und ich habe sie umgehend sowohl hier als auch bei Lysanda gefixt. Aber natürlich hat das Cyber_India nicht nur aus dem Guten seines Herzens gemacht. Kann ich nachvollziehen, schließlich müssen wir alle von etwas leben. Er behauptet ein Student zu sein, der zum Offensive Security Certified Professional (OSCP) werden möchte und dafür Geld sammelt. Das Zertifikat (PEN-200) ist wohl sehr hoch angesehen in der IT-Welt, weil es voll auf Praxis setzt und schlägt mit mindestens $999 zu Buche – je nachdem wie lange ihr Zugang zum Computerlabor benötigt, um die Aufgaben zu erledigen.

Zumindest ein paar grüne Häckchen!

Er bat mich also pro Report (zur Erinnerung: drei Stück) $50-$250 auf sein PayPal-Konto zu überweisen. Und machte auch gleich noch Werbung dafür ein vollständiges Vulnerability Assessement Penetration Testing (VAPT) für Beim Christoph durchzuführen – natürlich zum “besten” Preis (der ungenannt blieb). Wie ihr sicherlich schon vermutet: Ich habe ihm definitiv keine $150 und schon gar nicht $750 überwiesen und ein VAPT sehe ich für die Seite ebenfalls nicht als relevant an. Selbst, wenn ich hiermit Geld verdienen würde: Die Kritikalität der “Lücken” war äußerst überschaubar und sie sind bereits seit Jahren überall bekannt. Gleichzeitig hat er wie oben geschrieben innerhalb eines Tages tausende von Seiten vermutlich alle mit denselben Problemen gemeldet. Hätte ich freilich genauso gemacht. Masse machts und für den Roboter hat er garantiert nicht viel Aufwand gebraucht. Undankbar wollte ich also zwar nicht sein, aber belohnen wollte ich ihn dafür jetzt auch nicht unbedingt. Meine Lösung? Ich hab‘ ihm als Dank $10 (aktuell 9€) geschickt. Vermutlich immer noch zu viel aber man will ja nicht ganz unverschämt gegenüber einem sein, der potentiell die Möglichkeit hat schlimme Dinge mit der eigenen Webseite anzustellen .

Noch ein bisschen mehr Sicherheit

Da ich sowieso gerade im Code unterwegs war, habe ich mich auch mal wieder mit ein paar anderen Sicherheitsthemen beschäftigt. Ja, ich hatte damals für die DSGVO nicht alles gemacht, was theoretisch möglich und empfohlen ist. Schlicht und einfach, weil ich es nicht hinbekommen habe oder noch nicht wusste.

In letztere Kategorie fällt die sogenannte “Permissions Policy” (alt “Feature Policy”). Über diesen Header lässt sich regeln, welchen Seiten/Inhalten es erlaubt ist z.B. Zugriff auf eure Kamera oder eure Geolokation zu bekommen. Das macht Beim Christoph zwar sowieso nicht aber es von Haus zu unterbinden ist nie verkehrt. Dementsprechend habe ich meine .htaccess ergänzt:

Header always set Permissions-Policy: "geolocation=(), midi=(), camera=(), usb=(),
payment=(), vr=(), speaker=(), ambient-light-sensor=(), gyroscope=(), microphone=(), usb=(), interest-cohort=()"

“()” bedeutet: Nichts kann um Erlaubnis fragen und nichts kann sie bekommen. So soll das sein.

Das zweite Thema ist die sogenannte “Content Security Policy” (CSP). Hier geht es darum festzulegen welche Inhalte von wo welcher Quelle zulässig sind und welche nicht. Daran die möglichst restriktiv – also am besten ist ausschließlich www.beimchristoph.de eine zulässige Quelle – hinzubekommen bin ich in der Vergangenheit immer wieder gescheitert. Und auch dieses Mal war ich wieder nicht vollumfänglich erfolgreich aber immerhin zu 70% (7 von 10 Einschränkungen gesetzt) lt. webbkoll. Mehr Parameter und die Seite fing an in Teilen oder sogar überhaupt nicht mehr zu funktionieren. Also beispielsweise die WordPress-Editoren im Hintergrund, irgendwelche Plugins oder die eingebundenen YouTube-Videos. Ein paar Einschränkungen sind vermutlich schlicht nicht möglich (z.B. setzt WordPress so einige Berechtigungen voraus), bei anderen fehlt mir hingegen weiterhin das notwendige Wissen, um es richtig zu machen. Aber 70% ist schon mehr als die bislang 0% . Neu in der .htaccess ist entsprechend nun der folgende Satz:

Header set Content-Security-Policy: "frame-ancestors 'self'; base-uri 'self'; form-action 'self'; object-src 'none';"

Diese Policy führt im Prinzip dazu, dass ausschließlich Inhalte von meiner Seite geladen werden (“self”) dürfen oder im Falle der “object-src” sogar nicht einmal das, da ich weder Java noch Flash einsetze. Was jetzt noch fehlt sind “script-src”, “style-src” und “default-src”. Aber speziell letzteres macht in jeder Einstellung die Seite komplett unbrauchbar. Keine Ahnung wer da querschießt und dann keinen Zugriff mehr auf seine Dateien hat. Schließlich liegt ja alles auf meinem Server und es gibt soweit mir bekannt keinerlei Anfragen an Drittparteien solange man nicht auf ein YouTube-Video klickt. Aber irgendwann finde ich es bestimmt mal raus.

Epilog

Nun aber genug davon, wie ich meinen Samstag verbracht habe. War mal wieder was anders aber ab und zu mal im Code zu wühlen finde ich ja durchaus ganz nett. Da lernt man immer mal wieder was Neues oder bleibt zumindest frisch. Für euch gilt auf jeden Fall: Ihr könnt euch sicher sein, dass ihr hier Beim Christoph weiterhin sicher seid und ich ständig im Hintergrund daran arbeite, dass ihr auch sicher bleibt . Und nein, das war jetzt keine Aufforderung an alle mitlesenden Black Hats mir das Gegenteil zu beweisen *setzt den Bambi-Blick auf*.