Eine Sicherheitslücke ausnutzen, um eine Sicherheitsfunktion umzusetzen

Zum Schluss noch ein Beispiel für den umgekehrten Fall, bei dem eine Sicherheitslücke ausgenutzt wurde, um Sicherheit umzusetzen: Die Zertifizierungsstelle Let’s Encrypt hat mit ihren automatisch vergebenen und verlängerten Zertifikaten für einen Umbruch bei der Generierung von TLS-Zertifikaten gesorgt. Das dabei eingeführte ACME-Protokoll wird inzwischen auch von anderen Anbietern genutzt, und es gibt eine Reihe von Tools, die das Protokoll unterstützen und auf Servern die automatische Verlängerung übernehmen können. Eines davon ist die Umsetzung als Shellskript, genannt acme.sh. Dieses Skript hatte eine Remote-Execution-Lücke – und öffentlich bekannt wurde sie auf einem eher kuriosen Weg.

Matt Holt ist über den Zertifikatsanbieter HiCA gestolpert, der das ACME-Protokoll nutzt, aber offiziell nur einen einzigen Client zur Nutzung empfahl – acme.sh. Andere Clients funktionierten tatsächlich nicht – daher versuchte er herauszufinden, wo die mögliche Inkompatibilität lag. Überrascht stellte er fest, dass die HiCA-Server während der Verifikation Antworten schickten, die einen Fehler im acme.sh-Client ausnutzten und vom Server versandte Shellbefehle ausführten. Der Hintergrund war, dass HiCA ein Reseller einer anderen Zertifizierungsstelle war, die zwar auch automatische Verifikationen nutzte, aber nicht nach dem ACME-Protokoll. Daher wurden andere Nachweisdateien auf dem Webserver benötigt, die nach dem ACME-Protokoll nicht erzeugt werden konnten. Der HiCA-Betreiber hat deshalb einen Exploit entwickelt, der die Verifikation nach dem anderen Protokoll durchführte und die Nachweise anlegte – also im Grunde eine Sicherheitsfunktion im Exploit umgesetzt.

Die Lücke und auch die HiCA sind inzwischen geschlossen.

https://github.com/acmesh-official/acme.sh/issues/4659

Passt das Passwort noch?

Am 4. Mai war der Welt-Passwort-Tag – nicht zu verwechseln mit dem eher umstrittenen Ändere-Dein-Passwort-Tag am 2. Februar. Aber eigentlich ist doch jeder Tag irgendwie ein Passwort-Tag – oder wann haben Sie zuletzt einen Tag ohne eine Passworteingabe verbracht?

Vielleicht gibt auch Ihr Passwortmanager die meisten Passwörter für Sie ein? Eine bequeme Option, für jeden Dienst ein eigenes Passwort zu nutzen. Aber ist die Datenbank dahinter auch sicher abgespeichert? In unserem Januar-Digest hatten wir ja bereits über Vorfälle bei Passwortmanagern berichtet. Bei der unvorhersagbaren Passwortgestaltung sind die Tools deutlich im Vorteil gegenüber Menschen, deren Passwörter häufig erraten werden können. Diese Woche wagte Aaron Toponce einen Blick in die Passwortgenerierungs-Funktion der LastPass-Weboberfläche und fand gleich mehrere Indikatoren für einen nicht ganz so zufälligen Zufallszahlengenerator (die Zeit als Seed und RC4 als Algorithmus). Derart generierte Passwörter sind auch nicht trivial vorhersagbar, aber doch etwas leichter zu erraten als wirklich zufällige.

In unseren Pentests sind Mängel in der Passwortstärke oder der Speicherung einer der fünf häufigsten Befunde, die eine Kompromittierung des Active Directory ermöglichen. Auch ohne Netzwerkzugang kann man an Passwörter gelangen, zum Beispiel durch Schulter-Surfen, Fingerabdrücke auf Touchscreens oder Wärmebilder von Tastaturen. Den letzten Ansatz haben kürzlich Forscher an der Universität Glasgow mit KI-basierten Bildauswertungen noch weiter optimiert und konnten sogar eine Minute nach dem Eintippen kurze Passwörter mit 80 % Erfolgsrate aus den Wärmebildern ableiten. Die Forscher haben noch viele weitere Einflussfaktoren getestet – von der Passwortlänge über die Tippgeschwindigkeit bis zum Material der Tastatur.

