bueltge.de [by:ltge.de] » Sicherheitslücke

WordPress gehackt - was tun, eine Schnellhilfe

Frank Bültge — Fri, 16 Apr 2010 19:10:48 +0000

... die keinen Anspruch auf Vollständigkeit erhebt und mal eben dem einen oder anderen Leser dienen soll und getrieben aus gegebene Anlass. Das Hacken von Blogs ist keine Eigenart von WordPress Blogs - dies kann jedem CMS passieren. Ebenso kannst du dir nicht sicher sein, dass du nicht betroffen bist, nur weil du irgendein Plugin aktiv hast und weil du die aktuellste Version von WordPress fährst.

Wobei es hier keine Diskussion werden soll, ob WordPress mehr als andere Applikation betroffen ist oder anfälliger ist. Die Unterschiede sind weitreichend - Schwachstellen gehören zur Software und die meisten Standard-Tools sind nur für das Gewissen oder den Geldbeutel.

Es gibt verschiedene Erkennungsmerkmale, einige sollen helfen:

Ein Problem nennt man Code Injection, Base 64 codierte Inhalte, meist PHP, in deine Dateien.
Popups, Bilder, Frames, Links im Frontend
Unbekannte Links im Source des Frontend
HTML Code in den Tabelle options von WordPress
Rechte größer 644 sind ein Risiko und meist wollen viele Plugins 755

Folgende Links können helfen:

Folgende Schritte sind anzuwenden, wenn das Blog gehackt wurde und man nur rudimentäre Kenntnisse in WordPress, PHP und mySQL hat. Alle mit dem nötigen Wissen werden gezielter vorgehen.

