Kategorie: Schwachstelle

Allgemein, Penetrationstest, Schwachstelle

Windows-Angriffe entgegen der Vertrauensstellung

Windows Domänen lassen sich durch Vertrauensstellungen zusammenbringen. Wird der Zugriff nur in eine Richtung benötigt kann man das Vertrauen auch nur einseitig aussprechen – aber sind damit Angriffe in die andere Richtung ausgeschlossen? Leider nicht, denn es gibt Wege um das Vertrauen entgegen der „Direction of Access“ auszunutzen. 

In dem Artikel starten wir erst mit ein paar Grundlagen, um dann den konkreten Angriff vorzustellen. Zum Schluss geben wir noch Tipps für Gegenmaßnahmen und Detektionsmöglichkeiten. 

Vertrauensstellung, was ist das? 

Eine der Kernaufgaben des Active Directory (AD) ist es dafür zu sorgen, dass Nutzer sich bei verschiedenen Diensten und Systemen im eigenen Netz anmelden können. Dafür vertrauen alle Domänenmitglieder dem eigenen Domain Controller (DC), dass dieser die Authentizität der Nutzer gut prüft. 

Aber das Vertrauen kann auch über die Grenzen einer Domäne oder eines Forests hinausgehen1. Dazu wird in beiden Domänen eine Vertrauensstellung (Trust) eingerichtet. Im einfachsten Fall ist sie beidseitig, dann können Nutzer aus beiden Domänen Ressourcen in der jeweils anderen Domäne nutzen. Aber man kann auch nur eine einseitige Vertrauensstellung (One-Way Trust) einrichten, dann können Nutzer der einen Domäne Ressourcen der anderen Domäne nutzen aber nicht umgekehrt. Hier kommt man leicht mit den Richtungen und Begriffen durcheinander, daher findet sich in jeder guten AD-Anleitung ein Bild wie dieses: 

Für unser Beispiel würde dies also so aussehen: 

Ein Angreifer, der in der vertrauten Domäne (hier PARTNER.local) ein Konto oder gar die ganze Domäne übernommen hat, kann natürlich über die Vertrauensbeziehung auch Ressourcen in der anderen Domäne nutzen (entlang der “direction of access”). Bei der beidseitigen Vertrauensstellung gilt das logischerweise in beide Richtungen, aber auch bei der einseitigen Vertrauensstellung gibt es einen Grenzfall wie ein Angreifer, der bereits den Domain Controller übernommen hat, sich entgegen der “direction of access” weiterbewegen kann: 

Kerberos über Grenzen hinweg, die Theorie 

Für die verteilte Anmeldung nutzt Active Directory das Kerberos-Protokoll, das ursprünglich aus der akademischen Welt kommt und ganz im Sinne der akademischen Zusammenarbeit auch bereits alles für die hochschulübergreifende Zusammenarbeit mitbringt. Das Konzept hinter der Vertrauensstellung heißt bei Kerberos Cross-Realm-Authentifizierung.  

Innerhalb eines Realms (oder Domäne in AD-Terminologie) meldet sich der Nutzer initial beim Authentisierungsserver (AS) an und erhält ein Sitzungsticket (Ticket Granting Ticket, TGT). Mit diesem Ticket kann der Nutzer dann beim Ticket-Granting-Server (TGS) Service-Tickets beantragen und sich dann mit diesen bei den Systemen und Services ausweisen, die er nutzen möchte. 

Für die Cross-Realm-Authentifizierung wird dann einfach der fremde TGS wie ein Dienstserver im eigenen Realm betrachtet. Der Nutzer fragt also seinen Heimat-TGS nach einem Ticket für den Fremd-TGS. Dieses Ticket funktioniert dann analog zu einem TGT im anderen Realm. Der Nutzer beantragt mit diesem dann ein Service-Ticket beim Fremd-TGS für den eigentlichen Service, den er nutzen möchte. In beiden Schritten werden die gleichen Befehle ausgetauscht. 

In der Praxis sind der TGS und der AS keine getrennten Server, sondern zwei Funktionen des Key Distribution Centers (KDC), die beide über den UDP-Port 88 erreicht werden. In der Windows-Welt ist das ein Service auf dem Domain Controller.  

Um den Angriff gleich verstehen zu können, müssen wir noch einen Schritt tiefer gehen. Die Tickets, die bei Kerberos immer wieder ausgetauscht werden, sind Datenstrukturen, die mit einem symmetrischen Schlüssel verschlüsselt sind. Diese Schlüssel werden für Nutzer, Services und auch die Zwischenschritte am TGS in Principals gespeichert. Die Schlüssel für die Sitzungstickets (TGT) sind beispielsweise im Principal “krbtgt” gespeichert. 

Für den ersten Schritt, die initiale Anmeldung am AS, basiert der Schlüssel auf dem Nutzerpasswort. Für die anderen Fälle sind auch andere Wege möglich, aber in Windows wird für die Fälle, in denen kein Nutzer involviert ist, einfach ein zufälliges Passwort generiert und daraus der Schlüssel abgeleitet. 

Innerhalb einer Domäne bzw. eines Realms ist das auch einfach, da wir hier ja über eine zentral verwaltete Principal- bzw. Benutzer-Datenbank reden. Wenn wir jetzt aber die Grenzen überschreiten wollen, muss es in beiden Datenbanken einen gleichartigen Eintrag mit dem gleichen Schlüssel (also dem gleichen Passwort) geben. Auf der einen Seite der Grenze, um das Ticket verschlüsseln zu können, und auf der anderen Seite, um es wieder entschlüsseln zu können.  

Die Umsetzung im AD 

Jetzt wollen wir uns anschauen, was bei einer Vertrauensstellung in einem Windows Active Directory (AD) passiert. 

Das Trusted Domain Object (TDO) 

Um sich zu merken, mit welchen anderen Domänen oder Forests eine Vertrauensstellung existiert, wird pro Vertrauensstellung im “System”-Container der dazugehörigen Domänen (bzw. den Root-Domänen bei Forest-Trusts) jeweils ein Objekt angelegt – ein sogenanntes Trusted Domain Object (TDO). Auch bei einseitigen Vertrauensstellungen wird an beiden Enden ein TDO angelegt (einmal als eingehende, einmal als ausgehende Vertrauensstellung).  

In den Attributen des Objekts werden alle Einstellungen für die Vertrauensstellung gespeichert. In dem Objekt wird zudem ein Passwort für das TDO gespeichert. Und zwar zum einen wie man es sonst von Benutzern und Computern kennt als Hash bzw. abgeleiteter Schlüssel und in diesem Fall zusätzlich auch im Klartext. Das Passwort wird automatisch alle 30 Tage geändert und – um Störungen beim Passwortwechsel vorzubeugen – wird jeweils das aktuelle sowie das vorherige Kennwort im TDO gespeichert. Das Passwort, und das ist wichtig, ist für beide Objekte gleich. 

Das Objekt kann man in der MMC unter “Active Directory-Benutzer und -Computer” sehen, wenn man zuvor unter “Ansicht” die “Erweiterten Features” aktiviert hat. Dort findet es sich dann unter dem vollen Namen der jeweils anderen Domäne. 

Auf dem HISOCORP-DC
Auf dem PARTNER-DC

Der versteckte User 

Das es auf beiden Seiten einen gleichartigen Eintrag mit dem gleichen Schlüssel geben muss, hatten wir schon bei der Kerberos-Theorie gesehen. In der Windows-Welt sind die beiden TDO aber nicht die einzigen Repräsentanten der Vertrauensstellung. 

Schaut man sich die Nutzerliste auf der Seite der vertraueten Domäne (bei uns PARTNER.local) z. B. im ADSI-Editor etwas genauer an, findet sich dort ein User dessen Namen an die vertrauenden Domäne erinnert – in unserem Fall finden wir einen Benutzer HISOCORP$. 

ADSI-Editor auf dem PARTNER-DC.

In vielen anderen Ansichten wie der MMC wird der Nutzer ausgeblendet. Praktischerweise hat dieser versteckte Benutzer das gleiche Passwort, das auch in beiden TDO-Objekten im Klartext gespeichert wird. 

Der Angriff entgegen der Vertrauensrichtung 

Nach so viel Theorie und Grundlagen wollen wir jetzt endlich schauen, wie wir das Vertrauen gegen den Strom ausnutzen können. Noch einmal zur Erinnerung: Wir wollen gegen die erlaubte “Direction of Access” arbeiten. 

Der Trick ist jetzt, dass der versteckte Nutzer in der vertrauten Domäne ein fast normaler Nutzer ist, und wir sein Passwort kennen. 

