Darauf kommt es bei Responsible Disclosure an

Wie man Sicherheitslücken verantwortungsvoll meldet und Unternehmen richtig auf entsprechende Hinweise reagieren. Ein Erfahrungsbericht über Responsible Disclosure von Mika Schmidt, Gründer von Six Eight Consulting.

Seit ich im Cybersecurity Bereich arbeite, habe ich schätzungsweise 20-30 Schwachstellen bei verschiedenen Firmen gemeldet. Für den ein oder anderen White-Hat-Hacker sind das mit Sicherheit „Rookie Numbers“, aber ich bin damit sehr zufrieden.

Beim Melden meiner ersten Lücke hatte ich sehr großen Respekt vor dem Prozess und den möglichen Konsequenzen, deswegen hier ein kleiner Erfahrungsbericht mit positiven und weniger zufriedenstellenden Ergebnissen. Vielleicht helfen meine Learnings einigen von euch, die sich gerade in einer ähnlichen Situation befinden. Außerdem möchte ich ein paar Tipps mitgeben, wie sich Unternehmen im Umgang mit gemeldeten Sicherheitslücken meiner Meinung nach verhalten sollten.

Das bisherige Highlight

Ich habe zufällig eine Lücke entdeckt, durch die man Kundendaten einer Firma auslesen konnte. Nachdem ich die Lücke verifiziert und dokumentiert habe, hatte ich erstmal den Fall von Lilith Wittmann im Kopf und entsprechend großen Respekt davor, sie dem Betreiber zu melden.

Der Chaos Computer Club (ccc.de/disclosure) bietet via [email protected] eine Anlaufstelle, die beim anonymen Melden von Lücken unterstützt. Da die Kommunikation dann aber komplett über den CCC gesteuert und dadurch natürlich langsamer wird, habe ich mich dafür entschieden, die Meldung an den Datenschutzbeauftragten des Unternehmens selbst abzuschicken.

Nach ein paar Tagen kam die Reaktion und recht schnell eine Einladung zu einem gemeinsamen Call mit dem Head of IT-Security:

Freundliches Gespräch, aber erstmal ohne großartige Kommentare von seiner Seite. Lücke gezeigt, Lücke erklärt, Doku übergeben. „Wir melden uns.“

Kurz darauf (noch am selben Tag) kam die Mail vom CTO mit einem Dank, einer angebotenen Aufwandsentschädigung in Form von Geld, aber vor allem noch einer Einladung zu einem gemeinsamen Essen inklusive bezahlter Bahntickets und Übernachtung. Am Ende stand sogar ein Jobangebot im Raum.

Dieser Fall war mein bisheriges Highlight, wie so ein Prozess ablaufen kann und wie beide Parteien voneinander profitieren konnten. Freundlich, schnell, auf Augenhöhe und insgesamt sehr konstruktiv.

Mein „Lowlight“ – gleichzeitig aber auch ein wichtiges Learning

Bei einem Plattformanbieter im Bereich E-Commerce habe ich eine architektur-bedingte Schwachstelle festgestellt. In der Plattform werden unter anderem die Kundendaten von verschiedenen Online Shops verarbeitet und für die Shops per API zur Verfügung gestellt. 

Der Zugriff war zwar durch zwei Faktoren abgesichert, unter bestimmten Voraussetzungen ließen sich jedoch beide Faktoren durch gezieltes Raten ermitteln.

Ich habe die Lücke dem Shop gemeldet, in dem ich sie als erstes entdeckt habe. Dort gab es allerdings auch nach mehreren Monaten und einigen Follow-up Emails von meiner Seite keine Reaktion.

Währenddessen habe ich beim Anbieter der Plattform Referenzkunden herausgesucht und festgestellt, dass bei vielen davon die bestimmten Voraussetzungen gegeben waren, um die zwei Sicherheitsfaktoren raten zu können.

Nach kurzer Zeit hatte ich eine Liste von rund 20 Shops zusammengestellt, die zusammen mehrere hundert Millionen Euro Jahresumsatz erwirtschafteten und bei denen aus meiner Sicht dasselbe Problem bestand.

Mit diesen Erkenntnissen meldete ich mich direkt beim Betreiber. Innerhalb von 24 Stunden erhielt ich eine Antwort vom CTO.

Er hat sich für die Responsible Disclosure bedankt, dann aber recht schnell alle Punkte als nicht relevant eingestuft, da Maßnahmen dagegen aufgesetzt seien und sich die Kunden bewusst für dieses Setup entschieden hätten.

Meine Rückfragen wurden größtenteils ignoriert und auch mein Angebot eines koordinierten und kostenlosen Pentests wurde nicht angenommen.

Ich habe mich daraufhin direkt an die größten der 20 Shops gewandt und ihnen meine Findings einzeln gemeldet. Dort wiederum hatte ich recht schnell einige Reaktionen und z. B. Calls, in denen ich das Thema genauer erläutert und mit den Betreibern besprochen habe.

Nach einigen Tagen hatte ich bei LinkedIn eine neue Nachricht im Postfach:

