Personalausweis, Führerschein, Gesundheitskarte – diese Plastikkarten haben viele Menschen in ihrem Portemonnaie. Doch spätestens bis Anfang 2027 müssen EU-Länder eine EUDI-Wallet anbieten. Und dann sollen alle Bürger:innen statt der vielen Plastikkarten ihr Smartphone nutzen können.

Diese Möglichkeit habe das Potenzial, „unsere digitale Gesellschaft maßgeblich zu prägen“, heißt es einleitend in einem Positionspapier, das Verbände der Wirtschaft und der Zivilgesellschaft gemeinsam veröffentlicht haben. Unterzeichnet haben das Papier die Branchenverbände Bitkom, Deutsche Kreditwirtschaft und Gesamtverband der Versicherer. Außerdem sind die Interessenvertretungen Initiative D21 und buergerservice.org sowie die zivilgesellschaftliche Organisation epicenter.works mit von der Partie.

Die Verbände mahnen, dass die Ausgestaltung der Wallet kein Selbstläufer sei. Stattdessen müsse die Bundesregierung diese als gesellschaftlichen Auftrag begreifen. Und der könne nur dann erfolgreich sein, wenn die Politik in den kommenden Monaten fünf Weichenstellungen vornimmt.

Kompetenzen und Vertrauen schaffen

So brauche es erstens digitale Kompetenzen sowohl aufseiten der Nutzer:innen als auch in den Ministerien, den Aufsichtsbehörden und in der Verwaltung, „also im gesamten Staatsapparat“.

Andernfalls drohe ein ähnliches Fiasko wie bei der Einführung des elektronischen Personalausweises, der lediglich von gut einem Fünftel der Bürger:innen genutzt werde. „Wir haben in Deutschland erlebt, wie schleppend die Einführung der eID-Funktion des Personalausweises verlaufen ist“, sagt Susanne Dehmel, Mitglied der Bitkom-Geschäftsleitung. „Diesen Fehler dürfen wir nicht wiederholen.“

Zweitens brauche es verbindliche Rechtsvorschriften sowie technische Standards, damit sich alle Akteure in dem Identitätsökosystem untereinander vertrauen können. Der Staat müsse klar auf die EUDI-Wallet setzen und Doppelstrukturen oder Insellösungen vermeiden.

„Ein kluges Verbraucherschutzkonzept“

Daneben brauche es drittens „ein kluges Verbraucherschutzkonzept“, damit Nutzer:innen der digitalen Brieftasche selbstbestimmt entscheiden können, wem sie welche Daten übermitteln. Eine zentrale Stelle müsse prüfen, welche Unternehmen und Behörden als „vertrauenswürdige Parteien“ welche Daten aus der Wallet abfragen dürfen. Außerdem sollten Nutzer:innen standardmäßig ein Pseudonym nutzen können, um sich gegenüber diesen ausweisen zu können, wenn der amtliche Name nicht notwendig ist.

Außerdem sei viertens eine kontinuierliche Steuerung und Kontrolle auf ministerieller Ebene erforderlich. So brauche es „einen zentralen Ansprechpartner“ und themenspezifische Expertengremien innerhalb des Bundesministeriums für Digitalisierung und Staatsmodernisierung (BMDS), die das Thema innerhalb des Hauses vorantreiben und effizient weitergestalten.

Und fünftens müsse das BMDS Schlüssel-Anwendungsfälle für die EUDI-Wallet schaffen. Als Beispiele nennt das Bündnis hier – neben der digitalen Identifizierung und Authentifizierung – den digitalen Führerschein, digitale Reiseunterlagen und eine Lösung zur anonymen oder pseudonymen Altersverifikation.

Eine digitale Brieftasche für alle

Die EUDI-Wallet basiert auf einem EU-Gesetz, das im Mai 2024 in Kraft trat. Die novellierte eIDAS-Verordnung sieht vor, dass die Wallet freiwillig und kostenlos sowie interoperabel sein soll. Außerdem sollen die Nutzer:innen transparent darüber bestimmen können, welche Daten sie an wen weitergeben. Derzeit werden in Brüssel die technischen Anforderungen an die europäische digitale Brieftasche verhandelt.

Die jeweiligen EU-Mitgliedstaaten müssen die Verordnung in nationale Gesetze gießen. In Deutschland liegt diese Aufgabe auf dem Tisch der amtierenden Bundesregierung.

