Veröffentlichen, aber verantwortungsvoll: Responsible Disclosure

Findet man eine Sicherheitslücke, dann sollte man sie verantwortungsvoll veröffentlichen (Responsible Disclosure). Aber was ist verantwortungsvoll – und wem gegenüber? In der Regel kommen ja verschiedene Interessenlagen zusammen: Die Nutzer der betroffenen Anwendung wollen so schnell wie möglich davon erfahren und hätten gern auch Details, um das Risiko und mögliche Gegenmaßnahmen bewerten zu können. Der Hersteller dagegen hätte gern einen zeitlichen Vorsprung, um vor dem öffentlichen Bekanntwerden bereits eine Lösung vorzubereiten. Das sind aber noch nicht alle Beteiligten im Spiel: Der Entdecker will eigentlich nicht viel zusätzliche Arbeit haben und unbezahlt die Qualitätssicherung für den Hersteller übernehmen. Da sich aber gefundene Sicherheitslücken auch gut im Lebenslauf machen, will er die Lücke möglichst schnell und öffentlichkeitswirksam publik machen. Die Angreifer freuen sich am meisten, wenn außer ihnen niemand oder nur wenige von der Lücke wissen, das Thema also möglichst spät und mit möglichst wenig Tamtam öffentlich wird.

Daher hat sich inzwischen ein Ablauf mit einer Vorwarnzeit für den Hersteller etabliert. Die Zeiträume variieren dabei – wir bei HiSolutions etwa planen in unserem Responsible-Disclosure-Prozess 90 Tage für die Reaktion des Herstellers ein. Falls mehrere Hersteller gleichzeitig betroffen sind, gibt es inzwischen auch etablierte Wege für eine koordinierte Veröffentlichung.

Diese Koordination ist bei der jüngst entdeckten SMTP-Smuggling-Lücke schiefgegangen. Die technischen Details zur Lücke und wer jetzt was patchen muss, hat mein Kollege Folker Schmidt in unserem Research Blog zusammengestellt.

Die Lücke wurde von Timo Longin von SEC Consult auf dem 37. Chaos Communication Congress vorgestellt. Die Hersteller der Mailserver, die in seinen Experimenten auffällig waren, wurden auch im Vorfeld informiert und reagierten teilweise direkt mit einer Lösung. Betroffen waren aber auch weitere Mailserverlösungen wie Postfix, deren Entwickler von der Veröffentlichung überrascht wurden und sehr schnell aktiv werden mussten. Eine Rekonstruktion, wie es dazu kommen konnte, wurde inzwischen im Blogpost von SEC Consult ergänzt.

Wenig später machte ein anderer Maintainer einer Open-Source-Software seinen Unmut öffentlich, diesmal jedoch nicht wegen ausbleibender Benachrichtigungen, sondern über viele unsinnige: Daniel Stenberg ist der ursprüngliche Entwickler und inzwischen Maintainer des Open-Source-Projects cURL, das von modernen Linux-Konsolen nicht mehr wegzudenken ist. In letzter Zeit häufen sich dort KI-generierte Meldungen von angeblichen Sicherheitslücken. Das Perfide daran ist, dass sie alle sehr schlüssig klingen und teilweise vorgebliche Exploits mitliefern. Erst beim Nachvollziehen im Sourcecode fällt dann auf dass der beschriebene Angriff gar nicht möglich ist. Halluzinationen sind ein bekanntes Problem von großen Sprachmodellen (LLM) und werden mit solchen halluzinierten Reports nun auch zu einem Problem für die Softwareentwickler.

HiSolutions Research

Das Passwort war nicht RIPE genug

Für die spanische Mobilfunktochter von Orange begann das Jahr mit einem Schrecken und für die meisten Kunden landesweit mit einem dreistündigen Internetausfall: Ein Unbefugter hatte sich im Namen von Orange auf der Administrationswebseite des RIPE NCC angemeldet. Das RIPE NCC verwaltet nicht nur die IP-Adressräume von Europa über den Nahen Osten bis nach Zentralasien, sondern bietet auch digitale Zertifikate an, mit denen das Routing im Internet abgesichert werden kann. Genau diese Zertifikate (genauer: Route Origin Authorisations, ROA) hat der Angreifer ändern lassen und damit dafür gesorgt, dass die Router anderer Internetprovider denen von Orange nicht mehr vertrauten.

