„Hello, you reached Interpol, how can we…“ *click*

Heute morgen wurden wir aus Indien mit Fakenews zu unserem Air-Gapped Windows-PC angerufen. 4 mal, beim 5ten mal passierte das hier 😀

„Hello, you reached Interpol, how can we…“ *click*

Irgendwie hat das Wort Interpol bei den Indern eine Allergische Reaktion hervorgerufen, ich konnte nicht mal meinen Fiktiven Namen nennen 🙂

Na gut, da bleibt wohl nur die Forensische Untersuchung. Dazu brauchen wir:

– eine Fritzbox

Denn, eine Fritzbox hat ein Funktion zum Herunterladen von Erweiterten Supportdaten fĂŒr AVM, das machen wir uns zu nutze 🙂 Und Ihr mĂŒĂŸt schnell sein, schon der nĂ€chste Anruf kann die Daten die wir brauchen, aus der Liste werfen.

Wie kommt man an die Daten ran?

Dazu loggt Ihr Euch in die Fritz!box ein, notfalls die erweitere Ansicht starten.

1) auf Inhalt klicken

2) auf „Fritz!Box Support“ klicken

3) und Daten speichern

Da sind jetzt jede Menge Daten drin, aber findet man da die richtigen. U.a. ist in den Daten die Anruferliste drin, da taucht die fiktive Nummer auf, die der Anrufer sich gegeben hat. Außerdem stehen die SIP Header der letzten Anrufe zur VerfĂŒgung, aber eben nur 3 oder 4, deswegen gleich machen 😉

Wenn Ihr weiter nach der Rufnummer sucht, dann stoßt Ihr zwangslĂ€ufig auf das hier:

2022-06-14 10:50:34.284 – IN: my=Fritz.box-IP%16:5060 peer=212.227.124.129 port=5060 UDP, sipiface=none:
INVITE sip:49meinenummer@meine-IP;uniq=4ED0D261308B18E3479371E6DE583 2.0
Via: SIP/2.0/UDP 212.227.124.129;branch=z9hG4bK558a.a1b3af1c4cb4a9d3db770f9c2540be30.0
Via: SIP/2.0/UDP 212.227.67.227;branch=z9hG4bK558a.43f57bddf2d907ac8e703c88816f28c8.0
Via: SIP/2.0/UDP 212.227.124.145;branch=z9hG4bK558a.0196cb5967141d39c551e1029d6b8409.0
Via: SIP/2.0/UDP 212.93.31.246:5060;branch=z9hG4bK1kv0so005gggdkea0210.1
Record-Route: <sip:212.227.124.129;lr=on>
Record-Route: <sip:212.227.67.227;lr=on;ftag=o6at64tt-CC-1067-OFC-1770;did=e18.5d83>
Record-Route: <sip:212.227.124.145;lr=on>
From: „+49458911245“ <sip:+49458911245@Versatel.de;transport=udp;user=phone>;tag=o6at64tt-CC-1067-OFC-1770
To: „+49meinenummer“ <sip:+49meinenummer@1und1.de;user=phone>
Call-ID: y6bosyszeetyiy769vbssneaa9yetzi6@10.18.5.64
CSeq: 1 INVITE
Contact: <sip:+49458911245@212.93.31.246:5060;user=phone;transport=udp>
History-Info: <sip:+49meinenummer@1und1.de>;index=1
History-Info: <sip:+49meinenummer@1und1.de;user=phone>;index=1.1;np=1
Max-Forwards: 59
P-Early-Media: supported
Supported: timer
Min-SE: 90
Session-Expires: 1800;refresher=uac
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, INFO, PRACK, NOTIFY, MESSAGE, REFER, UPDATE
Content-Type: application/sdp
Content-Length: 313

Die IP Adresse im Contact:-Header ist die des Anrufer, oder zumindest die, die er nach außen in dem Netz hatte. Er könnte ja auch per VPN drin sei, oder einen gehackten PC kontrollieren. Diese IP ist das einzige wahre an dem ganzen Anruf, denn um die Verbindung zu halten, mĂŒssen die SIP Pakete routebar sein, also kann man keine gefĂ€lschten IPs wie bei einem DDOS benutzen.

Mit den Daten oben könnt Ihr dann tatsĂ€chlich zur Polizei gehen und Anzeige erstatten, weil es hier tatsĂ€chlich einen Ermittlungsansatz gibt. NatĂŒrlich sind die Inder nicht wirklich in Deutschland, aber beim Provider der das SIP GesprĂ€ch an Euch durchgereicht habt, muß es auch Log zur echten IP geben, weil, wie gesagt, mit gefĂ€lschten Ips gehts nicht. Also ist da entweder ein gehackter PC / Telefonanlage im Spiel, oder ein VPN. Auf beides muß man mit IPs zugreifen. So oder so, tut ihr was Gutes 😉

Um die Anrufer aus dem obigen Beispiel kĂŒmmert sich die Kripo Wuppertal 😉

