Aktualisieren Sie dringend Exim auf 4.92 – es läuft ein aktiver Befall

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

Potenziell sind mehrere Millionen Server weltweit betroffen, die Schwachstelle wird als kritisch eingeschätzt (CVSS 3.0 Basisbewertung = 9.8/10). Angreifer können willkürliche Befehle auf Ihrem Server ausführen, in vielen Fällen 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.

Update für CentOS 6: siehe Kommentar Theodor — für CentOS 7 funktioniert es ebenfalls, falls es noch nicht direkt aus EPEL verfügbar ist.

UPD: Ubuntu betroffen 18.04 und 18.10, das Update für diese Versionen wurde veröffentlicht. Versionen 16.04 und 19.04 sind nicht betroffen, es sei denn, es wurden benutzerdefinierte Varianten installiert. Weitere Details auf ihrer offiziellen Website.

Informationen zum Problem auf Opennet
Informationen auf der Exim-Website

Das dort beschriebene Problem wird derzeit aktiv ausgenutzt (vermutlich durch einen Bot), ich habe auf einigen meiner Server (die auf 4.91 liefen) eine Infektion festgestellt.

Die nachfolgenden Informationen sind nur relevant für diejenigen, die bereits betroffen sind — es bleibt entweder, alles auf einen sauberen VPS mit neuer Software zu migrieren oder nach einer Lösung zu suchen. Versuchen wir es? Schreiben Sie, wenn jemand diese Malware bekämpfen kann.

Wenn Sie Exim-Benutzer sind und dies lesen, sich aber noch nicht aktualisiert haben (nicht überprüft haben, ob 4.92 oder eine gepatchte Version vorhanden ist), halten Sie bitte an und aktualisieren Sie.

Für die bereits Betroffenen — machen wir weiter…

UPD: supersmile2009 hat eine andere Variante der Malware bei sich gefunden und gibt den richtigen Rat:

Es kann viele verschiedene Malware-Typen geben. Wenn der Benutzer ein Mittel ausführt, das nicht für die richtige Variante gedacht ist, wird er weder die Warteliste bereinigen noch sich vielleicht darum kümmern, wovon er geheilt werden muss.

Eine Infektion ist so bemerkbar: [kthrotlds] belastet die CPU; auf einem schwachen VDS auf 100%, auf schwächeren Servern aber signifikant.

Nach der Infektion entfernt die Malware die Einträge im Cron und hinterlässt nur sich selbst, um alle 4 Minuten ausgeführt zu werden, und macht die Crontab-Datei unveränderlich. Crontab -e kann die Änderungen nicht speichern und gibt einen Fehler aus.

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

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

Dann im Crontab-Editor (vim) die Zeile entfernen und speichern:dd
:wq

Allerdings schreibt ein aktiver Prozess es offenbar erneut zurück, ich bin dabei, das zu klären.

Dabei laufen eine Menge aktiver wget- (oder curl-) Prozesse auf die Adressen aus dem Installationsskript (siehe unten), ich stoppe sie vorübergehend so, 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 Trojaner-Installationsskript wurde hier (centos) gefunden: /usr/local/bin/nptd… ich veröffentliche es nicht zur Vermeidung von Problemen, aber wenn jemand infiziert ist und sich mit Shell-Skripten auskennt, bitte genauer untersuchen.

Ich werde dies ergänzen, sobald ich neue Informationen habe.

UPD 1: Das Löschen von Dateien (mit vorherigem chattr -i) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root hat nicht geholfen, ebenso wie das Anhalten des Dienstes — ich musste den Cron-Tab vorübergehend komplett löschen (den Binärdateinamen umbenennen).

UPD 2: Der Trojaner-Installer lag manchmal auch an anderen Orten, ein Suchauftrag nach der Größe hat geholfen:
find / -size 19825c

UPD 3: Achtung! Neben der Deaktivierung von SELinux fügt der Trojaner auch seinen SSH-Schlüssel in ${sshdir}/authorized_keys! Und aktiviert folgende Felder in /etc/ssh/sshd_config, falls diese noch nicht als YES aufgeführt 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 dringend den Trojaner-Schlüssel aus SSH und ändern Sie die sshd-Konfiguration, starten Sie sshd neu! Und es ist noch ungewiss, ob das helfen wird, aber ohne das ist es wirklich schlimm.

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

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

UPD 6: Paulmann hat ein vorübergehendes Medikament vorbereitet, wir testen! Nach einem Neustart oder Deaktivierung des Medikaments scheint es nicht mehr zu funktionieren, aber immerhin so.

