Schlagwort: Schwachstelle

Woher kommen eigentlich Zero-Days?
Schwachstelle, Zeroday

Woher kommen eigentlich Zero-Days?

Sicherheitslücken, die seit n Tage bekannt sind, nennt man „n-days“. Zero-Days sind demzufolge Lücken, die am heutigen Tage bekannt werden. Meist gibt es dann auch noch keine Patches oder Mitigationen dafür, weswegen diese Art von Lücken besonders interessant für Angreifende und Admins zugleich sind. Aber wer findet diese Lücken eigentlich?

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: Oftmals wird die Ausnutzung von Zero-Days durch staatliche Akteure gesteuert, also auch durch Steuergeld bezahlt.

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

News

Weitere News im März

Apple zieht Datenschutz-Tool nach Sicherheitsstreit mit der britischen Regierung zurück

Apple hat beschlossen, seine höchste Sicherheitsstufe, Advanced Data Protection (ADP), für Kunden im Vereinigten Königreich abzuschaffen, nachdem die britische Regierung Zugang zu den Nutzerdaten verlangt hat. ADP bietet eine Ende-zu-Ende-Verschlüsselung, die es nur Kontoinhabern ermöglicht, auf ihre gespeicherten Daten zuzugreifen. Die britische Regierung verlangte jedoch das Recht, diese Daten einzusehen.

Eine entsprechende Modifikation der Funktionalität hat Apple abgelehnt, weil diese die Sicherheit des Schutzmechanismus unterlaufen würde. Britische Apple-Nutzer können jedoch ADP nicht mehr aktivieren, und bestehende Nutzer werden den Zugang später verlieren. Damit fällt die Ende-zu-Ende-Verschlüsselung weg und Dritte, die Zugriff auf die Hintergrundsysteme haben, können prinzipiell die Kundendaten einsehen. Diese Entscheidung hat heftige Reaktionen von Datenschützern und Experten hervorgerufen, die diese Maßnahme als Schwächung der Online-Sicherheit und der Privatsphäre kritisieren.

Die Entscheidung von Apple, ADP in Großbritannien zu deaktivieren, zeigt die Spannungen zwischen Technologieunternehmen und Regierungen in Bezug auf Datenschutz und Sicherheit. Während die britische Regierung argumentiert, dass der Zugang zu verschlüsselten Daten für die Strafverfolgung notwendig sei, betonen Apple und Datenschützer die Bedeutung der Privatsphäre und die Risiken, die mit der Schaffung von „Hintertüren“ verbunden sind. Diese Entwicklung könnte als Präzedenzfall für andere Länder dienen und hat weitreichende Auswirkungen auf die globale Datensicherheit und den Schutz der Privatsphäre.

In Deutschland und der EU ist es aufgrund der strengen Datenschutzregelungen und der Unterstützung von Ende-zu-Ende-Verschlüsselung durch die DSGVO unwahrscheinlich, dass eine ähnliche Situation wie im Vereinigten Königreich entsteht.

https://www.bbc.com/news/articles/cgj54eq4vejo

https://www.heise.de/news/Vergleich-zu-China-Trump-kritisiert-Grossbritanniens-Backdoor-Anordnung-an-Apple-10302545.html

Cisco-Lücke in OpenH264 (CVE-2025-27091)

Eine Schwachstelle in den Decodierungsfunktionen der OpenH264-Bibliothek ermöglicht es einem nicht authentifizierten Angreifenden, aus der Ferne einen Heap-Überlauf auszulösen. Angreifende können einen bösartigen Bitstream in ein Video einbetten und das Opfer dazu bringen, das Video abzuspielen. Dies kann zu einem unerwarteten Absturz des Dekodier-Clients führen und möglicherweise beliebige Befehle auf dem System des Opfers ausführen.

Die betroffenen Versionen sind OpenH264 2.5.0 und vorherige.

OpenH264 sollte auf die neueste Version (2.6.0 oder höher) aktualisiert werden, um diese Schwachstelle zu beheben.

Firefox empfiehlt die Deaktivierung des H264-Features, wenn das Betriebssystem keinen Support für OpenH264 mitliefert.

https://github.com/cisco/openh264/security/advisories/GHSA-m99q-5j7x-7m9x

https://support.mozilla.org/de/kb/openh264-plugin-firefox

Herausforderungen und Chancen der neuen US-Regierung

