Tag Archives: Exim

Exim ist echt der beste Mailserver!

Ich weiß, er hatte dies Jahr seine Schwächen, wobei die Fixe der Schwachstellen ja das eigentliche Highlite sind, aber an einer Sache muß ich Euch kurz teilhaben lassen.

Anti-Botnetzfunktion im Exim gebaut

Neulich hatten wir auf der Exim-ML jemanden, der durch ein Botnetz mit gehackten Zugangsdaten gespammt hat und fragte, wie er das weg bekommt. Da kam mir eine Idee, wie man das im Exim selbst direkt erkennen und abwehren kann, inklusive abschalten des gehackten Accounts und Mail an den Admin. Heute überkam mich das Verlangen, das doch noch kurz zu beweisen und hab es das innerhalb einer Stunde, nachts um 12 zusammen gehackt 🙂 Da dies im Detail natürlich jetzt ein Betriebsgeheimnis ist ;D, kann ich Euch leider nur gedanklich daran teilhaben lassen.

So viel: Man braucht eine Datenbanktabelle und mickrige 3 Anweisungen in Exim Konfigfile um die volle Funktion zu erreichen :DDD

Das Prinzip

Das Prinzip ist ganz einfach: Ein normaler Benutzer hat am Tag 1-2 IPs, außer er macht was ganz komisches. Kommt er jetzt mit mehr als den 1-2 IPs und will Emails senden, verweigert der Server die Annahme der Emails, weil das in der normalen Welt nur passieren kann, wenn ein Botnetz von verschiedenen IPs aus Spam einliefern will. Ok, wenn einer TOR benutzen würde, dann hätte er auch mehr als eine IP am Tag, aber wer macht das ohne Not schon als normaler Benutzer?

Warum poste ich das jetzt, wenn ich nicht sage wie es genau geht? Na weil ich a) den Sportsgeist in Euch wecken möchte und b) damit zeigen will, daß man sowas mit Exim ultimativ schnell und einfach hinbekommt. Neulich wurden wir auf der Mailingliste mal gefragt, wo denn der Unterschied zwischen Exim und Postfix läge. Die Antwort ist recht einfach: Postfix bekommt man einfach an den Start, nur mal eine Email annehmen oder senden geht schnell. Exim braucht deutlich mehr Config, kann dafür aber auch die komplexesten Aufgaben meistern. Jeder nimmt, was er für seine Ziele braucht.

Kleiner Tip: als praktischer Nebeneffekt der Umsetzung, kann man das auf Pro-Konto-Basis ein- und ausschalten. Pro Domain ginge zwar auch, macht aber keinen Sinn, weil jeder Mailkontobenutzer anders damit umgeht.

Wir haben das auf unserer Plattform live im Einsatz und es funktioniert wie es sollte. Jetzt muß bloß noch jemand gehackt werden 😉

Exim: neue mögliche RCE Schwachstelle gefunden

Posted on by

Toller Sonntag. Überall Regen und dann weckt mich noch die Meldung, das im Exim eine neue, nicht abwehrbare Schwachstelle gefunden wurde 🙁 ( wichtiges 13 Uhr Update unten )

Elysium ist gefallen

Es gibt einen neuen Bug, der auch bereits gefixt wurde, aber leider nicht mit einem Workaround abzuwehren geht. Das bedeutet für Euch, daß Ihr Updaten müßt.

Der Fehler liegt in einem Programmierfehler der Stringverarbeitung, die dummerweise bereits beim HELO/EHLO greift. Ein Angreifer kann einen Heap-overflow auslösen, in dem er einen überlangen ELHO String sendet.

An der Stelle des Codes wurden die Rootrechte zwar schon gedroppt, aber das hilft nur wenig, falls der Angreifer tatsächlich einen RCE hinbekommt, was nicht ausdrücklich ausgeschlossen ist, aber auch nicht 100% bestätigt wurde. Daher muß man davon ausgehen, daß es jemand früher oder später schafft: Worst-Case halt.

Betroffen sind alle Versionen < 4.92.3.

Also entweder Ihr patchted Euren alten Exim selbst, oder Ihr updated auf die neue Version. Eure Entscheidung.

Aktuelle CVE Nummer zu dem Exim RCE : CVE-2019-16928 .
(Passage geändert, vorher keine bekannt gewesen.)

13 Uhr Update

Fedora kompilierte Versionen sind nicht angreifbar. Der Exploit funktioniert einfach nicht.

Getestet auf: Fedora 29 64Bit gegen 4.92.2

Andere Distros könnten angreifbar sein. Es hängt auch ein bisschen damit zusammen, wie das angegriffene System konfiguriert ist. „Eylsium ist gefallen“ ziehe ich damit teilweise zurück .. das Fedosium steht noch :DDD

Der Exploitstring ist übrigens 11k lang, nur falls Ihr das bei euch mal selbst ausprobieren wollt, nehmt gleich 12k.

