Liebe Leser:innen,

nach einem Jahr schwarz-roter Bundesregierung wurde in dieser Woche viel Bilanz gezogen. Und die fiel nicht gut aus. Weder in den Medien noch auf der Straße.

Die Regierung liefere nicht, was sie versprochen hat, heißt es. Und sie müsse sich endlich zusammenraufen. Sonst drohe im Herbst ein böses Erwachen. Aus dem „Herbst der Reformen“ sei der „Sommer der Wahrheit“ geworden.

Ich habe in dieser Woche nachgeschaut, was wir selbst zum Start der schwarz-roten Koalition geschrieben hatten. Und was soll ich sagen: Mit Blick auf Überwachung und Grundrechteabbau hat die Regierung leider durchaus geliefert.

Biometrische Videoüberwachung, die Rückkehr der Vorratsdatenspeicherung, Fotofahndung im Netz, automatisierte Datenanalyse à la Palantir, zunehmende Intransparenz und rechtswidrige „Zurückweisungen“ von Schutzsuchenden. Das ist stringente Kontroll- und Ordnungspolitik, von den Innenstädten bis an die deutschen Außengrenzen.

Zivilgesellschaftliche Organisationen, Menschenrechtler:innen und die Kirchen lehnen die Vorhaben ab – als verfassungs- und europarechtswidrig. Die Regierung schert das wenig. Mehr noch: Wenn die Zahlen den Law-and-Order-Kurs nicht rechtfertigen, verweist sie kurzerhand auf die „gefühlte Sicherheit“. So geht Populismus.

Dabei bräuchten wir in Zeiten multipler Dauerkrisen ein anderes Sicherheitsverständnis, wie auch meine Kollegin Anna schreibt. Unter Sicherheit sollten demnach vollkommen andere Fragen fallen: Wie senken wir die Mieten? Wie sichern wir die Renten? Wie stoppen wir die Klimakatastrophe? Wie verbessern wir die Schulen? Wie machen wir unsere Städte lebenswerter? Wie unsere Demokratie resistenter?

Gegen solche Sicherheitsfragen habe ich nichts einzuwenden, im Gegenteil.

Um darauf Antworten zu finden, bräuchte es eine Kehrtwende. Doch ein „Sommer der Kehrtwende“ ist von dieser Koalition am wenigsten zu erwarten. Dafür müssen wir selbst ran: vor dem Bundesverfassungsgericht, auf der Straße oder an der Wahlurne.

Habt ein gutes Wochenende
Daniel

Das Landgericht Berlin II hat die Rechte von Bankkunden bei Phishing-ähnlichen Täuschungsversuchen gestärkt und Finanzinstitute technologisch in die Pflicht genommen. Das ist einem heise online vorliegenden Urteil vom 22. April der Zivilkammer 38 zu entnehmen (Az.: 38 O 293/25). In dem Verfahren gegen die Deutsche Apotheker- und Ärztebank (Apobank) entschied das Gericht, dass das Finanzhaus für einen unautorisierten Schaden von über 200.000 Euro haften muss. Die Entscheidung verdeutlicht, dass die Annahme einer groben Fahrlässigkeit bei immer raffinierteren Betrugsszenarien kaum noch haltbar ist.

Der Fall wirft ein Licht auf die Professionalität der Angreifer: Die Betroffenen wurden durch eine Kombination aus einem täuschend echt wirkenden Brief im Namen der Bank, einer manipulierten Online-Banking-Oberfläche und einem persönlichen Telefonat in die Falle gelockt. Die Betrüger verfügten über Detailwissen zu weiteren Konten der Kläger, was den Eindruck einer legitimen Bankmitarbeiterin festigte.

Die Kundin schöpfte nach ihrer Aussage keinen Verdacht, als sie beim gewohnten Login über ihre Favoritenleiste am Rechner zur Einrichtung einer 2-Faktor-Authentifizierung aufgefordert worden sei. Dieser war zuvor in einem authentisch wirkenden Brief angekündigt worden. Die Szenerie habe zudem durch den zeitnahen Anruf einer vermeintlichen Bankmitarbeiterin glaubhaft gewirkt, der unter der offiziellen Nummer der Bank erfolgte. Im Weiteren fotografierte die Klägerin lediglich Codes vom Bildschirm ab, ohne sensible Autorisierungsdaten wie PINs oder TANs aktiv an die Anruferin zu übermitteln.