Follow-UP: „Hello, you reached Interpol, how can we …“ *click*

Exim: CVE-2019-15846 Root-Exploit und die Abwehr

So, es ist wieder soweit, wir stopfen den Exim gegen CVE-2019-15846. Diese LĂŒcke beinhaltet einen eher ungewöhnlichen Angriffsvektor, jedenfalls fĂŒr mich. Aus der Richtung hĂ€tte ich nicht mit Problemen gerechnet.

CVE-2019-15846: Root-Exploit durch SNI

Was ist das Problem werdet Ihr fragen? Schon mal was von TLS gehört? Nein? Nagut 😉 Das ist der Nachfolger von SSLv3 und wurde 1998 ins Leben gerufen um primĂ€r ein Problem zu lösen: FĂŒr SSLv3 braucht jede Domain, die das benutzen wollte, eine eigene IP auf dem Server, weil es nicht möglich war, das Cert passend zur aufgerufenen Domain auszuwĂ€hlen.

Dies wurde durch SNI in TLS 1.0 behoben, so daß Webserver jetzt alle verschlĂŒsselt erreichbaren Domains auf einer einzigen IP hosten konnten. Dazu gibt der Client, dem Web/ oder Mailserver mit, fĂŒr welche Domain er eine Verbindung aufbauen möchte, bevor die Verbindung wirklich aufgebaut wird.

Genau da liegt das Problem

Der per SNI ĂŒbergebene Domainname landet beim Exim derzeit ungeprĂŒft im Filesystem und wenn etwas ungeprĂŒft im Filesystem landet, kann man damit einiges anstellen, in diesem Fall Root werden. Das ist eine stark vereinfachte Darstellung, weil ich will ja nicht, daß Ihr Euch daraus einen eigenen Exploit baut 😉

Die Gegenmaßnahme

Mal von den bereits verfĂŒgbaren Update-Patchen abgesehen, kann man den Angriff dadurch erschweren, daß man die zum Angriff nötigen Zeichen im SNI blockiert.

Das geht so :

acl_check_mail:

deny condition = ${if eq{\\}{${substr{-1}{1}{$tls_in_sni}}}}
       message = no invalid SNI for you

deny condition = ${if eq{\\}{${substr{-1}{1}{$tls_in_peerdn}}}}
       message = no invalid tls strings for you

Es wird aber empfohlen das Update einzuspielen, weil nicht ausgeschlossen werden kann, daß dies nicht ausreicht um die LĂŒcke dauerhaft zu schließen.

FĂŒr den derzeit bekannten Angriffsvektor gibt es bereits einen Proof-of-Concept Exploit, daher solltet Ihr sehr schnell handeln und noch schneller Updaten!

Fedora patzt beim Update

Das ist dem schnell Updaten wird fĂŒr Redhat und Fedora Benutzer ein Problem werden, denn es gibt noch keine Updates. Fedora/Redhat hat es komplett verpennt, obwohl ich dem Maintainer höchstselbst eine Headsup Notitz gemailt habe und auf einer von den Distros ĂŒberwachten Liste, eine entsprechende Nachricht eingegangen ist. Da haben ich und Golem das ja auch her gehabt. Heise Sec meinte, es wĂŒrde reichen, wenn man das CERT bei Twitter abboniert hat.. ne sorry, reicht nicht 😀

Dann fixt jetzt mal eure Server, mein Cluster ist damit schon durch.

1. Update: 14:48

Wie aus sicherer Quelle bekannt wurde, hat Redhat eine „Urlaubsvertretung“ mit dem Problem betraut, da der Maintainer nicht zur VerfĂŒgung steht derzeit, er ist im Urlaub. Ob das die Ursache ist, daß es noch keine Updates gibt, weiß man nicht sicher, aber im Bereich des möglich wĂ€rs ja 😉 Sorry Fedora, aber ein bisschen Spot muß sein, ich sehe nĂ€mlich immer noch keine Pakete im Buildsystem bauen …

2. Update: 17:11

Das Update von Exim hat jetzt bei Fedora den Status „dringend“/“urgent“ .

3. Update: 18:20

TestRPMs sind verfĂŒgbar:

https://kojipkgs.fedoraproject.org//packages/exim/4.92.2/1.fc29/x86_64/exim-4.92.2-1.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/exim/4.92.2/1.fc29/x86_64/exim-mysql-4.92.2-1.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/exim/4.92.2/1.fc29/x86_64/exim-clamav-4.92.2-1.fc29.x86_64.rpm

4. Update: 19:01

Die RPMs wurden ins Stable gepusht. Damit gehen die Updates jetzt fĂŒr alle live.

Danke an alle Helfer, Urlauber, Urlaubsunterbrecher und Vertretungen, die es heute Nachmittag dann doch noch geschafft haben und besonders an Heiko Schlittermann, mit dem ich noch die Eckpunkte des Workarounds diskutieren konnte, bevor es offiziell wurde.