und gleich die nächste Timing Attacke auf Intel-CPUs: NetCAT

Niederländische Forscher der Vrije Universität in Amsterdam haben die Schwachstelle entdeckt. Vom Typ her eine Timing-Attacke, die man übers Netzwerk ausführen kann. .

NetCAT – Remote Attacke auf Intel CPUs dank DDIO

DDIO ( Data-Direct I/O ) gibt Netzwerkkarten und anderen Peripheriegeräten direkten Zugriff auf das CPU Cache. DDIO ist seit 2012 bei fast allen INTEL Server CPUs eingeschaltet, also eher schlecht für die Leistung, wenn man das abschaltet.

Die Lücke taugt zum Abgreifen von Tastatureingaben z.b. in SSH, weil man durch die Latenzunterschiede der Pakete vom Angreifer zum Server messen kann, welche Tasten gedrückt wurden. Schuld ist der Zustand der CPU-Caches, der in Abhängigkeit was man tut, eben schneller oder langsamer reagiert.

Wie auch schon bei Lauschangriffen auf Tastatureingaben, kann man aus den Abfolgen der Zeitunterschiede auf die Tasten rückschließen, weil es unterschiedlich lange dauert, mit dem Finger von A nach P zu kommen, als von A nach S.

Die Forscher haben zur Genauigkeit der Attacke über Netz folgendes zu sagen:

„Compared to a native local attacker, NetCAT’s attack from across the network only reduces the accuracy of the discovered keystrokes on average by 11.7% by discovering inter-arrival of SSH packets with a true positive rate of 85%.“

Meint: Das Netz macht es nur geringfügig ungenauer. Danke Intel!

Apros Intel, was sagen die dazu: „Pfff.. Klappt in der Realität wohl eher weniger, nicht so wichtig. Hier Forscher, ein kleines Dankeschön fürs Mitspielen.“

Gegenmaßnahmen

DDIO abschalten. Viel Spaß damit.

Oder man benutzt gleich Schlüssel zum SSH Login, dann ergibt sich das Problem gar nicht erst.

Quelle: https://thehackernews.com/2019/09/netcat-intel-side-channel.html

Schlag ins Gesicht der Spammafia – 281 verhaftet

Das US-Justizministerium hat eine gute Nachricht für alle spamgeplagten Mailboxbesitzer:

Justiznachrichten
Justizministerium
Büro für öffentliche Angelegenheiten
ZUR SOFORTIGEN FREIGABE
Dienstag, 10. September 2019

281 weltweit verhaftet in einer koordinierten internationalen Durchsetzungsaktion, die sich gegen Hunderte von Personen mit geschäftlichen E-Mail-Betrugsmethoden richtet.
74 mutmaßliche Betrüger in den Vereinigten Staaten verhaftet

Die Bundesbehörden gaben heute eine bedeutende koordinierte Anstrengung zur Störung von Business Email Compromise (BEC)-Programmen bekannt, die darauf abzielen, Banküberweisungen von Unternehmen und Privatpersonen, darunter viele ältere Menschen, abzufangen und zu entführen. Operation reWired, eine koordinierte Strafverfolgungsmaßnahme des U.S. Department of Justice, des U.S. Department of Homeland Security, des U.S. Department of the Treasury, des U.S. Postal Inspection Service und des U.S. Department of State, wurde über einen Zeitraum von vier Monaten durchgeführt, was zu 281 Verhaftungen in den Vereinigten Staaten und Übersee führte, darunter 167 in Nigeria, 18 in der Türkei und 15 in Ghana. Verhaftungen wurden auch in Frankreich, Italien, Japan, Kenia, Malaysia und dem Vereinigten Königreich (UK) vorgenommen. Die Operation führte auch zur Beschlagnahme von fast 3,7 Millionen Dollar.

Übersetzt mit www.DeepL.com/Translator

\o/ Strike \o/ Solche Nachrichten brauchen wir öfters 🙂

Quelle: https://www.justice.gov/opa/pr/281-arrested-worldwide-coordinated-international-enforcement-operation-targeting-hundreds

Willkommen im Club der TLS Verweigerer: Apache Foundation!