Geht es denn wirklich nicht ohne Passwörter? Klar, sagt die FIDO Alliance, die zusammen mit dem W3C schon 2015 den FIDO2-Standard u. a. für Anmeldungen bei Webanwendungen ohne klassische Passwörter definiert hat. Seit letztem Jahr nimmt das Thema deutlich Fahrt auf, weil Apple, Google und Microsoft unter dem Stichwort PassKey die Unterstützung prominent in ihre Endgeräte und Browser einbauen.

Schlüssel für Boot Guard nach Ransomware-Angriff veröffentlicht

Entsprechend der aktuell vorherrschenden „Double Extortion“-Angriffsmethode haben die Angreifer nicht nur den IT-Betrieb beim Hardwarehersteller MSI gestört, sondern auch vorher Daten heruntergeladen. Da der Hersteller das geforderte Lösegeld nicht gezahlt hat, wurden diese nun veröffentlicht. Bis hierhin liest sich der Ablauf wie bei einer Vielzahl aktueller Vorfälle.

Die veröffentlichten Daten enthielten jedoch auch private Schlüssel, mit denen UEFI-Firmware signiert werden kann. Konkret waren Schlüssel für Intel Boot Guard betroffen, die auch die Basis für das Secure Boot von Windows darstellen. Theoretisch können Angreifer damit für die betroffenen Geräte manipulierte UEFI-Images erstellen und diese so signieren, dass sie vom Gerät trotz Prüfung akzeptiert werden. In der Praxis gibt es für solch einen Angriff einige Hürden – vom Erstellen eines lauffähigen UEFI-Images bis hin zum benötigten physischen oder privilegierten Zugriff –, um die Firmware einspielen zu können. Andererseits sind die Schlüssel jetzt quasi öffentlich und leicht für Angreifer jeder Art verfügbar.

Verordnete Sicherheit: Europäische NIS2 auf dem Weg in deutsches Recht

Über das Thema NIS2 hatten wir im Digest schon oft berichtet. Zur Erinnerung: Es geht um die Aktualisierung der europäischen Verordnung zur Informationssicherheit von Behörden und Unternehmen.

Letzte Woche wurde der Referentenentwurf des Umsetzungsgesetztes der NIS2-Richtlinie mit dem gewagten Namen NIS2UmsuCG (NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz) bekannt. Das BMI folgt damit der europäischen Vorgabe, die Richtlinie bis zum 17. Oktober 2024 in deutsches Gesetz zu überführen. Dem geleakten Papier fehlen allerdings noch wichtige Inhalte. Beispielsweise ist die Schätzung zu einmaligen und kontinuierlichen Kosten noch undurchsichtig. Dafür wird die Rolle „CISO Bund“ etabliert, welche sich zentral mit der Sicherheit des Bundes auseinandersetzen soll.

Klar ist außerdem, dass der Begriff UBI (Unternehmen im besonderen öffentlichen Interesse) der Vergangenheit angehören soll. Die Bestimmungen dazu werden jedoch inhaltlich im Umsetzungsgesetz weiter existieren. Klarer werden außerdem die von den Unternehmen und Einrichtungen zu erfüllenden Anforderungen, welche in einem dezidierten Katalog gesammelt werden. Ein Handlungsdruck wird vorerst auf Seiten des BMI-liegen, das mit der deutschen Überführung zum Stichtag wahrscheinlich alle Hände voll zu tun haben wird. Die betroffenen Unternehmen und Einrichtungen müssen die Umsetzungsnachweise anschließend bis 2026 erbringen.

Der Windows-Patch, der die Neuinstallation verhindert – auch von Ihrem Notfall-USB-Stick?

Im letzten Digest ging es um viele Aspekte des Patchens. Nun wurde ein Patch veröffentlicht, der in Einzelfällen auch extreme Auswirkungen haben kann – er verhindert Neuinstallationen auf dem Gerät.

