Jeder fremde Code hat Zugriff auf alle Ressourcen

Plugins bergen im WordPress Universum die größte Gefahr, weil jede Zeile Code eine potenzielle Sicherheitsgefahr ist.

Eine Sicherheitsgefahr,die zuvor erst überprüft werden muss.
Diesmal wollen wir aber keine Plugins und deren Code durchleuchten, sondern aufzeigen, wieso es so gefährlich ist wenn ein Angreifer an irgendeiner Stelle im PHP Code Schreibrechte erlangt.

Angriffsvektoren gibt es viele: Skripte, die in die Datenbank kommen, Dateiupload, bei dem die Datei am Server ausgeführt wird oder einfach jeglicher Userinput, der an irgendeiner Stelle eingegeben/übermittelt werden kann.

Kurze Demo

Als Veranschaulichung gibt es ein bisschen Code.

Für diese Demo nehmen wir an, dass der Angreifer im „Footer“ von WordPress Schadcode einfügen kann.
In diesem Fall haben wir auf jeden Fall verloren, weil der Angreifer auf so gut wie alles Zugriff erlangt!

Über „get_defined_vars()“ kann ich beispielsweise bereits alle globalen WordPress Objekte auslesen!

Beispielsweise kann ich direkt die Datenbank-Details auslesen und erlange kann mich anschließend selbst mit der Datenbank verbinden.

file_get_contents()

Sobald ich Code ausführen kann, kann ich auch auf jede Datei zugreifen.

Sobald ich Zugriff in einem File erlangt habe, kann ich zum einen jede beliebige andere PHP Datei mit „require“ einbinden, zum anderen kann ich auch mit „file_get_contents“ auch ideal alle Variablen-Werte auslesen.

$content = file_get_contents( path_to_file . "Class.php");  $tokens = token_get_all($content);  echo $token[120][1];

Eine sehr einfache Methode ist beispielsweise die oben gezeigte Kombination aus „file_get_contents“ und „token_get_all“. Mit der ersten Funktion kann ich mir den gesamten Inhalt der Datei holen, mit „token_get_all“ kann ich anschließend Variablen-Werte an bestimmter Stelle auslesen.

exec, shell_exec…

Das Auslesen von Dateien ist nur der Anfang. Schlimmer können Shell-Zugriff sein!

Natürlich erlange ich auch direkten Shell-Zugriff und kann so beliebige Serveraktionen ausführen – beispielsweise alle Medien vom Server holen.
Ich erlange vollen Zugriff zum Server. Hier kann man zumindest noch entgegen wirken, indem man diese Funktionen mit Shell-Zugriff in der php.ini Datei explizit nicht erlaubt.

SQL Befehle ausführen

In jeder PHP-Datei kann ich auf die Datenbank-Zugangsdaten zugreifen.

Man erlangt logischerweise auch im Footer Schreibrechte für die Datenbank – einfach weil man die SQL Statements selbst ausführen kann!
Somit kann man seine eigenen SQL Befehle ausführen um wieder an anderer Stelle Schadcode auszuführen.

Stichwort stored injections.
Viele Sicherheitslücken in letzter Zeit betrafen diesen Angriffsvektor. Schadcode, der sich in der Datenbank befindet und dann im Frontend ausgeführt wird.

Logging

Den Zugriff merkt man nicht immer! Daher sollte man Maßnahmen setzen.

Bei all den erwähnten Attacken wird man wohl früher oder später bemerken, dass jemand Zugang zum Code erlangt hat.
Man könnte aber auch ohne weiteres Daten des Servers mitloggen, z.B. wer sich zu welcher Zeit einloggt, oder private Userdaten direkt an einen externen Service übermitteln.

Kurzum

Ein einmaliger Zugriff mit Schreibrechten erlaubt dem Angreifer vollen Zugriff auf den Server.

Jede nur erdenkliche Attacke ist daher möglich und das sollte uns einmal mehr nachdenklich stimmen, welche externen Plugins wir uns installieren.

Aber nicht nur das: Auch unser eigener Code muss entsprechend abgesichert sein!
Methoden um die eigenen WordPress Plugins sicherer zu gestalten, sollen in der „Security“ Reihe auf WP-Entwickler laufend erweitert werden. Stay Tuned!