"Schadsoftware" auf Virtuellem Server

S

spider1747

New Member
Hallo Forum,
ich habe einen virtuellen Linux-Server bei Hosteurope auf dem anscheinend Schadsoftware läuft. Ich habe den Server auch schon komplett neu installiert eine alte Sicherung eingespielt (es läuft OS Commerce auf dem Server) und alle Passwörter geändert.
Dennoch wurde der Server von Hosteurope wieder heruntergefahren, da die Schadsoftware erneut aktiv war.
Folgendes wurde mir von Hosteurope übermittelt:
Code: 
www-data 20317 97.6  0.5  51660 12284 ?        R    Jul23 1025:55 /usr/sbin/fakeproc
www-data 20469  0.0  0.5  51660 11252 ?        S    Jul23   0:00 /usr/sbin/fakeproc
www-data 22103  0.0  0.5  51612 11300 ?        S    Jul23   0:00 /usr/sbin/fakeproc
www-data 24163  0.0  0.5  51612 11300 ?        S    Jul23   0:00 /usr/sbin/fakeproc

# ls -l /proc/20317/{exe,cwd}
lrwxrwxrwx 1 www-data www-data 0 Jul 24 09:41 /proc/20317/cwd -> /tmp lrwxrwxrwx 1 www-data www-data 0 Jul 24 06:54 /proc/20317/exe -> /usr/bin/perl
Kann man anhand dieser Informationen erkennen wo ich nach der Schadsoftware suchen muss?
Gerne bin ich auch bereit Hilfe gegen Bezahlung zu erhalten. Ich müsste nur vorher in etwa die Kosten wissen.
Vielen Dank für Eure Hilfe,
Grüße,
spider1747
 
Da ist die Schadsoftware: /usr/sbin/fakeproc

Und die PID wurde offenbar vom www-data-Prozess gestartet, also dem Webserver. Vermutlich hast du in PHP exec() bzw shell_exec() aktiv, und durch irgend eine Lücke in einem Script konnte der Angreifer mit exec bzw shell_exec diese Prozesse starten.
 
Vielen Dank! Das heißt /usr/sbin/fakeproc löschen und exec() bzw shell_exec() deaktivieren und dann den Server neu starten wäre eine Lösung?
 
Du solltest auch die Sicherheitslücke in deinen verwendeten Scripten suchen.
 
Herzlichen Dank für Eure Hilfe!
Also: Server nochmal neu installieren und darauf achten das der safe_mode auf "on" gestellt ist.
Oder wäre es gleich besser auf einen Managed Server umzusteigen wenn ich die Sicherheitslücke im Skript nicht finden kann?
 
Auf einen Managed Server kann diese aber auch genutzt werden :) . Besser man holt sich Hilfe beim suchen und beheben und zieh zusätlich noch auf einen Managed. Aber dies ist eigentlich auch nur von Nöten wenn man keine Zeit etc hat für einen Root.
 
Managed Server ist immer gut, aber auch dort kann eine Scriptlücke gefährlich werden.

SafeMode kannste auf Off lassen, hier solltest du eher exec() und shell_exec() deaktivieren (disabled_functions in der php.ini). Zusätzlich solltest du open_basedir aktivieren, um den Angreifer ins Docroot einzusperren.
 
wurde denn schon einer der wichtigsten hinweise genannt? Updates, Updates und nochmals Updates! Nicht nur den Server sondern auch die verwendeten Scripte.
Oft nutzen Angreifer schon seit Ewigkeiten bekannte Sicherheitslücken in häufig genutzter Software.
 
Schreibzugriff auf /usr/sbin bedeutet, dass der Angreifer root-Rechte hat und die Lücke gravierend und nicht durch simples Reinstallieren behoben ist.
Und da die Lücke auch nach einer bereits erfolgten Reinstallation weiter bestand, wird auch eine erneute Reinstallation die Lücke nicht schliessen.

Da muss jemand ran, der Ahnung von dem hat, was er tut und der dem OP anschliessend gewaltig in den Allerwertesten tritt, damit soetwas nicht nochmal vorkommt...

Sind die Shopkunden mitlerweile darüber informiert, dass ihre Daten geklaut wurden? Der zuständige Datenschutzbeauftragte über den Vorfall informiert?
 
Joe User said:
Schreibzugriff auf /usr/sbin bedeutet, dass der Angreifer root-Rechte hat und die Lücke gravierend und nicht durch simples Reinstallieren behoben ist.
Click to expand...

Das dachte ich mir fast, wir anscheinend ein Kernel Exploit sein oder Dienste die als root laufen.
 
You must log in or register to reply here.
Back
Top