Die Sicherheitslücke mit dem Spitznamen „Citrix Bleed 2“ ist Angreifern offenbar schon länger bekannt als zunächst angenommen. Das hat ein Anbieter von Lösungen zur Angriffserkennung herausgefunden. Mittels historischer Daten, die sie mit den Signaturen des Exploits verglichen, fanden sie am 23. Juni 2025 einen Angriffsversuch auf einen ihrer Honeypots, also einen nur zum Schein verwundbaren Server.

Das ist fast genau eine Woche nach den durch Citrix veröffentlichten Patches für CVE-2025-6543 und CVE-2025-5777, den später von Sicherheitsforscher als „Citrix Bleed 2“ getauften kritischen Fehler. Das Sicherheitsunternehmen ReliaQuest hatte ebenfalls bereits Ende Juni gemutmaßt, es gebe einen aktiv ausgenutzten Exploit, fand jedoch nur Indizien und keine harten Beweise.

Wer hatte den ersten Exploit?

Diese Beweise sind nun da, schreibt Greynoise. Und offenbar handelt es sich nicht um ungerichtete Scans, sondern um gezielte Angriffsversuche, die einen als veralteter Netscaler verkleideten Honeypot angingen. Diese frühen Angriffsversuche kamen von IP-Adressen aus China, berichtet Greynoise.

Auch der Sicherheitsforscher Kevin Beaumont wies bereits vor einigen Tagen auf die frühen Versuche hin, die Lücke auszunutzen. Citrix hatte zu diesem Zeitpunkt noch abgestritten, dass „Citrix Bleed 2“ im Arsenal von Cyberkriminellen oder staatlichen Hackern gelandet sei. Spätestens am 10. Juli war es mit den Dementis hingegen vorbei: Da nahm die US-Cybersicherheitsbehörde CISA die Lücke in ihren „Known Exploited Vulnerabilities Catalog“ auf. Einen Tag später berichtete Imperva, ein weiteres Unternehmen aus dem Bereich der „Threat Intelligence“, von über 11,5 Millionen Angriffsversuchen, überwiegend auf Ziele in den USA, Spanien und Japan.

Noch fast 4.000 Netscaler angreifbar

Mittlerweile ist das Angriffsvolumen stabil. Das Shadowserver-Projekt verzeichnete am zwischen dem 14. und 16. Juli täglich etwa 3000 Angriffsversuche auf dreißig bis vierzig Ziele, Greynoise hat im Tagesverlauf des 17. Juli lediglich drei Angreifer-IPs verzeichnet. Die Anzahl verwundbarer Geräte machte jedoch Mitte Juli einen überraschend großen Sprung und steht den Shadowserver-Statistiken zufolge nun bei über 4.500. Admins von Netscaler-Installationen sollten also tunlichst ihre Geräte überprüfen und schnellstmöglich aktualisieren.

Kevin Beaumont stellt auf Github eine Liste mit über 25.000 aus dem Internet erreichbaren Netscaler-Instanzen bereit, von denen am Vormittag des 18. Juli noch 3.829 verwundbar waren. Knapp fünfhundert dieser angreifbaren Netscaler melden sich mit einer Domain, die mit der deutschen Landeskennung „.de“ endet.

Scheibchenweise neue Informationen

Und Citrix? Die hatten immerhin Patches veröffentlicht, sich aber ansonsten einer Salami-Taktik bedient und wichtige Informationen zur Schwere der Lücke und ihrer Behandlung ausgelassen. Sicherheitsforscher Beaumont hielt mit seiner Kritik am seiner Ansicht nach zu zögerlichen Vorgehen von Citrix dann auch nicht hinterm Berg. Er kritisiert in einem Blogbeitrag, dass ausgerechnet die Netscaler-eigene Web Application Firewall (WAF) Angriffsversuche nicht abfangen könne, die anderer Hersteller hingegen schon. Citrix versteigt sich in den „Frequently Asked Questions“ zu Citrix Bleed 2 zudem gar zu der Aussage, WAFs könnten den Angriff überhaupt nicht verhindern – angesichts der Tatsache, dass der Exploit mittels mehrerer HTTP-Anfragen funktioniert, ein gewagtes Statement.

Auch an weiteren Hinweisen für Citrix-Administratoren lässt Beaumont kein gutes Haar. Aufräum-Systemkommandos zum Löschen der von Angreifern kontrollierten Verbindungen seien unvollständig, weil sie Sitzungsdaten nicht aufräumten, so der Sicherheitsforscher.

