Aktualisieren Sie dringend Exim auf 4.92 – es gibt aktive Infektionen.

Kollegen, die Exim-Versionen 4.87…4.91 auf ihren Mailservern verwenden — aktualisieren Sie dringend auf Version 4.92, nachdem Sie Exim gestoppt haben, um eine Kompromittierung durch CVE-2019-10149 zu vermeiden.

Potenziell sind mehrere Millionen Server auf der ganzen Welt betroffen, die Schwachstelle wird als kritisch eingestuft (CVSS 3.0 Grundwert = 9,8/10). Angreifer können auf Ihrem Server beliebige Befehle ausführen, oft mit Root-Rechten.

Bitte stellen Sie sicher, dass Sie die korrigierte Version (4.92) oder bereits gepatchte verwenden.
Oder patchen Sie die bestehende, siehe den Thread Kommentar immaculate.

Updates für CentOS 6: siehe Kommentar von Theodor — für CentOS 7 funktioniert es auch, falls es noch nicht direkt aus EPEL angekommen ist.

UPD: Ubuntu betroffen 18.04 und 18.10, ein Update dafür wurde veröffentlicht. Die Versionen 16.04 und 19.04 sind nicht betroffen, es sei denn, es wurden benutzerdefinierte Varianten installiert. Mehr dazu auf ihrer offiziellen Webseite.

Informationen zu dem Problem auf Opennet
Informationen auf der Exim-Website

Das dort beschriebene Problem wird derzeit aktiv ausgebeutet (von einem Bot, wie man annehmen kann), ich habe auf einigen meiner Server (die auf 4.91 liefen) eine Infizierung festgestellt.

Das Folgende ist nur für diejenigen relevant, die bereits „betroffen“ sind — entweder alles auf eine neue VPS mit aktueller Software umziehen oder nach einer Lösung suchen. Versuchen wir es? Schreiben Sie, wenn jemand in der Lage ist, diese Malware zu bekämpfen.

Wenn Sie, als Benutzer von Exim, dies lesen und sich noch nicht auf Version 4.92 oder eine gepatchte Version aktualisiert haben, bitte stoppen Sie und gehen Sie sofort aktualisieren.

Für diejenigen, die bereits betroffen sind — fahren wir fort…

UPD: supersmile2009 hat eine andere Art von Malware bei sich gefunden und gibt den richtigen Rat:

Es kann eine Vielzahl von Bedrohungen geben. Wenn das falsche Tool gestartet wird und die Warteschlange aufgeräumt wird, wird der Benutzer weder geheilt noch erfährt er, wovon er geheilt werden muss.

Eine Infizierung ist so sichtbar: [kthrotlds] belastet die CPU; auf einer schwachen VDS zu 100 %, auf schwächeren Servern aber merklich.

Nach der Infektion entfernt die Malware Einträge im Cron und trägt dort nur sich selbst ein, die alle 4 Minuten ausgeführt werden, wobei die Crontab-Datei als unveränderlich markiert wird. Crontab -e kann Änderungen nicht speichern, gibt einen Fehler aus.

Unveränderlich kann man beispielsweise so entfernen, um danach die Befehlszeile zu löschen (1,5 KB):

chattr -i /var/spool/cron/root
crontab -e

Dann im Crontab-Editor (vim) die Zeile löschen und speichern:dd
:wq

Ein aktiver Prozess überschreibt jedoch erneut, ich arbeite daran.

Dabei hängen viele aktive wget- (oder curl-) Prozesse an den Adressen des Installationsskripts (siehe unten). Ich stoppe sie vorerst, aber sie starten wieder:

ps aux | grep wge[t]
ps aux | grep cur[l]
echo "Stopping..."
kill -9 `ps aux | grep wge[t] | awk '{print $2}'`
kill -9 `ps aux | grep cur[l] | awk '{print $2}'`

Das Installationsskript des Trojaners wurde hier (centos) gefunden: /usr/local/bin/nptd… ich veröffentliche es nicht, um Schwierigkeiten zu vermeiden, aber falls jemand infiziert ist und sich mit Shell-Skripts auskennt, bitte genauer untersuchen.

Ich werde die Informationen bei Updates ergänzen.

UPD 1: Das Löschen von Dateien (nach vorherigem chattr -i) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root hat nicht geholfen, auch nicht das Stoppen des Dienstes — ich musste das Crontab vorerst komplett entfernen (bin-Datei umbenennen).

UPD 2: Der Trojaner-Installer fand manchmal auch an anderen Orten Zuflucht, eine Suche nach Größe half:
find / -size 19825c

UPD 3: Achtung! Neben der Deaktivierung von selinux fügt der Trojaner auch seinen SSH-Schlüssel in ${sshdir}/authorized_keys hinzu! Und aktiviert die folgenden Felder in /etc/ssh/sshd_config, wenn sie noch nicht als YES eingetragen sind:
PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes
echo UsePAM yes
PasswordAuthentication yes

UPD 4: Zusammenfassend bisher: Deaktivieren Sie exim, cron (mit Root-Rechten), entfernen Sie schnell den Trojaner-Schlüssel aus dem SSH und bearbeiten Sie die sshd-Konfiguration, starten Sie sshd neu! Und auch das ist noch nicht sicher, ob es hilft, aber ohne das ist es wirklich katastrophal.