Nutze die Export-Funktion von WordPress und sichere deine Inhalte damit
Export der Datenbank-Inhalte und sichern
Sichere die wp-config.php
Sicherung des Ordners wp-content mit allen Inhalten
Prüfe die wp-config.php auf korrekten Inhalt und die Rechte auf dem Webspace, 644 reicht aus
Prüfe die Inhalte des Ordners wp-content - plugins, themes, uploads - auf richtige Inhalte
Ändere alle Passwörter: WP Backend (besser neuen User anlegen und Inhalte übernehmen, so ändert sich die ID), FTP Zugang (Achte auf starke Passwörter)
Ist die Datenbank das Problem, dann gilt es jede Tabelle zu überprüfen, insbesondere die Tabelle options, beschränke dich vorerst auf die WP Standard-Tabellen
Installiere WordPress neu, mit einer neuen Datenbank
Kopiere die Sicherung des gesäuberten Ordners wp-content auf die Neuinstallation
Importiere die Inhalte des bereinigten, falls nötig, WordPress Export-Files und hole so die Inhalte wieder rein (macht das Probleme, dann muss dies via dem SQL Export geschehen, welches du aber ohne die Tabelle options importieren solltest und bereinige auch dieses File

Überprüfe das Blog mit diversen Tools, nutze die Möglichkeiten, die die obige Artikel aufzeigen und nutze die Macht der .htaccess und der Rechtevergabe

Beispiele der Sicherung in der .htaccess


# PROTECT wp-config.php

 Order deny,allow
 deny from all


# PROTECT wp-login.php with password on .htpasswd

 AuthName "Admin-Bereich"
 AuthType Basic
 AuthUserFile /www/htdocs/w0123123/.htpasswd
 require valid-user


# PROTECT readme.html

 Order Allow,Deny
 Deny from all
 Satisfy all


# PROTECT liesmich.html für DE Edition

 Order Allow,Deny
 Deny from all
 Satisfy all


# PROTECT install.php

 Order Allow,Deny
 Deny from all
 Satisfy all

Beispiel .htaccess in WP Basis

Danke für das Abonnieren meines Feed! Inhalt gefällt? Danke sagen · Kommentieren

WordPress Plugins für mehr Sicherheit

Frank Bültge — Mon, 14 Apr 2008 10:41:30 +0000

In den letzten Tagen und Wochen wurden vermehrt Weblogs gehackt, die mit WordPress betrieben werden. Die Ursachen können sehr unterschiedlich sein, einer der letzten Punkte waren angreifbare freie Themes.

Ich wünsche, dass die Nutzer durch solche Themen sensibler werden und nicht blind jedes Plugin oder Theme in ihr Live-System kopieren und nutzen.

Ein ganz anderer Punkt ist die Sicherheit zu erhöhen, dass kann man mit einigen Punkte in der Installation, die ich hinreichend in den Artikeln „WordPress sicherer machen“ und „WordPress Templates sicherer machen“ erläutere.

Im weiteren haben sich aber auch eine ganze Reihe an Plugin-Autoren um die Sicherheit bemüht und entsprechende Plugins veröffentlicht.

Eine ausführliche Liste mit Hintergründen zu den Plugins hat speckyboy.com veröffentlicht. In jeden Fall eine Lese-Empfehlung.

Update: Weitere Plugins

WP-Adminprotection
Login LockDown
DigoWatchWP
Hash Checker
Postlogger
Secure WordPress - im laufe dieser Aktionen entstanden und erschwert es unerlaubten Personen Informationen zu erhalten
WordPress Exploit Scanner Scannt die Datenbank oder die Dateien nach klassischen Hack-Eingriffen, zum Beispiel Spamlinks im Theme.

Danke für das Abonnieren meines Feed! Inhalt gefällt? Danke sagen · Kommentieren

Sicherheitsloch in WordPress 2.5

Frank Bültge — Tue, 01 Apr 2008 08:24:19 +0000

Da ist sie, die erste große Lücke. Thomas weist auf eine Sicherheitslücke in der Funktion ignore_user_abort() hin, die sich mit einem einfach Fix im Theme beheben lässt.

Es gilt lediglich in die header.php des verwendeten Themes den folgenden Syntax zu schreiben und die Standardkonstante von WP neu zu setzen.

... direkt nach dem body-Tag.

Wichtig - Website besuchen und Fix kontrollieren.

Update: 2.April 2008

April, April!

Danke für das Abonnieren meines Feed! Inhalt gefällt? Danke sagen · Kommentieren

TextLinkAds WordPress Plugin mit Sicherheitslücke

Frank Bültge — Thu, 17 Jan 2008 11:49:20 +0000

BlogSecurity weist auf eine Sicherheitslücke im Plugin von TextLinkAds hin.

Schon Michael empfand das Plugin als unseriös und berichtet im Artikel „Text Link Ads verliert Seriösität“ warum und wieso er dieser Meinung ist.

TLA wird von vielen WordPress Usern in der Form als Plugin genutzt, obwohl es unnötig ist. Das Script für den Zugriff auf die XML-Datei kann extra im Theme-Ordner abgelegt werden und mittels einer einfachen include-Anweisung eingebunden werden. Damit können zwar immer noch Lücken entstehen, aber der Zugriff auf die Datenbank ist nicht gegeben.


Wer also das Plugin im Einsatz hat - Sicherheitslücke schließen! BlogSecurity erklärt wie es geht.

Fix information:
The vulnerable code is found on line 512:

$postId = $postId;

This variable is passed to $wpdb->get_results without being sanitised.

to fix this hole, simply change the above line to:

$postId = (int) $postId; /* FIXED */ 


 © Frank Bültge, All rights reserved / Alle Rechte vorbehalten. (ID: 6e8b33de4342c4f2ca76b245199aeee8)
Danke für das Abonnieren meines Feed! Inhalt gefällt? Danke sagen · Kommentieren



Schwachstelle in Cookie-Authentifizierung von WordPress
Frank Bültge — Tue, 20 Nov 2007 13:40:48 +0000
Durch einen Design-Fehler in der Authentifizierung der Blogsoftware WordPress kann ein Angreifer einfacher als gedacht ein System kompromittieren. Die meisten Content-Management-Systeme und Blogs speichern die Passwörter der Anwender als Hashes in der zugrundeliegenden Datenbank. Erhält ein Angreifer etwa über eine SQL-Injection-Lücke Zugriff auf die gespeicherten Hashes in der Datenbank, kann er damit zunächst nichts anfangen. Um an das ursprüngliche Passwort zu gelangen, muss er den Hash beispielsweise mit den Einträgen einer sogenannten Rainbow-Table vergleichen. Unter Umständen kann dies einige Zeit in Anspruch nehmen, bei langen Passwörtern kann dies auch gänzlich scheitern, da die Tabellen dafür noch nicht vorbereitet sind.
Unter WordPress kann sich der Angreifer laut eines Berichtes von Steven J. Murdoch von der Universität Cambridge aber eine Eigenheit zunutze machen, um ohne Passwort den Zugriff zu erhalten. Dazu bastelt er sich anhand des Hashes einfach ein Authentifizierungs-Cookie und verwendet diesen bei Zugriffen auf das System. Laut Murdoch, der auch zum Kernteam des Anonymisierungsprojektes The Onion Router (TOR) gehört, muss man dafür nur den ausgelesenen MD5-Hash nochmals mit MD5 hashen. Das von WordPress zur Authentifizierung benutzte wordpresspass-Cookie hat dann laut Bericht den Aufbau:
wordpresspass_=MD5(user_pass)
wobei die URL offen einsehbar ist und user_pass dem Hash (MD5(password)) entspricht. Zusammen mit dem wordpressuser-Cookie (wordpressuser_=admin) soll dann der Zugriff auf den Admin-Account von WordPress möglich sein. Die Entwickler von WordPress sollen über das Problem informiert sein, bislang aber noch nicht reagiert haben.

Nach Angaben von Murdoch wird der Designfehler schon aktiv ausgenutzt. Allerdings lässt er offen, wie die Angreifer an den Passwort-Hash gelangt sind. In der aktuellen Version von WordPress sind keine SQL-Injection-Schwachstellen bekannt. Ältere WordPress-Installationen können jedoch durchaus noch verwundbar sein.
Betroffene Versionen
WordPress 1.5 - 2.3.1 (including current version, as of 2007-11-19)
Quellen

Enrique Bergemann
WordPress Cookie Authentication Vulnerability, Fehlerbericht von Steven J. Murdoch

Weitere Links

http://en.wikipedia.org/wiki/Salt_(cryptography)
http://trac.wordpress.org/ticket/2394
http://www.lightbluetouchpaper.org/2007/11/16/google-as-a-password-cracker/


 © Frank Bültge, All rights reserved / Alle Rechte vorbehalten. (ID: 6e8b33de4342c4f2ca76b245199aeee8)
Danke für das Abonnieren meines Feed! Inhalt gefällt? Danke sagen · Kommentieren



Der erste XSS Wurm für WordPress
Frank Bültge — Wed, 01 Aug 2007 13:09:04 +0000
Wie man die XSS-Lücke ausnutzt und wie man den Wurm indiziert, das erklärt mybeNi. Das ganze basiert auf WordPress Version 2.2.1.
Was man davon halten soll - das muss jeder selbst entscheiden. In jedem Fall lohnt es sich, die Hinweise zu lesen. Es handelt sich um einen „freundlichen“ Wurm, der nur die Lücke aufzeigen will - ein Trost? Schön ist, dass der Wurm dem Admin hilft, die nötigen Lücken zu patchen.
Im weiteren werden alle 7 Lücken erläutert und als Beispiel dargelegt. Die Lücken sind im WP trac registriert und vielleicht erwartet uns bald ein Update. Wer sich händisch an die Arbeit machen will, der liest die Lösungen. In der Regel kommt die WordPress eigene Sicherheits-Funktion attribute_escape() zum Einsatz. Es sind 5 Lücken zu schließen - kurz und bündig im Folgenden.
wp-admin/upload-functions.php Zeile 109

 id="upload-file" method="post" action=""> 

wird zu:

 id="upload-file" method="post" action=""> 

wp-includes/functions.php Zeile 206

function get_option($setting) { 
global $wpdb; 

$setting = $wpdb->escape($setting); 

// Allow plugins to short-circuit options. 
$pre = apply_filters( 'pre_option_' . $setting, false ); 

wp-includes/functions.php Zeile 386

function delete_option($name) { 
global $wpdb; 

$name = $wpdb->escape($name); 

wp_protect_special_option($name);

wp-admin/link-import.php Zeile 76

$cat_id = $_POST['cat_id']; 
if ( $cat_id == '' || $cat_id == 0 ) 

wird zu:

$cat_id = (int) $_POST['cat_id']; 
if ( $cat_id < 1 ) 

wp-admin/edit-comments.php Zeile 78

if ( isset( $_GET['apage'] ) )

wird zu:

if ( isset( $_GET['apage'] ) ) { 
	$page = (int) $_GET['apage']; 
	if($page < 1) 
	$page = 1; 
}


 © Frank Bültge, All rights reserved / Alle Rechte vorbehalten. (ID: 6e8b33de4342c4f2ca76b245199aeee8)
Danke für das Abonnieren meines Feed! Inhalt gefällt? Danke sagen · Kommentieren



Sicherheitslücken im Plugin WP-FeedStats
Frank Bültge — Fri, 13 Jul 2007 20:37:11 +0000
Das Plugin WP-FeedStats weist wohl Sicherheitslücken auf. Es empfiehlt sich, nach Angaben von BlogSecurity das Plugin vorerst zu deaktivieren.
Sollte ich die Probleme finden und beheben können, dann mache ich das natürlich. Dies wird aber sicher nicht gleich und sofort passieren, denn ansonsten wären sie nicht im Plugin aufgetreten.

Ich hoffe auf Verständnis.
Kontaktiert wurde ich allerdings nicht, wie es im Beitrag von BlogSecurity steht, aber dank Trackback-Funktion bin ich eben darauf aufmerksam geworden.


 © Frank Bültge, All rights reserved / Alle Rechte vorbehalten. (ID: 6e8b33de4342c4f2ca76b245199aeee8)
Danke für das Abonnieren meines Feed! Inhalt gefällt? Danke sagen · Kommentieren



WordPress Sicherheitslücke nach Update auf 2.0.6
Frank Bültge — Fri, 12 Jan 2007 10:14:44 +0000
Nach dem vor kurzem das Update auf 2.0.6 veröffentlicht wurde, gibt es erneut Probleme, wobei es diesmal an einem PHP-Problem liegt. Weitere Hinweise und mögliche Berichtigungen mit register_globals sind unter anderem bei Jowra, Michael und Robert zu finden.
Nur als kurzer Hinweis, im englischen Original ist das Feedburner bzw. Feed-Problem auch in der Version 2.0.6 behoben. Kurz nach der ersten Veröffentlichung wurde es nochmals geändert und neu hoch geladen, die Version wurde nicht hoch gezählt. Im deutschen Update 2.0.5 --> 2.0.6 ist dieser Fehler noch drin, so dass man dort folgende Veränderung vornehmen muss.
Achtung: Keine Garantie auf Funktion! Sicherung anfertigen.
Bearbeite die Datei functions.php im Verzeichnis wp-includes und suche folgenden Code (Zeile 2.231):

if ( substr(php_sapi_name(), 0, 3) == 'cgi' )
@header("HTTP/1.1 $header $text");
else
@header("Status: $header $text");

ändern in (die drei Zeilen löschen):

@header("HTTP/1.1 $header $text");

Um nun das aktuelle Problem PHP zu beseitigen sollte folgender Workaround helfen.
In Datei wp-settings.php Zeile 16:

if ( !in_array($k, $noUnset) && isset($GLOBALS[$k]) )
	unset($GLOBALS[$k]);

ändern in:

if ( !in_array($k, $noUnset) && isset($GLOBALS[$k]) ) {
	$GLOBALS[$k] = NULL;
	unset($GLOBALS[$k]);
}


 © Frank Bültge, All rights reserved / Alle Rechte vorbehalten. (ID: 6e8b33de4342c4f2ca76b245199aeee8)
Danke für das Abonnieren meines Feed! Inhalt gefällt? Danke sagen · Kommentieren



Sicherheitslücke in WordPress < 2.0.6
Frank Bültge — Thu, 04 Jan 2007 12:23:15 +0000
Mal wieder wurde eine Sicherheitslücke im System von WordPress entdeckt, der SecurityForus berichtet. Das Problem wird als Hoch (7.0) eingestuft und sollte behoben werden. Dazu gibt es einen Patch, der folgender maßen aussieht oder downloade die aktuelle Datei auf der Patch-Seite und überschreibe die aktuelle Datei.
** In der Version 2.0.6 beta 1 ist der Fehler nicht behoben!
Workflow:
Die Datei templates.php im Ordner wp-admin bearbeiten. Suche nach (ab Zeile 111):

';
foreach ($recents as $recent) :
	echo "" . get_file_description(basename($recent)) . "";
endforeach;
?>

und ersetze mit:

';
foreach ($recents as $recent) :
	echo "" . wp_specialchars(get_file_description(basename($recent))) . "";
endforeach;
?>


 © Frank Bültge, All rights reserved / Alle Rechte vorbehalten. (ID: 6e8b33de4342c4f2ca76b245199aeee8)
Danke für das Abonnieren meines Feed! Inhalt gefällt? Danke sagen · Kommentieren