Liebe Leserin, lieber Leser,

in den letzten Wochen habe ich sehr viele spannende Themen gesehen, sodass mir die Auswahl diesmal besonders schwerfiel und der Digest zum Jahresende etwas länger wurde. Daher ohne viele weitere Worte hier die Themen des Monats:

• Produktiver durch mehr Sicherheitsmaßnahmen
• Züge, die nicht mehr booten wollen
• Zwei Bluetooth-Lücken zum Advent
• CVSS Score 4.0
• Sichere KI, unsichere KI
• Seitenkanal des Monats: Die Finger des VR-Nutzers

Wir wünschen Ihnen viel Spaß beim Lesen und entspannte Feiertage – Ihr Feedback ist wie immer herzlich willkommen!

Mit besten Grüßen
Jörg Schneider
 

Produktiver durch mehr Sicherheitsmaßnahmen

Immer wenn von Sicherheitsmaßnahmen die Rede ist, werden sofort Bedenken zu Produktivitätsverlusten geäußert. Die Kunst des Sicherheitsmanagements ist es dann, die passende Balance zu finden: Welche Risiken können wir akzeptieren, um unsere Produktivitätsziele zu erreichen? Und welche Einschränkungen können wir beim täglichen Arbeiten in Kauf nehmen, um unsere Sicherheitsziele zu erreichen?

In der Novemberausgabe von „Computer“, der Hauszeitschrift der IEEE Computer Society, wird der Stand der Forschung zu diesem Zielkonflikt zusammengefasst. So wird eine Studie von G. A. Stout zitiert, nach der 60 % der Befragten sich zumindest gelegentlich durch Sicherheitsmaßnahmen in ihrem Job eingeschränkt fühlen. Andere zitierte Studien zeigen in vergleichbare Richtungen.

Überraschend ist das Ergebnis einer Studie, die Produktivität und Sicherheit bei der Softwareentwicklung ins Verhältnis setzt. Dafür wurden Entwicklerteams und Manager zu ihren Vorgehensweisen, Tools und Vorgaben befragt. Aus den Ergebnissen wurden vier Cluster gebildet:

• Low Performer für Teams, die in beiden Aspekten Verbesserungsbedarf hatten,
• Security First bzw. Productivity First für Teams, die den Fokus primär auf das eine oder andere Thema legen,
• und zuletzt High Performer, die beide Themen intensiv verfolgen.

Trägt man die Ergebnisse in einem Graphen mit zwei Bewertungen für Produktivität und Sicherheit ein, dann sind logischerweise die vier Cluster hauptsächlich in den jeweiligen Quadranten zu finden. Es wird aber auch sichtbar, dass der Mittelwert des Produktivitätsindexes des High-Performer-Clusters deutlich über dem Mittelwert des Productivity-First-Clusters liegt. Entwicklungsteams, die sich um beide Themen gekümmert haben (Sicherheit und Produktivität) hatten also im Schnitt eine höhere Produktivität als solche, die sich nur auf Produktivität konzentriert hatten.

Die Autoren versuchen den Effekt vor allem damit zu erklären, dass vorausschauende Sicherheitsüberlegungen zu selteneren Unterbrechungen durch kurzfristig zu behebende Sicherheitsprobleme führen und so mehr Zeit für die planmäßige Abarbeitung aller offenen Aufgaben bleibt. Einschränkend muss man anmerken, dass diese Studie von einem Hersteller von Sicherheitslösungen für die Softwareentwicklung (SonaType) erstellt wurde. Aber unsere Erfahrung beim Betrieb von IT zeigt auch, egal ob es ein großer oder ein kleinerer Sicherheitsvorfall ist: Nutzer und Techniker müssen sich immer kurzfristig um Lösungen kümmern und haben dann weniger Zeit für die Dinge, für die sie eigentlich bezahlt werden.

https://www.computer.org/csdl/magazine/co/2023/11/10286241/1RimXhneuAM

Züge, die nicht mehr booten wollen

Im September-Digest hatten wir über Angriffe auf polnische Züge berichtet, die durch gefälschte Notsignale per Funk zum Anhalten gebracht wurden. Jetzt wurde in Polen ein Fall öffentlich, bei dem Züge nach erfolgreicher Inspektion die Werkstatt nicht mehr verlassen konnten. Diesmal zeigt der Verdacht direkt auf den Hersteller der Triebwagen.