Die neue US-Regierung unter Trump hat in den vergangenen Wochen viele Entscheidungen getroffen, die für Schlagzeilen gesorgt haben. Nach Anweisung des Secretary of Defense an das Cyber Command Ende Februar, alle Aktionen gegen Russland einzustellen, wurde dies Anfang März dementiert. Parallel arbeitete das Department of Goverment Efficiency („DOGE“) an der Entlassung des Red Teams der CISA bzw. an fragwürdigen Einstellungen ehemaliger Cyberkrimineller im Department of Homeland Security (DHS).

Neben den direkten Auswirkungen auf z. B. bestehende Konflikte sind auch die Verbündeten der USA unsicher über die weitere Zusammenarbeit. Auch die Sicherheits-Community ist von diesen Änderungen betroffen. Das Thema Threat Intelligence wurde in den letzten Jahren maßgeblich durch diese Institutionen geprägt, und bisher ist noch unklar, ob und in welcher Form Alternativen funktionieren.

https://therecord.media/hegseth-orders-cyber-command-stand-down-russia-planning

https://www.politico.eu/article/france-has-trouble-understanding-us-halt-on-cyber-operations-against-russia

https://www.csoonline.com/article/3839098/the-risks-of-standing-down-why-halting-us-cyber-ops-against-russia-erodes-deterrence.html

https://www.stripes.com/theaters/us/2025-03-04/cyber-hegseth-pentagon-russia-17031715.html

Sicherheitsrisiko IoT

Die Akira-Ransomware konnte trotz vorhandener Schutzsoftware im Firmennetzwerk durch den Einsatz eines nicht gepatchten IoT-Geräts (Webcam) in das Firmennetz eindringen und dort die Rechner infizieren. Die Angreifenden nutzten eine Schwachstelle in der Software der Webcam, die nicht von der Endpoint-Detection-and-Response-Software überwacht wurde, um die Ransomware zu verbreiten und Rechner im Firmennetzwerk zu infizieren.

Um derartige Angriffe zu unterbinden, ist eine möglichst feine Segmentierung der Netzwerke sowie eine Überwachung des Datenverkehrs, insbesondere im Zusammenhang mit IoT-Geräten, empfehlenswert.

https://www.heise.de/news/Akira-Ransomware-schluepft-ueber-Webcam-an-IT-Schutzloesung-vorbei-10307987.html

https://www.golem.de/news/cyberangriff-analysiert-hacker-verschluesseln-unternehmensdaten-ueber-eine-webcam-2503-194073.html

https://www.bleepingcomputer.com/news/security/ransomware-gang-encrypted-network-from-a-webcam-to-bypass-edr

Entwickler erstellt Schadcode für den Fall seiner Entlassung

Ein Entwickler installierte in Sorge um seine Entlassung Schadcode auf Systemen seines Arbeitgebers. Dieser Code detektierte die Entlassung bei einer Deaktivierung seines Active-Directory-Nutzers. Der Schadcode setzte Endlosschleifen ein, die darauf abzielten, Java-Virtual-Machines unbenutzbar zu machen und so den Zugriff auf Server zu unterbinden. Als sein Nutzerkonto deaktiviert wurde, führte der Schadcode dazu, dass tausende Anwendende weltweit keinen Zugriff mehr hatten, was zu erheblichen Schäden führte. Dies ereignete sich bereits im Jahr 2019 und führte nun zu einer Verurteilung des Entwicklers.

Regelmäßige Peer-Reviews und Quellcode-Audits, ggf. auch automatisierte Tests und Continuous Integration/Continuous Deployment (CI/CD)-Pipelines, die primär der Qualitätssicherung in der Softwareentwicklung dienen, hätten hier die Tat des Entwicklers vereiteln oder mindestens ihn einem erhöhten Entdeckungsrisiko aussetzen können.

https://www.heise.de/news/Zeitbombe-in-Code-versteckt-Entwickler-verurteilt-10311150.html

https://www.golem.de/news/kollegen-ausgesperrt-systeme-des-ex-arbeitgebers-mit-kill-switch-sabotiert-2503-194115.html

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

News

Weitere News im Februar

Die Grand Challenges der Informatik 2025

Die GI (Gesellschaft für Informatik e. V.) hat die „Grand Challenges der Informatik 2025“ vorgestellt. Es sollen die größten Herausforderungen sein, denen sich die Informatik in den kommenden Jahren stellen muss. Die GI hat fünf Herausforderungen identifiziert:

Internet of Everything – Die Vernetzung aller Elemente des täglichen Lebens erfordert effiziente und belastbare Lösungen für Industrie 4.0, Smart Cities und Telemedizin.

Dezentrale KI – KI-Modelle sollen direkt dort trainiert und ausgeführt werden, wo die Daten anfallen, was neue Forschungsfragen zu Handhabung und Sicherheit aufwirft.