Dann besteht der Angriff aus diesen Schritten: 

  1. Die vertrauende Domäne kompromittieren (in unserem Beispiel HISOCORP.local) 
  2. Auf dem kompromittierten DC das Passwort aus dem Trusted Domain Object (TDO) auslesen
  3. Mit dem bekannten Nutzernamen und dem ausgelesenen Passwort bei der vertrauenden Domäne (in unserem Beispiel PARTNER.local) anmelden. Also ein TGT beziehen.
  4. Mit dem TGT können jetzt Dienst-Tickets bezogen werden und ggf. Dienste genutzt werden. 

Auf Schritt 1 gehen wir nicht näher ein. Für die folgenden Schritte nehmen wir an, es ist bereits gelungen die Domäne zu kompromittieren und Zugriff auf einen Domain Controller (DC) zu erlangen. Das ist keine kleine Annahme und damit haben wir bereits vollen Zugriff auf alle Ressourcen auf dieser Seite der Vertrauensstellung. 

Auf dem DC können wir jetzt für Schritt 2 das bekannte Tool Mimikatz nutzen. Für das Auslesen des TDO gibt es einen eigenen Befehl: lsadump::trust /patch 

Im TDO ist das gemeinsame Passwort im Klartext gespeichert – in der Ausgabe oben jedes Zeichen als eine Hexadezimalzahl nach dem Stichwort „CLEAR“ – sowie verschiedene Hashwerte vom Passwort.  

Den NT-Hash (rc4_hmac_nt) können wir direkt für Schritt 3 nutzen. Die beiden anderen Hashes/Schlüssel wurden mit einem anderen Salt erzeugt und entsprechen daher nicht den Hashes, die bei der vertrauten Domain im versteckten Nutzer gespeichert sind. Aber wir kennen jetzt ja das Klartextpasswort und die Berechnungsformel für die Nutzer-Schlüssel, können also diese beiden Werte auch selbst berechnen. 

Wir nehmen in Schritt 3 den einfachsten Weg und melden uns direkt mit dem erbeuteten NT-Hash an. Dafür bietet sich beispielsweise die impacket-Suite an. Damit können wir direkt ein TGT beziehen: 

Das TGT können wir in Schritt 4 dann zum Beispiel für einen Zugriff auf eine Dateifreigabe per SMB nutzen: 

Im Beispiel wird auf die SYSVOL-Freigabe des fremden DC zugegriffen. Das geht, weil diese Freigabe grundsätzlich von allen Nutzern (Gruppe „Domänenbenutzer“) gelesen werden kann.

Da der Nutzer in der normalen Administration nicht sichtbar ist, ist er weder Mitglied in anderen Gruppen noch wurde der User selbst für Dienste oder Zugriffe explizit berechtigt. In einem realen Netz finden sich aber auch häufig weitere Freigaben und Dienste, die alle gemeinsam nutzen und die für die allgemeine Gruppe der Domänenbenutzer freigegeben sind. 

Bei der Bewertung von Sicherheitslücken wird immer unterschieden, ob sie auch ohne Login oder nur nach erfolgreicher Authentifizierung möglich sind. Und genau diesen Sprung zum authentifizierten Angreifer konnten wir jetzt machen, unabhängig davon wie wenig Rechte dem versteckten Nutzer eingeräumt wurden.  

Ein Beispiel sind Kerberoasting-Angriffe, die darauf abzielen, Service-Konten zu übernehmen, die nicht mit einem zufällig automatisch generierten Passwort, sondern mit einem menschlich erdachten Passwort gesichert sind. Einzige Voraussetzung für diesen Angriff ist der Zugriff auf ein funktionierendes Nutzerkonto in der Domäne. Dieser Nutzer muss gar keine Zugriffsrechte für den zu knackenden Dienst haben, daher funktioniert der Angriff auch mit dem versteckten Nutzer: 

Im Anschluss haben wir Zugriff auf ein Nutzerkonto mit mehr Zugriffsrechten, meist sogar einigen administrativen Rechten und können uns so immer weiter in der Partner-Domäne ausbreiten. 

Mögliche Detektions- und Gegenmaßnahmen 

In den nächsten Abschnitten wollen wir uns anschauen, wie man sich gegen diese Art von Angriffen wappnen kann und auch kurz Maßnahmen besprechen, die zwar naheliegend klingen, aber nicht wirken.  

All diese Maßnahmen zielen auf die Sicherheit der vertrauten Domäne (in unserem Beispiel PARTNER.local). Für die vertrauende Domäne (in unserem Beispiel HISOCORP.local) gibt es unabhängig von dem hier geschilderten Problem auch einiges zu beachten, um nicht durch die Vertrauensstellung Probleme zu bekommen. Da dies aber der geplante Zugriffsweg ist, gibt es dazu bereits passende Anleitungen. 

Detektion 

Das versteckte Nutzerkonto für die Vertrauensstellung wird nie als Nutzer im eigentlichen Sinn verwendet. Daher sind jegliche Aktivitäten mit der Nutzerkennung (Muster <Domänenkürzel>$) wie das Ausstellen eines TGT (Windows Event 4768), eines Service Tickets (Anfordern Windows Event 4769, Erneuern Windows Event 4770, Fehler Windows Event 4773) oder eine Anmeldung ein eindeutiges Zeichen für eine Ausnutzung.  

Gegenmaßnahmen 

Auf verschiedenen Wegen kann die Anmeldung mit dem versteckten Nutzerkonto verhindert werden. 

Die Systeme der beiden Domänen befinden sich meist auch in unterschiedlichen Netzen, daher kann per Firewall der Zugriff auf Port 88 zum Domain Controller der vertrauten Domäne (in unserem Beispiel PARTNER.local) vom Netz der vertrauenden Domäne (HISOCORP.local) gesperrt werden. In die umgekehrte Richtung ist der Zugriff nötig, damit Nutzer sich Service Tickets für freigegebene Dienste der vertrauenden Domäne ziehen können, in dieser Richtung jedoch nicht. Damit wird der Angriff verhindert, wenn der Angreifer aus dem anderen Netz agiert. Hat der Angreifer unabhängig von der Kompromittierung der vertrauten Domäne auch bereits Netzwerkzugriff auf Systeme der vertrauten Domäne, hilft die Firewallregel nicht. 

Die Nutzung des versteckten Kontos kann auch per GPO unterbunden werden. Dafür muss die Regel „Zugriff vom Netzwerk auf diesen Computer verweigern“ erstellt werden und dort dann manuell das Konto (in unserem Beispiel HISOCPRP$) eintragen werden. Der Kontoname muss händisch eingegeben werden, da bei der „Durchsuchen“-Funktion das Konto auch ausgeblendet ist. Wenn die GPO wirksam ist, kann zwar weiterhin ein TGT für dieses Konto bezogen werden, aber keine Servicetickets. Damit geht auch kein Zugriff auf Dienste (wie Dateifreigaben) oder der oben geschilderte Kerberoasting-Angriff. 

Als weitere Verteidigungsschicht können die Zugriffsrechte für den Nutzer eingeschränkt werden. Der Nutzer ist automatisch Mitglied in der Gruppe „Domänenbenutzer“ und gehört auch zur Gruppe „Benutzer“. Dienste und Dateien sollten nicht für eine der beiden Gruppen freigegeben werden, auch wenn sie von allen genutzt werden sollen. Stattdessen bieten sich für solche Freigaben eine zusätzlich gepflegte Gruppe mit allen aktiven Nutzern an. 

Maßnahmen, die nicht wirken 

Es gibt einige Gegenmaßnahmen, die sehr naheliegend klingen, aber tatsächlich nicht umsetzbar oder hilfreich sind.  

So kann der versteckte Nutzer nicht einfach deaktiviert oder gelöscht werden, entsprechende Versuche führen direkt zu Fehlermeldungen.  

Der Nutzer hat als primäre Gruppe die Gruppe „Domänenbenutzer“. Das ist eine automatische Gruppenzuordnung, das heißt man kann zwar eine andere primäre Gruppe eintragen aber der Nutzer wird dennoch immer Mitglied der „Domänenbenutzer“ bleiben. 

Fazit 

Aus einer einseitigen Vertrauensstellung zwischen Domänen kann sich damit auch ein Risiko entgegen der „Direction of Access“ ergeben. Wird die eine Domäne kompromittiert erhält der Angreifer auch das Passwort für einen versteckten Nutzer in der anderen Domäne. Der hat zwar kaum Zugriffsrechte, aber kann als erster „Fuß in der Tür“ für weiterführende Angriffe genutzt werden. 

Da Risiko lässt sich aber durch Firewallregeln, GPOs und gutes Rechtemanagement adressieren. Ein erfolgreicher Angriff lässt sich auch eindeutig in den Windows Events identifizieren. 

  1. Im Folgenden werden wir der Einfachheit halber immer von einer Domäne sprechen, da sich ganze Forests in diesem Fall wie eine Domäne verhalten ↩︎