Aufgefallen ist es, als die Bahngesellschaft Koleje Dolnośląskie die Eine-Million-Kilometer-Inspektion ausgeschrieben hat und statt dem Hersteller mit der Firma SPS quasi eine freie Werkstatt beauftragte. Das Vorgehen war im Wartungshandbuch beschrieben, und die Firma hielt sich wohl auch an alle dort beschriebenen Schritte – am Ende der Wartung fuhr der Triebwagen jedoch nicht wieder los, da kein Strom mehr bei den Motoren ankam. Mit der Zeit sammelten sich mehrere Züge, die entweder fertig gewartet waren, aber nicht mehr losfuhren oder die eine Million Kilometer voll hatten und ohne Inspektion nicht mehr genutzt werden konnten. Die Bahngesellschaft war kurz davor, den Wartungsvertrag aufzulösen und die Triebwagen doch beim Hersteller zur Inspektion zu bringen.

Es war offensichtlich ein Problem in der Steuerungstechnik – also ein Computerproblem. Daher beauftragte die Werkstatt Sicherheitsexperten damit, den Fehler in den Steuerungsrechnern per Reverse Engineering zu finden. Das ist kein leichtes Unterfangen ohne weiterführende Informationen vom Hersteller, aber es gelang, und bei der Analyse der Steuerungsrechner von mehreren Zügen kamen an verschiedenen Stellen Auslöser für vermeintliche Störungen ans Licht: Für mehrere konkurrierende Wartungszentren waren GPS-Koordinaten hinterlegt und der Zug ließ sich nicht mehr in Betrieb nehmen, wenn er mehr als zehn Tage an diesen Orten war. Außerdem gab es Prüfungen auf bestimmte Tage, an denen der Kompressor einen Fehler melden sollte oder ob Teile gewechselt wurden.

Das ist die Darstellung der betroffenen Werkstatt. Der Hersteller verweist auf Sicherheitssysteme im Sinne von Safety, die von der freien Werkstatt nicht ordnungsgemäß gewartet wurden. Mehr Details stellen die Entdecker vom Team Dragon Sector nach Weihnachten beim Chaos Communication Congress vor.

Nicht jeder Digest-Leser wird Züge einsetzen, aber ähnliche Angriffe durch geheime Hintertüren der Hersteller sind nicht nur für andere OT-Umgebungen denkbar, sondern genauso auch für IT-Anwendungen und deren diverse Abhängigkeiten.

https://badcyber.com/dieselgate-but-for-trains-some-heavyweight-hardware-hacking/

Auch interessant dazu ist der Vortrag unseres Kollegen Daniel Jedecke zu „Informationssicherheit und Gefahrenabwehr in modernen Fabriken“: https://youtu.be/8XVV35VTh6k

Zwei Bluetooth-Lücken zum Advent

In den letzten Wochen sind zwei Angriffe auf Bluetooth bekannt geworden. Beide sind vermutlich schwer für einen praktischen Angriff nutzbar — wenn die passenden räumlichen Voraussetzungen gegeben sind, eigentlich aber sehr leicht.

Marc Newlin hatte sich 2016 bereits kabellose Mäuse und Tastaturen angeschaut und die MouseJack-Lücke gefunden. Darauf fußt unter anderem die häufige Empfehlung, anstelle der proprietären Dongles mit eigenem Protokoll nur Mäuse und Tastaturen mit Bluetooth zu nutzen. Folgerichtig hat er jetzt einen Blick auf Bluetooth-Eingabegeräte geworfen und unter der Nummer CVE-2023-45866 einen Weg teilweise veröffentlicht, wie ohne Zutun des Nutzers fremde Tastaturen mit PCs und Handys gekoppelt werden können: Während bei Android bereits das aktivierte Bluetooth ausreicht, muss für den Angriff bei iOS und Mac OS irgendwann zuvor eine Tastatur von Apple gekoppelt worden sein. Der Angriff gelingt dann aber auch ohne weitere Nutzerinteraktion und sogar trotz Apples speziellem Lockdown-Mode. Der Angreifer kann aber keine Tastatureingaben der Nutzer mitlesen, sondern nur blind eigene Tastenanschläge einspielen. Die Auswirkungen hängen also stark von der konkreten Nutzung ab, und wie der Angreifer die passenden Eingaben timen kann. Noch sind nur wenige Eckdaten bekannt. Mehr Details will der Entdecker später teilen.

