Autor: Dr. Jörg Schneider

Senior Expert
News

Trojanisierte SSH-Keys

In der Linux-Welt wird die Authentisierung beim Fernzugriff gern mit SSH-Keys umgesetzt. Diese Schlüsselpaare aus privatem und öffentlichem Schlüssel haben gegenüber Passwörtern viele Vorteile – so können z. B. für einen Nutzer mehrere autorisierte Schlüssel hinterlegt werden, und der gleiche Mensch kann sich je nach Quellrechner unterschiedlich anmelden (z. B. Laptop, Desktopsystem oder Sprungserver). In der zuständigen Datei „authorized_keys“ können noch weitere Einschränkungen für Zugriffe mit bestimmten Schlüsseln gemacht werden. Beispielsweise kann ein Backupsystem einen Zugriff erhalten, der lediglich das Ausführen des notwendigen Datensammelskripts erlaubt.

In einem Blogpost wurde gezeigt, wie sich diese eigentlich gut gemachte Sicherheitsfunktion ausnutzen lässt, um eine Hintertür auf einem System zu hinterlassen. Eine notwendige Voraussetzung dafür ist der Zugriff auf die Datei „authorized_keys“. Damit kann man sich natürlich auch einfach seinen eigenen Schlüssel in die Liste schreiben, aber das könnte bei einer Inventur der Zugänge auffallen. Daher wird bei dem geschilderten Angriff ein bestehender Eintrag so modifiziert, dass bei jedem Anmelden des berechtigen Nutzers zusätzlich eine Backdoor gestartet wird.

Die betroffene Datei „authorized_keys“ ist sehr geschickt gewählt, da sie nur jeweils den öffentlichen Schlüssel der berechtigten User enthält. Diese Datei wird daher häufig bei größeren Setups und automatischen Deployments mit Git versioniert und dann automatisch auf alle Systeme verteilt. Eine versteckte Manipulation kann also schnell viele kompromittierte Systeme zur Folge haben.

https://blog.thc.org/infecting-ssh-public-keys-with-backdoors

News

Datenaustauschplattform mit unerwünschten Nebenfunktionen

Um keine Dateien als Mailanhänge mehr verschicken zu müssen, werden häufig Datenaustauschplattformen aufgesetzt. Ähnlich wie das ESG können diese zur Vorprüfung eingehender und ausgehender Dateien genutzt werden und damit als klar definierter Ein- und Austrittspunkt aus dem eigenen Netz – also wieder eine klassische Sicherheitsfunktion. Bei der Lösung MOVEit Transfer von Progress ist jedoch Ende Mai eine Sicherheitslücke bekannt geworden, die ebenfalls bereits aktiv ausgenutzt wird. In Deutschland wurden diesbezüglich mehr als 100 betroffene Systeme vermutet. Mehrere AOKs haben die Lösung im Einsatz und hatten sie vorsichtshalber abgeschaltet.

Sehr viele Instanzen sind immer noch in der verwundbaren Version erreichbar – und das, obwohl die Lücke bereits u. a. von Ransomware-Gruppen ausgenutzt wird. Es gibt sogar Hinweise darauf, dass die CL0P-Gruppe bereits seit 2021 mit der Ausnutzung der Lücke experimentiert.

https://community.progress.com/s/article/MOVEit-Transfer-Critical-Vulnerability-31May2023

https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-158a

https://aok-bv.de/presse/pressemitteilungen/2023/index_26408.html

News

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

Passwörter

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.

News

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.

News

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.

News

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.

Schwachstelle

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:

News

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

News

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.

„Acropalypse“ NOW!

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