Woher kommen eigentlich Zero-Days?
Schwachstelle, Zeroday

Woher kommen eigentlich Zero-Days?

Nachtrag (2025-05-16): Nach Hinweisen einiger Lesender haben wir die Definition von Zero-Days am Anfang des Artikels angepasst. Vorher benannten wir Zero-Days als „Lücken, die am heutigen Tage bekannt werden“. Dies sorgte daraufhin intern für eine (akademische) Diskussion zu dem Thema, die allerdings am Ziel des Beitrages vorbei ging. Insbesondere war dies verwirrend im Kontext des referenzierten Beitrages der GTIG, deren Definition wir in der aktuellen Version übernommen haben. Vielen Dank für die Hinweise!

Sicherheitslücken ohne verfügbaren Patch oder Mitigation, die bereits ausgenutzt werden, nennt man Zero-Days. Besonders interessant sind diese Lücken offensichtlich für Angreifende, wenngleich auch Admins Diese im Blick behalten sollten. Aber wer findet eigentlich Zero-Days?

Ein prominenter Player in dem Bereich ist die Google Threat Intelligence Group (GTIG). Im Jahresbericht zu 2024 zieht sie Bilanz zu Zero-Day-Aktivität und -Attribution und was man daraus lernen kann. Neben einigen durchaus spannenden Zahlen zum Thema „ausgenutzte Systeme“ war für uns vor allem der Absatz zu Attribution relevant. Solche Zahlen sind zwar grundsätzlich mit Vorsicht zu genießen, da eine direkte Zuordnung oft sehr schwierig ist. Die GTIG hat „nur“ 34 der 75 erkannten Zero-Days attributiert. Wenn man die Methodik akzeptiert, dann ordnet sie 15 Ausnutzungen staatlichen Akteuren zu. Weitere acht wurden durch kommerzielle Anbieter, wie z. B. Cellebrite, genutzt.

Da auch diese Händler oftmals für staatliche Akteure tätig sind, kann man einen beunruhigenden Trend erkennen: Die Ausnutzung von Zero-Days wird vermehrt durch staatliche Akteure gesteuert und finanziert, also auch direkt durch Steuergeld.

https://www.heise.de/news/Steuergeld-finanziert-Angriffe-mit-Zerodays-10367137.html

https://cloud.google.com/blog/topics/threat-intelligence/2024-zero-day-trends?hl=en

Hier gibt es weitere News aus dem Mai

Allgemein, Risikomanagement, Schwachstelle, Supply Chain

Drohende Abschaltung der CVE-Datenbank und mögliche Alternativen

Kurz vor Ostern schreckte eine Nachricht des CVE-Teams die Sicherheitswelt auf. Die Finanzierung des CVE-Programms stand auf der Kippe und im Extremfall wäre einen Tag später bereits Schluss gewesen. Der Aufschrei war zu Recht groß und so konnte der Betreiber MITRE eine Vertragsverlängerung bis Anfang nächsten Jahres erreichen. Aber was kommt dann?  

In diesem Blogpost wollen wir mit etwas Abstand zu den Ereignissen zusammenfassen, welche Alternativen in der Diskussion um eine mögliche CVE-Abschaltung oft genannt wurden und ob sie tatsächlich in die Fußstapfen von CVE treten könnten.  

Anwendungsfälle

Zuerst wollen wir uns kurz anschauen, wo wir und viele unserer Kunden Berührungspunkte mit CVE haben. Es gibt darüber hinaus weitere Anwendungsfälle, aber für diese häufigen Nutzungen wollen wir uns im Folgenden die Alternativen anschauen. 

Risikomanagement im ISMS 

Beim Thema Informationssicherheit denken viele Laien als Erstes an die Sicherheitsupdates, die ihre Geräte regelmäßig von ihnen fordern. Im professionellen ISMS kommt noch dazu, dass einige Updates nur mit einer Betriebsunterbrechung eingespielt werden können oder unerwünschte Nebenwirkungen haben. Es muss also eine bewusste Entscheidung zwischen dem neu hinzugekommenen Sicherheitsrisiko und den betrieblichen Einschränkungen getroffen werden. Wenn eine Sicherheitslücke bereits bekannt ist, aber noch kein Patch verfügbar ist, wird die Entscheidung zwischen Abschalten und Risikoakzeptanz noch herausfordernder. 

Die reinen CVE-Nummern können in dem Anwendungsfall bei der weitergehenden Recherche helfen oder teilweise den Abgleich von verschiedenen Prüfformen ermöglichen (z.B. ob die im Pentest erkannten Lücken, bereits aus einem anderen Audit adressiert werden). 

Meist nutzt man jedoch auf CVE-basierte Datenbanken wie die National Vulnerability Database (NVD) der US-Regierung oder Ableitungen davon, die bereits eine allgemeine Risikobewertung mitbringen. Damit können bereits erkannte Risiken schneller und ressourcensparsam vorbewertet werden. Das konkrete Risiko für die jeweilige Betriebssituation muss man dennoch individuell bewerten (z.B. ob die betroffene Funktion überhaupt genutzt wird). 

Außerdem nutzen viele Informationsdienste und Vulnerability-Management-Tools CVE-basierte Datenbanken, um auf neu bekanntgewordene Schwachstellen hinzuweisen. Im besten Fall wählt man als Betreiber alle genutzten Softwareprodukte aus und wird dann aktiv auf neue Schwachstellen hingewiesen. 

Schwachstellenscan für Container 

Für Betreiber von containerisierten Services ist das Scannen von Containern bzw. Container-Scanning ist ein weiterer Anwendungsfall für die Nutzung von CVEs.  

Dabei werden Container-Images auf Sicherheitslücken überprüft. Zuerst wird analysiert, welche OS-Pakete, Dependencies und weitere Software in dem zu scannenden Image benutzt werden, z.B. openssl. Anschließend werden die Findings (Name der Komponente sowie Versionsnummer/-stand) mit den gängigen CVE-basierten Datenbanken wie NVD abgeglichen. Sollten bekannte Schwachstellen identifiziert werden, wird dies an das Scanning-Tool zurückgemeldet und das Tool erstellt auf Basis dieser Informationen einen Bericht. 

Der Bericht enthält dann. welche CVE gefunden wurde, wie schwerwiegend diese ist bzw. wie hoch ihr CVSS-Score ist, wo im Image die Schwachstelle gefunden wurde, und es werden in den meisten Fällen auch direkt Mitigationsmaßnahmen empfohlen. Diese Maßnahmen beziehen sich entweder auf ein Update/Upgrade der verwendeten Version auf die nächste sichere Version oder auf geeignete Konfigurationen, um die Sicherheitslücke zu schließen. 

Gängige Tools, die man für Scanning verwenden kann, sind u.a. die OpenSource Tools Trivy sowie Clair. Kommerzielle Tools, die z.B. auch einen erweiterten Support zur Verfügung stellen können oder weitere Funktionen haben, sind Snyk sowie JFrog.

Verwendet man Container-Scanning in seiner Infrastruktur, hat man den großen Vorteil, dass Schwachstellen noch vor dem Deployment entdeckt werden können. Auch ist das Container-Scanning in CI/CD-Pipelines automatisierbar und bietet so eine weitere Dosis Sicherheit. 

Software Supply Chain 

Nicht nur Betreiber, sondern auch Softwareanbieter benötigen ein Risikomanagement. Sicherheitsrelevante Fehler in genutzten Komponenten, Bibliotheken und Hilfstools können sich auch auf die ausgelieferte Software übertragen. Angriffe, die gezielt auf diese Vererbung der Sicherheitslücken abzielen, werden Software-Supply-Chain-Angriff genannt. 

Die reinen CVE-Nummern helfen den Softwareanbietern bei der Kommunikation. In ihren Release-Notes können sie ihren Kunden eindeutig aufzeigen, welche Schwachstellen (eigene und von Drittkomponenten geerbte) beseitigt wurden. Die Kunden können die Information dann mit ihrem eigenen Risikomanagement aus Betriebssicht abgleichen. Die CVE-Nummer kann aber auch gut genutzt werden, um aufzuzeigen, dass die eigene Software von einer konkreten Lücke nicht betroffen ist. So forderten beispielsweise bei der Log4Shell-Schwachstelle in der Log4j-Bibliothek viele große IT-Organisationen von ihren Zulieferern Negativbescheide, dass ihre Produkte von dieser Lücke nicht betroffen waren. 