Außerdem wurde mitgeteilt, daß es im Rahmen der 4.92.x eingeführt wurde und mit 4.93 auch schon wieder draußen war. Die Exploitmeldung war leider etwas hastig formuliert worden. Allerdings sehe ich da keinen Schaden drin, weil „besser safe than sorry“ wie der Denglischer sagt 😉

 

Exim: CVE-2019-15846 Root-Exploit und die Abwehr

Posted on by

So, es ist wieder soweit, wir stopfen den Exim gegen CVE-2019-15846. Diese Lücke beinhaltet einen eher ungewöhnlichen Angriffsvektor, jedenfalls für mich. Aus der Richtung hätte ich nicht mit Problemen gerechnet.

CVE-2019-15846: Root-Exploit durch SNI

Was ist das Problem werdet Ihr fragen? Schon mal was von TLS gehört? Nein? Nagut 😉 Das ist der Nachfolger von SSLv3 und wurde 1998 ins Leben gerufen um primär ein Problem zu lösen: Für SSLv3 braucht jede Domain, die das benutzen wollte, eine eigene IP auf dem Server, weil es nicht möglich war, das Cert passend zur aufgerufenen Domain auszuwählen.

Dies wurde durch SNI in TLS 1.0 behoben, so daß Webserver jetzt alle verschlüsselt erreichbaren Domains auf einer einzigen IP hosten konnten. Dazu gibt der Client, dem Web/ oder Mailserver mit, für welche Domain er eine Verbindung aufbauen möchte, bevor die Verbindung wirklich aufgebaut wird.

Genau da liegt das Problem

Der per SNI übergebene Domainname landet beim Exim derzeit ungeprüft im Filesystem und wenn etwas ungeprüft im Filesystem landet, kann man damit einiges anstellen, in diesem Fall Root werden. Das ist eine stark vereinfachte Darstellung, weil ich will ja nicht, daß Ihr Euch daraus einen eigenen Exploit baut 😉

Die Gegenmaßnahme

Mal von den bereits verfügbaren Update-Patchen abgesehen, kann man den Angriff dadurch erschweren, daß man die zum Angriff nötigen Zeichen im SNI blockiert.

Das geht so :

acl_check_mail:

deny condition = ${if eq{\\}{${substr{-1}{1}{$tls_in_sni}}}}
       message = no invalid SNI for you

deny condition = ${if eq{\\}{${substr{-1}{1}{$tls_in_peerdn}}}}
       message = no invalid tls strings for you

Es wird aber empfohlen das Update einzuspielen, weil nicht ausgeschlossen werden kann, daß dies nicht ausreicht um die Lücke dauerhaft zu schließen.

Für den derzeit bekannten Angriffsvektor gibt es bereits einen Proof-of-Concept Exploit, daher solltet Ihr sehr schnell handeln und noch schneller Updaten!

Fedora patzt beim Update

Das ist dem schnell Updaten wird für Redhat und Fedora Benutzer ein Problem werden, denn es gibt noch keine Updates. Fedora/Redhat hat es komplett verpennt, obwohl ich dem Maintainer höchstselbst eine Headsup Notitz gemailt habe und auf einer von den Distros überwachten Liste, eine entsprechende Nachricht eingegangen ist. Da haben ich und Golem das ja auch her gehabt. Heise Sec meinte, es würde reichen, wenn man das CERT bei Twitter abboniert hat.. ne sorry, reicht nicht 😀

Dann fixt jetzt mal eure Server, mein Cluster ist damit schon durch.

1. Update: 14:48

Wie aus sicherer Quelle bekannt wurde, hat Redhat eine „Urlaubsvertretung“ mit dem Problem betraut, da der Maintainer nicht zur Verfügung steht derzeit, er ist im Urlaub. Ob das die Ursache ist, daß es noch keine Updates gibt, weiß man nicht sicher, aber im Bereich des möglich wärs ja 😉 Sorry Fedora, aber ein bisschen Spot muß sein, ich sehe nämlich immer noch keine Pakete im Buildsystem bauen …

2. Update: 17:11

Das Update von Exim hat jetzt bei Fedora den Status „dringend“/“urgent“ .

3. Update: 18:20

TestRPMs sind verfügbar:

https://kojipkgs.fedoraproject.org//packages/exim/4.92.2/1.fc29/x86_64/exim-4.92.2-1.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/exim/4.92.2/1.fc29/x86_64/exim-mysql-4.92.2-1.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/exim/4.92.2/1.fc29/x86_64/exim-clamav-4.92.2-1.fc29.x86_64.rpm

4. Update: 19:01

Die RPMs wurden ins Stable gepusht. Damit gehen die Updates jetzt für alle live.

Danke an alle Helfer, Urlauber, Urlaubsunterbrecher und Vertretungen, die es heute Nachmittag dann doch noch geschafft haben und besonders an Heiko Schlittermann, mit dem ich noch die Eckpunkte des Workarounds diskutieren konnte, bevor es offiziell wurde.