Tagesarchiv für den 7. November 2008

7. November 2008WordPress Fake mit Trojaner im Gepäck

Wie auf wp-magazin.ch zu lesen ist, gibt es eine Hintertür in der aktuellen(?) WordPress-Version, über welche es möglich ist, einen falschen Update-Hinweis im Dashboard zu plazieren. wurde ein News-Feed dazu genutzt um eine Falschmeldung über ein vermeintliches WordPress-Update zu verbreiten.

Als ob das alleine nicht schon beunruhigend genug wäre, lädt man beim vermeintlichen Update eine modifizierte Version von WP herunter. Beim Download dieses Updates sollten aber schon die Alarmglocken läuten, da die Quelle wordpresz.org lautet (man beachte das “z” am Ende des Domainnamens!).

In diesem Download wurde die pluggable.php modifiziert, welche die Cookies der angemeldeten Benutzer zur gefakten Website schickte. Besagte Webseite ist aber derzeit offline.

*Nachtrag*

Da im Screenshot eine Version 2.5.1 gezeigt wird, bin ich mir nicht mehr sicher, ob die Dashboard-Lücke nicht nur eine alte Version betrifft.

*Nachtrag*

So wie es aussieht, wurde nicht die Update-Funktion von WP missbraucht, sondern nur ein News-Feed gekapert.

7. November 2008404-Grafik für Smilies

Eigentlich wollte ich im letzten Beitrag zum Update der Smilie-Schreibmaschine noch erwähnen, dass es nun eine 404-Grafik für Smilies gibt, aber nachdem ein Satz schon die komplette Höhe meiner Bildschirmauflösung von 1.200 Pixeln verbraucht, habe ich mir das dann doch verkniffen.

Worum geht es? Hierum:

Dieser nette Ugly-Smilie begegnet euch, wenn ihr einen Smilie von GreenSmilies fehlerhaft verlinkt. Er dient einerseits um euch auf den Fehler hinzuweisen und andererseits entlastet er meinen Server. Bislang wurde nämlich immer die 404-Seite von GreenSmilies aufgerufen, wenn ein Image-Link fehlerhaft war. Wenn das tausendfach innerhalb kürzester Zeit passiert, geht die Last doch erheblich nach oben. Vor allem ein fehlendes Leerzeichen in der Smilie-Schreibmaschine trieb die 404-Quote kräftig nach oben.

Eventuell weiß auch einer der hier Mitlesenden eine Lösung für folgendes Problem. Anfangs hatte ich versucht über diesen htaccess-Eintrag den nicht vorhandenen Bildern ein Ersatzbild unterzuschieben:

ErrorDocument 404 /smile/smiley_emoticons_404ups.gif

<FilesMatch "\.(gif|jpe?g|png)$">
  ErrorDocument 404 /smile/smiley_emoticons_404ups.gif
</FilesMatch>

Doch es erschien trotzdem immer die 404-Seite von WordPress. Erst als ich folgende fehlerhafte(!) RewriteRule darunter gesetzt habe (liefert ein “File not found”) funktionierte der ErrorDocument-Eintrag:

Options +FollowSymLinks
RewriteEngine on
RewriteCond %{REQUEST_URI} !-U
RewriteRule (.*).gif$ http://www.greensmilies.com/smile/smiley_emoticons_404ups.gif [L]

Hat jemand eine Idee, warum a) das ErrorDocument nicht greift und b) was an der RewriteRule falsch ist?

*Update*

Mit der Hilfe von WPD und Ammaletu kam nun folgende Lösung für die htaccess im root zum Einsatz:

# BEGIN Bilder404
<IfModule mod_rewrite.c>
ErrorDocument 404 /smile/smiley_emoticons_404ups.gif
  <FilesMatch "\.(gif|jpe?g|png)$">
    RewriteEngine on
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule .*\.(gif|jpe?g|png)$ /smile/smiley_emoticons_404ups.gif [R=404,L]
  </FilesMatch>
</IfModule>
# END Bilder404

Nun werden alle Grafiken auf GreenSmilies, sofern ihr Pfad irgendwie nicht stimmt, statt mit der 404-Seite von WordPress mit einer 404-Grafik abgefangen.


Smilie-Album