Gehackt – Fehler in index.php – ich finde ihn nicht

    Joomla Version
    Joomla 3
    PHP Version
    Unbekannt
    Hoster
    Strato
    Link (URL) zur Seite mit dem Problem
    nicht abrufbar - gesperrt

    Hallo,


    meine Seite wurde gehackt. Es wurden unerwünschte Mails versandt. Die Domains (zwei) im gleichen Paket wurden von Strato gesperrt. Nach den Daten müsste die das Problem in >Domain >index.php liegen.

    Ich habe ein Backup aufgespielt. Trotzdem teilt Strato mir mit, dass das Problem nach wie vor in der index.php besteht. Mangels Programmierkenntnisse finde ich das Problem nicht.

    Kann mir jemand helfen und die index.php anschauen? Oder andere Frage: Gibt es eine Standard-index.php, die man aufspielen kann und mit der die Homepage trotzdem läuft.

    Danke.


    Index.php:

    .....

    Zitat von frieder

    Ich habe ein Backup aufgespielt. Trotzdem teilt Strato mir mit, dass das Problem nach wie vor in der index.php besteht. Mangels Programmierkenntnisse finde ich das Problem nicht.

    Kann mir jemand helfen und die index.php anschauen? Oder andere Frage: Gibt es eine Standard-index.php, die man aufspielen kann und mit der die Homepage trotzdem läuft.

    Ohne Analyse des Hacks ist die Vorgehensweise fahrlässig. Ich kenne keinen einzigen Hack (und habe schon hunderte untersucht), wo nur eine Datei kompromittiert ist.
    Ganz kurz: Erst-Hack druch Analyse ermittelt und dann ien Backup von VOR dem Hack aufspielen. Danach alle Sicherheitslücken schießen

    Komplexer: Meine Website wurde gehackt - was tun?

    Also auf Anhieb kann ich am Inhalt nichts ungewöhnliches feststellen.

    Datei lokal sichern und dann auf dem Webspace löschen.

    Warte dann was Strato dazu sagt.


    Ich denke dass es nicht nur eine index.php Geschichte ist.


    Da wohl auch deine Postfächer gehackt wurden ist der Anleitung von flotte dringend zu folgen!

    Danke für die Antworten, auf die ich nur laienhaft antworten kann. Ich habe gesehen dass einige Dateien am 4.12.2023 geändert wurden. Ich habe auf meinem Webspace nur die Ordner belassen (NACHTRAG: DARIN ABER ALLE INHALTE GELÖSCHT). Also je ein Ordner für die beiden Domains. Die cgi-bin ganz geleert. Und ein Ordner für die akeeba-Sicherung mit Inhalt belassen. Komplettes Backup von Ende November für beide Domains aufgespielt. Strato meldet, dass weiter die index.php im Pfad >OrnderDomain1 >index.php den Fehler verursacht.


    Jetzt habe ich gerade eine index.php mit Datum Sommer 2023 in einem Backup von Anf. November gefunden und aufgespielt und bei Strato einen neuen Scan beantragt. Läuft zur Zeit. Übrigens die cgi-bin ist weiter leer. Wenn wieder ein Fehler gemeldet wird, werde ich wie von WM-Loose geschrieben, die index.php mal sichern und ersatzlos auf dem Server löschen.

    Die Datenbanken habe ich bisher nicht gelöscht, sondern nur neue Passwörter vergeben. Wie ich diese leeren kann, ist mir aber nicht bekannt. Oder ist es einfach über ftp die Inhalte der Ordner zu löschen. Das habe ich bereits gemacht.

    Danke.

    Im Ernst Leute:
    Wer keinen Hack eindeutig analysieren kann und auch keinen Profi beauftragen möchte, sollte seine Seite unbedingt neu machen und alles löschen und überall neue Passwörter verwenden.

    Und Voraussetzung für eine Analyse sind die originalen Webserverlogs und unveränderte Files in Webspace. Wer blind einfach schon mal ein Backup drübergebügel hat, kann sich die Analyse auch schenken.

    Leider erschweren auch DSGVO-Vorgaben wie das Entfernen von IPs nach wenigen Tagen, die eindeutige Analyse ungemein. Ältere Hacks kann man daher nur ganz selten wirklich analysieren. Das nur nebenbei.


    Quasi alle "Selbstbereinigsversuche" die wir so im Lauf der Jahre beobachten konnten sind gescheitert. Auch die Angaben die großen Massenhoster, die sich oft auf einige wenige Dateien beziehen, die deren Schadcodescanner zufälligerweise als kompromittiert erkennen, sind kontraproduktiv. Das suggerriert nur, das man die Files ersetzen muss und damit Problem erledigt ist. Typische Schadcodescanner erkennen zudem nur ein Bruchteil möglicher Hacks. Das liegt einfach daran, dass ein simpler Einzeiler, versteckt in irgend einer PHP-Datei schon eine Backdoor realisieren kann. Der Code ist unauffällig und könnte in ähnlicher Form ganz legal in php-Datein auftauchen.

    Die Datenbankinhalte werden in deinem Kundenaccount mit phpmyadmin bearbeitet.

    Damit kannst du auch alle Inhalte der DB löschen.


    Zitat von flotte

    Im Ernst Leute:
    Wer keinen Hack eindeutig analysieren kann und auch keinen Profi beauftragen möchte, sollte seine Seite unbedingt neu machen und alles löschen und überall neue Passwörter verwenden.

    Und Voraussetzung für eine Analyse sind die originalen Webserverlogs und unveränderte Files in Webspace. Wer blind einfach schon mal ein Backup drübergebügel hat, kann sich die Analyse auch schenken.

    Leider erschweren auch DSGVO-Vorgaben wie das Entfernen von IPs nach wenigen Tagen, die eindeutige Analyse ungemein. Ältere Hacks kann man daher nur ganz selten wirklich analysieren. Das nur nebenbei.


    Quasi alle "Selbstbereinigsversuche" die wir so im Lauf der Jahre beobachten konnten sind gescheitert. Auch die Angaben die großen Massenhoster, die sich oft auf einige wenige Dateien beziehen, die deren Schadcodescanner zufälligerweise als kompromittiert erkennen, sind kontraproduktiv. Das suggerriert nur, das man die Files ersetzen muss und damit Problem erledigt ist. Typische Schadcodescanner erkennen zudem nur ein Bruchteil möglicher Hacks. Das liegt einfach daran, dass ein simpler Einzeiler, versteckt in irgend einer PHP-Datei schon eine Backdoor realisieren kann. Der Code ist unauffällig und könnte in ähnlicher Form ganz legal in php-Datein auftauchen.

    Damit ist wirklich alles gesagt.

    Der Scann bei Strato ist noch nicht vorbei. Ich habe aber vermutlich etwas nicht gemeldet. Die index.php im Startbeitrag, sah auf dem server so aus wie von mir in den Beitrag kopiert. Allerdings habe ich "wirren Buchstabensalat" vorher gelöscht. Als ich den kopierten Inhalt der index.php in meine Textverarbeitung lud, ergab sich das Bild laut Anlage.

    Ich versteh dich - eine gehackte Seite ist wirklich ein Alptraum und woher sollst du auch wissen, wie man damit umgeht?

    Aber bastle da nicht weiter herum.

    Wenn die Seite für dich sehr wichtig ist dann beauftrage einen Profi mit der Sanierung - du holst ja auch einen Klempner wenn dein Wasserrohr bricht, oder?

    Dienstleisterverzeichnis gibt es rechts oben.

    Wenn du genug Zeit hast dann lösche den gesamtem Webspace einschließlich der Datenbank und baue dir eine neue Seite.

    firstlady , danke. Darauf wird es hinauslaufen. Seite ist zwar mit etwas Einnahmen, aber mehr Hobby. Und ich habe eigentlich die Inhalt schon längst rauskopiert und werde sie (nicht auf Joomla4 oder 5) auf Wordpress einstellen. Ich habs immer vor mir hergeschoben. Vermutlich musste das jetzt passieren. Ich versuch jetzt noch ein paar Dinge (von denen ich keine Ahnung habe), werde mich dann aber auf das Neuaufsetzen der Seite machen.

    kitepascal , ja die zweite Domain ist Wordpress. Aber warum wird der Fehler für die erste Domain (Joomla) angezeigt. Wordpress dürfte dann doch sicher sein. Wird aber zur Zeit auch gesperrt, vermutlich weil im gleichen Webspace.

    Ja ich hatte zwar nicht unbedingt ein leichtes aber das gleiche Passwort seit einem Jahr. Newsletter nutze ich nicht.

    Danke.

    Potenziell ist der ganze Webspace gefährdet, heißt auch die WordPress Installation oder umgekehrt, weil sich Schadcode meist vermehrt in Form von Backdoors (weitere Schaddateien, die in die Verzeichnis Tiefen gestreut werden). Heißt der Angreifer behält Zugriff, verändert die index.php wahrscheinlich immer wieder, wenn du nicht alles erwischst oder das Backup 100% sauber ist, bevor du alle Passwörter änderst.

    Evt. würdest du gut und stressfreier damit fahren, jmd 1-2 h für die Problemlösung zu beauftragen.

    Ich hätte jetzt noch eine blöde Frage:

    Ich möchte Joomla3 in einen neuen Ordner mit einer neuen Bezeichnung, neuer Datenbank installieren. Dort über akeeba den alten Inhalt der Domain einspielen. Die akeeba-Daten habe ich natürlich auch in meinem Webspace gespeichert!?
    Besteht eine Wahrscheinlichkeit, dass sich der Virus dort nicht gleich einnistet? Ich brauche einige Tage, bis ich danach alles auf Wordpress umgestellt habe.


    Danke.