Autor: Dr. Jörg Schneider

Am Beispiel der Gegenmaßnahmen zu den Prozessorlücken Spectre und Meltdown hat die Forscherin Henriette Hofmeier aufgezeigt, dass sich mit einem gezielten Einsatz von Sicherheitsmaßnahmen auch der Energieverbrauch senken lässt. In diesem Fall deaktivieren die Gegenmaßnahmen Optimierungen und verbrauchen zusätzliche Taktzyklen. Sie werden aber eigentlich nur benötigt, wenn besonders schützenswerte Informationen aktiv verarbeitet werden, beispielsweise die privaten Schlüssel beim Verschlüsseln. Trotzdem werden sie in der Praxis derzeit global für das gesamte System dauerhaft aktiviert. Wie Hofmeier mit Änderungen am Linux-Kernel gezeigt hat, geht das auch anders – dann müssen allerdings die Anwendungen ihren Schutzbedarf auch an den Kernel melden, damit dieser die passenden Maßnahmen an- und ausschalten kann.

Dieses Spannungsfeld existiert auch an vielen anderen Stellen. Ein äußerst plakatives Beispiel bilden signierte Mails, in denen die Signatur in der Regel den eigentlichen Textanteil um ein Vielfaches übersteigt. Aber deshalb gleich alle Sicherheitsmaßnahmen abstellen, ist auch keine Lösung. Eher sollten, wie in Hofmeiers Arbeit gezeigt, die für den Schutzbedarf passenden Maßnahmen zur richtigen Zeit greifen.

https://inf.gi.de/04/wie-viel-energie-darf-schutz-kosten

https://sys.cs.fau.de/publications/2022/hofmeier_22_thesis.pdf

Diesmal nehmen wir ein größeres Ziel für den Seitenkanal des Monats. Und auch die Richtung des Angriffs ist anders als in den letzten Digests. Heute geht es um ein Auto, genauer einen Tesla und dessen System für das autonome Fahren. Und statt direkt an Daten zu kommen, soll diesmal dem Gerät ein falsches Zertifikat untergejubelt werden. Forscher des Fachgebiets SecT der TU Berlin haben es geschafft, den Steuerungsrechner mit einer manipulierten Firmware zu starten. Eigentlich sollten kryptografische Prüfungen nur das Starten der Hersteller-Firmware erlauben, aber durch Glitchen der Versorgungsspannung konnte das Zertifikat für die Prüfung geändert werden.

Durch die so gestartete Firmware hatten die Forscher vollen Zugriff auf das laufende System und konnten auch Informationen auslesen. Alle Details gibt es im Vortrag der Forscher auf dem 37C3.

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

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