Der CEO der Plattform wollte mit mir quatschen. Dem habe ich zugestimmt und recht schnell saßen wir dann in einem Telefonat. 

Leider war auch dieses aus meiner Sicht wieder ernüchternd. Er hat sich darüber beschwert, dass sich viele Kunden bei ihm gemeldet haben, ich zu Unrecht sein Geschäft störe und ihm „Steine in den Weg lege“.

Damit war die Kommunikation für mich beendet. Nach meinem letzten Kenntnisstand wurde das grundlegende Problem nicht vollständig behoben. Auch später stieß ich noch auf Shops, bei denen die für einen möglichen Angriff erforderlichen Voraussetzungen aus meiner Sicht gegeben waren.

Meine wichtigsten Learnings

1. Über welchen Weg melde ich eine Lücke?

Das war Anfangs bei mir auch eine große Frage. Ich habe inzwischen für mich folgende Reihenfolge/Priorität zur Kontaktaufnahme festgelegt:

• Vorhandene Responsible-Disclosure-, Vulnerability-Disclosure- oder Bug-Bounty-Seite
• Spezielle Security-Kontaktadresse des Unternehmens
• Datenschutzbeauftragte Person aus dem Impressum oder der Datenschutzerklärung
• Allgemeine Kontaktadresse beziehungsweise info@-Adresse
• Geeignete verantwortliche Personen über LinkedIn

Unabhängig vom gewählten Kanal dokumentiere ich, wann und an wen ich die Meldung verschickt habe.

2. Kommuniziert sachlich und höflich!

Alle verantwortlichen Personen sollten verstehen, wer ihr seid, warum ihr geschrieben habt und vor allem, dass ihr helfen wollt. Es sollte eindeutig sein, dass ihr weder kriminelle noch erpresserische Absichten verfolgt.

David Kriesel hat beim CCC einen wunderbaren Talk darüber gehalten, wie er einen großen Bug bei der Firma Xerox gemeldet hat. Dort hat er ebenfalls deutlich gemacht, wie wichtig es ist, fair und freundlich zu kommunizieren und das versuche ich seit meiner ersten Meldung zu beachten.

David Kriesel: Traue keinem Scan, den du nicht selbst gefälscht hast

3. Kommuniziert klar und adressatengerecht!

Eine Meldung sollte möglichst viele konkrete und nachvollziehbare Informationen enthalten. Erklärt nicht nur, wie sich die Sicherheitslücke technisch äußert, sondern vor allem, welche Auswirkungen sie für das betroffene Unternehmen und seine Kunden haben könnte.

Beschreibt das Problem außerdem so, dass auch Personen ohne technischen Hintergrund die Situation und ihre mögliche Tragweite verstehen können.

Hilfreich sind insbesondere:

• eine verständliche Zusammenfassung,
• eine nachvollziehbare Beschreibung der Reproduktion,
• eine Einschätzung der möglichen Auswirkungen,
• geeignete Nachweise wie Screenshots oder Protokolle,
• Hinweise darauf, welche Informationen bewusst nicht weiter abgerufen oder gespeichert wurden.

4. Seid geduldig!

Ich bin selbst schlecht darin und hätte am liebsten auf jede Email sofort eine Antwort. Das passiert leider nur sehr selten und gerade bei Themen im Bereich IT-Security können Reaktionszeiten durch zusätzliche Kontroll- oder Konzerninstanzen (zB. Legal Teams oder PR Abteilungen) sehr lange werden. Wundert euch auch nicht, wenn ihr nach der initialen Meldung erst wieder was hört, nachdem die Lücke geschlossen wurde.

Trotzdem kann es sinnvoll sein, angemessene Fristen festzuhalten und höflich nachzufassen. Jede Kommunikation sollte sauber dokumentiert werden.

Tipps für Unternehmen

Fehler im Bereich IT-Security können immer und überall entstehen, sowohl im kleinen 3-Personen-Startup, als auch im Konzern mit 50.000 Mitarbeitenden. Deswegen ergibt es meiner Meinung nach auch für jedes Unternehmen Sinn, zumindest mal ein paar grundlegende Schritte für diesen Fall zu gehen:

1. Richtet eine dedizierte Kontakt-Email für Security Meldungen ein. Das kann z.B. ein security-report@ oder disclosure@ Postfach sein.
2. Sorgt dafür, dass dieses Postfacher auch regelmäßig gesichtet werden! Niemanden bringt es etwas, wenn Meldungen zwar ankommen, aber nicht bearbeitet werden.
3. Positioniert dieses Postfach prominent, sodass es auch gefunden wird. Ich empfehle eine Erwähnung im Impressum und der Datenschutzseite.
4. Richtet eine security.txt gemäß RFC 9116 ein (https://securitytxt.org/).
5. Kommuniziert klar und deutlich, dass Security Meldungen nicht strafrechtlich verfolgt werden
6. Behandelt Meldungen als konstruktives Feedback und Möglichkeit zur Verbesserung der eigenen Leistung und nicht als Hate oder Störung