Aber von vorn: Im Herbst 2022 tauchte das BlackLotus-Rootkit auf, das sich unbemerkt in das UEFI einschleichen kann (ganz ohne die oben beschriebenen Schlüssel). Martin Smolár von ESET hat das Rootkit tiefer analysiert und dabei neben bekannten Exploits für bekannte Lücken auch einen neuen Weg gefunden, um Windows Secure Boot zu umgehen (CVE-2023-24932). Dafür hat Microsoft jetzt einen Patch vorbereitet, der allerdings bei vollständiger Anwendung bestehende Boot-Medien ausschließt – und damit auch Installationsmedien und Notfall-Bootsticks, die man vorsorglich vorbereitet hat.

Das Risiko ist Microsoft bekannt, daher bringt das Update erst einmal nur alles in Stellung, und die Rekonfiguration des UEFI im System durch Einspielen einer Revocation List muss vor 2024 händisch angestoßen werden. Das gibt allen ausreichend Zeit, die Notfall-Bootsticks durchzugehen. Aber nicht zu lange warten: Im Q1 2024 soll die Änderung automatisch eingespielt werden.

Wenn der Patch zum Trojaner wird

Die Desktop-Anwendung des VoIP-Telefonie-Herstellers 3CX wurde Ende März trojanisiert. Der Definition für Malware vom Typ „Trojanisches Pferd“ folgend, tat die Software, was sie eigentlich sollte – brachte aber zusätzliche Schadfunktionen mit. Ein sehr schwacher Trost für die Mehrzahl der Betroffenen mag sein, dass sie nicht das eigentliche Ziel des Angriffs waren. Und obwohl das auf den ersten Blick sehr beruhigend klingen mag, erforderte die Kompromittierung einer Großzahl ihrer Clients auch für diese Betroffenen selbst umfangreiche Maßnahmen, um das Ausmaß des Schadens zu bestimmen und trojanisierte Systeme neu aufzusetzen.

Betroffen sind die Versionen Update 6 und 7 für MacOS sowie Update 7 für Windows. Sie wurden bereits beim Hersteller modifiziert und typischerweise automatisch über die eingebaute Update-Funktion der Desktop-Anwendung installiert. Bereinigte Versionen stehen inzwischen bereit. Alle, für die Patchmanagement nicht nur das schnelle, ungeprüfte Installieren von Updates ist, fühlen sich jetzt sicherlich bestätigt. Das IT-Grundschutz-Kompendium fordert in OPS.1.1.3.A15 auch: „Es MUSS entschieden werden, ob der Patch eingespielt werden soll.“

Aber hätte man die Trojanisierung des Software-Updates auf einem Testsystem erkennen können? Beim Beobachten des Netzwerkverkehrs hätte man zuvor nicht vorhandene Verbindungen bemerken können – allerdings haben die Angreifer dafür extra Domainnamen reserviert, die man leicht einem legitimen Zweck zugeordnet hätte. Man hätte auch über die Art und Weise stolpern können, wie ein Teil der Malware in den DLLs der legitimen Software versteckt wurde: Während der erste Teil (der Loader) vom Hersteller unwissentlich direkt in eine DLL-Datei einkompiliert war, wurde der zweite Teil so an eine signierte DLL-Datei angehängt, dass die Authenticode-Signatur weiter gültig ist. Das sich Signaturen so leicht austricksen lassen sollen, klingt nach einem Fehler – und tatsächlich gibt es dagegen bereits seit 2013 einen Patch von Microsoft. Vermutlich ist der Patch auf Ihrem Testsystem aber nicht installiert, denn er wurde kurz nach der Veröffentlichung als „optional“ gekennzeichnet. Zu viele Nutzer meldeten legitime Software, die plötzlich nicht mehr die Signaturprüfung bestand. Auch das ist ein „schwieriger“ Teil des Patchmanagements –die positiven wie negativen Auswirkungen auch von solchen Updates zu prüfen, die der Hersteller nur eingeschränkt empfiehlt.

Mit der Patchmanagement-Brille betrachtet, bleibt als Krux festzuhalten: Ein vom Hersteller empfohlenes Update, das man besser nicht installiert hätte, traf auf ein vom Hersteller nicht uneingeschränkt empfohlenes Update, das man besser installiert hätte.

Hintergrund zum trojanisierten 3CX-Desktop-Client:

Hintergrund zu der manipulierbaren Authenticode-Signatur:

