Dipl.-Inform. Carsten Eilers

Am 23. April wurde ich auf eine neue Drive-by-Infektion aufmerksam gemacht und bekam auch den in die PHP-Skript eingeschleusten Code zum Analysieren. Recht interessant: Normalerweise verbergen sich Drive-by-Infektionen vor Besuchern, die nicht von Suchmaschinen kommen. Damit soll verhindert werden, dass regelmäßige Besucher, die die Seite aus den Bookmarks aufrufen, vor allem natürlich die Website-Betreiber, auf den eingeschleusten Code aufmerksam werden. Dieser Code verbirgt den JavaScript-Schadcode vor den Suchmaschinen-Bots. Auch keine schlechte Idee, denn wenn z.B. der Google-Bot den Schadcode entdeckt, landet diese Information natürlich in Googles "Safe Browsing", und die Suchmaschine warnt in den Ergebnissen vor der Infektion.

Ist der Besucher kein Suchmaschinen-Bot, wird JavaScript-Schadcode von einem Server nachgeladen und in die Seite eingebettet. Diesen Server nenne ich jetzt mal den "JavaScript-Server". Nun bin ich in der letzten April-Woche zeitlich einfach nicht dazu gekommen, diesen in die ausgegebene HTML-Seite eingeschleusten Code genauer zu analysieren. Wie üblich ist das mehr oder weniger stark getarnter JavaScript-Code. Also habe ich mir ein Exemplar herunter geladen, und wollte es nun am 2. Mai analysieren. Erst mal habe ich den Code Wepawet vorgeworfen, und es kam tatsächlich ein brauchbares Ergebnis raus. Leider (für meine Analyse, ansonsten: Zum Glück) ist der Server, von dem der erste Exploit geladen wird, inzwischen offline. Diesen Server und seine Nachfolger nenne ich ab jetzt "Exploit-Server". Ende im Gelände, da geht es nicht weiter.

Aber vielleicht gibt es ja einen neuen Exploit-Server. In der Tat ist der JavaScript-Server noch aktiv. Es gibt neuen JavaScript-Code, diesmal anders kodiert. Mit dem kommt Wepawet nicht klar, aber dafür JSUNPACK. Auch hier endet die Spur wieder bei einem nicht mehr aktiven Exploit-Server. Das Spiel habe ich dann noch mal wiederholt, wieder gab es anders getarnten JavaScript-Code, der zu einem erst mit einer Fehlermeldung antwortenden nginx-Server als Exploit-Server führte, inzwischen ist die zugehörige Domain offline. Das gleiche passierte bei zwei weiteren Wiederholungen, allerdings mit dem gleichen JavaScript-Code wie beim dritten Versuch, nur mit anderen Exploit-Servern.

Der JavaScript-Server ist weiterhin aktiv. Aber ich habe keine Lust mehr, Hase und Igel zu spielen. Zumindest nicht, so lange ich den Hasen geben soll. Ich bin ja mal gespannt, wie lange es dauert, bis jemand beim JavaScript-Server den Stecker zieht, das wäre doch viel einfacher als immer nur die Exploit-Server lahm zu legen.

Was die Drive-by-Infektion machen soll, weiß ich nun leider nicht. "Bestimmt nichts Gutes" ist zwar eine korrekte, aber zumindest mich nicht besonders zufrieden stellende Antwort.

Kommen wir zur nächsten Reaktion:

Glassarg, Steine

Einige Leser kennen ja vielleicht das Bestatterweblog von TOM. Für die, die es nicht kennen: TOM ist ein ehemaliger Bestatter, der im Bestatterweblog Aufklärung rund um die Themen Tod und Bestattung betreibt. Dann gibt es da einen Verein, der ungefähr das gleiche Betätigungsfeld hat und sich nach der römischen Göttin der Ewigkeit benannt hat. Schon aus Sicherheitsgründen verlinke ich den Verein hier nicht, ganz abgesehen davon, dass der sich keinen Link verdient hat.

Dieser Verein führt auch Umfragen im Web durch, die aber keinen Klick wert sind, denn da wird jeder Klick gezählt. Darauf hat TOM hingewiesen. Nicht mehr, nicht weniger. Nun ist das passiert, was jeder Website mal passiert: Irgend jemand fand es wohl witzig, diese Umfrage automatisiert zu beantworten. Ob das nun ein Skript war oder nur ein regelmäßiger Reload durch einen Browser kann ich als Außenstehender nicht beurteilen. Der Webserver des Vereins scheint darauf nicht gut reagiert zu haben, woraufhin der Betreiber sich "sein eigenes Grab schaufelte", wie es in den Kommentaren unter TOMs Texten so schön heißt: Man drohte TOM mit der juristischen Keule, woraufhin TOM erst mal das Bloggen einstellen will.

Über Streisand-Effekt etc. hat Tante Jay schon sehr schön geschrieben, dem ist nichts hinzuzufügen. Auch über das Motiv möchte ich nicht weiter spekulieren, auch wenn sich der Verdacht, dass da ein konstruierter Zusammenhang zum Einschlagen auf einen Konkurrenten genutzt wird, geradezu aufdrängt. Aber hier geht es schließlich um IT-Sicherheit.

