Skip to content

Drive-by-Infektionen über kompromittierte Webanwendungen

Präparierte Werbung wie zum Jahreswechsel 2013/2014 auf Yahoo.com ist nur eine von vielen Möglichkeiten, harmlosen Websites den Code für die Drive-by-Infektionen unter zu schieben. Genau so gut können auch die Webanwendungen selbst angegriffen werden.

Kompromittierte Webanwendungen

Egal ob WordPress, Joomla oder was auch immer, egal ob auf Apache, Nginx, IIS oder anderen Webservern - alles, was sich kompromittieren lässt, wird von den Cyberkriminellen dankend missbraucht. Besonders beliebt sind natürlich Schwachstellen in weit verbreiteten Anwendungen: Wenn die Angreifer die Wahl zwischen zum Beispiel einer Schwachstelle in WordPress oder einer in einer nur auf einem einzigen Server verwendeten Anwendung haben, wählen sie natürlich meist die WordPress-Schwachstelle und kompromittieren darüber einige hundert, tausend oder noch mehr Sites. Aber auch vor individuellen Anwendungen machen die Cyberkriminellen natürlich nicht halt, sofern es sich nur lohnt. Eine individuelle Anwendung mit einigen 100.000 Besuchern ist allemal besser als einige dutzend Blogs mit jeweils nur einigen 100 Besuchern, denn Drive-by-Infektionen sind ein Massengeschäft. Je mehr Besucher, desto größer die Anzahl der kompromittierbaren Rechner.

Vorsicht: Bekannte Websites sind begehrt!

Darum sind bekannte Websites besonders interessant für die Cyberkriminellen: Zum einen haben sie viele Besucher, zum anderen wirken sie vertrauenswürdig. Der gut gemeinte Rat "Besuchen Sie nur vertrauenswürdige Website" schützt schon lange nicht mehr vor Angriffen, siehe zum Beispiel die Angriffe über präparierte Werbung. Ich will hier aber auf einen anderen Angriff hinaus: Den auf php.net Ende Oktober 2013: Google hatte die Website als bösartig eingestuft, die Administratoren konnten aber keinen Schadcode finden. Des Rätsels Lösung war eine neue Taktik der Cyberkriminellen zum Verbergen ihrer Manipulationen: Über einen rsync-cron-Job wurde die betroffene JavaScript-Datei zeitweise gegen eine präparierte Version ausgetauscht, so dass mal die kompromittierte und mal die harmlose Version ausgeliefert wurde. Während Googles Crawler irgend wann eine manipulierte Seite präsentiert worden war, erwischten die php.net-Administratoren bei ihrer Prüfung eine saubere Version. Was das Entfernen des Schadcodes natürlich deutlich verzögert hat. Und genau das wollten die Cyberkriminellen mit ihrer Taktik auch erreichen. Man sieht also: Die Cyberkriminellen lassen sich immer wieder neue Tricks einfallen, um ihren Schadcode vor ihren Gegenspielern zu verbergen.

Besonders gefährdet: Alte Versionen

Im allgemeinen richten sich die Angriffe gegen Schwachstellen in älteren Versionen der Webanwendungen, die in der aktuellen Version längst behoben wurden. Wenn Sie eine Webanwendung betreiben, achten Sie also darauf, immer die aktuelle Version zu verwenden. Sie wollen doch nicht zum Opfer eines Angriffs auf eine längst behobene Schwachstelle werden, oder? Und achten Sie auch auf evtl. vorhandene Plugins etc. von Drittherstellern, die mitunter unbeachtet zur Gefahr werden können. Ein Beispiel dafür ist das weit verbreitete WordPress-Plugin TimThumb, das ein beliebtes Angriffsziel ist. Oder genauer: Eine ältere Version des Plugins mit bekannter Schwachstelle, die in der aktuellen Version längst behoben wurde. Viele WordPress-Installationen und -Erweiterungen nutzen aber noch eine angreifbare Version, und das nutzen die Cyberkriminellen natürlich aus: Laut Akamai sind 73% aller Angriffe auf WordPress-Blogs gegen TimThumb gerichtet. Treffen die auf eine veraltete Version, ist das komplette Blog danach kompromittiert.

