Ich habe eine Schwachstelle gefunden. Sie fanden einen Anwalt

• Der Autor, ein Tauchlehrer und Platform Engineer, entdeckte eine schwerwiegende Sicherheitslücke im Mitgliederportal eines Tauchversicherers
• Das Portal verwendete fortlaufende Benutzer-IDs und dasselbe Standardpasswort, sodass jeder mit einer einfachen Kombination auf die personenbezogenen Daten anderer Mitglieder zugreifen konnte
• Er meldete das Problem gleichzeitig an CSIRT Malta und die betroffene Organisation, doch statt Dank erhielt er über eine rechtliche Vertretung die Warnung vor möglicher strafrechtlicher Verantwortung
• Der Autor lehnte die geforderte Vertraulichkeitserklärung (NDA) ab und schlug stattdessen eine bereinigte Erklärung vor, die nur die Löschung der Daten bestätigte; die Organisation drohte jedoch erneut unter Verweis auf mögliche Verleumdung
• Der Vorfall zeigt die Bedeutung verantwortungsvoller Offenlegung von Schwachstellen und die Realität, dass rechtliche Drohungen den Schutz von Forschenden abschrecken

---

Entdeckung der Schwachstelle

• Während einer Taucherreise zur Kokosinsel in Costa Rica entdeckte der Autor einen strukturellen Fehler im Mitgliederportal eines Tauchversicherers
  • Wenn ein Ausbilder einen Schüler registrierte, erzeugte das System eine fortlaufende numerische ID und ein unverändertes Standardpasswort
  • Viele Nutzer änderten ihr Passwort nicht, sodass Zugriff auf die vollständigen personenbezogenen Daten anderer Mitglieder möglich war (Name, Adresse, Geburtsdatum, Kontaktdaten usw.)
• Grundlegende Sicherheitsmaßnahmen wie erzwungene Passwortänderung, Login-Beschränkungen oder MFA fehlten vollständig
• Einige Konten enthielten auch Informationen von Minderjährigen (14 Jahre)
• Der Autor überprüfte das Problem mit minimalem Zugriff, brach dann sofort ab und löschte alle gesammelten Daten dauerhaft

Verifizierung und Nachweis

• Ein Versuch mit Python requests scheiterte an der komplexen Sitzungsstruktur, daher erfolgte die Verifizierung per Browser-Automatisierung mit Selenium
  • Allein durch Eingabe der Benutzer-ID und des Standardpassworts war ein Login möglich
  • Das Automatisierungsskript wurde als nicht funktionsfähiger Beispielcode veröffentlicht, alle realen Identifikatoren wurden entfernt
• Die Beispielausgabe enthielt vollständige Profildaten wie Name, E-Mail, Adresse und Geburtsdatum
• Dabei wurde bestätigt, dass mehrere Konten von Minderjährigen auf dieselbe Weise offengelegt waren

Verfahren zur Offenlegung der Schwachstelle

• Am 28. April 2025 meldete der Autor die Schwachstelle offiziell und setzte eine Frist von 30 Tagen für die Behebung
• CSIRT Malta und die betroffene Organisation wurden gleichzeitig per E-Mail informiert
  • Der Bericht enthielt eine Zusammenfassung des Problems, mögliche GDPR-Verstöße, Screenshots und einen verschlüsselten PoC-Link
  • Er bat um Eingangsbestätigung innerhalb von 7 Tagen und Behebung innerhalb von 30 Tagen
• Dies entsprach dem Standardverfahren gemäß der nationalen Richtlinie zur Offenlegung von Schwachstellen (NCVDP)

Reaktion der Organisation

• Zwei Tage später kam die Antwort nicht vom IT-Team, sondern von einer für Datenschutz zuständigen Anwaltskanzlei (DPO Law Office)
  • Zwar wurden Passwort-Resets und die Einführung von 2FA erwähnt, doch dass zuerst eine staatliche Stelle informiert wurde, wurde zum Problem gemacht
  • Der Autor wurde gewarnt, sein Handeln könne nach dem maltesischen Strafrecht eine Straftat darstellen und rechtliche Folgen haben
• Die Organisation verlangte die Unterzeichnung einer Vertraulichkeitserklärung und setzte dafür die Vorlage einer Passkopie sowie eine Unterschriftsfrist am selben Tag
  • Die Erklärung enthielt eine Klausel, wonach „der Inhalt dieser Erklärung vertraulich zu behandeln ist“, faktisch also die Form eines NDA (Geheimhaltungsvereinbarung)
• Anschließend folgten wiederholte Aufforderungen zur Unterschrift mit Betreffs wie „freundliche Erinnerung“ und „dringende Erinnerung“

Ablehnung und Erwiderung des Forschers

• Der Autor weigerte sich, eine Vertraulichkeitsklausel zu unterzeichnen, und schlug stattdessen eine überarbeitete Erklärung vor, die nur die Löschung der Daten bestätigte
  • Er stellte klar, dass die Benachrichtigung von CSIRT Malta Teil des offiziellen Verfahrens sei und dass die Analyse nach der Offenlegung gängige Praxis in der Sicherheitsbranche sei