Da der Angreifer mit Screenshots bei Twitter/X angegeben hat, ist auch bekannt geworden, dass die Ursache für den großen Ausfall mit einem sehr einfachen Passwort („ripeadmin“) zusammenhing und die Administrationswebseite auch keinen zweiten Faktor für so weitreichende Änderungen benötigte. Hier hätten beide Seiten besser agieren können: die Nutzer bei Orange, indem sie auch für externe Dienste sichere Passwörter wählen und die angebotene Zwei-Faktor-Anmeldung aktivieren. Und der Anwendungsanbieter RIPE NCC, der so triviale Passworte abweisen und die Zwei-Faktor-Anmeldung verpflichtend machen sollte.

Tatsächlich sind Vorgaben für Passwörter bei Onlinediensten nicht immer so streng, wie man es von internen Anwendungen kennt. Suood Alroomi und Frank Li vom Georgia Institute of Technology haben letztes Jahr einen großen Scan von 20.000 Webanwendungen durchgeführt und beim Anlegen von Nutzerkonten ausprobiert, wie schwach ein Passwort sein konnte. Ein erschreckendes Ergebnis: Die Hälfte der getesteten Seiten akzeptierte sehr schwache Passwörter wie „123456“ oder „password“. Mit verschiedenen Stichproben haben sie dabei auch gezeigt, dass populäre Seiten häufiger mit strengeren Regeln aufwarteten als solche, die weiter hinten in den Rankings der Top-1-Million liegen.

Aber war nun das triviale Passwort die Ursache für den Ausfall? In diesem Fall hätte der Angreifer nicht viele Versuche beim Raten benötigt. Aber nach den von ihm geposteten Screenshots zu urteilen, brauchte er gar nicht erst zu raten, da scheinbar die Racoon-Malware auf einem System lief und dort unter anderem die RIPE-Zugangsdaten abgegriffen wurden.

Wie sieht es bei Ihnen aus? Gibt es eine Übersicht über alle Zugangsdaten für externe Dienste – vom Social-Media-Account über Dienstleister-Weboberflächen bis zum ELSTER-Steuerkonto? Entsprechen die Passwörter Ihren Anforderungen und sind sie sicher abgelegt? In Pentests finden wir gelegentlich immer noch gemeinsam gepflegte Excel-Tabellen mit solchen Zugangsdaten.

Mehr Details zum Orange-Ausfall: https://doublepulsar.com/how-50-of-telco-orange-spains-traffic-got-hijacked-a-weak-password-d7cde085b0c5

Der wissenschaftliche Artikel zur Verbreitung von Passwort-Vorgaben: https://dl.acm.org/doi/abs/10.1145/3576915.3623156

HiSolutions Research

Aufstieg und Niedergang des Mirai-Botnetzes

Falls das Jahr es bei Ihnen noch ruhig angehen lässt, hätte ich noch einen längeren Lesetipp. Schon im November veröffentlichte Andy Greenberg einen sehr ausführlichen Artikel über die Anfänge und das Ende des Mirai-Botnetzes. Sie erinnern sich vermutlich an das damals größte Botnetz, das zwar hauptsächlich aus leistungsschwachen Webcams bestand, aber durch die schiere Masse an Geräten ganze Internetprovider per DDoS überlasten konnte.

Der Artikel geht auf die technischen Aspekte nur so weit wie notwendig ein und konzentriert sich eher auf die Entstehungsgeschichte und die spätere Entdeckung und Läuterung der Verursacher. Mit vielen Emotionen und einer Art Happy End ist es auch eine (verspätete) kleine Weihnachtsgeschichte.

Ein weiterer spannender Aspekt der Geschichte: Die Macher des Botnetzes wollten zwischenzeitlich einen legitimen DDoS-Verteidigungsdienst aufbauen – und als dieser nicht so erfolgreich war, selbst per DDoS die Kunden zu sich treiben. Dieser Versuch war ebenfalls nicht von Erfolg gekrönt, so dass sie schlussendlich doch wieder zum reinen Verkaufen von offensiven Angriffen zurückkehrten.

https://www.wired.com/story/mirai-untold-story-three-young-hackers-web-killing-monster/

HiSolutions Research

Die Umwelt und die Sicherheit

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

HiSolutions Research

Seitenkanal des Monats: Ein Auto

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.

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

HiSolutions Research

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

HiSolutions Research

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.

HiSolutions Research

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.

    HiSolutions Research

    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