Wie werden die angreifbaren Webanwendungen gefunden?

Webanwendungen mit bekannten Schwachstellen werden zum einen ganz klassisch mittels Google Hacking gefunden, zum anderen suchen die Cyberkriminellen auch selbst nach neuen Schwachstellen in Webanwendungen. Oder lassen darin suchen, denn es wurde zum Bespiel ein Botnet entdeckt, dass von einem Firefox-Add-on aufgebaut wurde und in allen mit infizierten Firefox-Installationen besuchten Websites nach SQL-Injection-Schwachstellen suchte. Wo ein Wille ist, ist bekanntlich auch ein Weg. Nur um die seit langer Zeit üblichen Massenhacks über blindwütige SQL-Injection-Angriffe auf ASP.NET-Websites ist es etwas ruhig geworden, zumindest die scheinen also zurück zu gehen. Vielleicht sind die für die heutigen Zeiten auch einfach zu auffällig, da der eingeschleuste Schadcode sich durch sein Erscheinen an unpassenden Orten leicht verraten hat.

Massenhack führt zu Social Engineering statt Drive-by-Infektion

Die Websense Security Labs haben im Oktober 2013 über einen Massenhack berichtet, bei dem die präparierten Websites die Besucher nicht auf eine Seite für Drive-by-Infektionen leiten, sondern auf eine, auf der sie über Social Engineering zur Installation von Schadcode bewegt werden sollen: Angeblich muss der VLC Player installiert werden, um die besuchte Website ansehen zu können. Stimmen die Benutzer zu, wird nicht der normale, harmlose VLC Player installiert, sondern eine ganze Reihe von Schadprogrammen (oder zumindest unerwünschten Programmen), die sog. "Cost Per Action" (CPA) Werbung verbreiten. Ob dieser Wechsel der Taktik auf die jüngsten Schläge gegen die Entwickler von Exploit-Kits zurück zu führen sind, wie von Websense vermutet wird, bleibt zu beweisen. Vielleicht sind diesen Cyberkriminellen die Exploit-Kits auch einfach zu teuer, oder die Erfolgsrate der Social-Engineering-Angriffe ist einfach besser.

Übrigens nutzen nicht nur Cyberkriminelle Drive-by-Infektionen, auch Strafverfolger (und Geheimdienste und was es da sonst noch so gibt) greifen auf Drive-by-Infektionen zurück, wie eine Präsentation der FinFisher-Angriffstools verraten hat. Aber das sei nur am Rande erwähnt. In der nächsten Folge gibt es zum Abschluss noch eine bunte Sammlung an Informationen rund um Drive-by-Infektionen.

Carsten Eilers


Übersicht über alle Artikel zum Thema

Drive-by-Infektionen - Gefahren drohen überall
Drive-by-Infektionen durch SQL-Injection vorbereitet
Drive-by-Infektionen: So kommt der Schadcode auf den Server
Drive-by-Infektionen - Vom Server auf den Client
Drive-by-Infektionen - Ein Blick auf die Exploits
Drive-by-Infektionen erkennen und abwehren
LizaMoon - Massenhack mit minimalen Folgen
Aktuelles: LizaMoon auf Apples iTunes-Seiten
Drive-by-Infektionen über präparierte Werbung
Drive-by-Infektionen über kompromittierte Webanwendungen

Trackbacks

Dipl.-Inform. Carsten Eilers am : Drucksache: PHP Magazin 6.15 - Docker-Sicherheit - eine Bestandsaufnahme

Vorschau anzeigen
Im PHP Magazin 6.2015 ist ein Artikel zur Sicherheit von Docker erschienen. Docker isoliert Anwendungen in Container. Aber ist diese Isolation auch sicher? Manche meinen, nein - und bringen eine Alternative an den Start. Sollte man also um