Und mit der Sicherheit des Vereins-Server scheint es ja nicht weit her zu sein. Wenn das Umfrage-Skript nicht mal einen rudimentären Schutz vor Mehrfach-Abstimmungen hat, drängt sich mir die Frage auf, was es da wohl noch für Schwachstellen gibt. Da mich Schwachstellen dort weder direkt noch indirekt betreffen, ist das aber nur eine rhetorische Frage. Anders sähe es aus, wenn es eine Website wäre, die ich regelmäßig besuche und/oder die Daten von mir gespeichert hat.

Womit wir beim Thema wären: Wenn Sie mal in die gleiche Situation wie besagter Verein kommen, reagieren Sie besonnen. Beseitigen Sie die Schwachstelle, Bedanken Sie sich ggf. beim Entdecker, und ansonsten gilt "Kopf einziehen und die Füße still halten". Denn wenn man im Glashaus sitzt, sollte man nicht nur nicht selbst mit Steinen werfen, sondern auch niemanden anderes provozieren, mit Steinen auf einen zu werfen.

Vor allem sollte man dann alles vermeiden, was den möglichen Angreifer provozieren könnte. Z.B., indem man ihn direkt oder indirekt ärgert. Nun war es in diesem Fall das Bestatterweblog, in dem sich wohl kaum viele Hacker tummeln. Aber stellen Sie sich mal vor, ein Website-Betreiber startet so eine Gegenaktion in einem Hacker-Forum - der Streisand-Effekt dürfte dann zu vernachlässigen sein, stattdessen dürfte der Server einigen unerwarteten Stresstests unterzogen werden. Darum: Schwachstellen beseitigen und Ruhig bleiben. Die Schwachstellen hat man selbst bzw. der zuständige Programmier zu verantworten - und provozierte Angriffe auch. Beides zusammen ist eine ungesunde Kombination. Für den Server und den eigenen Blutdruck.

Und nun zum Abschluss noch eine Reaktion:

Hier gibt es keine Malware

Jetzt fange ich mal mit einer Reaktion an: Meinen am 1.5. veröffentlichten und seitdem mehrmals aktualisierten Text "Hier gibt es keine Malware...". Auslöser war eine Mail von einem Leser, der einen Artikel im Macuser-Forum verlinkt hatte und dabei auf Bitdefenders Warnung gestoßen war. Freundlicherweise hat er mich per E-Mail auf die Warnung aufmerksam gemacht.

Ich bin mir zwar nahezu sicher, dass es hier keine Schwachstellen und damit auch keine eingeschleuste Schadsoftware gibt, habe aber trotzdem sofort alles überprüft. Zum einen könnte es ja eine bisher unbekannte Schwachstelle in Serendipity oder Piwik geben, zum anderen läuft diese Site auf einem Shared-Hosting-Server und man weiß ja nie, ob da nicht evtl. was "von nebenan" kommt. Den Hoster, Hetzner, halte ich zwar für ziemlich sicher, er hatte letztes Jahr aber auch ein m.E. etwas aufgebauschtes Problem, bei dem Benutzer auf für sie eigentlich nicht zugängliche Verzeichnisse zugreifen konnten.

Wie zu erwarten war, gab es nichts zu finden. Der Rest der Geschichte ist in der oben verlinkten Reaktion auf den False Positive nachzulesen, die ich ggf. auch weiter aktualisieren werde. Insbesondere natürlich, falls ich noch eine Information bekomme, was Bitdefender zu dem False Positive verleitet hat. Ich vermute ja, dass der Scanner über die nicht ausführbaren Beispiele zu den Drive-by-Infektionen gestolpert ist.

Auf jeden Fall ist Bitdefender damit auf meiner Liste sowieso nur bedingt empfehlenswerter Virenscanner ziemlich weit nach unten gerutscht. Die unbrauchbare Antwort auf meine Anfrage übers Kontaktformular wird bei weitem nicht durch die schnelle Problemlösung nach der Meldung im Forum aufgewogen. Vor allem, weil ich mich dafür erst bei Bitdefender anmelden musste. Die Reaktion vom Support am Montag ist dann wohl nur noch eine weitere Kuriosität: Nachdem nach die Meldung im Forum der False Positive am Sonntag beseitigt wurde, hat der Support nichts mehr gefunden. Ach so: Im Forum wimmelt es von Meldungen über False-Positive-Erkennungen von Websites. Nicht gerade vertrauenserweckend, oder? Vor allem, wenn man davon ausgeht, das bestimmt nicht alle Opfer den Weg ins Forum finden.

Im deutschsprachigen Bereich gibt es gar kein Unterforum für False Positives, dafür eine Diskussion, der zu Folge die Benutzer eine Website-Sperre nicht umgehen können, sondern die Websites dort posten sollen, damit sie freigeschaltet werden kann. Also mit anderen Worten: Wenn eine u.U. wichtige Website wegen eines False Positive nicht erreichbar ist, soll man die in einem Thread posten, dessen erster Beitrag vom 20. Dezember 2011 stammt, dessen letzter vom 24. April ist und in dem zwischendurch Probleme mit den Jugendschutz-Einstellungen gelöst wurden. Und dann hilft wohl nur noch beten, dass der Scanner schnell aktualisiert wird. Ich denke mal, dann ist "Bitdefender löschen" die schnellere Lösung, oder? Und damit es gar nicht erst so weit kommt, drängt sich doch die Idee auf, das Programm gar nicht erst zu installieren, oder?

Carsten Eilers