Digitale Selbstbestimmung – Der Schutz der Selbstbestimmung der Nutzerinnen und Nutzer und die Förderung ihrer kritischen Kompetenz sind angesichts der Datenflut und der systematischen Verwertung von zentraler Bedeutung.

Vollautomatisierte Softwareentwicklung – Die Automatisierung in der Softwareentwicklung muss zuverlässig und ethisch reflektiert erfolgen.

World Wide Metaverse – Das Metaverse soll als erweiterter digitaler Lebensraum offen, frei und sicher gestaltet werden.

https://gi.de/grand-challenges

Datenlecks

In den letzten Wochen gab es weltweit eine Reihe bedeutender Cybersicherheitsvorfälle, die verschiedene Branchen und Unternehmen betrafen. Hier sind einige Ereignisse, die es in die Presse geschafft haben, zusammengefasst.

Potenzielles Datenleck bei OpenAI

OpenAI untersucht derzeit ein mögliches Datenleck, bei dem die Daten von 20 Millionen Nutzern gestohlen worden sein sollen. Cyberkriminelle behaupten, Zugangsdaten von ChatGPT-Nutzern im Darknet zum Verkauf anzubieten. Obwohl der Wahrheitsgehalt dieser Behauptungen noch unklar ist, nimmt OpenAI die Situation ernst und führt umfangreiche Untersuchungen durch.

https://www.heise.de/news/Cyberangriff-OpenAI-untersucht-potenzielles-Leck-von-20-Millionen-Nutzerdaten-10275538.html

https://www.golem.de/news/cybersicherheit-openai-benutzerdatenbank-angeblich-gehackt-2502-193173.html

Datenleck bei Thermomix

Ein Datenleck im Rezeptforum des Thermomix-Herstellers Vorwerk hat dazu geführt, dass die Daten von mehr als einer Million deutscher Nutzer im Darknet gelandet sind. Betroffen sind E-Mail-Adressen, Telefonnummern und andere persönliche Informationen. Vorwerk hat die Sicherheitslücke inzwischen geschlossen und die betroffenen Nutzer informiert.

https://www.heise.de/news/Datenleck-bei-Thermomix-Daten-von-1-Million-deutscher-Nutzer-im-Darknet-10273696.html

https://www.golem.de/news/thermomix-forum-hacker-erbeuten-millionenfach-nutzerdaten-von-vorwerk-2502-193119.html

Sicherheitslücken bei Legaltech-Unternehmen

Sicherheitsexperten haben triviale Datenlecks bei zwei Legaltech-Unternehmen aufgedeckt. Die Unternehmen, die automatisierte Rechtsdienstleistungen anbieten, hatten ungeschützte Daten im Netz, die leicht zugänglich waren. Nach Hinweisen des Chaos Computer Clubs (CCC) haben die betroffenen Firmen die Sicherheitslücken schnell geschlossen.

https://www.heise.de/news/Sicherheitsexperten-enthuellen-triviale-Datenlecks-bei-Legaltechs-10272273.html

https://www.ccc.de/de/updates/2025/ccc-deckt-datenlecks-bei-legal-tech-plattformen-auf

Datenleck in Reha-Kliniken

Ein massives Datenleck bei den ZAR-Reha-Kliniken in Deutschland hat potenziell Hunderttausende von Patienten betroffen. Hochsensible medizinische Daten waren ungeschützt zugänglich. Die betroffenen Kliniken haben die Sicherheitslücke inzwischen geschlossen und arbeiten an weiteren Sicherheitsmaßnahmen.

https://www.heise.de/news/Datenleck-in-Reha-Kliniken-Hunderttausende-Patienten-potenziell-betroffen-10262109.html

Ransomware-Angriff auf Tata Technologies

Der indische Technologiekonzern Tata Technologies wurde Opfer eines Ransomware-Angriffs, der zum vorübergehenden Ausfall einiger IT-Dienste führte. Das Unternehmen hat die betroffenen Dienste inzwischen wiederhergestellt und führt eine detaillierte Untersuchung durch, um die Ursache des Angriffs zu ermitteln und künftige Risiken zu minimieren.

https://therecord.media/tata-ransomware-attack-report-incident

Stealer-Apps im App Store

Zum ersten Mal wurden im Apple App Store Stealer-Apps entdeckt, die Passwörter aus Screenshots stehlen. Die unter dem Namen SparkCat bekannte Malware zielt auf Android- und iOS-Benutzer ab und durchsucht deren Foto-Bibliotheken nach sensiblen Informationen wie Krypto-Wallet-Seed-Phrasen. Apple hat die betroffenen Apps mittlerweile entfernt.