• Die Organisation verwies auf § 337E des Strafgesetzbuchs (Computer Missbrauch) und warnte, dass auch im Ausland begangene Handlungen in Malta als Straftat gewertet werden könnten
• Außerdem teilte sie mit, dass die Nennung des Organisationsnamens in Blogs oder auf Konferenzen zu Verleumdungsvorwürfen und Schadensersatzforderungen führen könne
• Die Schwachstelle ist inzwischen behoben, und das Zurücksetzen der Standardpasswörter sowie die Einführung von 2FA laufen
• Unklar bleibt jedoch, ob gemäß Art. 33 und 34 GDPR eine Benachrichtigung der Betroffenen erfolgt ist

Verantwortungsabwälzung und GDPR-Verstoß

• Die Organisation behauptete, die Änderung des Passworts liege in der Verantwortung der Nutzer
• Nach Art. 5(1)(f) und Art. 24(1) GDPR muss jedoch der Verantwortliche angemessene technische und organisatorische Maßnahmen ergreifen
• Dasselbe Standardpasswort in Kombination mit fortlaufenden IDs ist eindeutig als unangemessene Sicherheitsmaßnahme zu bewerten

Ein wiederkehrendes Muster

• Wenn Sicherheitsforschende Schwachstellen verantwortungsvoll offenlegen, erleben sie weiterhin einen „Chilling Effect“ durch rechtliche Drohungen
• Juristische Gegenmaßnahmen verschlechtern den Ruf eher noch; das Problem ist nicht die Schwachstelle selbst, sondern die Art, wie die Organisation reagiert

Das richtige Vorgehen

• Meldung entgegennehmen und die Schwachstelle beheben
• Dem Forscher Dank aussprechen
• Eine CVD-Richtlinie (Coordinated Vulnerability Disclosure) etablieren
• Betroffene Nutzer informieren, insbesondere zum Schutz Minderjähriger
• Kein Schweigen per NDA erzwingen

Ratschläge für Organisationen und Forschende

• Organisationen sollten klare Offenlegungsverfahren wie security.txt bereitstellen und Forschenden danken
• Forschende sollten das nationale CSIRT einbeziehen, alle Unterlagen aufbewahren und nach der Datenlöschung Vertraulichkeitsforderungen ablehnen
• Die NIS2-Richtlinie fördert in der EU die verantwortungsvolle Offenlegung von Schwachstellen
• Selbst im Jahr 2026 besteht weiterhin die Realität, dass schon eine einfache Meldung einer Schwachstelle zu rechtlichen Drohungen führen kann

[GN⁺]

Hacker-News-Kommentare

• Auch andere haben schon monoton steigende Benutzer-IDs gefunden, sie getestet und sind dafür im Gefängnis gelandet
  In dem Moment, in dem man so testet, besteht das Risiko eines CFAA-Verstoßes
  Wenn man bereits wusste, dass die IDs monoton steigen und ein Standardpasswort gesetzt war, hätte man die Schwachstelle genau in diesem Moment melden müssen
  Ab dem Zeitpunkt, an dem der Test ausgeführt wurde, könnte das bereits ein Gesetzesverstoß gewesen sein
  Das jetzt aufzuschreiben ist praktisch ein Geständnis, also sollte man einen Anwalt beauftragen und sich in das relevante Recht einarbeiten

• Ich habe keine juristische Expertise, aber drei Gedanken dazu

  1. Wenn ein rechtmäßiges Offenlegungsverfahren zu schwierig ist, werden Schwachstellen am Ende nur noch durch Kriminelle bekannt
  2. In anderen Branchen wäre es absurd, wenn Architekten verklagt würden, weil sie Baumängel entdecken. Cybersecurity unterscheidet sich allerdings dadurch, dass schon das Wissen über einen Mangel das Risiko erhöhen kann
  3. Dass zufällig vorbeikommende Personen Audits durchführen, ist viel zu instabil. Wenn eine Website meine PII (personenbezogene Identifikationsdaten) verlangt, sollte ich ein Recht darauf haben, Sicherheit für diese Daten einzufordern
     Für Versicherungen und ähnliche Unternehmen sollte gesetzlich vorgeschrieben sein, dass sie Cyber-Audits durchlaufen, White-Hat-Hacker geschützt werden und Nutzer Sammelklagen einreichen können
     Dann würden grundlegende Schwachstellen verschwinden, und Softwareingenieure wären wirtschaftlich wertvoller als Anwälte
  • In anderen Branchen gibt es das System beruflich haftender Ingenieure
    Ich frage mich, ob sich auch die Informatik im KI-Zeitalter in diese Richtung entwickeln wird
    Solche Ingenieure sind für Freigaben und Inspektionen von Entwürfen zuständig und spielen eine Schlüsselrolle bei der Gewährleistung von Sicherheit
    Entsprechend groß sind Befugnisse und Verantwortung, und die Vergütung ist hoch
  • In anderen Branchen verfügen die Entwurfsverantwortlichen über Versicherung und Zulassung
    Ich möchte Open-Source-Aktivitäten von Junior-Entwicklern nicht behindern, aber ich denke, Websites, die große Mengen personenbezogener Daten oder Geld verarbeiten, sollten von einem zertifizierten Softwareingenieur abgezeichnet werden müssen
    Das würde ihnen die nötige Durchsetzungskraft geben, um überzogene Forderungen des Managements abzuwehren
    Natürlich zeigen Fälle wie Boeing oder Volkswagen, dass auch das keine perfekte Lösung ist
  • In manchen Ländern kann Verleumdung auch dann vorliegen, wenn etwas wahr ist
    Das heißt, eine Meldung an Behörden und eine Veröffentlichung in den Medien sind zwei völlig verschiedene Dinge
    Besonders an Orten wie Malta sind organisierte Kriminalität und Korruption so stark, dass jemand, der so etwas öffentlich macht, einen „zufälligen Unfall“ erleiden könnte