Wichtige Informationen aus den Kommentaren zu Patches/Updates habe ich an den Anfang der Notiz verschoben, damit die Leser dort beginnen.

UPD 5: AnotherDenni schreibt dass Malware die Passwörter in WordPress geändert hat.

UPD 6: Paulmann hat ein vorübergehendes Mittel vorbereitet, wir testen! Nach einem Neustart oder Deaktivierung des Mittels scheint es zu verschwinden, aber vorerst hilft es zumindest.

Wer eine stabile Lösung findet (oder erstellt), bitte melden, vielen wird geholfen.

UPD 7: Benutzer clsv schreibt:

Falls es noch nicht erwähnt wurde, der Virus wird durch eine nicht gesendete E-Mail in exim wiederbelebt, bei einem erneuten Versuch, die E-Mail zu senden, wird er wiederhergestellt, schauen Sie in /var/spool/exim4.

Die gesamte exim-Warteschlange kann so gelöscht werden:
exipick -i | xargs exim -Mrm
Überprüfung der Anzahl der Einträge in der Warteschlange:
exim -bpc

UPD 8: Wieder danke für die Informationen, AnotherDenni: FirstVDS hat seine Version des Skripts zur Behebung angeboten, lasst uns testen!

UPD 9: Es scheint, dass mit einem einzigen Thread arbeitet., danke Kirill für das Skript!

Wichtig ist, dass der Server bereits kompromittiert wurde und Angreifer möglicherweise noch andere atypische Schadstoffe (die nicht im Dropper aufgeführt sind) installiert haben.

Deshalb ist es besser, auf einen frisch installierten Server (VDS) umzuziehen oder zumindest das Thema weiter zu verfolgen – wenn es neue Entwicklungen gibt, schreibt hier in die Kommentare, da offensichtlich nicht alle auf eine frische Installation umziehen werden.

UPD 10: Nochmals danke clsv: er erinnert daran, dass nicht nur Server, sondern zum Beispiel auch Raspberry Piund verschiedene virtuelle Maschinen infektiös werden können… Also vergesst nicht, nach der Rettung der Server auch eure Set-Top-Boxen, Roboter usw. zu schützen.

UPD 11: Von dem Autor des heilenden Skripts eine wichtige Anmerkung für diejenigen, die «manuell heilen»:
Nach der Anwendung einer bestimmten Methode zur Bekämpfung dieser Malware

muss man unbedingt neu starten – die Malware sitzt irgendwo in den offenen Prozessen und entsprechend im Speicher und schreibt sich alle 30 Sekunden neu in den Cron.

UPD 12: supersmile2009 hat in seiner Warteschlange exim eine andere(?) Malware gefunden und rät zunächst, sein spezifisches Problem zu analysieren, bevor man mit der Behandlung beginnt.

UPD 13: lorc empfiehlt Es ist besser, auf ein sauberes System umzusteigen und die Dateien sehr vorsichtig zu übertragen, da Malware bereits öffentlich zugänglich ist und auf weniger offensichtliche und gefährlichere Weise verwendet werden kann.

UPD 14: sich beruhigend, dass intelligente Menschen von Root aus nicht starten – noch eine. Dringende Nachricht von clsv:

Selbst wenn es nicht unter Root ausgeführt wird, kommt es zu einem Hacking… Ich habe Debian Jessie auf OrangePi, UPD: Stretch, Exim läuft unter Debian-Exim und es gab trotzdem ein Hacking, Cron und anderes wurde gelöscht.

UPD 15: beim Umzug auf einen sauberen Server von einem kompromittierten, vergesst nicht die Hygiene. Nützliche Erinnerung von w0den:

Achtet beim Datenübertragen nicht nur auf ausführbare oder Konfigurationsdateien, sondern auch auf alles, was schädliche Befehle enthalten könnte (zum Beispiel kann das in MySQL CREATE TRIGGER oder CREATE EVENT sein). Vergesst auch .html, .js, .php, .py und andere öffentliche Dateien nicht (idealerweise sollten diese Dateien, wie andere Daten, aus einem lokalen oder einem anderen vertrauenswürdigen Speicher wiederhergestellt werden).

UPD 16: daykkin und savage_me wir sind auf ein anderes Problem gestoßen: im System war eine Version von Exim auf den Ports installiert, tatsächlich wurde jedoch eine andere ausgeführt.

Also an alle Nach dem Update sollten Sie sicherstellen dass Sie tatsächlich die neue Version verwenden!

exim --version

Wir haben gemeinsam die Situation geklärt.

Auf dem Server wurde DirectAdmin verwendet, und es war das alte Paket da_exim (alte Version ohne Schwachstelle) installiert.

Darüber hinaus wurde über den Custombuild-Paketmanager von DirectAdmin eine neuere, bereits verwundbare Version von Exim installiert.

In dieser speziellen Situation half auch das Update über Custombuild.

Vergessen Sie nicht, vorher Backups zu machen, und stellen Sie sicher, dass vor und nach dem Update alle Prozesse der alten Exim-Version gestoppt wurden und nicht im Speicher ‚hängen geblieben‘ sind.

Quelle: habr.com