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.