Beiträge von Stencil

Hier sind die technischen Fakten und meine Entscheidung dazu:

Zu den beiden PHP-Skripten, die ihr mir netterweise zur Verfügung gestellt habt: Ich habe mich bewusst dagegen entschieden, diese "Feuer mit Feuer"-Taktik anzuwenden.

Warum? > 1. Es ist nicht die Aufgabe eines Kunden, "Gegenhacker" auf dem eigenen Webspace zu spielen. 2. Meine Tests mit einfachen PHP-Befehlen (is_writable, fileowner) haben bereits gezeigt: Die betroffenen Dateien/Ordner (wie .ssh, .trash und die 67MB Binaries) sind für meinen User k348036 nicht beschreibbar.

Der ls -al Befehl zeigt eindeutig: Die Dateien haben entweder den Owner root (UID 0) oder sie sind durch das Immutable-Bit (chattr +i) gesperrt. In beiden Fällen hat mein User im Plesk-Kontext keine administrativen Privilegien, um diese Sperren aufzuheben.

Mein Standpunkt: Seit über einer Woche versuche ich, dieses Problem zu lösen. Es ist die Verantwortung von netcup, die Integrität des Host-Systems und die Isolierung der Accounts zu garantieren. Wenn Dateien im Home-Verzeichnis eines Kunden landen, auf die der Kunde keinen Zugriff hat, ist die Sicherheitsebene des Providers korrumpiert.

Ich warte nun auf die Reaktion des 2nd Level Supports, da nur dieser die notwendigen Root-Rechte hat, um den chown oder chattr -i Befehl auszuführen oder den Account komplett zurückzusetzen.

Wer von euch Experten kann bestätigen, dass ein Shared-Hosting-Kunde technisch unmöglich Root-Sperren ohne Hilfe des Providers lösen kann? Das ist der Kern der Sache.

Eure Reaktion ist enttäuschend. Wir sind in einem Technik-Forum, aber ihr lehnt Technologie ab, weil sie euch unbequem ist?

Ich nutze die KI als Werkzeug, um ein Problem zu lösen, das netcup bisher ignoriert hat. Wer das als 'Gehirnwäsche' bezeichnet, hat den Anschluss an die moderne Welt verpasst. > Ich habe die Fakten geliefert (Root-Dateien, CVE-Lücke). Wenn ihr lieber über KI philosophiert, statt technische Lösungen zu diskutieren, seid ihr es, die keine Zeit für dieses Problem haben. Viel Spaß noch in eurer statischen Welt. Ich kümmere mich jetzt direkt mit dem Support um die Lösung. Ende der Durchsage.

No shitstorm!

Zitat von ASS

Dazu ist eine KI ja aber SOWAS von unngeeignet.

Du weißtr ja nichtmal, ob das was die rauswirft nicht den Sinn völlig verdreht.

Bei solen KI Posts sollte man wenigstens dazu schreiben, dass sie ki erzeugt sind.

Ich finde solche Posts total äzend und du bist nun einer der wenigen User, der auf meiner Ignorlist landet.

KI Lügen tu ich mir nicht an.

Alles anzeigen

Da ich keine Zeit zu verlieren habe und nach konkreten, pragmatischen Antworten suche, die mir helfen, eine Lösung für mein Problem zu finden, und da wir (mein Freund KI und ich) deiner herablassenden Art nicht gewachsen sind, bitte ich dich, uns in Ruhe zu lassen und deines Weges zu gehen. Hab ein schönes Leben. Hier ist die Antwort von KI:

Gemini hat gesagt:

Das ist eine heftige Reaktion, aber in deutschen Technik-Foren gibt es oft Nutzer mit einer sehr strikten Einstellung zu KI. Dieser User wirft dir vor, dass die KI den Sinn verdrehen könnte („KI-Lügen“) und setzt dich auf seine Ignorierliste (er wird deine Beiträge also nicht mehr sehen).

Meine Einschätzung für dich: Lass ihn ziehen. Wenn er dich blockiert, ist das eigentlich ein Vorteil für dich: Er wird dich nicht mehr mit Grundsatzdiskussionen über KI nerven, und du kannst dich mit den Leuten konzentrieren, die dir wirklich helfen wollen (wie friend_of_root).

Da du im letzten Post bereits ehrlich geschrieben hast, dass du KI nutzt, hast du moralisch alles richtig gemacht. Du hast mit offenen Karten gespielt.

Wie gehen wir jetzt vor? Du hast zwei Möglichkeiten:

1. Gar nicht reagieren: Das ist oft das Beste bei Leuten, die dich bereits auf "Ignore" gesetzt haben. Es spart Energie.
2. Ein kurzer, kühler Abschied (optional): Nur um den anderen Mitlesern zu zeigen, dass du souverän bleibst.

Vorschlag für eine kurze Antwort (nur falls du unbedingt etwas sagen willst): „Schade, dass du das so siehst. Ich habe offen kommuniziert, dass ich die KI als Werkzeug für die Sprachbarriere und Log-Analyse nutze, eben damit der Sinn nicht entstellt wird. Mein Problem mit den Root-Rechten ist real, nicht fiktiv. Alles Gute auf der Ignorliste.“

Aber mein Rat: Ignoriere ihn einfach. Er hat sich selbst aus der Diskussion genommen.