Unser Schwachstellenreport: Was wurde besser? Was nicht?

Letzte Woche haben wir unseren jährlichen Schwachstellenreport veröffentlicht –erstmals nicht nur basierend auf den Prüfergebnissen unserer Pentester, sondern auch mit den wichtigsten Erkenntnissen aus unseren Forensik- und Incident-Response-Einsätzen. Darunter finden sich auch unsere Top-5-Maßnahmen zur Prävention, die die Auswirkungen reduziert oder gar den Vorfall selbst vermieden hätten. Mit dabei sind, passend zum Monatsthema Patchmanagement: „Zeitnahes Patchen exponierter Dienste und Systeme“ – aber auch manipulationsgesicherte Back-ups, Mehrfaktor-Authentisierung, bessere Zugriffskontrolle für Admin-Systeme und bessere Detektionsverfahren.

Bei unseren Penetrationstests, egal ob extern über das Internet oder nach dem Assume-Breach-Gedanken von einem internen Startpunkt aus, identifizieren wir auch regelmäßig Systeme mit bekannten Sicherheitslücken (und fehlenden Patches).

Die gute Nachricht im Jahresvergleich ist, dass wir bei externen Penetrationstests aus der Perspektive eines unauthentifizierten Angreifers aus dem Internet immer weniger kritische Lücken finden. Der Perimeter wird also immer besser geschützt. Das wissen leider auch die Angreifer und versuchen daher, möglichst von innen heraus zu agieren (z. B. VPN-Einwahl per Phishing erbeuten, Malware auf einem Client im internen Netz ausführen lassen). Unsere internen Penetrationstests, die ebenfalls von dieser Position starten, zeigen im Jahresvergleich einen kontinuierlich hohen Kritikalitätsvektor. Tatsächlich endet kaum ein interner Penetrationstest, ohne dass administrative Konten oder gar die gesamte Windows-Domäne übernommen werden konnten.

Noch mehr Auswertungen und Trends finden Sie im HiSolutions-Schwachstellenreport 2023: https://www.hisolutions.com/detail/schwachstellenreport-2023

Cropocalypse: Wenn Wegschneiden nicht Wegschneiden ist.

Direkt nach Redaktionsschluss unseres März-Newsletters wurde eine spannende Sicherheitslücke in zwei verschiedenen Bildbearbeitungstools identifiziert: Wenn man ein Bild zugeschnitten und dieses Bild als PNG gespeichert hatte (z. B. um vertrauliche Details zu entfernen), enthielt die Datei teilweise noch die nicht mehr sichtbaren Bildbereiche (und wenn man Pech hatte, auch das vertrauliche Detail), so dass diese mit entsprechenden Tools wieder sichtbar gemacht werden konnten. Betroffen waren das Bildverarbeitungstool für Google-Pixel-Smartphones sowie das unter Windows 11 „Snipping Tool“ bzw. unter Windows 10 „Ausschneiden und skizzieren“ genannte Screenshot-Tool (das klassische „Snipping Tool“ von Windows 10 war nicht betroffen).

Da zwei komplett verschiedene Programme den gleichen Fehler aufwiesen, haben wir in unserem Labor einen Aufbau erstellt, um weitere betroffene Programme erkennen zu können. Dazu  haben wir auch das Tool der ursprünglichen Entdecker der Lücke, Simon Aarons und David Buchanan, für die Windows 11/10-Tools angepasst. Zudem haben wir weitere Tools, die unsere Kunden für die Screenshot-Erstellung verwenden, auf Auffälligkeiten geprüft – und glücklicherweise keine weiteren betroffenen Tools gefunden. Falls Ihr favorisiertes Screenshot-Tool nicht dabei ist, schicken Sie uns gern eine Mail einschließlich Benennung der Softwarequelle und ggf. mit einem zugeschnittenen PNG.

Fehlt noch die Referenz zum Monatsthema Patchmanagement – diesmal nicht als Herausforderung beim sicheren Betrieb, sondern in der Softwareentwicklung. Eine Änderung in der Android-API fand die Entwicklerin Iliana Etaoin als mögliche Erklärung für den Fehler in der Google-Pixel-App. Seit Android 10 muss man den Parameter „t“ dem Befehl zum Öffnen der Datei mitgeben, damit ungenutzter Speicher nach dem Schreiben freigegeben wird. Davor war das auch ohne zusätzlichen Parameter der Fall. Möglicherweise wurden also die Änderung der Funktionsweise des Befehls und die sich daraus ergebenden Seiteneffekte nicht berücksichtigt.

