Dipl.-Inform. Carsten Eilers

Einen Hinweis auf eine bisher zumindest von mir übersehene Tatsache gibt es im Information Security Blog von Security Steet / Rapid 7: Die 0-Day-Schwachstelle betrifft alle Versionen ab dem Internet Explorer 6, sie ist also womöglich schon seit dessen Veröffentlichung 2001 im Code enthalten. Da würde ich nicht ganz so schwarz sehen, vom ursprünglichen Code dürfte nicht mehr viel erhalten sein. Die Schwachstelle kann genau so gut auch später eingeführt worden sein, der IE 6 wurde ja doch einige Jahre weiterentwickelt.

Im Blog wird spekuliert, ob sich die Schwachstelle vielleicht schon seit über einer Dekade in der privaten Werkzeugsammlung der besten Schadsoftware-Autoren befindet. Das schließe ich aus. Wenn die Cyberkriminellen oder wer auch immer eine 0-Day-Schwachstelle finden und ausnutzen wollen, werden sie das zeitnah tun. Es ist doch völliger Quatsch, 0-Day-Schwachstellen zu horten - die können schließlich schon mit dem nächsten Patch behoben werden. Ebenso, wie Microsoft und Co. immer damit rechnen müssen, dass die ihnen vertraulich gemeldeten Schwachstellen parallel von Dritten entdeckt und ausgenutzt werden, müssen die Cyberkriminellen damit rechnen, dass die von ihnen entdeckten Schwachstellen parallel von verantwortungsbewussten Forschern entdeckt und an die Hersteller gemeldet werden.

Kommen wir zurück zum 0-Day-Exploit. Der ist womöglich schon deutlich länger aktiv als bisher vermutet (seit dem 19. August): Die Websense Security Labs haben gemeldet, dass es aus dem Netz eines der möglichen Opfer des Angriffs bereits am 1. Juli erste Zugriffe auf die für den Angriff genutzten Command&Control-Server gab. Wenn damals schon die 0-Day-Schwachstelle ausgenutzt wurde, wurde die ja ziemlich lange übersehen. Was machen eigentlich die Antivirenhersteller die ganze Zeit?
Von Websense selbst wurde der erste Exploit erst am 25. September entdeckt, Ziel war eine "major financial institution" in Japan.

Das war es dann auch schon mit Neuigkeiten zur Schwachstelle. Die wichtigste Frage, "Wann gibt es einen Patch?", ist weiterhin offen. Ich schätze, der wird frühestens am nächsten Patchday am 8. Oktober veröffentlicht. Vielleicht auch erst später, denn da es aufgrund der Vielzahl betroffener Versionen schwierig war, das FixIt-Tool zu entwickeln, dürfte es auch schwierig sein, einen endgültigen Patch für die Schwachstelle zu entwickeln und zu testen.

Es gibt aber auch eine gute Nachricht zur Schwachstelle: Zumindest bisher gibt es keine Meldungen über den Einsatz des Exploits in den Exploit-Kits, es gibt also noch keine für Drive-by-Infektionen präparierte Seiten mit dem Exploit.

Angriffe auf und über WordPress-Installationen

Schon im April griff ein Botnet WordPress-Installationen an, um dort Hintertüren zu installieren. Die wurden nun anscheinend genutzt, denn das Anti-Botnet Beratungszentrum berichtet, dass laut eines auf Pastbin veröffentlichten Logfile-Auszugs 569 kompromittierte WordPress-Installationen für DDoS-Angriffe genutzt wurden. Unter den kompromittierten Blogs befinden sich auch eine Reihe von auf WordPress.com gehosteten Blogs.

Wer ist Schuld an den Kompromittierungen der WordPress-Installationen? Laut einer auf Daten von Sandro Gauci, dem Gründer von EnableSecurity, basierenden Statistik von WP WhiteSecurity verwendeten von 42.106 WordPress-Blogs der Alexa Top 1 Million Websites mehr als 70% eine veraltete WordPress-Version.

Getestet wurden die Websites zwischen dem 12. und 15. September 2013, beginnend einen Tag nach der Veröffentlichung von WordPress 3.6.1. Einen unpassenderen Zeitpunkt konnte man sich wohl nicht aussuchen? Als ob die Admins nichts besseres zu tun haben, als sofort eine neue Version zu installieren. Normalerweise testet man neue Software, bevor man sie produktiv einsetzt. Oder man lässt sie testen, zum Beispiel indem man erst mal abwartet, wie viele Probleme in den einschlägigen Foren veröffentlicht werden. Angesichts der vielen WordPress-PlugIns ist immer mit Problemen zu rechnen, und ich kenne keinen Admin, der darauf Wert legt. Ich vermute mal, einige Tage später hätten die Ergebnisse zwar immer noch schlimm, aber nicht so schlimm ausgesehen. Außerdem ist die Beschränkung auf die WordPress-Version nicht unbedingt zielführend.

Generell sind veraltete WordPress-Versionen ein Problem, aber auch die PlugIns sind nicht zu unterschätzen. Darauf weisen zum Beispiel Studien des Bundesamts für Sicherheit in der Informationstechnik und von Checkmarx (PDF) hin, die beide im Juni dieses Jahres veröffentlicht wurden. Auch die aktuellste WordPress-Version kann Opfer eines Angriffs auf eine PlugIn-Schwachstelle werden!

In diesem Fall sind die WordPress-Versionen, egal ob veraltet oder aktuell, aber sowieso irrelevant. Und zumindest die Blogs auf WordPress.com verwenden immer die aktuellste WordPress-Version, und davon sind ja auch einige betroffen. Das Botnet versuchte nämlich, über einen Brute-Force-Angriff das Administrator-Passwort zu ermitteln. Und das funktioniert unabhängig von der WordPress-Version, es kommt ganz allein auf die Sicherheit des Passworts an. Wobei PlugIns, die die Anzahl der Login-Versuche beschränken, oder auch nur ein von "admin" abweichender Benutzername die Angriffe zumindest erschweren und eine Zwei-Faktor-Authentifizierung sie sogar verhindert.

Brute-Force-Angriffe laufen auch jetzt noch, von F-Secure wurde ein Schädling entdeckt, der im September am einem einzigen Tag Angriffe auf mehr als 17.000 verschiedene Domains durchgeführt hat - von einem einzigen infizierten Rechner aus! Sie sollten also darauf achten, immer ein sicheres Passwort zu verwenden! Und wenn Sie es noch nicht getan haben: Härten Sie ihre selbst gehostete WordPress-Installation

Carsten Eilers