https://www.heise.de/news/Klaut-Passwoerter-aus-Screenshots-Stealer-Apps-erstmals-im-App-Store-gesichtet-10273411.html

Fazit

Diese Vorfälle unterstreichen die Bedeutung robuster Cybersecurity-Maßnahmen und die Notwendigkeit, ständig wachsam zu bleiben, um Datenlecks und Cyberangriffe zu verhindern. Auch wenn der folgende Artikel schon ein paar Jahr alt ist, bringt dieser die Problematik rund um Datenlecks auf den Punkt.

https://www.ccc.de/en/updates/2022/web-patrouille-ccc

Wo Unternehmen aufgrund eines Fehlers Daten abhandenkommen, will die britische Sicherheitsbehörde auf Basis des “Investigatory Powers Act“ einen dauerhaften Datenzugriff auf Benutzerdaten erhalten.

https://www.heise.de/news/Britische-Regierung-erzwingt-Zugriff-auf-Apples-verschluesselte-Cloud-Daten-10273896.html

Menschen, die gerne mal wissen wollen, ob ihr Passwort bei einem der vielen Datenlecks betroffen ist, können Seiten wie https://haveibeenpwned.com/Passwords verwenden. Doch Vorsicht mit der Eingabe von eigenen Passwörtern auf fremden Webseiten. Im Zweifel hat man sein Passwort gerade aus der Hand gegeben.

Seitenkanalangriff des Monats

Forscher vom Georgia Institute of Technology und von der Ruhr University Bochum haben zwei neue Seitenkanal-Schwachstellen in modernen Apple-Prozessoren entdeckt, die als „FLOP“ und „SLAP“ bezeichnet werden. Beide Seitenkanalangriffe zielen auf Funktionen ab, die die Verarbeitung beschleunigen sollen, indem sie zukünftige Anweisungen erraten, anstatt auf sie zu warten, und so Spuren im Speicher hinterlassen, um sensible Informationen zu extrahieren.

FLOP (False Load Output Prediction) ist ein Problem mit Apples neuesten M3-, M4- und A17-Prozessoren, die nicht nur die Speicheradressen vorhersagen, auf die sie zugreifen werden, sondern sogar die tatsächlich im Speicher gespeicherten Werte. https://predictors.fail/files/FLOP.pdf

SLAP (Speculative Load Address Prediction) betrifft Apples M2- und A15-Prozessoren und viele der späteren Modelle. Anstelle von FLOP, bei dem es darum geht, zu erraten, welchen Wert eine Speicherladung zurückgeben wird, geht es bei SLAP um die Vorhersage der Speicheradresse, auf die als Nächstes zugegriffen wird, genannt Load Address Prediction (LAP). https://predictors.fail/files/SLAP.pdf

Die FLOP- und SLAP-Angriffe sind von Bedeutung, da sie moderne und weitverbreitete Hardware betreffen und aus der Ferne ausgeführt werden können, ohne dass physischer Zugang erforderlich ist.

Hat ein Angreifer ein Opfer auf eine bösartige Seite locken können, kann der Angreifer mit diesen Schwachstellen Daten aus Webbrowsern stehlen.

Die Forscher haben auf ihrer Webseite Videos veröffentlicht, mit denen der Angriff demonstriert wird: https://predictors.fail/

https://www.bleepingcomputer.com/news/security/new-apple-cpu-side-channel-attack-steals-data-from-browsers

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/

News

Windows-BitLocker-Probleme

BitLocker ist die Microsoft-Implementierung der Verschlüsselung des gesamten Datenträgers. Es bietet mehrere Betriebsmodi, wobei die Secure-Boot-basierte Verschlüsselung am weitesten verbreitet ist. Diese ist bei neueren Windows-11-Installationen standardmäßig unter „Geräteverschlüsselung“ aktiviert. In diesem Modus ist die Festplatte im Ruhezustand verschlüsselt, wird aber automatisch entschlüsselt, wenn ein legitimes Windows gestartet wird. Der Benutzer muss sich lediglich mit seinem normalen Benutzerkonto anmelden. Die wenig bekannte Schwachstelle Bitpixie (CVE-2023-21563), die Microsoft seit 2022 nicht mehr gepatcht hat, kann ausgenutzt werden, um die BitLocker-Verschlüsselung auf einem brandneuen Windows-11-System mit Secure Boot durch einen Downgrade-Angriff zu umgehen.

https://media.ccc.de/v/38c3-windows-bitlocker-screwed-without-a-screwdriver

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.