Schadcode auf Server

Nun, habe wieder vom Hoster eine Meldung bekommen in Bezug Schadcode :

'xxxxxx/components/com_users/SysManager.php'
# Known exploit = [Fingerprint Match] [PHP Shell Exploit [P0001]]

'xxxxxx/plugins/twofactorauth/totp/tmpl/backup.php'
# (decoded file [depth: 3]) Known exploit = [Fingerprint Match] [PHP Obfuscation Exploit [P0835]]

D.h. der Server wird regelmässig über Nacht gescannt und plötzlich waren diese Files da

Gibt es irgend einen Hinweise in Logs oder wie und wann genau (IP-Addresse) der diese Scheisse wie auch immer schreiben resp. hochladen kann?

BTW: Habe einen Cront Job der von extern meine NewsLetter versendet. Könnte der sowas einschleusen?

Hp

Vielleicht hilft dir der Vortrag von Christian Schmidt am J!DD 16 in Leipzig weiter:



Du musst dir aber bewusst sein, dass die Säuberung einer gehackten Seite einiges an Fachkennnissen voraussetzt. Wenn du nicht jemanden beauftragen kannst ($$), bleibt nur plattmachen und neubauen. Ich gehe davon aus, dass kein sauberer Backup existiert?

PS: Der Cronjob, den du erwähnst darf eigentlich nichts weiter machen, als in festgelegten Zeitabständen ein bestimmtes PHP File ausführen. Solange selbiges nicht einen Bock hat, müsste der Cron eigentlich unschuldig sein.
Selbstverständlich sagen dir die Serverlogs, wer wann was gemacht hat, ohne spezielle Tools und das notwendige Wissen glaube ich nicht, dass du da Schlüsse ziehen kannst. Christian Schmidt hat dazu in seinem Vorttrag übrigens einen Tipp.

Danke für den Hinweis!

Ja mit WinMerge zu spielen war auch schon eine Idee. Wobei mir keine Admin Tools mehr installiert werden, denn damit hat sich das Problem möglicherweise im zusammenhang mit dem 2.4.7 Explot multipliziert.

Backup macht der Provider, eber eben, wann hat die Seuche angefangen ist die Gretchenfrage.

Zudem immer ein Restore auf ein Blanken Folder gemacht werden sollte.

Auch verstehe ich nicht warum es nichts gibt dass man den Kontent (welcher ja nur aus Text Files sind, ausser Bilder oder download Zip's etc) vergleichen kann und jedes File (php oder java-script) untereinander mit MD5 vergleicht sowie dessen File welche da sein müssen oder eben welche nicht.

Zudem sprechen wir noch nicht über Server Travers Gegebenheiten :woohoo:

Hp

Mit diesem letzten Post von dir bin ich raus aus der Nummer.

wann hat die Seuche angefangen ist die Gretchenfrage

Check mal das Erstellungsdatum dieser Dateien. Das wäre mal ein Anhaltspunkt. Ist dieses nicht manipuliert lässt sich zusammen mit dem Access-Log so ev. sogar die Lücke selbst finden.

Ich verwende meist dieses Script , um verseuchte Dateien zu finden. Falls das mal nötig ist. Es gibt zwar auch sehr viele Resultate aus, wo z.B. ein 'eval' oder 'base64' legitim sind (die Funktion 'base64' wird z.B. u.a. bei Joomlas Redirects verwendet), was aber kein Problem ist, wenn man den Code einigermassen kennt.

Wir hatten erst vor zwei Wochen ein Neu-Kunde, der mit einer gehackten Seite zu uns migrierte. Backup war keines vorhanden. Die Seite mit dem Script gesäubert (waren ca. 15 Dateien verteilt auf das ganze System), alle Extensions akualisiert, entfernt was nicht gebraucht wurde, und fertig. Die Seite läuft seither wieder stabil, obwohl sie nach dem Umzug von aussen her (auch für den Hacker) immer noch unter derselben Domain erreichbar ist.

Nebenbei: Inhalte/Content in Joomla sind Datenbankeinträge, nicht Files.

Danke mal für den Hinweis auf das script! Leider ist das von 2014 ....

Was mit im Zusammenhang mit dem

- SysManager.php: Timestamp von 2016 Sep13 6 AM
- backup.php; Timestamp 2016 21 Jun 03:28 PM

Am 27 Nov auf die Files:

1. Mit PUT 200 status (dachte zuerst PUT = puting some files )
2. Schadcode Meldung Abends wurde dies am und gleich gesperrt!
3. Man konnte dann im Server log die repetiven GET 403 Zugriffe sehen

Für den Hoster sieht das nach einem Joomla Exploit aus...

Ich werde mal das Script starten und sehen was da abgeht...

BTW: Mod-Security is Aktive

Leider ist das von 2014

Das spielt keine Rolle, denn die PHP-Funktionsnamen, nach denen gescannt wird, sind immer noch dieselben. Und wär's nicht zu gebrauchen, hätt ich es auch kaum gepostet

Und den Rest von deinem Post verstehe ich schlichtweg gar nicht.

Nochmals,

auf die Files :

- SysManager.php: Timestamp von 2016 Sep13 6 AM
- backup.php; Timestamp 2016 21 Jun 03:28 PM

wurden vom Hoster der Zugriff am 27 Nov 2016 Abends verweigert, da diese in den täglichen Scans bemerkt wurde.

Vor der Blockierung (am gleichen Tag) habe ich im Log PUT 200 Zugriffe auf diese Files gesehen... vorher gabs die nicht ev. gar nicht da auch in älteren Logs nix gesehen.

Heist für mich, dass diese Files erst am 27 Nov erschienen sind (trotz älterem TimeStamp dieser Files).

Nach dem blockieren habe ich im Log verschieden Versuche gesehen diese Dateien mit GET 403 zu lesen.

Nun ist die Seuche total

Das Ganze scheint mit /components/com_users/auth.class.php
github.com/liamjack/Auth angefangen zu haben und am Ende war dieses dann nicht mehr auf dem Server. Nur gesehen hat man es im Log. Proscht

Ich denke fange von VORNE an... Kontent export und Import wäre gefragt :-X

Ist ja wie bein Win 3.1 Uhr-Design ohne Sicherheitskonzept by design... :woohoo:



Hp

Das Sicherheitskonzept heisst 'Updates'. Ich bin mir ziemlich sicher, das zum Zeitpunkt des Hacks deine J nicht in der neusten Version war, oder?

Wieso Content Im- und Export? Falls die Datenbank nicht betroffen ist, reicht es ja alle Files zu löschen und ein neues, Joomla-Full-Pakage derselben Version hochzuladen (ohne Installationsordner). Configuration.php erstellen/kopieren. Wirklich säubern müsstest du dann nur noch die Files der zus. Erweiterungen. Diese dann auch noch rüberkopieren, alles aktualisieren, fertig.

Oder eben, von vorne anfangen.