Ähnlich wie die Scanner für Container gibt es auch Scantools, die über die Versionsstände von eingebundenen Dependencies ermitteln, ob eine neue Schwachstelle bekannt wurde. Nutzt man zum Verwalten der Abhängigkeiten einen Registry-basierten Ansatz (z.B. mit NPM), erhält man so leicht die notwendigen Informationen. Für händisch hinzugefügte Abhängigkeiten (z.B. JAR-Archiv, Binärbibliothek, JavaScript) gibt es ebenfalls Scanner, die teilweise Heuristiken einsetzen müssen, um den eindeutigen Namen der Bibliothek und die Versionsnummer zu bestimmen (z.B. RetireJS, Trivy). 

Exploits/Lücken nachvollziehen im Pentest / in der Incident Response 

Im Bereich von Penetrationstests, technischen Audits und Incident Response werden CVEs regelmäßig verwendet. Durch die eindeutige Benennung sprechen sowohl Kunden als auch Sicherheitsberatende über dieselbe Sicherheitslücke. Kunden erlaubt dies beispielsweise einfacher einzuschätzen, in welchen Versionen eine Sicherheitslücke eines eingesetzten Systemes vom Hersteller behoben wurde, da Changelogs der Hersteller und externe Quellen die CVEs zu betroffenen Versionen mappen. 

Ebenso werden anhand der CVE z.B. weiterführende Recherchen, sei es über Suchmaschinen, auf GitHub oder in dedizierten Vulnerability Databases, erleichtert. Es kann z.B. besser eingeschätzt werden, ob bereits öffentlich verfügbare Write-Ups, Exploits oder Proof-of-Concept Code existiert, der durch Angreifende verwendet werden kann. Im Incident Response kann dies als Indiz für die Ausgereiftheit der Angreifenden herangezogen werden. 

Gefundene Schwachstelle melden 

Bei der Meldung von Schwachstellen wird die gefundene Sicherheitslücke im Rahmen von Responsible Disclosure häufig bei einer CVE Numbering Authority (CNA) eingereicht, um für diese Lücke eine CVE zugewiesen zu bekommen. Da während des Prozesses der Meldung viele Parteien beteiligt sein können, z.B. die Entdeckenden der Lücke, die Herstellenden des Systems, die Personen, die das System einsetzen, oder auch Vermittelnde wie ein CERT, soll eine CVE dabei sicherstellen, dass von der gleichen Lücke gesprochen wird. Außerdem können alle Beteiligten den Fortschritt während des Prozesses der Responsible Disclosure effektiver verfolgen. Nach der Behebung einer Sicherheitslücke erlaubt eine veröffentlichte CVE der Öffentlichkeit, z.B. betroffenen Firmen, den Einfluss der Sicherheitslücke auf die eigenen Systeme zu beurteilen und ggf. Maßnahmen zu ergreifen. 

Alternativen 

Für diese Anwendungsfälle wollen wir uns jetzt mögliche Alternativen anschauen. Wir haben dabei die Ansätze ausgewählt, die in den Tagen um die drohende CVE-Abschaltung am breitesten diskutiert wurden. Einige der Ansätze sind aktuell noch nicht praktisch nutzbar oder zielen auch auf ein ganz anderes Anwendungsfeld ab. Wenn sie dennoch in der Diskussion Raum eingenommen haben, haben wir sie hier aufgegriffen. 

Das Original: MITRE CVE 

Betrieben von der Non-Government-Organization (NGO) MITRE Corporation, gilt das Common Vulnerabilities and Exposures (CVE) System als die Referenz in der Welt der IT-Sicherheit für Sicherheitslücken und Schwachstellen. Durch die Vereinheitlichung der Nummerierung von Sicherheitslücken ist jederzeit eindeutig, auf welcher Sicherheitslücke man sich bezieht.  

Dadurch ist das Kürzel “CVE” für einige auch schon zum Synonym für “Sicherheitslücke” geworden und wird meist auch mit den detaillierten Einträgen in CVE-basierten Datenbanken wie der NVD gleichgesetzt. Die CVE-Datenbank selbst enthält allerdings nur sehr wenige Informationen zur Lücke. Grundsätzlich gerade so viele Informationen, um die Lücke wiedererkennen zu können. Das Datenbankformat erlaubt auch Risikoeinschätzungen und andere Informationen, diese sind aber optional.  

Besondere Aufmerksamkeit bekam dieses System, nachdem die US-Regierung unter Trump im April 2025 die Finanzierung stoppte. Dieses System wird vom US-Heimschatzuministerium (DHS) sowie der untergeordneten Cybersecurity and Infrastructure Security Agency (CISA) unterstützt. Durch das Ziehen einer Optionsklausel im Vertrag der Förderung durch die US-Regierung, bleibt das MITRE CVE System bis 16.03.2026 am Start. Was danach passiert, kann niemand abschätzen. 

Dadurch, dass dieses System seit 1999 im Einsatz ist, hat es sich zum Standard entwickelt. Es ist daher die derzeit aktuellste, kompatibelste und vollständigste Lösung. 

Neu aufgedeckte Schwachstellen werden von den CVE Numbering Authorities (CNA) eingepflegt, nummeriert und verwaltet. Die Meldung erfolgt u.a. über ein eigenes Portal. Es können jedoch auch vorgefertigte sowie selbst programmierte Clients verwendet werden. Eine CVE kann bereits vor der Veröffentlichung beantragt werden, und für die Zuweisung erfolgt meist nur eine grobe Prüfung. Eine zugewiesene CVE bedeutet also nicht automatisch, dass ein tatsächliches Risiko besteht. Zu vielen CVEs werden keine Lücken veröffentlicht – so wurden z.B. 2023 ca. 40.000 CVEs reserviert, aber nur ca. 29.000 veröffentlicht. 

Die reinen CVE-Nummern bilden nur einen Teil der Anwendungsfälle ab, insbesondere liefern sie nicht unbedingt eine Risikobewertung. Sie bilden aber die Basis für viele darauf aufbauende Datenbanken wie die NVD. 

Wird oft mit CVE verwechselt: NIST National Vulnerability Database (NVD) 

Die National Vulnerability Database (NVD) wird von der US-Behörde NIST betrieben und oft mit CVE verwechselt. Beide sind auch eng miteinander verknüpft – für jede CVE im Zustand “veröffentlicht” wird automatisch ein Eintrag in der NVD erzeugt. Während die CVE-Datenbank nur rudimentäre Informationen zur Lücke enthält, wird der Eintrag in der NVD noch um weitere Informationen wie einen Risikoscore nach dem Industriestandard Common Vulnerability Scoring System (CVSS) oder Links zu weiteren Informationen ergänzt. 

Diese Informationen werden teilweise manuell ergänzt. Im Frühjahr 2024 kam es dabei zu einer Überlastung des zuständigen Teams, und es wurden für mehrere Monate keine Ergänzungen insbesondere auch keine Risikobewertungen eingepflegt. Durch den Einsatz von externen Partnern konnte der Stau aufgelöst und das System resilienter gemacht werden, aber wie bei CVE zeigt der Vorfall, wie stark die NVD vom amerikanischen Bundeshaushalt abhängt. 

Die NVD-Daten stehen auch als strukturierte Daten im Security Content Automation Protocol (SCAP) Format zur Verfügung und können ohne Einschränkungen verwendet werden. Daher setzen viele Tools und auch Schwachstellen-Webseiten die NVD-Daten direkt ein oder nutzen sie als Basisdatensatz, der durch eigene Erkenntnisse ergänzt wird. Da die NVD nicht zwingend genannt werden muss, ist der Zusammenhang nicht immer direkt erkennbar. 

Fast alle unserer Anwendungsfälle kann die NVD bedienen. Lediglich neue Lücken können nicht direkt bei der NVD gemeldet werden – hier muss eine CVE beantragt werden und damit entsteht automatisch auch der NVD-Eintrag. 

CVE Foundation 

Die Meldung, dass die US-Regierung die Förderung von MITRE CVE einstellen will, sorgte berechtigterweise für eine Menge Wirbel in der globalen Cybersecurity Szene. Angetrieben durch dieses Ereignis sowie dem schon länger existierenden Wunsch noch neutraler und nachhaltiger auftreten zu können (und nicht an eine Regierung gebunden zu sein) entschieden sich diverse Vorstandsmitglieder des CVE-Systems ihre eigene (non-profit) Stiftung zu gründen, um die Finanzierung des MITRE Programms zu realisieren. 

Die CVE Foundation ist daher keine Alternative zu bestehenden Programmen und will es nach unserem Kenntnisstand auch gar nicht werden. Aktuell befindet sich die Stiftung noch im Aufbau – Informationen dazu wie es weitergeht und was die nächsten Schritte sein werden, sind daher rar. In ihren eigenen FAQs werden lediglich einige Fragen zum Auftrag sowie einige der baldigen Vorstände benannt. 

Unsere Anwendungsfälle wären bei einer CVE-Stiftung genauso abgedeckt wie bisher. Wenn die Stiftung die bestehende Datenbank und Nummerierung übernehmen würde, gäbe es auch keinen Umstellungsaufwand. 