Wer eine stabile Lösung findet (oder erstellt), bitte schreiben Sie, das wird vielen helfen.

UPD 7: Der Benutzer clsv schreibt:

Falls es noch nicht gesagt wurde, der Virus wird durch eine nicht versendete E-Mail an exim wiederbelebt, bei dem erneuten Versuch, die E-Mail zu senden, wird er wiederhergestellt, schauen Sie in /var/spool/exim4.

Die gesamte Warteschlange von exim kann so geleert werden:
exipick -i | xargs exim -Mrm
Überprüfung der Anzahl der Aufzeichnungen in der Warteschlange:
exim -bpc

UPD 8: Nochmals danke für die Informationen, AnotherDenni: FirstVDS hat ihre Version des Skripts zur Behandlung vorgeschlagen, lassen Sie uns testen!

UPD 9: Es scheint, dass an uarch-bench, danke Kirill für das Skript!

Wichtig: Vergessen Sie nicht, dass der Server bereits kompromittiert wurde und die Angreifer möglicherweise noch weitere untypische Schadsoftware (die im Dropper nicht aufgeführt sind) eingeführt haben.

Es ist besser, auf einen frisch installierten Server (VDS) umzuziehen oder zumindest das Thema im Auge zu behalten - wenn etwas Neues kommt, schreibt Kommentare hier, denn offensichtlich werden nicht alle auf eine frische Installation umsteigen...

UPD 10: Nochmals danke clsv: er erinnert daran, dass nicht nur Server infiziert werden, sondern auch Raspberry Pi, und verschiedene virtuelle Maschinen… Vergessen Sie also nach der Rettung der Server nicht, auch Ihre Spielkonsolen, Roboter usw. zu retten.

UPD 11: Von dem Autor des heilenden Skripts eine wichtige Notiz für "manuelle Heiler":
(nach Anwendung einer oder anderen Methode zur Bekämpfung dieses Schadprogramms)

muss unbedingt neu gestartet werden - die Malware sitzt irgendwo in den offenen Prozessen und somit im Speicher und schreibt sich alle 30 Sekunden neu in den Cron.

UPD 12: supersmile2009 fand in seiner Warteschlange ein anderes (?) Schadprogramm in exim und rät, zunächst das spezifische Problem zu untersuchen, bevor die Behandlung beginnt.

UPD 13: lorc empfiehlt schließlich auf ein sauberes System umzuziehen und die Dateien äußerst vorsichtig zu übertragen, da die Malware bereits öffentlich zugänglich ist und von anderen auf weniger offensichtliche und gefährlichere Weise genutzt werden könnte.

UPD 14: sich beruhigend mit dem Gedanken, dass intelligente Menschen nicht aus dem Root-Bereich starten - eine weitere dringende Mitteilung von clsv:

Selbst wenn es nicht unter Root funktioniert, kommt es zu einer Kompromittierung… Auf meinem OrangePi läuft Debian Jessie UPD: Stretch, exim wird von Debian-exim ausgeführt und trotzdem gab es einen Angriff, der Cron und andere Teile gelöscht hat.

UPD 15: Bei der Migration auf einen sauberen Server von einem kompromittierten vergessen Sie nicht die Hygiene, eine nützliche Erinnerung von w0den:

Achten Sie beim Übertragen von Daten nicht nur auf ausführbare oder Konfigurationsdateien, sondern auch auf alles, was schädlichen Code enthalten kann (zum Beispiel kann das in MySQL CREATE TRIGGER oder CREATE EVENT sein). Außerdem, vergessen Sie nicht auf .html, .js, .php, .py und andere öffentliche Dateien (idealerweise sollten diese Dateien, wie auch andere Daten, aus einem lokalen oder einem anderen vertrauenswürdigen Speicher wiederhergestellt werden).

UPD 16: daykkin und savage_me waren mit einem anderen Problem konfrontiert: im System war eine Version von exim auf den Ports, aber tatsächlich wurde eine andere ausgeführt.

Also sollten alle nach dem Update sicherstellen dass sie tatsächlich die neue Version verwenden!

exim --version

Wir haben gemeinsam ihre Situation geklärt.

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

Mit dem DirectAdmin-Paketmanager Custombuild wurde tatsächlich eine neuere Version von Exim installiert, die nun anfällig ist.

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

Vergessen Sie nicht, vor solchen Experimenten Sicherungskopien zu erstellen, und stellen Sie sicher, dass vor/nach dem Update alle Prozesse der alten Exim-Version gestoppt wurden und nicht im Speicher "hängengeblieben" sind.

Quelle: habr.com