KRITISCH: Gehacktes Webhosting – Support reagiert nicht

Hallo zusammen,

ich brauche dringend eure Einschätzung zu einem massiven Sicherheitsproblem bei meinem Webhosting (hosting236431). Mein Account wurde kompromittiert, aber was ich im File-Manager sehe, beunruhigt mich zutiefst:

In meinem Basisverzeichnis sind plötzlich Systemordner wie .ssh, /bin, /dev, /etc, /lib64, /usr, /var sichtbar.

Zudem habe ich folgende Entdeckungen gemacht:

• ssh-keygen wurde vom Angreifer im Verzeichnis abgelegt.
• Eine unbefugte id_rsa.pub wurde erstellt.
• Malware-Dateien (z.B. OlBVAHW.php) lassen sich nicht löschen (Permission Denied), vermutlich durch chattr +i Manipulationen.
• Die .htaccess wurde mit FilesMatch Deny from all komplett verriegelt.

Der Support antwortet seit Tagen nur, ich solle "manuell löschen". Aber als Webhosting-Nutzer habe ich keine Root-Rechte, um /etc oder gesperrte Malware zu bereinigen.

Ist das ein Chroot-Breakout? Wenn ich Zugriff auf /etc habe, ist dann die Isolation meines Accounts zu anderen Kunden noch gegeben?

Ich bitte um Hilfe oder eine offizielle Stellungnahme von netcup, da mein Business komplett stillsteht.

Danke!

Zitat

Danke für die Antwort, aber das Problem ist tiefgreifender:

Ja, Chroot-Verzeichnisse sind normal, aber mein Account wurde aktiv missbraucht, um Angriffe nach außen zu starten. Hier sind die Details, die zeigen, dass es kein "normaler" Zustand ist:

1. SSH-Keys Injektion: In meinem .ssh Verzeichnis wurde eine unbefugte id_rsa.pub hinterlegt. Der Angreifer hat sich also eine Backdoor auf Systemebene gebaut.
2. Malware mit Root-Attributen: Ich habe Dateien wie OlBVAHW.php, die ich als Nutzer NICHT löschen kann (Permission Denied). Selbst über den Dateimanager oder FTP schlägt das Löschen fehl. Dies deutet darauf hin, dass der Angreifer Attribute (wie chattr +i) gesetzt hat, die über normale User-Rechte hinausgehen.
3. Angriffs-Tools: Es wurde aktiv das Tool ssh-keygen in meinem Home-Verzeichnis ausgeführt, um weitere Keys für "Island Hopping" Angriffe zu generieren.
4. Datenbank-Lock: Ich kann die Datenbank k348036_joomla_0 nicht löschen. Die Option "Entfernen" wird im Panel gar nicht erst angezeigt.

Meine Frage an euch: Wenn ein Hacker bereits eigene SSH-Keys hinterlegt hat und Dateien sperrt, die der Nutzer nicht mehr löschen kann – ist dann "Abwarten" wirklich die richtige Strategie?

Ich fordere einen Full-Wipe, aber der Support verweigert diesen und verlangt, dass ich Malware lösche, auf die ich keinen Schreibzugriff mehr habe. Wie würdet ihr hier vorgehen?

Danke für die technische Einschätzung! Hier ist der aktuelle Stand der Fakten:

1. Berechtigungen: Die Dateien im Verzeichnis (wie die Malware im Ordner .trash/wp-content/...) stehen laut Anzeige auf Standardwerten, aber jeder Löschversuch (über Plesk File Manager und FTP) wird mit "Permission Denied" abgebrochen. Das ist der Grund, warum ich vermute, dass hier tiefgreifendere Sperren vorliegen, die über normale User-Rechte hinausgehen.
2. Der .ssh Ordner: Ich habe die unbefugte Datei .ssh/id_rsa.pub entdeckt. Auch hier schlägt das Löschen fehl. Der Zugriff auf diesen Bereich ist für mich faktisch blockiert.
3. Datenbank-Sperre: Die Datenbank k348036_joomla_0 lässt sich nicht entfernen. Im Panel fehlt die Option "Löschen" komplett, obwohl sie zu meinem Account gehört.
4. System-Tools: Ich habe die Datei ssh-keygen im Verzeichnis gefunden, was darauf hindeutet, dass der Account für die Generierung von Keys missbraucht wurde.