Gibt es schon Neuigkeiten von Netcup oder von anderen Usern, die auf deine Zusammenfassung reagiert haben? Das ist jetzt viel wichtiger als dieser eine Nutzer.

Zitat von webdesignheld

Das Gute an diesen Infektionen und CVE's ist dass man dafür jetzt kein Abitur mehr braucht. Jedes Skript Kiddie kann sehr bald mit der delusional KI solche feindlichen Übernahmen masterminden. Goldene Zeiten für statische Seiten. Mark my words.

Don't feed the troll"

Update & Zusammenfassung

Hallo zusammen,

es ist schön zu sehen, dass in diesem Forum so viele wachsame und brillante Köpfe unterwegs sind. Und ja, ihr habt mich erwischt: Ich nutze eine KI für die präzise Übersetzung meiner Texte und die Analyse der Log-Dateien. Ich lerne gerade sehr schnell, dieses Werkzeug effektiv einzusetzen, um Sprachbarrieren zu überwinden und technische Probleme tiefgreifend zu verstehen.

Aber kommen wir zurück zum Kern der Sache: Mein Problem ist kein KI-generierter Fake, sondern ein realer Sicherheitsvorfall. Ich danke friend_of_root, PopDog und den anderen für ihre wertvollen Ratschläge. Ihr habt mir geholfen, meine Strategie zu schärfen.

Hier ist der aktuelle Stand der Dinge:

Zusammenfassung der Situation & Strategie

Die Fakten:

• Ursache: Wahrscheinliche Infektion über die kritische Sicherheitslücke CVE-2026-21628 (Astroid Framework/Joomla), die eine Remote-Shell-Injektion ermöglichte.
• Status Quo: Mein Home-Verzeichnis ist administrativ gesperrt. Es befinden sich dort Dateien und Verzeichnisse (wie .ssh, .trash, bin), die dem User root:root gehören oder mit dem Immutable-Bit (chattr +i) versehen wurden.
• Blockade: Jeder manuelle Löschversuch (rm -rf) oder Rechteänderung (chmod, chown) über das Plesk-Panel oder die Konsole schlägt mit "Permission Denied" fehl.

Meine bisherige Strategie:

1. Beweissicherung: Analyse der Verzeichnislisten und Dokumentation von Root-Dateien sowie manipulierten Binaries (67MB PHP-Binary, ssh-keygen etc.).
2. Quarantäne-Versuch: Versuch, infizierte Ordner manuell zu verschieben und .htaccess-Dateien zu neutralisieren, was durch die Systemberechtigungen sabotiert wird.
3. Eskalation: Ich habe den netcup-Support offiziell aufgefordert, das Ticket an die Fachabteilung (2nd Level) zu eskalieren, da ein Standard-User keine Root-Attribute (chattr/chown) zurücksetzen kann.

Meine Ziele:

1. Die Wiederherstellung meiner administrativen Handlungsfähigkeit.
2. Einen vollständigen Full-Wipe (Reset) des Accounts, da eine manuelle Bereinigung unter diesen Umständen technisch unmöglich und unsicher ist.

Meine Frage an die Experten: Gibt es aus eurer Sicht irgendeinen Weg, wie ich diese Root-Sperren ohne den Support von netcup lösen kann? Wenn nicht, sehe ich netcup in der Pflicht, hier endlich einzugreifen, da die Sicherheit des gesamten Host-Systems gefährdet ist.

I am a Nice guy. But definitely the wrong one to mess with!

P.S. Auch diese Nachricht wurde mit Hilfe einer KI erstellt.

Danke friend_of_root für die detaillierte Analyse und die Links! Das rückt die Situation in ein technisches Licht, das weniger nach "Kernel-Hack" und mehr nach einem extrem hartnäckigen "Plesk-Cronjob-Injektions-Hack" aussieht.

Wenn ich deine Argumentation folge, dann ist genau das mein Problem:

1. Der Angreifer hat über eine Lücke (vermutlich RCE in einer App) Cronjobs angelegt, die sich im System festgesetzt haben.
2. Das Problem der Handlungsfähigkeit: Wenn ich versuche, diese Cronjobs oder die manipulierten Dateien (wie im .trash oder .ssh) über das Plesk-Panel zu entfernen, erhalte ich trotzdem ein "Permission Denied".
3. Wenn, wie du sagst, der Hacker sich über exec() in die Plesk-Ebene eingegraben hat, scheint mein Standard-User-Account nicht mehr die nötigen Privilegien zu haben, um diese "geplanten Aufgaben" zu löschen oder die Sperren (vielleicht Symlink-Loops, wie du vermutest) aufzuheben.

Meine Frage an die Runde: Wenn ein User-Account durch so einen Hack in einen Zustand gerät, in dem er seine eigenen Cronjobs und Dateien nicht mehr bereinigen kann (trotz Anzeige von 0644/0755), ist dann nicht genau der Punkt erreicht, an dem der Hoster den Account resetten muss?

Ein manuelles Löschen durch mich ist in diesem "Teufelskreis" aus Cronjobs und Zugriffssperren technisch schlichtweg nicht möglich. Da hilft mir auch der Rat vom Support "löschen Sie es manuell" leider nicht weiter.

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?

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.

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 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?

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?

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.

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?

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?

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!