Gegenüber heise security ordnete Beaumont die Reaktion von Citrix als nicht akzeptabel ein. „Sie haben Informationen über Angriffsaktivitäten und Hinweise zur Betroffenheitsprüfung viel zu spät abgeliefert“, so Beaumont.

Hinter dem Spitznamen „Citrix Bleed 2“ verbirgt sich ein Fehler in der Speicherverwaltung der Netscaler-Geräte, den Angreifer über das Web aus der Ferne ausnutzen können. Stellen sie eine HTTP-Anfrage mit einem bestimmten, fehlerhaften Parameter, antwortet das Gerät mit einigen Bytes seines Hauptspeichers, es „blutet Speicher aus“. Diese Speicherauszüge können nutzlose Daten, aber auch Session- und andere sensible Informationen enthalten.

(cku)

Am Samstag jährt sich das Crowdstrike-Debakel. Ein guter Anlass, zurückzublicken. Was war passiert? Am 19. Juli 2024 rollte Crowdstrike ein fehlerhaftes Update auf alle Endpoint-Security-Agenten mit Crowdstrikes EDR-System Falcon aus, das Millionen von Windows-Rechnern zum Absturz brachte. Erschwerend kam hinzu, dass die Systeme dabei so nachhaltig beschädigt wurden, dass ein manueller Eingriff vor Ort erforderlich war, um sie wieder benutzbar zu machen.

Das hieß, dass manche Admins tatsächlich zu tausenden Windows-Rechnern gehen mussten, was sich teils über Tage hinzog. Die damit verursachten Schäden belaufen sich auch nach konservativen Schätzungen auf viele Milliarden US-Dollar.

Ursachenforschung

Die zentrale Ursache war Crowdstrikes miserable Qualitätssicherung beim Verteilen von derart kritischen Updates an Millionen von Systemen. Crowdstrike hat dieses Update vorab praktisch nicht getestet und es auf einen Schlag an alle Systeme verteilt. Üblich ist es, das gestaffelt in mehreren Phasen zu machen. Und schließlich haben sie auf die quasi sofort auftretenden Abstürze erst viel zu spät und unzureichend reagiert.

Hinzu kam die System-Architektur bei Windows, die es erlaubte, dass ein solches Channel-Update eine Speicherverletzung im Kernel verursachte. Denn beträchtliche Teile der Sicherheits-Software liefen direkt als Teil des Betriebssystemkerns, was bei Fehlern nicht nur ein Programm, sondern das komplette System zum Absturz bringt. Das hätte man technisch besser lösen können – übrigens auch unter Windows.

Apropos: Mit Windows traf das Problem ein Betriebssystem, das selbst nicht resilient genug konzipiert war. Der Linux-Kernel etwa bietet mit eBPF (extended Berkeley Packet Filter) eine Schnittstelle an, über die Sicherheits-Software auf Kernel-Ressourcen zugreifen kann, ohne selbst im Kernel-Modus zu agieren. Ziel ist es, möglicherweise weniger zuverlässigen Code aus dem Kern des Systems herauszuhalten. Unter Windows hingegen fehlten sowohl Unterstützung als auch Regeln für den Zugriff auf den Kern. Deshalb operieren alle Hersteller – einschließlich Crowdstrike – mit eigenen Treibern selbst im Windows-Kern herum. Und beim Laden dieses Crowdstrike-Treibers stürzte Windows ab.

Das geschah dann auch noch so früh im Startprozess, dass Anwender keine Chance hatten, einzugreifen; ihr System war in einer endlosen Reboot-Schleife gefangen. Auf die naheliegende Idee, den Boot-Prozess zu protokollieren und beim dritten Absturz an derselben Stelle einen Systemstart ohne den problematischen Treiber anzubieten, war man in Redmond offenbar nicht gekommen. Diese einfache Maßnahme hätte die Auswirkungen des Problems deutlich reduziert.

Nachgebessert

Mittlerweile haben die verantwortlichen Akteure nicht nur Besserung gelobt, sondern auch bereits konkrete Maßnahmen umgesetzt, mit denen man solch einen Super-GAU zukünftig vermeiden möchte. Allen voran Crowdstrike, die ihre Systeme und deren Betrieb nun „Resilient by Design“ auslegen wollen. Darunter firmiert zunächst die Beseitigung der bereits angesprochenen Versäumnisse beim Testen und Ausrollen der Updates.