Mein Problem: Ich würde die Ratschläge (Löschen von .ssh Inhalten, Datenbankbereinigung) gerne befolgen, aber das System verweigert mir die Ausführung. Wenn der Support sagt "lösch es manuell", aber der Server den Befehl mit "Permission Denied" quittiert, bin ich in einer Sackgasse.

Was kann man tun, wenn man als User aus seinem eigenen Home-Verzeichnis (bzw. den darin liegenden Malware-Resten) ausgesperrt wird?

Ich habe es über drei verschiedene Wege versucht, alle mit demselben negativen Ergebnis (Permission Denied / Zugriff verweigert

1. Plesk File Manager: Beim Versuch, die Dateien (z.B. im Ordner .trash oder .ssh) zu löschen, erscheint oben rechts die rote Fehlermeldung "Permission Denied".
2. FTP/SFTP (FileZilla): Ich erhalte den Fehler 550 Permission denied oder Critical file transfer error. Die Berechtigungen werden als 0644/0755 angezeigt, aber der Löschbefehl wird vom Server abgelehnt.
3. SSH (Terminal): Beim Befehl rm -rf .ssh/id_rsa.pub erhalte ich: rm: cannot remove '.ssh/id_rsa.pub': Operation not permitted.

Da die Standard-Berechtigungen (Owner/Group) korrekt aussehen, vermute ich, dass der Angreifer entweder den Owner auf Root geändert hat (was im Plesk Panel manchmal nicht korrekt visualisiert wird) oder das Immutable-Bit (chattr +i) gesetzt hat.

Da ich als Webhosting-Nutzer keinen Root-Zugriff habe, kann ich diese Attribute nicht mit chattr -i entfernen. Genau hier liegt meine Sackgasse mit dem Support.

anke für diese wirklich beunruhigende Analyse. Das würde erklären, warum meine Löschversuche (rm -rf) fehlschlagen, obwohl die Flags korrekt aussehen.

Wenn meine Shell tatsächlich manipuliert ist oder ich mich in einer Art "Spiegelwelt" befinde, wie ihr vermutet, dann ist das ja nicht nur ein Problem für meine Daten.

Frage an die Experten hier: Besteht in so einem Fall (mit sichtbaren /etc, /dev und manipulierten bin/bin/ Strukturen) nicht auch die Gefahr, dass der Angreifer von meinem Account aus die Isolation zum restlichen Host-System angreift?

Ich möchte ungern blind Befehle eingeben, wenn ich der Shell nicht trauen kann. Was ist in so einer Situation der sicherste Weg für den Provider? Ein manuelles Löschen durch den Kunden scheint mir bei diesem Verdacht technisch nicht mehr der richtige Standardprozess zu sein, oder?

Zitat von ASS

Die sind "immer" sichtbar. Die sind aber nur ein Overlay, nur für deinen Account. Andere können die nicht nutzen.

Verstanden, danke für die technische Klarstellung zum Overlay/Chroot. Das beruhigt mich bezüglich der Isolation zu anderen Kunden etwas.

Aber mein Kernproblem bleibt die Handlungsunfähigkeit:

Auch wenn es "nur" mein Overlay ist, befinden sich darin nun manipulierte Dateien (wie die unbefugte .ssh/id_rsa.pub und Malware im .trash), auf die ich keinen Schreibzugriff (Permission Denied) mehr habe.

Wenn der Support mir sagt: "Löschen Sie alles manuell", aber mein User-Account im Chroot-Gefängnis nicht einmal mehr die Berechtigung hat, seine eigenen .ssh Keys oder die .htaccess Sperren zu entfernen – wie soll ich dann jemals wieder ein sauberes System bekommen?

Ohne einen Full-Wipe (Reset auf Werkseinstellungen) durch netcup bleibe ich in einem infizierten Overlay gefangen, das ich nicht selbst bereinigen kann.

Was würdet ihr an meiner Stelle tun, wenn der Support den Reset verweigert, man selbst aber technisch ausgesperrt ist?

Zitat von Tim Chen

Bezüglich der Löschung kann ich dir auch nicht helfen beziehungsweise möchte nicht ausschließen dass du hier tatsächlich die Hälfte des Supports benötigst, um aus der Situation wieder herauszukommen. Aber ich erlaube mir durchaus einzuschätzen, dass seitens netcup absolut kein Sicherheitsproblem besteht. Bei dir besteht eins. Bei deinem Hoster nicht.

Ich möchte hier eines klarstellen: Ich bin mir absolut nicht sicher, ob die Sicherheitslücke bei meiner Anwendung lag.

Tatsächlich hatte io bereits in den ersten Tagen nach der Bereitstellung dieses Hostings Probleme, Datenbanken korrekt zu löschen oder zu verwalten. Das deutet für mich darauf hin, dass mit diesem Account von Anfang an etwas nicht stimmte oder bereits Altlasten/unbefugte Zugriffe existierten, bevor ich meine Seite vollständig eingerichtet hatte.

Fakt ist:

1. Ich bin in meinem eigenen Home-Verzeichnis ausgesperrt (Permission Denied).
2. Die Manipulationen (wie die .ssh Keys) und die rekursiven bin/bin/ Strukturen sind so tief im System verankert, dass sie meine Nutzerrechte übersteigen.
3. Wenn ein Kunde bereits direkt nach der Aktivierung des Produkts auf technische Hürden stößt, liegt der Verdacht einer mangelhaften Bereitstellung oder einer Vor-Kompromittierung nahe.

Anstatt die Schuld beim Kunden zu suchen, sollte der Support erklären, warum ein Standard-Nutzer keine Kontrolle über seine eigenen Dateien hat. Ich fordere weiterhin eine vollständige Bereinigung (Full Wipe), um sicherzustellen, dass ich endlich auf einer wirklich sauberen Infrastruktur arbeiten kann.

Zitat von Hille

Ändere doch mal testweise manuell die Rechte auf 777 und versuche dann zu löschen

Das habe ich bereits mehrfach versucht: Ein chmod 777 auf die betroffenen Dateien oder Verzeichnisse (z.B. im .ssh oder .trash Ordner) schlägt fehl oder hat keinerlei Auswirkungen.

Ich erhalte auch hier die Meldung: "Permission Denied" oder "Operation not permitted".

Das ist der endgültige Beweis: Wenn ich als rechtmäßiger Nutzer meines Hostings nicht einmal die Berechtigungen (chmod) meiner eigenen Dateien ändern kann, dann hat das System die Kontrolle über diesen Account verloren.

Entweder hat der Angreifer den Owner auf Root geändert oder die Dateien mit dem Immutable-Bit gesperrt. In beiden Fällen kann ich als Standard-Nutzer ohne Root-Rechte absolut nichts tun.

An die Experten: Wenn selbst chmod versagt, wie kann der Support dann ernsthaft von mir verlangen, die Reinigung "manuell" durchzuführen? Das ist technisch unmöglich.

Ich glaube, hier wird das eigentliche Risiko unterschätzt: Wenn ich als rechtmäßiger User keine Ownership mehr über meine Verzeichnisse habe und chmod fehlschlägt, ist dieser Account auf Systemebene (Root/Kernel) kompromittiert.

Das ist kein "Webseiten-Problem" mehr, das ist ein Infrastruktur-Risiko:

1. Gefahr für Interventen: Jeder Login-Versuch via SSH (auch durch den Support) findet in einer potenziell manipulierten Shell statt. Wer garantiert, dass hier keine Passwörter durch Keylogger abgegriffen werden?
2. Gefahr für das Netzwerk: Ein Account, der so tief infiziert ist, dass der User ausgesperrt wird, fungiert als perfektes Sprungbrett (Jump-Host) für Angriffe auf andere Kunden auf demselben Host-System.
3. Isolation-Breakout: Die rekursiven bin/bin/ Strukturen und die Sichtbarkeit von Systemverzeichnissen deuten darauf hin, dass die Chroot-Umgebung nicht mehr sicher ist.

Ich warne ausdrücklich davor, mich weiterhin zur "manuellen Reinigung" aufzufordern. In einem kompromittierten System zu arbeiten, ist grob fahrlässig. Ich fordere den Support auf, die Integrität des gesamten Host-Systems zu prüfen und meinen Account sofort auf Root-Ebene zu terminieren und neu bereitzustellen.

Wer übernimmt die Verantwortung, wenn dieser Account als Basis für einen größeren Angriff auf netcup-Infrastruktur genutzt wird?