https://iliana.fyi/blog/acropalypse-now/

Reddit-Ausfall: Nicht nur Systeme, sondern auch die Menschen aktuell halten 

In der pointierten Kurzform klingen die Ursachen für den jüngsten Ausfall der Plattform „Reddit“ wie der Albtraum jedes Betreibers von historisch gewachsenen Systemlandschaften: Die Routing-Regeln, die der Ursprung für einen Ausfall waren, wurden vor sehr langer Zeit geschrieben – und jeder aus dem ursprünglichen Team war inzwischen entweder in einer anderen Rolle im Unternehmen oder ganz woanders unterwegs.

Für mehr Details empfiehlt sich der sehr lange, aber auch schön zu lesende Post des Reddit-Engineering-Teams. Er schildert sehr anschaulich das Auf und Ab zwischen gewählten Lösungsansätzen und dann plötzlich querschlagenden Komplikationen, für die wieder neue Lösungen gesucht werden müssen. Auch die schwierige Entscheidung zwischen dem Weiterdebuggen im laufenden Restbetrieb und dem aktiven Abschalten zum Einspielen der Back-ups ist ein gutes Beispiel für die Entscheidungen in einer Krise, wie sie unsere Krisencoaches auch bei unseren Kunden begleiten.

Neben dem Problem, dass es für das ursächliche Teilsystem keine Experten mehr gab und dieses ganz anders verwaltet wurde als die neueren Teile, so dass sich die Mitarbeiter erst tiefer einarbeiten mussten, war auch ein weiteres organisatorisches Problem, dass die Wiederherstellung aus dem Back-up in der Form nicht geübt worden war. Damit fehlten Erfahrungswerte für die Dauer der Wiederherstellung, und man liest aus dem Beitrag auch heraus, dass dieser Lösungsweg aus Furcht vor Fehlern anfangs vermieden werden sollte.

Aber auch unser Monatsthema Patchmanagement kommt in dem Bericht nicht zu kurz: Die Back-up-Wiederherstellungsskripte wurden nicht an die Änderungen im produktiven Cluster angepasst. Daher passten sie nicht zu architektonischen Änderungen des Reddit-Teams, enthielten aber auch Kommandos für eine inzwischen End-of-Life-Version von Kubernetes. Der ursächliche Fehler mit den „Route Reflectors“ basierte auf einer Umbenennung, die bereits mit Kubernetes 1.20 im Jahr 2020 eingeführt wurde. In den folgenden Versionen waren dann noch übergangsweise die alten Bezeichner gültig, bis sie in der beim Vorfall installierten Version 1.24 ganz entfernt wurden.

Explodierende USB-Sticks

In fast jeder Sensibilisierungsschulung wird auf die Risiken von gefundenen oder zugesendeten USB-Sticks hingewiesen. Dabei sind aber meist Risiken für die IT-Systeme gemeint, in die der USB-Stick dann eingesteckt wird. Die Beispiele reichen vom einfachen Speicher-USB-Stick, auf dem eine Malware liegt und die vom Nutzer aus Neugier per Hand gestartet wird, über automatisierte Tastaturen wie den „Rubber Ducky“ bis hin zu USB-Geräten, die das Gerät mit Stromschlägen physisch beschädigen sollen (z. B. USBKill).

In Ecuador haben fünf Journalisten eine noch drastischere Version per Brief zugeschickt bekommen. Die Geräte in Form von handelsüblichen USB-Sticks sollten nach dem Einstecken explodieren. In einem Fall kam es tatsächlich zu einer Explosion des enthaltenen Sprengstoffes, und der Journalist Lenin Artieda wurde dabei verletzt. In den anderen vier Fällen konnten die Briefe rechtzeitig als Briefbombe identifiziert werden.

https://arstechnica.com/gadgets/2023/03/journalist-plugs-in-unknown-usb-drive-mailed-to-him-it-exploded-in-his-face/