Die Berliner Richter stellten klar, dass Kunden in einer solchen nahezu perfekt inszenierten Täuschung nicht grob fahrlässig handeln.

Technische Früherkennung als Bankpflicht

Bemerkenswert sind die Ausführungen des Gerichts über die Entscheidung hinaus. Die Kammer deutet darin Ansätze für notwendige Früherkennungssysteme an: Die Bank hätte den Betrug erkennen und unterbinden können, da die Einwahl des Kunden und die gleichzeitige Registrierung eines neuen Geräts durch die Täter über vollkommen unterschiedliche IP-Adressen und Provider erfolgten. Das Finanzhaus habe diese offensichtliche Diskrepanz nicht durch automatisierte Sicherheitsmechanismen blockiert und die Verknüpfung des neuen Geräts ohne hinreichende Besitzprüfung zugelassen.

Ulrich Schulte am Hülse von der Kanzlei Ilex Rechtsanwälte, der das Urteil erstritten hat, bewertet diese Einschätzung zwar als technisch noch laienhaft. Er sieht die Justiz aber auf dem richtigen Weg. In Verfahren gegen die Apobank stünden fast immer vollständige Logfiles inklusive IP-Adressen zur Verfügung. Anhand dieser Daten und einer Kundenbefragung lasse sich rückschauend exakt belegen, welche Handlung den Tätern zuzurechnen sei und wo die Bank hätte intervenieren müssen.

Der Anwalt unterstreicht, dass Phishing längst kein reines Verbraucherthema mehr sei. An der Entscheidung lasse sich ersehen, dass die größten Einzelschäden verstärkt im Bereich der mittelständischen Wirtschaft entstünden. Es seien etwa Freiberufler, Selbständige und gestandene Kapitalgesellschaften betroffen. Durch modernes Multibanking, bei dem Geschäfts- und Privatkonten zusammengeführt werden, verschwömmen die Kategorien zunehmend. Das Urteil schütze so Akteure, deren Existenz durch hohe Schadenssummen bedroht sein könnte.

Rückenwind durch OLG-Rechtsprechung

Diese Sichtweise deckt sich mit der Tendenz anderer Gerichte. Das Oberlandesgericht Koblenz machte vor Kurzem die Ansage, dass selbst das Anklicken von Links in SMS und die Eingabe von Transaktionsnummern in ein Browser-Formular nicht automatisch als grobe Fahrlässigkeit gewertet werden darf, wenn die Betrugsmasche eine täuschend echte Interaktionskette aufbaut.

Das Berliner Urteil sendet so ein Signal: Banken müssen ihre Sicherheitsalgorithmen schärfen. Auffällige Diskrepanzen in den Logfiles, wie etwa zeitgleiche Logins aus technisch unplausiblen Quellen, sollten proaktiv zur Betrugsverhinderung genutzt werden.

(nen)

Am 5. Mai um 21:43 knirschte es im deutschen Teil des Internets: Wer versuchte, Adressen mit der Endung .de aufzurufen, erhielt nur eine Fehlermeldung – zumindest, wenn der verwendete DNS-Server DNSSEC-Signaturen validierte. Erst nach 1 Uhr in der Nacht war das Problem vollständig behoben. Verantwortlich für die DNSSEC-Konfiguration der Zone .de ist die DENIC eG, die diese Domains verwaltet. Die hat jetzt Erklärungen für die Probleme geliefert.

Aus dem Blogbeitrag der DENIC geht hervor, dass die DNS-Server die Software Knot nutzen, ein Open-Source-Serverdienst, der von der tschechischen Domain-Verwaltungsorganisation CZ.NIC, Verwalterin der Domain .cz, gepflegt wird. Bei der DENIC läuft Knot zusammen mit „Eigenentwicklungen in Verbindung mit Hardware Security Modulen (HSMs)“. Im April 2026 habe man diese Infrastruktur auf die dritte Generation umgestellt.