Ziel sei es, Fehler zu finden und zu beseitigen, bevor sie die Systeme der Kunden treffen. Und die Kunden können mittlerweile sogar selbst bestimmen, ob sie Signatur- und Sensorupdates sofort oder mit zeitlicher Verzögerung erhalten wollen. Doch das birgt natürlich auch Risiken: Ganz aktuelle Angriffsmuster erkennt der Sensor dann erst mit Verspätung. Die kritisierte Kernel-Nutzung will Crowdstrike minimieren. Und schließlich soll ein „Chief Resilience Officer“ als Stabsstelle direkt unter dem Geschäftsführer die Widerstandsfähigkeit gegen neuerliche Ausfälle erhöhen.

Auch bei Microsoft steht die Zuverlässigkeit wieder höher im Kurs. Im Rahmen der Windows Resiliency Initiative hat man unter anderem den Boot-Prozess um die Quick Machine Recovery erweitert. Damit soll es zukünftig möglich sein, Windows-Systeme mit Boot-Problemen aus der Ferne wieder flottzubekommen. Ferner verbannt Microsoft Sicherheits-Software weitgehend aus dem Kernel und die Microsoft Virus Initiative (MVI) verpflichtet Sicherheitsanbieter zu umfassenderen Tests und gestaffelten Rollouts ihrer Updates.

Doch die Maßnahmen rufen auch Kritik hervor. Denn anders als bei Linux oder im eingezäunten Garten der Apple-Security ist Microsoft selbst Anbieter von kommerziellen Security-Produkten. Und es mehren sich in der Sicherheitsbranche bereits die Stimmen, dass Microsoft seine Position ausnutze, um sich weitere Vorteile für die eigene Sicherheitssoftware zu verschaffen. Es wäre nicht das erste Mal, dass man in Redmond Windows gezielt nutzt, um die Konkurrenz zu behindern und weitere Monopole aufzubauen. Da werden wir in Zukunft ganz genau aufpassen müssen, was technisch tatsächlich sinnvoll und nötig ist und wo die Wettbewerbsverzerrung beginnt.

Apropos Monopole und Monokulturen

Häufig ist auch zu hören, das Crowdstrike-Fiasko sei das Resultat einer Monokultur. Dem würde ich widersprechen. Crowdstrike ist zwar einer der großen Anbieter im Security-Markt aber bei weitem kein Monopolist; da gibt es SentinelOne, Trend Micro, Palo Alto und nicht zuletzt Microsoft selbst mit seinem Defender for Endpoint als valide Alternativen. Windows ist zwar eine Monokultur und damit auch ein Single Point of Failure. Aber wenn Windows statt auf 70 nur auf 30 Prozent der Systeme liefe und sich den Markt mit mehreren ähnlich starken Wettbewerbern teilte, hätte der Crowdstrike-Fail immer noch Milliardenschäden angerichtet. Microsofts Quasi-Monopol hat das Problem also höchstens vergrößert, aber keineswegs verursacht.

Zu kurz kommt in der Diskussion meiner Ansicht nach hingegen die Frage, wie es kommen konnte, dass ein großer, renommierter Hersteller wie Crowdstrike bei der Qualitätssicherung derart schlampt. Das liegt primär an den fehlenden Konsequenzen. Der Börsenkurs von Crowdstrike ist zwar kurzfristig abgestürzt, aber längst wieder auf neuen Höhenflügen. Den Schaden durch die Ausfälle tragen nicht die Verursacher – also Crowdstrike oder Microsoft, sondern deren Unternehmenskunden und wiederum deren Kunden, die etwa in Scharen an Flughäfen strandeten. Die laufenden Schadensersatzklagen wie die von Delta Airlines werden wohl bestenfalls ein paar leicht verschmerzbare Milliönchen ergeben.

An der systematischen Auslagerung des durch Schlamperei entstehenden Risikos auf die Gesellschaft hat sich auch ein Jahr nach Crowdstrike nichts nennenswert geändert. Sicherheit und Zuverlässigkeit erzeugen beim Hersteller primär Kosten, die er ohne direkte Umsatzverluste einsparen kann. Treibt man es zu weit und es knallt, dann tut man etwas Buße – und macht nach ein paar Jahren genauso weiter. Solange wir die Hersteller und Anbieter im Bereich IT nicht für grob fahrlässige Versäumnisse im Bereich Sicherheit und Zuverlässigkeit haften lassen, wird es auch weiter solche Vorfälle geben.

(ju)