Common Security Advisory Framework (CSAF)

Ein weiterer Name, der in diesen Zusammenhängen immer wieder genannt wurde, ist das Common Security Advisory Framework (CSAF). Dahinter verbirgt sich eine technische Spezifikation für einen verteilten Ansatz. Eine vertrauenswürdige Instanz wie aktuell beispielsweise das Bundesamt für Sicherheit in der Informationstechnik (BSI) pflegt eine Liste von Organisationen, die Sicherheitslücken dokumentieren. Diese wiederum veröffentlichen die Sicherheitslücken in einem strukturierten Format (JSON). 

Laut der eigenen FAQ sieht sich CSAF nicht als CVE-Ersatz. Der Standard bietet ein optionales Feld für die CVE-Nummer an, und in der Technischen Richtlinie TR-03191 des BSI ist die CVE-Nummer sogar verpflichtend. In CSAF geht es eher um die Details zu jeder Lücke, man kann CSAF also eher als eine dezentrale Alternative zur NVD-Datenbank betrachten. 

Die Anwendungsfälle, in denen die Eindeutigkeit der CVE-Nummer im Vordergrund steht – z.B. als Ordnungsmerkmal im Risikomanagement oder als eindeutige Kennung in der Software Supply Chain – können von CSAF nicht abgebildet werden. CSAF-Dokumente haben zwar eindeutige Kennungen, aber zwei Dokumente können sich auf die gleiche Lücke beziehen. 

Als Informationsbasis und insbesondere als Datenbasis für Scan-Tools eignen sich die CSAF-Dokumente dagegen gut. Die CSAF-Seite verzeichnet direkt einige passende Tools. Es gibt jedoch keinen Automatismus wie bei der NVD, der für jede veröffentlichte CVE zumindest einen rudimentären Eintrag erzeugt. 

Global CVE Allocation System (GCVE)

Das Global CVE Allocation System (GCVE) ist ein neuer Ansatz vom Computer Incident Response Center Luxembourg (CIRCL), bei dem statt einer zentralen Instanz wie MITRE die Vergabe von IDs für Sicherheitslücken dezentral stattfinden soll. Zwar gibt es im traditionellen CVE-System auch verschiedene Vergabestellen für CVEs – sogenannte CVE Numbering Authorities (CNAs) – jedoch müssen die Vorgaben von MITRE eingehalten werden, und die Vergabe von eindeutigen IDs wird durch die zentrale Instanz gesteuert. Im GCVE wird die ID dazu im Format „GCVE-<GNA ID>-<YEAR>-<UNIQUE ID>“ vergeben. Jeder teilnehmenden Organisation wird eine sogenannte GNA ID zugeteilt, sodass die Organisationen ihren eigenen ID-Bereich unabhängig vergeben können, ohne Überschneidungen hervorzurufen. Es bleibt abzuwarten, ob die Anzahl der aktuell acht teilnehmenden Organisationen steigt und sich auch bekannte Größen dem im Aufbau befindlichen System anschließen. 

Für die oben definierten Anwendungsfälle ist es aktuell kaum nutzbar. Nur die vom CIRCL betriebene Datenbank Vulnerability Lookup benutzt derzeit das Schema.  

Da die Teilbereiche unabhängig verwaltet werden, wird es Lücken geben, die mehrere GCVE-Nummern von unterschiedlichen GNA erhalten werden. Die GCVE eignet sich dann nicht als eindeutiges Ordnungsmerkmal im Risikomanagement oder in der Software Supply Chain. 

European Vulnerability Database (EUVD) 

Eigentlich noch im Probebetrieb wurde die europäische Antwort auf die NVD im Zuge der drohenden CVE-Abschaltung kurzerhand öffentlich verfügbar gemacht. Die Datenbank ist noch in der Beta-Phase und soll vor allem die Korrelation aus verschiedenen Datenquellen ermöglichen.  

Da so auch Sicherheitslücken aufgenommen werden, die nicht bei der CVE gemeldet wurden, vergibt die European Network and Information Security Agency (ENISA) eigene Nummern, die mit EUVD starten. Aktuell ist das System auf eine Ko-Existenz und eine Abbildung auf CVEs ausgelegt, könnte aber bei einer CVE-Abschaltung auch problemlos weiterbetrieben werden. 

Während einzelne neuere Einträge bereits sehr viele Informationen aufweisen, konnten wir in Stichproben immer wieder Einträge finden, die entweder nur die Basis-Daten aus der CVE-Datenbank enthielten oder die im Vergleich zum korrespondierenden NVD-Eintrag viel weniger Details hatten. 

Die EUVD ist so ausgelegt, dass alle unsere oben beschriebenen Anwendungsfälle langfristig bedient werden können. Aktuell ist die Datenqualität noch nicht vergleichbar mit der NVD, und nur wenige Tools nutzen die EUVD als Datenbasis. Beides kann sich aber mit der Zeit noch ändern.  

Ob die EUVD-Nummern die etablierten CVE-Nummern als eindeutige Kennung ersetzen können, ist noch offen. Da die EUVD Teil der NIS2-Richtlinie der EU ist und von den europäischen Informationssicherheitsbehörden gemeinsam genutzt wird, stehen die Chancen aber zumindest für Europa nicht schlecht. 

Single Reporting Platform (SRP) des europäischen Cyber Resilience Act (CRA) 

Neben der NIS-2-Richtlinie, die vor allem auf den sicheren IT-Betrieb abzielt, macht die EU im Cyber Resilience Act (CRA) Informationssicherheitsvorgaben für Produkte. Darin sind auch Vorgaben wie Schwachstellen veröffentlicht werden sollen und welche Meldewege die Hersteller ermöglichen müssen. 

Eine neue geschaffene Single Reporting Platform (SRP) soll dabei eine zentrale Rolle spielen. Die Erstellung der Plattform wird gerade ausgeschrieben. Daher kann es noch keine konkrete Einschätzung geben, wie sich die SRP auf die Anwendungsfälle auswirkt. Bisher bekannt ist lediglich die Arbeitsteilung zwischen SRP und EUVD: Während die SRP auch unveröffentlichte Schwachstellen für einen beschränkten Empfängerkreis bereitstellen soll, sollen veröffentlichte Schwachstellen aus der SRP direkt in die EUVD aufgenommen werden. 

Was müssen Anwender jetzt tun? 

Bis März 2026 kann erstmal alles wie bisher bleiben. Es ist jedoch ratsam, sich bereits auf mögliche Alternativszenarien nach dem Datum vorzubereiten. 

Für die Nutzung der CVE als eindeutige Kennung (im Risikomanagement, als Hersteller, als Entdecker), kann man bereits jetzt anfangen, zusätzlich eine der alternativen Kennungen wie die EUVD-Nummer zu dokumentieren. Idealerweise spricht man mit Kunden und Lieferanten über die Alternativen und findet vielleicht eine gemeinsame Alternative. 

Bei den Scan-Tools und Informationsdiensten (fürs ISMS, Container, Software) sollte man rechtzeitig prüfen, auf welchen Daten sie basieren. Nutzen sie einfach die NVD oder binden sie bereits heute verschiedene Datenbanken (die nicht nur Kopien der NVD sind) an? Möglicherweise müssen Tools und damit die daran hängenden Prozesse ausgetauscht werden, um mehr Datenquellen nutzen zu können. 

Titel Signalgate
Schwachstelle

Signalgate

Die sogenannte Signal-Affäre hat in den letzten Wochen für erhebliche Aufregung in Washington gesorgt. Ein angesehener US-Journalist, Jeffrey Goldberg, wurde versehentlich in einen vertraulichen Signal-Chat der US-Regierung eingeladen, in dem hochrangige Regierungsvertreter militärische Operationen im Jemen diskutierten. Die Frage, die sich in diesem Zusammenhang stellt, ist, wie es zu diesem sicherheitsrelevanten Fauxpas kommen konnte. Wir können guten Gewissens ausschließen, dass es sich um einen Hack oder eine schadhafte Funktion in der Signal-App gehandelt hat, wie es von Seiten der amerikanischen Regierung anfänglich angedeutet wurde.

Der Signal-Messenger hat eine Schwäche im Design: Die Überprüfung, ob der Gesprächspartner tatsächlich derjenige ist, mit dem man kommunizieren möchte, liegt in der Verantwortung des Benutzers. Dies bedeutet, dass keine Sicherheitsgarantie für die Authentizität des Kommunikationspartners besteht. Signal bietet seinen Nutzern jedoch die Möglichkeit, die Authentizität ihrer Kommunikationspartner selbst zu überprüfen und dann in Signal zu vermerken. Diese Funktion wird jedoch in der Benutzeroberfläche nicht so prominent dargestellt wie beispielsweise bei Threema mit dem Ampelsystem. Erst durch die Überprüfung der Sicherheitsnummer über einen zweiten Kanal wird die Authentizität des Kommunikationspartners sichergestellt.