Nachdem ich die Admins von Mozilla dies Jahr endlich dazu bewegen konnte, für den Mailserver Ihres Bugtrackers TLS zu aktivieren, muß ich leider feststellen, daß eine der größten Organisationen im FOSS Bereich derbe ins Klo gegriffen hat:

Willkommen im Club der TLS-Verweigerer: Apache Foundation!

Eigentlich sagen Bilder ja mehr als tausend Worte, aber in dem Fall erfüllt eine einzige Logzeile den gleichen Zweck:

2019-09-09 12:20:07 H=hermes.apache.org (mail.apache.org) [207.244.88.153] F=<bugzilla@apache.org> rejected RCPT <empfänger@empfängerdomain.de>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.

Damit reiht sich die Apache Foundation erfolgreich in den Club der TLS-Verweigerer ein. Ich vermute, daß, da auch der Mozilla Bugtracker das gleiche Problem hatte, eine gemeinsame Programmbasis vorliegt, mit den gleichen schlechten Default Einstellungen! Da ich schlecht fragen kann, weil Emailantworten ja nicht ankommen, werden wir nie rausfinden woran das liegt 😉

Fest steht, daß gerade für einen Bugtracker, der ja „Security related Content“ transportiert, die TLS-Verweigerung ein klarer Sicherheitsbruch ist. Wünschen wir dem Verantwortlichen daher ein böses Erwachen.

Natürlich werde ich versuchen, Apache zum Besseren zu bekehren, aber erfahrungsgemäß sind Admins, die das nicht selbst merken oder es für kein Problem halten, schwer in die Realität zu überführen. Bei Mozilla hat es 2 Jahre gedauert 😉

Update: 22:19

Entschuldigt die Ausdrucksweise, aber „boar ist das hart!“ . Ich habe ja die Geschichten von den störischen OO Entwicklern nicht sooo richtig geglaubt, aber was da heute an dämlichen Antworten auf Bugreports kam, das haut dem Fass den Boden raus!

„Was für eine unfassbare Scheiße.:!!“

Ich melde da einen Segmentation Fault, der seit einigen Tagen auftritt und bekomme als Antwort: „Das liegt an Deiner Maschine.“ . Die „latest“ Version von OpenOffice ist 4.1.6 , die ist von September 2018, also rund 1 Jahr alt. Das der Rest der Welt da mal ein paar Updates eingespielt haben könnte und OO deswegen crashed, ist zwar primär richtig, aber sowas von arrogante Scheiße, daß man dem Herrn gern mal eins zwischen die Ohren geben will. „Es ist natürlich nicht unser uralt Code der da failed, es ist das Security Update auf Deinem Rechner, daß nicht mitspielt.“ Was denkt sich so ein Depp eigentlich?

Ticket Nummer zwei war dann zu dem fehlenden TLS im Mailserver, kam als Antwort „ist kein OOO Problem“. Was zum Geier ist ein OOO Problem? OpenOfficeOrganisation oder was? Das ist doch dem Reporter egal, ob das vom Apache Admin, oder vom Projektleiter gelöst wird, Fakt ist, daß die mit dem mangelnden TLS Support technisch in der Steinzeit leben. Das wurde Anfang der 90er Jahre des letzten Jahrtausends eingeführt, immerhin ist das fast !!! 30 !!! Jahre her! Echt unglaublich.

Aber diese Mentalität paßt natürlich zur „unser Code ist steinalt, deswegen ist der gut“ Antwort. Konsequent sind die ja dann irgendwie 😀

Es gibt nur eine Lösung

Da kann man nur eins empfehlen: dnf erase openoffice;dnf install libreoffice

Auch wenn ich LibreOffice nicht mag, da dort bei Präsentationen die Medien Einbindung nicht richtig funktioniert. Aber immerhin schicken die häufiger Updates raus.

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.

Nicht schon wieder ein Root-Exploit im Exim

Wie heute bekannt wurde, gibt es schon wieder einen Remote-Root-Exploit im Exim-Mailserver: CVE-2019-15846 . Das wäre jetzt schon die dritte krasse Sicherheitslücke im Exim in diesem Jahr. Ich mag ja Exim sehr gern, aber die Pille ist schon irgendwie bitter, IMHO.

Das Kurz-Interview zum Thema mit einem der Exim-Verantwortlichen findet Ihr unten.

