KRITISCH: Gehacktes Webhosting – Support reagiert nicht

    Zitat von terence

    Zuerst das Datum, wann das Hosting erstellt wurde und danach das der rsa-Dateien

    ich hab #81 editiert.

    so wie es aussieht, kann man am /error_docs-directory die erstellung des webhostings erkennen.
    bei mir stimmt es zumindest bei 3 von 4.
    bei zweien gibt es rsa-keys mit identischem datum zum /error_docs,
    bei einem sind die keys 3 tage älter und
    beim ältesten gibt es nur die authorized_keys (ich kann mich auch nicht erinnern, die gelöscht zu haben).

    und du hast deine keys nie angefasst?

    »Hauptsache BogoMIPS!«
    Volksfront DLT #64Ksplit
    Sag' NEIN zu Wordpress

    2 Mal editiert, zuletzt von Olivetti (31. März 2026 um 20:50)

    mir geht's ja jetzt darum, wie ich prüfen kann, ob z.b. die original-keys etc. manipuliert wurden – d.h. gibt es möglicherweise
    feste regeln und verfahren, wie webhostings angelegt werden.

    und der TS antwortet ja eh' nicht auf aufforderungen, um zumindest weitere lösungsmöglichkeiten in betracht zu ziehen (z.b. chattr).

    »Hauptsache BogoMIPS!«
    Volksfront DLT #64Ksplit
    Sag' NEIN zu Wordpress

    3 Mal editiert, zuletzt von Olivetti (31. März 2026 um 21:03)

    Zitat von Olivetti

    so wie es aussieht, kann man am /error_docs-directory die erstellung des webhostings erkennen.

    Ja, bei mir stimmt das Datum des error-Verzeichnis auch mit dem Erstellungsdatum aus dem CCP überein, welches ich oben verwendet hatte.

    Zitat von Olivetti

    und du hast deine keys nie angefasst?

    Es kann sein, daß ich die Keys von 2019 damals selbst erstellt hatte, um Dateien von da auf ein anderes WH zu schieben. Aber bei den anderen Servern bin ich mir ziemlich sicher, daß ich da nichts gemacht habe. Vielleicht wurden die mal per Job erneuert um längere Keys zu verwenden? Keine Ahnung.

    Von wann sind denn Deine Hostings?

    [Suche] RS Piccolo gesucht

    Einmal editiert, zuletzt von terence (31. März 2026 um 21:08) aus folgendem Grund: Typos

    schade. ich sehe leider, das datum des /error_docs stimmt nicht wirklich mit dem bereitstellungsdatum überein (außer natürlich das jahr).

    Zitat von terence

    Mal sehen, ob da neue entstehen.

    ich denke, die werden nur beim bereitstellen des WHs erzeugt.

    »Hauptsache BogoMIPS!«
    Volksfront DLT #64Ksplit
    Sag' NEIN zu Wordpress

    2 Mal editiert, zuletzt von Olivetti (31. März 2026 um 21:35)

    Moin,

    Ich bin über dieses Thema gestolpert, weil ich einen Hosting-Account mit einer kleinen Firmen-Homepage für meine Frau verwalte und diese genau von dem erwähnten CVE-2026-21628 (Astroid Framework/Joomla) betroffen war.

    Allerdings stellte sich das ganze bei mir alles etwas anders dar, als vom Themen-Initiator beschrieben.
    Wir wurden darauf aufmerksam gemacht, dass die Homepage einen Fehler meldet und "irgendwie gehackt" scheint. Als ich nun nachschaute, bekam ich beim Aufruf der Joomla-Admin-Seite einen HTTP 403 (Forbidden). Per FTP kam ich drauf und auch über das CCP/Plesk. Bis auf haufenweise kryptische Dateinamen und Verzeichnisse im httpdocs Verzeichnis sah alles normal aus. Das heißt unter den anderen Ordner (.ssh, etc usw.) war nix verändert worden.
    Also wollte ich erstmal httpdocs leeren, um dann ein Backup einzuspielen und abzusichern, aber ich war ausgesperrt - genau wie es der Themen-Initiator schilderte. Ich bekam per FTP und Plesk-Dateimanager immer nur "Permission Denied".

    Ich versuchte die von friend_of_root ins Thema geschriebenen PHP-Scripte zu benutzen (Stichwort: Selben Rechte wie der Angreifer) ... allerdings konnte ich in httpdocs auch keine neuen Dateien anlegen/hochladen.

    Ich habe dann den SSH-Zugang aktiviert, um mit meinem leicht eingerostetem Linuxianisch mal zu schauen. Leider sind auf dem eingeschränkten Hosting-Account viele der Bash-Befehle (z.b. stat, lsattr usw) unbekannt, deshalb kann ich Euch auch die früher im Thema erfragten Outputs nicht liefern. Aber ich kam letztendlich dahinter, dass mir lediglich die Schreibrechte genommen worden waren. Das heißt der gesamte httpdocs Ordner und alle Dateien und Ordner darin war auf Berechtigung 555 (also nur lesen und ausführen für alle).

    Somit konnte ich letztendlich mit einem simplen chmod -R 755 ./httpdocs per SSH Terminal mir wieder Zugriff verschaffen und kann nun das Backup einspielen.

    das ist doch mal ein super feedback!

    gut vorstellbar, dass bei einem 'hack' die write permissions via chmod entfernt werden. das ist die simpelste art, die ein user selbst auf seine eigenen Dateien ausführen kann (zB auch via php), um diese erstmal vor dem überschreiben zu schützen.

    das war dann aber halt teil der attacke und nicht der support :)

    und ja, Linux permissions können tricky sein.

    Und es bestätigt, dass es geholfen hätte, einfach mal in Ruhe die Verzeichnisse und ihre Rechte anzusehen, wie es hier mehrfach gefordert wurde. Dann wäre man dem Problem und der Lösung sicherlich schnell auf die Spur gekommen, und das Herumhacken auf dem Support wäre nicht nötig gewesen.

    Muss mich hier mit einschalten.


    Bin seit Oktober Nutzer aber habe seit dem einen Virus drauf ich weiß nicht was passiert ist. Ich kann nix löschen der Virus hat scheinbar alles blockiert. Ich habe die Rechte auf 777 gesetzt dennoch geht nichts

    Was kann ich tun


    Support gibt immer allgemeine Antworten "alles Löschen"