Die Nachlässigkeit, die Sicherheitsnummer nicht überprüft zu haben, wurde dem nationalen Sicherheitsberater Mike Waltz zum Verhängnis, da er die Personen nur aufgrund der in seinem Handy gespeicherten Telefonnummern in die betroffene Signal-Gruppe aufnahm. Aktuellen Berichten zufolge hat das Mobiltelefon von Mike Waltz die Telefonnummer von Jeffrey Goldberg aufgrund eines Fehlers in der automatischen Kontaktverknüpfung des iPhones einem bestehenden Kontakt zugeordnet.

Nicht ohne Grund gibt es für die Kommunikation, bei der nicht nur Nachrichten sicher verschlüsselt übertragen werden sollen, sondern auch die Authentizität aller Kommunikationsteilnehmenden zuverlässig und dauerhaft sichergestellt sein muss, zertifizierte Lösungen, die zentral von einer der Geheimhaltungsstufe entsprechenden vertrauenswürdigen Stelle betrieben werden. Diese Stelle übernimmt auch die Registrierung und Prüfung der Authentizität von Teilnehmenden. Warum eine solche Kommunikationsplattform in diesem Fall nicht verwendet wurde, darüber kann nur spekuliert werden.

https://t3n.de/news/geheimchat-affaere-usa-signal-gewinner-1680595

https://www.br.de/nachrichten/deutschland-welt/signal-affaere-pentagon-ermittelt-gegen-eigenen-chef-hegseth

https://www.heise.de/news/Signal-Affaere-US-Journalist-angeblich-dank-iOS-Funktion-in-geheimem-Gruppenchat-10342141.html

https://www.t-online.de/nachrichten/ausland/usa/id_100668006/signal-affaere-wie-jeffrey-goldberg-vom-atlantic-in-die-chatgruppe-kam.html

https://www.theguardian.com/us-news/2025/apr/06/signal-group-chat-leak-how-it-happened

https://www.heise.de/news/US-Verteidigungsminister-Pentagon-Aufsicht-prueft-Verhalten-in-Signal-Affaere-10340035.html

https://www.heise.de/news/US-Regierung-Austausch-ueber-die-Krisen-der-Welt-in-viel-mehr-Gruppenchats-10339137.html

https://threema.ch/de/faq/levels_expl

https://support.signal.org/hc/de/articles/360007060632

KI/ML, Schwachstelle

KI-Agenten anfällig für einfache gefährliche Angriffe

Es lässt sich eine signifikant zunehmende Verwendung von KI-Agenten in verschiedenen Bereichen zur Automatisierung von Aufgaben und zur Unterstützung bei Entscheidungsprozessen beobachten (i. d. R. mit Large Language Models – LLM). Die Kompetenz, diese KI-Systeme effektiv zu nutzen und zu steuern, gewinnt damit an Bedeutung.

Doch wie sicher sind diese KI-Agenten?

Eine aktuelle Studie mit dem Titel „Commercial LLM Agents Are Already Vulnerable to Simple Yet Dangerous Attacks“ beleuchtet die Sicherheits- und Datenschutzlücken von kommerziellen LLM-Agenten und zeigt, dass diese oft anfällig für einfache, aber gefährliche Angriffe sind.

Die Autoren der Studie haben eine umfassende Taxonomie der Angriffe erstellt, die Bedrohungsakteure, Ziele, Einstiegspunkte, Sichtbarkeit des Angreifenden, Angriffstechniken und die inhärenten Schwachstellen der Agenten-Pipelines kategorisiert. Die systematische Analyse zeigt, dass die Integration von LLMs in größere Systeme neue Sicherheitsherausforderungen mit sich bringt, die über die bekannten Schwachstellen isolierter LLMs hinausgehen.

Um die praktischen Auswirkungen dieser Schwachstellen zu demonstrieren, führten die Autoren eine Reihe von Angriffen auf populäre Open-Source- und kommerzielle Agenten durch, die bemerkenswert einfach umzusetzen waren und keine speziellen Kenntnisse im Bereich maschinelles Lernen erforderten. Dies unterstreicht die Dringlichkeit, Sicherheitsmaßnahmen zu verbessern und die Robustheit dieser Systeme zu erhöhen.

https://arxiv.org/html/2502.08586v1

https://www.linkedin.com/pulse/wenn-ki-agenten-zu-komplizen-werden-roger-basler-de-roca-qnrre

Schwachstelle

Freigiebiger Datenreichtum bei VW

Die Frage der Datenhoheit, die sich aus der Erfassung und Nutzung von Daten durch Fahrzeuge ergibt, ist Gegenstand kontroverser Diskussionen. Fahrzeughersteller vertreten die Auffassung, dass diese Daten als ihr Eigentum zu betrachten sind, während Halter von Fahrzeugen der Meinung sind, dass es sich um personenbezogene Daten handelt, was die Anwendung der DSGVO impliziert.

https://www.adac.de/rund-ums-fahrzeug/ausstattung-technik-zubehoer/assistenzsysteme/daten-im-auto-eu-data-act

Der ADAC hat bereits 2016 festgestellt, dass sich aus Daten der Autosensoren und der Bewegungsdaten Rückschlüsse auf das Nutzungsprofil ziehen lassen. Im Januar 2024 wies der ADAC erneut darauf hin, dass unsere Autos mittlerweile sehr viele Daten sammeln.

https://www.adac.de/rund-ums-fahrzeug/ausstattung-technik-zubehoer/assistenzsysteme/daten-modernes-auto

Das ungewollte Offenlegen der Bewegungsdaten von Elektrofahrzeugen des Volkswagen-Konzerns kann als eine natürliche „Fruchtfolge“ von Erhebung, Verwendung und Datenpanne betrachtet werden.

Wie bereits von den Vortragenden auf dem 38C3 treffend angemerkt, lag der eigentliche Fehler darin begründet, dass die Daten überhaupt erhoben wurden.

Doch was ist passiert? Die VW-Tochter Cariad, die für die Entwicklung der betroffenen Software des Autokonzerns verantwortlich ist, betreibt eine Spring-basierte Webanwendung, die aus dem Internet erreichbar ist. Über diese Webanwendung waren mehrere API-Endpunkte ohne Passwortschutz erreichbar. Darunter auch der Spring Boot Actuator mit seinem Endpunkt Heapdump.

https://docs.spring.io/spring-boot/api/rest/actuator/heapdump.html

Ein Heapdump ist eine Momentaufnahme des Speichers (Heap) einer laufenden Java-Anwendung. Er enthält Informationen über alle Objekte, die sich zu einem bestimmten Zeitpunkt im Speicher befinden, einschließlich ihrer Referenzen untereinander.

https://www.codecentric.de/wissens-hub/blog/java-heapdumps-erzeugen-und-verstehen-4-akt

Heapdumps werden häufig zur Analyse von Speicherproblemen wie OutOfMemoryError verwendet.

https://www.baeldung.com/java-heap-thread-core-dumps

Es können aber auch gespeicherte Geheimnisse wie z. B. (API-)Schlüssel enthalten sein, welche sich mit einfachen Analysewerkzeugen extrahieren lassen. Genau dies war bei VW der Fall. Mit diesen Geheimnissen konnte dann auf einen eigentlich zugriffsgeschützten Cloud-Speicher zugegriffen werden. Und auf diesem befand sich eine sehr umfangreiche Datensammlung.

Da VW die Positionsdaten mit einer höheren Genauigkeit speicherte (10 cm) als in den AGB vorgesehen (diese spricht von „gekürzten GPS-Daten“), waren sehr genaue Auswertungen der Fahrzeughalter möglich. Böswillige Organisationen hätten mit diesen Daten den Aufenthaltsort und ggf. das Verhalten u. a. auch von Mitarbeitern sicherheitsrelevanter Behörden ermitteln können – wo geht wer zu welchen Sportaktivitäten, welcher Arzt wird wann aufgesucht, wo wird einkauft, …

Fazit: Daten, die nicht erhoben werden, können auch nicht ungewollt offengelegt werden. Datensparsamkeit darf keine leere Phrase sein.

https://spiegel.de/netzwelt/web/volkswagen-konzern-datenleck-wir-wissen-wo-dein-auto-steht-a-e12d33d0-97bc-493c-96d1-aa5892861027

https://heise.de/news/In-der-Cloud-abgelegt-Terabyte-an-Bewegungsdaten-von-VW-Elektroautos-gefunden-10220623.html

https://vinqo.de/vw-datenskandal-betroffene-schliessen-sich-fur-mogliche-sammelklage-zusammen/