Die andere Lücke hat neben der simplen CVE-Nummer (CVE-2023-24023) auch einen markanten Namen (BLUFFS), eine Webseite mit animierten GIFs und für die seriöse Seite auch einen wissenschaftlichen Artikel. Beim ersten Überfliegen des Artikels hatte ich ihn schon fast zur Seite gelegt, da der Autor Daniele Antonioli in der Herleitung von einer Sicherheitszusage spricht, die zwar gebrochen wird, aber laut Bluetooth-Spezifikation gar nicht vorgesehen war (Future/Forward Secrecy).

Sie wird aber implizit angenommen und durch regelmäßige Wechsel der Sitzungsschlüssel praktisch auch adressiert. Daniele Antonioli konnte jedoch zeigen, dass er den Schlüsselwechsel beeinflussen und so die Kommunikationspartner dazu bringen konnte, immer wieder den gleichen Schlüssel zu nutzen. Der Funkverkehr muss dafür aber über das Angreifersystem gelenkt werden. Im ersten Schritt erzwingt der Angreifer einen ihm unbekannten, aber festen Schlüssel und kann die damit verschlüsselte Kommunikation mitschneiden. Jetzt kann der Angreifer in Ruhe versuchen, den Schlüssel zu knacken, was vermutlich Tage dauern wird. Kennt er dann den Schlüssel, kann er zurück zum Opfer gehen, wieder den Funkverkehr über sich umleiten, wieder den festen Schlüssel erzwingen und diesmal ungehindert mitlesen und sogar manipulieren.

Gelingt der Angriff, wären wieder Bluetooth-Tastaturen ein gutes Ziel – diesmal sogar zum Mitlesen und gezielten Ändern von Eingaben. Der Angriff ist geräteunspezifisch, es können also auch Freisprecheinrichtungen und Headsets abgehört werden.

Gegenmaßnahmen sind aktuell noch rar. Aber auch die Angriffsseite ist nicht so trivial. Zwar sind die notwendigen Tools inzwischen öffentlich, und der erfolgreiche Angriff wurde für eine Reihe von typischen Peripheriegeräten und Handys/Laptops gezeigt, jedoch ist unklar, wie leicht ein Angreifer den Funkverkehr umleiten kann. Da die Peripheriegeräte typischerweise sehr nah beim Hostgerät gestartet werden, muss sich der Angreifer mit sehr viel Funkleistung „vordrängeln“ und verhindern, dass die Geräte sich direkt miteinander verbinden. Das muss außerdem mehrmals in einem Abstand von einigen Tagen passieren. Bei der Risikobewertung sollte man berücksichtigen, ob ein Angreifer, der sich wiederholt so dicht seinem Opfer nähern kann, vielleicht auch einfachere Wege zum Mithören hat.

CVE-2023-45866: https://github.com/skysafe/reblog/tree/main/cve-2023-45866

CVE-2023-24023 / BLUFFS

• Bunte Webseite: https://francozappa.github.io/post/2023/bluffs-ccs23/
• Reaktion der Bluetooth-SIG: https://www.bluetooth.com/learn-about-bluetooth/key-attributes/bluetooth-security/bluffs-vulnerability/
• Wissenschaftlicher Artikel: https://dl.acm.org/doi/10.1145/3576915.3623066

CVSS-Score 4.0

Na, wer hat beim Lesen der Überschrift gleich reflexartig gedacht: „Nur eine 4? Das patchen wir nicht.“? Aber hier geht es nicht um eine Sicherheitslücke, die es in der CVSS-Olympiade nur auf¬ einen niedrigen Wert geschafft hat, sondern um das Bewertungssystem selbst. Die Version 4.0 des Common Vulnerability Scoring System (CVSS) wurde Anfang November veröffentlicht.

Die Rechenregeln für die Base-Metric haben sich leicht geändert. Deutlich stärker haben sich die abgeleiteten Metriken gewandelt, die das tatsächliche Risiko einer Ausnutzung der Lücke durch Mitbetrachtung der Bedrohungslage und/oder des Schutzbedarfs der konkreten Nutzung besser beschreiben.

