Kollegen, die die Exim-Versionen 4.87...4.91 auf ihren Mailservern verwenden – aktualisieren dringend auf Version 4.92, nachdem sie zuvor Exim selbst gestoppt haben, um Hackerangriffe durch CVE-2019-10149 zu vermeiden.
Mehrere Millionen Server auf der ganzen Welt sind potenziell anfällig, die Schwachstelle wird als kritisch eingestuft (CVSS 3.0-Basiswert = 9.8/10). Angreifer können beliebige Befehle auf Ihrem Server ausführen, in vielen Fällen von Root aus.
Bitte stellen Sie sicher, dass Sie eine feste oder bereits gepatchte Version (4.92) verwenden.
Oder patchen Sie das vorhandene, siehe Thread .
Update für CentOS 6: cm. — für Centos 7 funktioniert es auch, wenn es noch nicht direkt von Epel angekommen ist.
UPD: Ubuntu ist betroffen 18.04 und 18.10Für sie wurde ein Update veröffentlicht. Die Versionen 16.04 und 19.04 sind nicht betroffen, es sei denn, auf ihnen wurden benutzerdefinierte Optionen installiert. Mehr Details .
Da das dort beschriebene Problem nun aktiv ausgenutzt wird (vermutlich durch einen Bot), ist mir auf einigen Servern (die unter 4.91 laufen) eine Infektion aufgefallen.
Weiterführende Lektüre ist nur für diejenigen relevant, die es bereits „verstanden“ haben – Sie müssen entweder alles auf einen sauberen VPS mit frischer Software transportieren oder nach einer Lösung suchen. Sollen wir es probieren? Schreiben Sie, ob jemand diese Malware überwinden kann.
Wenn Sie als Exim-Benutzer dies lesen und immer noch nicht aktualisiert haben (nicht sichergestellt haben, dass 4.92 oder eine gepatchte Version verfügbar ist), stoppen Sie bitte und führen Sie die Aktualisierung aus.
Für diejenigen, die es bereits geschafft haben: Weiter geht’s...
UPD: und gibt den richtigen Rat:
Es kann eine große Vielfalt an Malware geben. Durch die Verabreichung des Arzneimittels für das Falsche und das Löschen der Warteschlange wird der Benutzer nicht geheilt und weiß möglicherweise nicht, wofür er behandelt werden muss.
Die Infektion macht sich folgendermaßen bemerkbar: [kthrotlds] lädt den Prozessor; Auf einem schwachen VDS beträgt er 100 %, auf Servern ist er schwächer, aber spürbar.
Nach der Infektion löscht die Malware Cron-Einträge und registriert sich nur dort, um alle 4 Minuten ausgeführt zu werden, während die Crontab-Datei unveränderlich gemacht wird. Crontab -e Änderungen können nicht gespeichert werden, gibt einen Fehler aus.
Immutable kann beispielsweise wie folgt entfernt und anschließend über die Befehlszeile (1.5 KB) gelöscht werden:
chattr -i /var/spool/cron/root
crontab -e
Als nächstes löschen Sie im Crontab-Editor (vim) die Zeile und speichern:dd
:wq
Allerdings werden einige der aktiven Prozesse wieder überschrieben, ich bin gerade dabei, es herauszubekommen.
Gleichzeitig hängen eine Reihe aktiver Wgets (oder Curls) an den Adressen aus dem Installationsskript (siehe unten). Ich schalte sie vorerst so aus, aber sie beginnen erneut:
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}'`
Ich habe das Trojaner-Installationsskript hier gefunden (Centos): /usr/local/bin/nptd... Ich poste es nicht, um es zu vermeiden, aber wenn jemand infiziert ist und Shell-Skripte versteht, lesen Sie es bitte genauer.
Ich werde hinzufügen, sobald die Informationen aktualisiert werden.
UPD 1: Das Löschen von Dateien (mit vorläufigem chattr -i) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root hat weder geholfen, noch hat das Stoppen des Dienstes geholfen – ich musste crontab vorerst komplett entfernen (bin-Datei umbenennen).
UPD 2: Der Trojaner-Installer lag manchmal auch an anderen Stellen herum, die Suche nach Größe hat geholfen:
Fund / -Größe 19825c
UPD 3: Achtung! Der Trojaner deaktiviert nicht nur Selinux, sondern fügt auch sein eigenes hinzu SSH-Schlüssel in ${sshdir}/authorized_keys! Und aktiviert die folgenden Felder in /etc/ssh/sshd_config, sofern diese nicht bereits auf JA gesetzt wurden:
PermitRootLogin ja
RSAAuthentication ja
PubkeyAuthentication ja
echo UsePAM ja
PasswortAuthentifizierung ja
UPD 4: Um es vorerst zusammenzufassen: Deaktivieren Sie Exim, Cron (mit Roots), entfernen Sie dringend den Trojaner-Schlüssel von ssh und bearbeiten Sie die sshd-Konfiguration, starten Sie sshd neu! Und es ist noch nicht klar, ob das helfen wird, aber ohne es gibt es ein Problem.
Ich habe wichtige Informationen aus den Kommentaren zu Patches/Updates an den Anfang des Hinweises verschoben, damit die Leser damit beginnen können.
UPD 5: dass die Malware Passwörter in WordPress geändert hat.
UPD 6: , lasst uns testen! Nach einem Neustart oder Herunterfahren scheint das Medikament zu verschwinden, aber das ist zumindest vorerst alles.
Wer eine stabile Lösung herstellt (oder findet), bitte schreiben, das wird vielen helfen.
UPD 7: schreibt:
Wenn Sie nicht bereits gesagt haben, dass der Virus dank eines nicht gesendeten Briefs in Exim wiederbelebt wurde und Sie versuchen, den Brief erneut zu senden, wird er wiederhergestellt. Schauen Sie in /var/spool/exim4 nach
Sie können die gesamte Exim-Warteschlange wie folgt löschen:
exipick -i | xargs exim -Mrm
Überprüfung der Anzahl der Einträge in der Warteschlange:
exim -bpc
UPD 8: Schon wieder : FirstVDS hat seine Version des Behandlungsskripts angeboten, testen wir es!
UPD 9: Es sieht so aus arbeitet, Danke für das Drehbuch!
Die Hauptsache ist, nicht zu vergessen, dass der Server bereits kompromittiert war und die Angreifer es hätten schaffen können, noch weitere untypische böse Dinge einzuschleusen (die nicht im Dropper aufgeführt sind).
Daher ist es besser, auf einen vollständig installierten Server (vds) umzusteigen oder das Thema zumindest weiterhin zu beobachten. Wenn es etwas Neues gibt, schreiben Sie es hier in die Kommentare, denn Natürlich wird nicht jeder auf eine Neuinstallation umsteigen ...
UPD 10: Nochmals vielen Dank : Es erinnert daran, dass nicht nur Server infiziert sind, sondern auch Raspberry Piund alle Arten von virtuellen Maschinen ... Vergessen Sie also nicht, nach dem Speichern der Server auch Ihre Videokonsolen, Roboter usw. zu speichern.
UPD 11: Von Wichtiger Hinweis für Handheiler:
(nachdem die eine oder andere Methode zur Bekämpfung dieser Malware angewendet wurde)
Sie müssen unbedingt einen Neustart durchführen – die Malware sitzt irgendwo in offenen Prozessen und dementsprechend im Speicher und schreibt sich alle 30 Sekunden einen neuen Cron
UPD 12: Exim hat eine weitere(?) Malware in seiner Warteschlange und empfiehlt Ihnen, zunächst Ihr spezifisches Problem zu untersuchen, bevor Sie mit der Behandlung beginnen.
UPD 13: Wechseln Sie lieber zu einem sauberen System und übertragen Sie die Dateien äußerst sorgfältig, denn... Die Malware ist bereits öffentlich verfügbar und kann auf andere, weniger offensichtliche und gefährlichere Weise verwendet werden.
UPD 14: Wir versichern uns, dass kluge Leute nicht vor der Wurzel davonlaufen – noch etwas :
Auch wenn es von Root aus nicht funktioniert, kommt es zu Hacking ... Ich habe Debian Jessie UPD: Stretch auf meinem OrangePi, Exim läuft von Debian-Exim und es kam immer noch zu Hacking, verlorenen Kronen usw.
UPD 15: Vergessen Sie beim Wechsel von einem kompromittierten Server auf einen sauberen Server nicht die Hygiene. :
Achten Sie beim Übertragen von Daten nicht nur auf ausführbare Dateien oder Konfigurationsdateien, sondern auch auf alles, was schädliche Befehle enthalten könnte (in MySQL könnte dies beispielsweise CREATE TRIGGER oder CREATE EVENT sein). Vergessen Sie auch nicht .html, .js, .php, .py und andere öffentliche Dateien (idealerweise sollten diese Dateien, wie auch andere Daten, aus einem lokalen oder anderen vertrauenswürdigen Speicher wiederhergestellt werden).
UPD 16: и : Auf dem System war eine Version von Exim in den Ports installiert, aber in Wirklichkeit lief eine andere.
Also alle Nach dem Update sollten Sie sich vergewissern dass Sie die neue Version verwenden!
exim --versionWir haben gemeinsam ihre spezifische Situation geklärt.
Der Server verwendete DirectAdmin und sein altes da_exim-Paket (alte Version, ohne Schwachstelle).
Gleichzeitig wurde mit Hilfe des Custombuild-Paketmanagers von DirectAdmin tatsächlich eine neuere Version von Exim installiert, die bereits angreifbar war.
In dieser speziellen Situation hat auch die Aktualisierung über Custombuild geholfen.
Vergessen Sie nicht, vor solchen Experimenten Backups zu erstellen und stellen Sie außerdem sicher, dass vor/nach dem Update alle Exim-Prozesse auf der alten Version sind und nicht im Gedächtnis „hängen bleiben“.
Source: habr.com