Feb 28 2013

WalliBlog under HackAttack – Schadwirkung – Teil 2

Teil 1 Beginn/Bemerken des Angriffs

Teil 2 allgemeinen Beschreibung der Folgen

Teil 3 technische Dokumentation (steht zur Zeit noch aus)

 


Die Schadwirkung

Das Abuse-Team meines Providers hatte mir den Einstieg des Hackerangriffs benannt. Es handelte sich um eine vergessene Testversion von CMSimple bzw. eines eingebundenen PHP-Komforteditors die dann sofort vollständig gelöscht wurde. Ebenfalls gelöscht wurden die  PHP-Programme die gemäß Maillog den Mailverkehr verursachten. Es handelte sich um Programme mit Namen wie w8881736927605465.php und w1610327850865301.php.

Leider war es damit nicht vollständig getan. Nach relativ kurzer Zeit – ca. zwei Wochen – ging es wieder von vorne los. Ich war ganz offensichtlich nicht sorgfältig genug bzw. zu faul gewesen. Dies insbesondere, weil ich auch so gar keine privaten, nicht öffentlichen oder gar geheime Daten auf dem Webserver meines Providers liegen hatte. Ich hatten offensichtlich den Fokus nicht richtig gesetzt, und dies eigentlich wieder besseren (theoretischen) Wissens.

Der Angreifer hatte eben nicht nur über den Einstieg des alten Programmes die oben genannten PHP-Programme ablegt, sondern sich – wie eine genauere Kontrolle ergab –  auch an seine Zukunft gedacht.

Der PHP-Source der Dateien “ w[0-9]{17}.php “ ist nicht einfach oder fast gar nicht lesbar. Der Source ist in zwei längeren Zeilen mit 994 und 23285 Zeichen ohne weitere Umbrüche enthalten. Es wird in der ersten Zeile mit “ preg_replace „, „ @setcookie “ und so feinen Konstruktionen wie “ eval(base64_decode(str_replace(chr(32),chr(43),$_POST[$sessdt_p]))) “ gearbeitet. Die Zeile enthält dann viele maskierte Zeichen und den Code als base64.

Ich werde im dritten Teil dann den Source vorstellen. Vielleicht können ja PHP-Experten mit umfangreicherem  technischen Wissen die Dinge beschreiben, auseinander nehmen und kommentieren.

Mehr vordergründig ist das Verstecken des Source indem nur die Zeichen “ <?php “ zu Beginn der Zeile steht und der aggressive Rest dann ab Zeichen 97 beginnt. Bei einer schnellen Kontrolle ist dieser Rattenschwanz rasch mal übersehen. Jedenfalls ist es bei mir durchgerutscht. Dafür bitte ich die Empfänger des Spam nach der Schnellreinigung am 06.12.2011 um Entschuldigung.

Diese erste Zeile stand nämlich zu Beginn JEDER PHP-Datei. Fiel aber allein aufgrund der Art der Formatierung nicht sofort auf.

Ich bin kein PHP-Experte. Ich verstehe den absichtlich unleserlich gestalteten Source zur Zeit so, dass bei jedem Aufruf eines PHP-Scriptes meines Blogs von Besuchern zum einen ein Cookie gesetzt und zum anderen wieder alle PHP-Dateien mit seinem Code in der ersten Zeile infiziert wurden. Dann wurden diese “ w[0-9]{17}.php “ ausgeführt und mit dem verschicken von Mail beauftragt.

Daneben wurde anscheinend der Bot-Führer-host informiert, dass hier was zu holen sei, damit er in Zukunft „nach dem Rechten“ schauen kann. Ich gehe davon aus, dass er auf diesem Weg auch mit frischen Mailadressen versorgt wurde.

Damit es bei der Rückkehr einfacher ist, wurde die „ .htaccess “ natürlich immer wieder den Wünschen des neuen Herrn angepasst.

Im Ergebnis führte also nach meiner Auffassung jeder Aufruf meines Blog zu einem „Auffrischen“ der Infektion, einer Meldung nach oben und einem Cookie beim Leser.

Ich habe danach meine gesamte Webpräsenz vollständig gelöscht bzw. verschoben und durch eine kleine HTML-Datei ersetzt. Ein Backup – hätte es bestanden – hätte nicht viel genutzt, es sein denn man würde es über eine wirklich längere Zeit – bis die Zeit vor dem Angriff – aufheben. Sämtliche Änderungen und neue Post gingen dann aber verloren oder würden die Gefahr einer Neuinfektion bergen. Da ich nicht viel auf der Seite hatte, war das Löschen und Archivieren für eine Dokumentation (nämliche diese hier) der sinnvollere und einfachere Weg.

Heute habe ich natürlich automatisierte BackUps ausserhalb und innerhalb von WordPress. Desweiteren habe ich einige Security- bzw. Logingtools installiert. Benennen werde ich sie aber in diesem Zusammenhang einmal nicht. Ich weiß daher, dass bis heute immer noch Aufrufe meiner alten Seiten erfolgen, und diese bestimmt nicht, weil die so wahnsinnig spannend sind.

In den 404-Logs steht beispieleweise:

2013-01-31, 9:20 AM 78.30.200.81 /blog/2011/04/aldi-kiel-sonderverkauf-und-ich-war-nicht-dabei

Bei zu vielen 404-Fehlern wird man dann jetzt erstmal gesperrt – das bringt dann Ruhe. Die genannte IP-Adresse 78.30.200.81aus Sevastopol ist immer wieder gerne dabei. So auch andere wie ein Verbund mehrerer Adressen aus Chikago.

Die direkten Aufrufe von Programmen, auch nie vorhandenen Themes oder Widgets  oder auch WordPress-PHP-Scripts sind ausweislich der Webserverlogs in bestimmten zeitlichen Perioden (Kontrollgänge??) leider höher, als die Aufrufe meiner mit Piwik protokollierten Blogseiten. Allerdings ist die Tendenz derzeit positiv.

 Update 01.03.2013:

Bei der Zeile  “ eval(base64_decode(str_replace(chr(32),chr(43),$_POST[$sessdt_p]))) “ mussten die umschließenden geschweiften Klammern entfernt werden. SiteLock meldete ansonsten einen Schadcode für diese Seite. Fand ich unpassend.

 


Teil 1 Beginn/Bemerken des Angriffs

Teil 2 allgemeinen Beschreibung der Folgen

Teil 3 technische Dokumentation (steht zur Zeit noch aus)

Permanentlink zu diesem Beitrag: https://www.wallinet.de/blog/2013/02/walliblog-under-hackattack-schadwirkung-teil-2/

2 Pings

  1. […] Wal­li­Blog under Hack­At­tack – Schad­wirkung – Teil 2 […]

  2. […] Teil 2 allgemeinen Beschreibung der Folgen […]

Schreibe einen Kommentar

Your email address will not be published.

Social Widgets powered by AB-WebLog.com.