Geblieben ist das Problem, eine komplexe Entscheidung über die Behandlung von Risiken auf eine simple Nummer zu reduzieren. Mit ihrer Nachkommastelle und der mathematischen Rechenregel für die Herleitung fällt es leicht, die Zahl als formalen Fakt zu nutzen. Aber die Base-Metric, die fälschlicherweise häufig für Entscheidungen zum Patchen herangezogen wird, weil sie immer direkt an den CVE-Meldungen dran steht, ist laut CVSS-Standard gar kein Maß für Risiken. Mit dem Base-Score wird die „Schwere“ der Lücke im Allgemeinen beschrieben, für eine Annäherung an das Risiko werden Threat-Metric, Enviromental-Metric oder noch besser die Kombination aus beiden empfohlen.

CVSS 4.0 Standard und interaktiver Rechner: https://www.first.org/cvss/v4.0/user-guide

Zusammenfassung der wichtigsten Änderungen bei Heise Online: https://www.heise.de/hintergrund/Die-wichtigsten-Aenderungen-der-neuen-Schwachstellenbewertung-CVSS-4-0-9318903.html?seite=all

Sichere KI, unsichere KI

Kurzes Durchatmen im KI-Hype liefert vielleicht die Studie von Cameron Jones und Benjamin Bergen, die zeigt, dass auch aktuelle große Sprachmodelle (LLM) den Turing-Test nicht bestehen. Informatik-Pionier Alan Turing hat schon 1950 diesen Test vorgeschlagen, in dem eine künstliche Intelligenz und ein Mensch mit einem Menschen chatten. Der Turing-Test gilt als bestanden, wenn der Mensch den Computer nicht sicher erkennen kann. Inzwischen wird der Test eher so aufgebaut, dass die menschlichen Teilnehmenden am Ende einer Sitzung eine Schätzung abgeben müssen. Denken sie dabei in mehr als der Hälfte der Fälle, dass sie gerade mit einem Menschen gesprochen haben, gilt der Test für die KI als bestanden. GPT-4 war noch unter der Schwelle, kam ihr aber mit 41 % recht nah.

Um Sicherheit angemessen bei KI-Projekten zu berücksichtigen, haben 23 Cybersicherheitsbehörden, darunter auch das BSI, einen gemeinsamen Leitfaden entwickelt und veröffentlicht. Der Leitfaden stellt kompakt wichtige Sicherheitsaspekte bei der Entwicklung und beim Betrieb von KI-Systemen vor. Einige überschneiden sich deutlich mit klassischen Anforderungen in den jeweiligen Phasen, aber am Ende sind KI-Systeme auch nur Computer.

Does GPT-4 Pass the Turing Test? https://arxiv.org/abs/2310.20216

Guidelines for secure AI system development https://www.ncsc.gov.uk/files/Guidelines-for-secure-AI-system-development.pdf

Seitenkanal des Monats: Die Finger des VR-Nutzers

Beim Seitenkanal des Monats darf die KI natürlich nicht fehlen. Diesmal betrachten wir Nutzer, die sich mit VR-Brillen auf dem Kopf in virtuellen Meetingräumen treffen. In Meetings wird häufig auch Zugriff auf den Computer gebraucht, allein um Notizen machen zu können. Das ist aber kein Problem, da man sich in bestehenden VR-Welten bereits den Bildschirm oder die einzelne Anwendung als schwebendes Fenster einblenden kann. Auch kann man für seine Notizen eine physische Tastatur nutzen – entweder wird die Realität per Augmented Reality eingeblendet oder man nutzt sein Wissen aus dem Schreibmaschinenkurs zum Blindschreiben.

Falls Sie nach all den Annahmen noch dabei sind, haben wir jetzt eigentlich ein schönes Set-up mit dem wir ungestört im VR-Meeting Notizen machen können, ohne dass der Gesprächspartner sieht, was wir tippen. 

Ein Team der University of Chicago hat jedoch gezeigt, dass die von der VR-Brille aufgezeichneten und als Teil des Avatars dargestellten Hände ausreichend genau sind, um die gedrückten Tasten zu rekonstruieren. Ein anderer Teilnehmender im virtuellen Raum könnte also Notizen oder gar eingetippte Passwörter rekonstruieren.

https://arxiv.org/abs/2310.16191