Schlüsselkollision

Am 2. Mai begann dann der turnusmäßige Tausch des Zone-Signing-Keys. Veröffentlicht wurde ein neuer öffentlicher Schlüssel mit der ID 33834 – 3 Tage, bevor er zum ersten Mal zum Signieren benutzt wurde. Was da noch niemand ahnte: Im selbstentwickelten Teil des Codes steckte ein Fehler, der dazu führte, dass auf den Servern gleich drei Schlüsselpaare mit dem Tag 33834 erzeugt wurden, aber nur ein öffentlicher Schlüssel unter dieser Nummer veröffentlicht wurde. Als dieser Schlüssel erstmals benutzt wurde, um SOA-Einträge zu signieren, entstand das eigentümliche Fehlerbild, das man mit einem Werkzeug wie dnsviz.com nachverfolgen kann: Nur ein Teil der sechs DENIC-Nameserver nutzte jeweils den richtigen privaten Schlüssel, der zum öffentlichen Schlüssel passte, die anderen lieferten immer ungültige Signaturen aus. Der SOA-Eintrag wird häufig geändert, weil bei jeder Änderung an der Zone die Seriennummer in diesem Eintrag geändert wird. Das passt zum Hin-und-Her, das wir in einer ausführlichen Auswertung der vorliegenden Daten bereits beobachtet haben.

Die DENIC-Verantwortlichen halten fest, dass ein Codeabschnitt in der selbstgebauten Software „durch die Testszenarien nicht vollständig abgedeckt wurde und darum weder bei Testläufen, noch im ‚kalten‘ Parallelbetrieb vor der Inbetriebnahme als defekt erkannt wurde“ und betonen weiter, dass man gleich drei Prüfwerkzeuge auf die Zone anwende, die auch alle angeschlagen haben – „die Meldungen wurden allerdings nicht korrekt verarbeitet.“

Vollständige Klarheit liefert die Erklärung noch nicht. Der Code der Eigenentwicklungen ist nicht quelloffen, das verwendete Hardware Security Module wird nicht benannt und unter welchen Bedingungen die Schlüsselkollision ausschließlich im Produktivsystem und nicht in Testumgebungen auftrat, wird nicht erklärt. Immerhin verspricht man, mehr Informationen zu liefern, wenn die Untersuchung abgeschlossen ist.

Alle Domains betroffen

Im Blogbeitrag stellt die DENIC auch die Aussage aus der Nacht richtig, nach der nur solche Domains betroffen waren, bei denen DNSSEC aktiv war. Diese Behauptung deckte sich nicht mit Beobachtungen während des Ausfalls. Richtig ist, dass neben dem SOA-Eintrag auch NSEC3-Einträge betroffen waren. NSEC3 verhindert, dass ein Angreifer, der in den Verkehr eingreifen kann, DNSSEC einfach dadurch aushebeln kann, dass er die Antwort sendet „für diese Domain ist DNSSEC deaktiviert“. NSEC3 ist ein kryptografischer Beweis der Nichtexistenz. Ohne gültige NSEC3-Einträge scheiterte die DNSSEC-Prüfung für alle .de-Domains.

Fazit

Abgeschlossen ist der Fall noch nicht, wie die DENIC selbst schreibt. Die DENIC hat neben einer genauen Erklärung des Problems (bestenfalls inklusive Code) auch noch keine Liste an geplanten Maßnahmen veröffentlicht, wie ein solches Problem künftig erkannt werden könnte. Von solchen Erkenntnissen würden nicht nur Betreiber von DNSSEC-Infrastruktur für Domains, sondern auch andere TLD-Betreiber profitieren. Probleme mit Schlüsselkollisionen auf Ebene einer Toplevel-Domain sind nichts Neues: 2024 hatte der russische Betreiber der .ru-TLD einen Ausfall, Schuld war damals eine Schlüsselkollision.

(jam)