„A local or remote attacker can execute programs with root privileges.“

Alle Versionen bis einschließlich 4.92.1 sind laut Vorabmeldung davon betroffen. Derzeit gibt es für die Lücke noch keinen funktionierenden Exploit, aber da es schon einen Proof-of-Concept gibt, kann das nicht lange dauern, bis es einen Exploit in der Wildnis geben wird.

Mehr Details mochte man uns noch nicht anvertrauen, aber Freitag um 12 Uhr gibt es mehr Infos. Ist wie bei einer Pressekonferenz, wenn die Polizei mehr zu den aktuellen Erkenntnissen eines Falls rausrückt 😉

Gefixt ist das Problem in Version 4.92.2. Ich werde Euch mitteilen, wenn die Pakete im Koji auftauchen, da ich die natürlich testen werde 😉

Hier ein Auszug aus der Originalmeldung:

Version:    up to and including 4.92.1
Issue:      A local or remote attacker can execute programs with root
            privileges.
Details:    Will be made public at CRD. Currently there is no known
            exploit, but a rudimentary POC exists.

Coordinated Release Date (CRD) for Exim 4.92.2:
            2019-09-06 10:00 UTC

Ein Kurzinterview mit einem der Exim Entwickler

Ich habe kurzentschlossen Heiko Schlittermann ein paar Fragen zum Thema gestellt, die er mir freundlicherweise spontan beantwortet hat. Heiko hatte heute morgen auch die Head-Ups-Mail an die Eximliste geschrieben, steckt also voll im Thema drin:

Kommen die diesjährigen Schwachstellen aus Projekten, die den Code von Exim extra auditiert haben, oder sind es eher voneinander unabhängige Reporter?

Sowohl als auch. CVE-2019-10149 (Juni) wurde uns von einer Security-Firma gemeldet. Ich vermute, daß die im Auftrag eines Kunden Auditing gemacht haben. Dieses CVE betraf streng genommen uns nicht, weil die aktuelle Version den Bug nicht mehr drin hatte (wurde unbeabsichtigt beseitigt).

CVE-2019-13917 (Juli) war „Selbstanzeige“. Es ist einem der Entwickler aufgefallen, nachdem er nach CVE-2019-10149 begonnen hat, den Code so umzubauen, daß er „tainted data“ besser erkennt.

CVE-2019-15846 (September) wurde uns von einem User als Bug reported, daraufhin haben wir die o.g. Security-Firma beauftragt, das Potential dieses Problems zu untersuchen. Haben sie. Daher wurde es ein CVE. Sie fanden noch zwei weitere verdächtige Sachen, die wir aber mit ihnen klären konnten und es sind jetzt einfach nur Bugs, die sich nicht ausnutzen lassen. (Sind im „master“ schon gefixt.)

2. Drei schwere Lücken in wenigen Monaten Abstand, erschüttert das nicht das generelle Vertrauen in so ein Produkt?

Das Gespräch hatte ich auch eben mit meinem Kollegen. Wie ist die kritische Schwachstellendichte? Zu wenige: könnte bedeuten, da kümmert sich niemand, zu viele: könnte bedeuten, die Software ist Schrott. Mein Vertrauen erschüttert es nicht. Aber ich bin nicht objektiv, denn ich bin ja involviert. Natürlich führen diese Schwachstellen auch bei den Entwicklern zum Denken – sie oben, in Reaktion auf -1049 wurde „tainted data“ eingeführt. Gut möglich, daß weitere Änderungen folgen.

3. Ist für das Jahr noch mehr zu erwarten? (Dann muß ich ein neues Rezept gegen Bluthochdruck besorgen 😉 )

Wenn wir das wüssten, würden wir es gleich mit erledigen. Kannst ja präventiv eins besorgen, vielleicht verwendest Du ja noch andere Produkte. Die Summe allen Elends ist konstant 🙂

4. Was waren in den letzten Jahren die bisherigen Security-Nightmare-Highlights bei Exim?

Die uns bekannten sind als CVE veröffentlicht: http://www.exim.org/static/doc/security/ Ich denke, diese Liste müsste vollständig sein. Wenn nicht, dann gib Bescheid, ich kümmere mich drum.

Danke für das Gespräch.