• Ich verwende für jeden Dienst eine andere E-Mail-Adresse
  Vor etwa 15 Jahren bekam ich plötzlich Spam an eine diversalertnetwork-Adresse
  Als ich DAN auf den Vorfall hinwies, bekam ich nur eine Mail mit der Aufforderung, mein Passwort zu ändern
  Ich schätze, ich kann froh sein, dass ich nicht strafrechtlich angezeigt wurde

  • Entweder war das ein Hack, oder das Unternehmen hat die Daten an Dritte verkauft
  • Ich hatte etwas Ähnliches. An eine eigens für eine portugiesische Fluggesellschaft verwendete E-Mail-Adresse kam plötzlich Spam, und das Unternehmen hat überhaupt nicht reagiert

• Dass der Autor Angst hat, den Namen der Organisation zu nennen, bedeutet, dass die rechtliche Drohung wirksam war

  • Oder in der Tauch-Community kann schon die Formulierung „ein in Malta ansässiger Tauchversicherer“ als Hinweis auf DAN Europe verstanden werden
  • Nach den Hinweisen im Text ist unter internationalen Tauchversicherern nur DAN Europe in Malta registriert, also ist es so gut wie sicher
  • Natürlich kann man auch nicht ausschließen, dass er die gewonnenen Informationen an Black-Hats verkauft hat

• Bei der Forderung „Unterschreibe eine Bestätigung zur Löschung der Daten“ fragt man sich, warum überhaupt unterschrieben wurde
  Das Unternehmen wollte offenbar eher Kontrolle als Kooperation

  • Wenn man die Gegenseite aber dazu bringt, den eigenen Bedingungen zuzustimmen, hebelt man ihre Kontrollstrategie aus und schafft rechtliche Verbindlichkeit

• Das Muster, dass Sicherheitsforscher Schwachstellen melden und dafür rechtlich bedroht werden, wiederholt sich seit Jahrzehnten
  Regierungen und Unternehmen sprechen von der Bedeutung von Cybersecurity, in der Praxis sind sie Forschern aber feindselig gesinnt
  Es braucht Gesetzgebung, die solche ungerechtfertigten Reaktionen verhindert
  Ähnliche Fälle finden sich unter diesem Link

• Ich frage mich, ob das Ziel in diesem Fall DAN Europe und seine Tochtergesellschaft IDA Insurance Limited sind

  • In anderen Kommentaren wurde das bereits so geschlussfolgert

• In Deutschland ist es auf diese Weise illegal, per Skript auf die Daten anderer Personen zuzugreifen
  Das ist so, als stünde die Autotür eines anderen offen und man würde trotzdem einsteigen und den Motor starten
  Eine rechtliche Einordnung dazu gibt es hier

  • Dann sollte das Gesetz geändert werden. Ein solches Maß an Sorglosigkeit bei der Sicherheit wird sich ohne gutgläubige Hinweisgeber oder einen großen Leak niemals bessern
  • Sehe ich auch so. Man muss wissen, wo man aufhören muss
    Im Rahmen der normalen Nutzung der Website Screenshots zu machen und das zu melden, ist in Ordnung, aber mit einem Python-Skript Daten zu sammeln überschreitet die Grenze
    Das ist so, als würde man bei einer offenstehenden Banktür nicht die Polizei rufen, sondern hineingehen
  • Hoffentlich nutzt kein Krimineller diese Lücke aus

• Ich habe letztes Jahr in einem Ticket-System für eine große Veranstaltung eine Schwachstelle gefunden
  Der per E-Mail verschickte Ticket-Link war eine Base64-Kodierung einer fortlaufenden Bestellnummer
  Das bedeutete, dass man auch die Tickets anderer Leute leicht herunterladen konnte
  Ich habe den Veranstalter und die Entwicklungsfirma per Mail kontaktiert, aber es kam keinerlei Reaktion, und bis heute ist alles unverändert offen
  Ich werde bei der diesjährigen Veranstaltung darauf achten, ob es behoben wurde

• Wenn Benutzer-IDs fortlaufend waren und alle dasselbe Standardpasswort hatten, dann war die eigentliche Schwachstelle die „Annahme, dass es jemanden für Sicherheit gibt“
  Heutzutage bedeutet „Responsible Disclosure“ letztlich nur noch, Unternehmen Zeit zu verschaffen, Anwälte zu beauftragen