Netzwerk, Schwachstelle

Perimeter Defense

Zuletzt häuften sich erneut herstellerübergreifend die Sicherheitslücken in Firewalls, also gerade in den Geräten, die die Umgebung eigentlich schützen sollten. Die Rolle der Perimeterverteidigung wird nunmehr infrage gestellt und Zero Trust nicht nur als neues Buzzword verwendet, sondern auch als innovative Lösung der Hersteller versprochen.

Das Konzept dahinter ist aber gar nicht so innovativ: Bereits 1994 wurde „Zero Trust“ im Rahmen einer Dissertation definiert. Über die Jahre finden sich viele weitere Talks und Beiträge, die gegen Firewalls als alleinige Sicherheitskonzepte plädieren, aber auch die grundsätzliche Rolle dieser Geräte hinterfragen. Eine eindeutige Definition des Begriffes „Zero Trust“ wird zunehmend durch die Derivationen der Hersteller schwieriger, aber das Konzept ist recht simpel: statt einer geschützten Grenze zwischen dem „bösen“ Internet und dem „guten“ Intranet wird das gesamte Transportmedium als grundsätzlich nicht vertrauenswürdig angesehen. Ein Schutz der Daten findet dann direkt über das Anwendungsprotokoll statt.

Wenngleich der Begriff das Misstrauen gegenüber allen beteiligten Instanzen suggeriert, verbleibt die Notwendigkeit dem Anbieter einer solchen Lösung zu vertrauen. Das heißt wie auch schon heute mit Firewalls ist dessen Reputation entscheidend. Besonders klar machte uns das die Meldung über die Ausnutzung eben dieser besonderen Privilegien durch das X-Ops Team von Sophos, um eine chinesische APT-Gruppe zu verfolgen, indem die Sicherheitsforschenden eigene Malware auf den Geräten hinterlegten.

Wie so oft ist die vorgestellte Lösung also nicht das Allheilmittel, es ist weiterhin wichtig alle Optionen im Blick zu haben und die beste Umsetzung für die eigene Umgebung auszuwählen.

https://www.wired.com/story/sophos-chengdu-china-five-year-hacker-war

https://news.sophos.com/en-us/2024/10/31/pacific-rim-neutralizing-china-based-threat/

https://www.securityweek.com/security-perimeter-dead

https://media.ccc.de/v/gpn21-88-perimeter-security-is-dead-get-over-it-

https://www.cvedetails.com/vulnerability-list/vendor_id-3080/Fortinet.html?page=1&year=2024&month=-1&order=1

https://dspace.stir.ac.uk/bitstream/1893/2010/1/Formalising%20trust%20as%20a%20computational%20concept.pdf

Schwachstelle

Bewerbungsgespräch mit einem Angreifer

Das Sicherheitsunternehmen KnowB4 hat einen Fall öffentlich gemacht, bei dem sich ein neuer Mitarbeiter als nordkoreanischer Spion entpuppte. Enttarnt wurde er gleich am ersten Tag, nachdem er als Remote-Arbeiter zum ersten Mal seinen zugesandten Rechner startete und sofort eine Malware installieren wollte. Im Nachhinein fielen dann auch weitere Ungereimtheiten bei der Bewerbung auf, die das Sicherheitsunternehmen zur Warnung anderer Unternehmen in seinem Blog beschreibt.

Im Juni hatte das Wall Street Journal bereits ausführlicher über diese Gefahr berichtet und verschiedene andere Betroffene zitiert. Genutzt werden dabei sogenannte Laptop-Farmen, die die Rechner der vermeintlichen Homeoffice-Arbeitenden einsammeln, zeitlich passend in Betrieb nehmen und mit einer Fernsteuerungslösung ausstatten, damit sich anschließend mehrere Personen die Aufgaben des vorgeblichen Mitarbeitenden teilen können und natürlich gleichzeitig ihre eigenen Ziele verfolgen.

Diese Angriffsart funktioniert “dank“ standardisierter Bewerbungsprozesse, die komplett remote ablaufen und der Tatsachen, dass auch zur Arbeitsaufnahme kein persönliches Treffen vorgesehen ist. Die vermeintlichen Mitarbeitenden existieren nur als KI-generierte Lebensläufe und als manipulierte Bilder.

Wenn Sie jetzt an Ihre Abläufe bei Bewerbungen und die ersten Wochen für neue Mitarbeitende denken: An welcher Stelle würde Ihnen ein Angriffsversuch dieser Art auffallen?

https://blog.knowbe4.com/how-a-north-korean-fake-it-worker-tried-to-infiltrate-us

https://www.wsj.com/articles/deepfakes-fraudsters-and-hackers-are-coming-for-cybersecurity-jobs-e2a76d06

Advisories, Allgemein, Penetrationstest, Schwachstelle

Schwachstelle öffnet Türen in mehr als 3.000 Hotels

Es mag bequem klingen: Die Zimmertür im Hotel lässt sich ganz ohne Schlüssel oder Karte vom Smartphone aus entriegeln. Doch was passiert, wenn die Logik eines solchen Systems nicht ausreichend abgesichert ist?

Zimmertüren von Hotels aus über 25 Ländern ließen sich mit einer neu entdeckten Schwachstelle öffnen. Bequem? Ja, über das Internet und ohne Zugangsdaten. Dazu konnten sämtliche Reservierungsinformationen (u. a. Name, E-Mail, Reservierungszeitraum und Raumnummer) eingesehen werden. Doch wie kam es dazu?

Zusammenfassung

Die Firma straiv ist ein innovativer und digitaler Begleiter für Hotelbranchen. Als solcher bieten sie unter anderem Online-Check-ins und digitale Türöffnungen an. Was den Sicherheitsforschern Björn Brauer, Deniz Adrian und David Mathiszik bei einem Hotelbesuch jedoch auffiel: Angreifenden wäre es dank einer fehlerhaften Zugangskontrolle in der API möglich, den Check-in und das Öffnen von Türen auch ohne Autorisierung über das Internet zu bedienen.

Im Rahmen einer vertraulichen Offenlegung (engl. Responsible Disclosure oder auch Coordinated Vulnerability Disclosure – CVD) wurden die technischen Details daraufhin direkt an den Hersteller übermittelt. straiv reagierte zeitnah und behob die Sicherheitslücke in ihrer Anwendung umgehend.

Dank ihres Software-as-a-Service-Ansatzes konnte das Unternehmen das Sicherheitsrisiko zeitgleich für alle Kunden mitigieren. Es wird daher auch keine CVE-ID für diese Schwachstelle vergeben. Die Veröffentlichung der Schwachstelle erfolgt in Abstimmung mit dem Hersteller frühestens einen Monat nach der erfolgreichen Behebung.

Die Ursache: Broken Access Control

Broken Access Control belegt aktuell Platz 1 unter den beliebtesten (lies: häufigsten) Schwachstellen in Webanwendungen (siehe: A01:2021 – OWASP Top 10). Auch hier war eine fehlerhafte Zugriffskontrolle die Ursache.

Für gewöhnlich erhalten Gäste eine E-Mail mit einem Link zu ihrer Reservierung. Über diesen werden sie auf die Webanwendung von straiv weitergeleitet. Dort können Buchungsinformationen, die Reisedaten und alle Begleiterprofile eingesehen werden. Ein weiterer Menüreiter führt zu den digitalen Zimmerschlüsseln. Darüber kann die Zimmertür während des eigenen Buchungszeitraums gesteuert werden. Dies geschieht über die API von straiv.io.

Normale API-Anfragen schienen mindestens durch einen HTTP-Header (X-Token), einen Code (cryptcode) und die Reservierungsnummer (reservation) geschützt zu werden. Wurde auch nur einer der Werte verändert, so wurde der Zugriff erwartungsgemäß verwehrt. Fehlten jedoch alle Werte gleichzeitig, wurde nur noch die Reservierungsnummer interpretiert.

In der folgenden beispielhaften Anfrage wurden sämtliche Authentifizierungsparameter, bis auf die Reservierungsnummer, leer gelassen und die API antwortete dennoch mit Informationen zur Reservierung.

POST /api/v2/auth HTTP/2
Host: start.straiv.io
X-Token:
X-Code:
X-Version: 12.3.0
Content-Type: application/json
{
    "cryptcode":"",
    "platform":"linux",
    "browser":"Firefox",
    "version":"115.0",
    "tokens":[],
    "reservation":"3XXXXX"
}

Das Ergebnis enthielt neben anderen Informationen auch einen validen token, der für weitere API-Anfragen genutzt werden konnte.

So lieferte der folgende API-Aufruf noch mehr Kundendetails:

GET /api/v2/vblo/pms/reservation?reservation_id= HTTP/2
Host: start.straiv.io
Accept: application/json, text/plain, */
X-Token: sXXXXXXXXXXXXXXXXXXXh
X-Code: XXXX
X-Version: 12.3.0

Statt die API zu verwenden, kann auch die remote_url aus der Antwort der ersten API-Anfrage verwendet werden, um bequem über die Webanwendung auf die Reservierung zuzugreifen:

HiSolutions hat keine Enumeration von Nutzerdaten durchgeführt und über das Abschätzen der Auswirkungen dieser Schwachstelle hinaus nicht mit der API oder den Buchungen interagiert. Prinzipiell standen alle Funktionalitäten des legitimen Benutzers uneingeschränkt zur Verfügung.

Mitigation

Für die Kunden von straiv bestand kein weiterer Handlungsbedarf. Die Sicherheitslücke wurde von den Entwicklern ernst genommen und umgehend geschlossen.

Grundsätzlich lassen sich Fehler dieser Art durch folgende allgemeine Empfehlungen verhindern:

  • Vertrauen Sie keinen Nutzereingaben – validieren Sie diese.
    Verlassen Sie sich nie auf die Gültigkeit von jeglichen Werten, die von den Endbenutzern beeinflusst werden können. Dazu gehören auch Cookie-Werte, Anfragenparameter und HTTP-Header. Auch auf serverseitig gespeicherte Informationen sollte nich blind in allen Kontexten vertraut werden.
  • Überprüfen Sie Gültigkeit aller Werte serverseitig. Weisen Sie leere oder ungültige Authentifizierungsinformationen zurück. Achten Sie bei der Implementierung von Tests auf eine vollständige Abdeckung aller Randszenarien (ein, mehrere oder auch alle Werte sind unerwartet, NULL, nicht definiert, vom falschen Typ, etc.).
  • Verwenden Sie starke Authentifizierungsmethoden.
    Implementationen sind stets abhängig von der Anwendung und dem Kontext. Greifen Sie, wenn möglich, auf bewährte und praxiserprobte Bibliotheken und Authentifizierungslösungen zurück. Verwenden Sie besonders in Bezug auf sensitive Informationen Zwei-Faktor-Authentifizierung. Stellen Sie zudem sicher, dass alle automatisch generierten Schlüssel, Codes und Token nicht leicht zu erraten und somit vor Brute-Force-Angriffen geschützt sind (vgl. UUID v4).
  • Durchsatzbegrenzung (engl. Rate Limiting) der API-Anfragen:
    Begrenzen Sie die mögliche Anzahl der Anfragen von einzelnen Systemen, um dem Missbrauch, wie der schnellen Enumeration von gültigen Reservierungen, vorzubeugen.

In ihrem Update hat straiv mindestens eine Anfragenbegrenzung aktiviert und Reservierungsnummern auf ein nicht-erratbares Format geändert.

Wie HiSolutions helfen kann

HiSolutions bietet spezialisierte Penetrationstests für Webanwendungen und Infrastrukturen an. Hierbei greifen wir auf langjährige Erfahrung zurück und kombinieren die Fähigkeiten modernster Scantechnologien mit manuellen Prüfverfahren, um die bestmögliche Testabdeckung zu gewährleisten.

Stellen Sie sicher, dass Schwachstellen gefunden und behoben werden, bevor Sie ausgenutzt werden können und kontaktieren Sie uns unter +49 30 533 289 0 oder dem Kontakformular für ein kostenloses Erstgespräch.

Koordinierte Veröffentlichung

  • 22.05.2024 HiSolutions sammelt Details zur Schwachstelle.
    Finder: Björn Brauer, Deniz Adrian & David Mathiszik
  • 23.05.2024 HiSolutions informiert betroffene Hotelkette und wird an straiv weitergeleitet.
  • 25.05.2024 straiv vereinbart einen Termin für die Übermittlung aller Details.
  • 04.06.2024 HiSolutions teilt alle Details mit straiv.
  • 06.06.2024 straiv veröffentlicht ein Update und HiSolutions bestätigt den Fix.
Schwachstelle

Lücken sichtbar machen

Im letzten Monat gab es verschiedene Meldungen über den Umgang mit Sicherheitslücken, die von Externen gefunden wurden. Grundsätzlich ist es immer gut, wenn Menschen, die Sicherheitslücken finden, diese nicht für sich behalten oder gar meistbietend an Angreifergruppen verkaufen.

In der Theorie gibt es für die Meldewege und die Reaktion inzwischen einen ISO-Standard sowie Empfehlungen des BSI und der Allianz für Cybersecurity. In der Praxis hakt es gern mal, wie ein paar aktuelle Fälle zeigen.

Wenn es um Sicherheitslücken geht, sind immer mindestens die folgenden Parteien involviert: Der Entdecker der Lücke, der Hersteller des betroffenen Systems und diejenigen, die das System einsetzen. Dazu können noch Wiederverkäufer, Vermittler wie ein CERT und weitere Parteien kommen. Um sicherzugehen, dass man tatsächlich über die gleiche Lücke spricht, hat man daher 1999 angefangen, Sicherheitslücken mit einer CVE-Nummer zu versehen. In diesem Zusammenhang wird meist auch die amerikanische Lückendatenbank NVD (National Vulnerability Database) erwähnt. Datenbanken wie diese, die zu den CVE-Nummern die passenden Metadaten, Risikobewertungen und Links zusammentragen, gibt es mehrere. Die NVD ist jedoch häufig die erste Wahl und wird auch von vielen Programmen als Datenbasis verwendet. Wir haben in den letzten Jahren bereits deutliche Verzögerungen bei der Vergabe von CVE-Nummern erlebt. Das ist aber nichts im Vergleich zu den Verzögerungen in der NVD, die ab Februar 2024 kaum noch neue Beiträge veröffentlicht hat. Im Mai wurde nach Protesten vom Betreiber ein Dienstleister beauftragt, um den Rückstau abzuarbeiten.

In der Beziehung zwischen Entdecker der Lücke und Hersteller werden nicht selten dem Entdecker böse Absichten unterstellt und gelegentlich auch zivil- oder strafrechtliche Schritte angedroht. Im Zuge des aktuellen Sicherheitsvorfalls bei der CDU verwiesen daher auch mehrere Forschende auf einen älteren Vorfall bei der Wahlkampf-App der CDU, bei dem die Entdeckerin Lilith Wittmann von der CDU angezeigt wurde. Mehrere Forschende und der CCC hatten daraufhin angekündigt, keine Sicherheitslücken mehr an die Partei zu melden. Ob der aktuelle Vorfall andernfalls früher hätte erkannt oder gar vermieden werden können, ist offen, aber der Fall zeigt sehr deutlich den Konflikt, in dem die Entdeckenden sich befinden. Der Koalitionsvertrag sieht bereits eine Verbesserung der rechtlichen Lage vor. Auf die Umsetzung wurde von mehreren Seiten in den letzten Wochen gedrängt.

Offizielle Bug-Bounty-Programme, also strukturierte Angebote der Hersteller, für gemeldete Sicherheitslücken Geld auszuzahlen, sind ebenso eine Möglichkeit, dem Ganzen einen rechtlichen Rahmen zu geben. Während einige Entdecker diese Programme als gute Gelegenheit für ein Einkommen sehen, wehren sich andere dagegen, in solch ein Programm gedrängt zu werden. Sie sehen sich durch die Vertragsbedingungen, vor allem durch die Verschwiegenheitsklauseln, zu stark eingeschränkt. Außerdem schwingt hierbei das Misstrauen aufseiten des Entdeckers mit, dass das Bug Bounty eher ein Schweigegeld ist und der Hersteller die Problembehebung anschließend beliebig hinauszögern kann.

Aber auch die Entdecker agieren nicht immer verantwortungsvoll. Ein drastisches Beispiel erlebte die Kryptobörse Kraken. Eine Gruppe meldete erst über das bestehende Bug-Bounty-Programm eine Lücke, um diese kurz danach selbst auszunutzen und sich fast 3 Millionen Dollar auszuzahlen. Das Geld wollten sie nur dann zurückzahlen, wenn sie eine angemessene Aufwandsentschädigung erhielten. Unsere Kunden berichten auch von Fällen, bei denen sich vorgebliche Sicherheitsforschende melden, die angeblich identifizierte Lücken und die Details nur gegen Vorauszahlungen preisgeben. Einige Ransomware-Gruppen nennen ihre Lösegeldforderung jetzt sogar „Pentest with Post Payment“.

Insgesamt ist das „richtige“ Lückenmelden ein komplexes Feld, das aber sehr zentral für das Risikomanagement ist.

Wie sollte man es machen?

NVD – aktueller Status: https://nvd.nist.gov/general/news/nvd-program-transition-announcement

Rechtliche Situation in Deutschland

Unverantwortliche Entdecker: