“Verdammt, ich habe eine Sicherheitslücke gefunden” – das haben wir uns in diesem Jahr immer wieder gedacht. Was wir dabei gelernt haben, haben wir für einen Talk auf dem rc3 zusammengefasst; um euch zu helfen und die Frage zu beantworten: Was tun? Hier findet ihr einen Link zum Video, eine Linkliste zum Talk und das Skript.

Wir erzählen euch, was wir vor dem Melden unserer ersten Sicherheitslücke gerne gewusst hätten. Und wir beantworten Fragen wie: Was ist eigentlich Responsible Disclosure? Wie mache ich das richtig?

Außerdem wollen wir einen Blick werfen auf Fälle, in denen sich Menschen unmöglich verhalten haben. Denn dieses Jahr gab es leider auch mehrere Fälle, bei denen die schlimmsten Befürchtung eines Responsible-Disclosure-Prozesses eingetreten ist: Eine Anzeige. Allerdings nicht gegen das Unternehmen, das kriminell schlechte Software gebaut hat, sondern gegen die Finder*innen von Sicherheitslücken. Daher wollen wir auch einen Blick darauf werfen, wie Unternehmen richtig mit ihnen gemeldeten Sicherheitslücken umgehen können.

zerforschung zum Angucken

Den aufgezeichneten Talk könnt ihr euch hier anschauen:

Links

Was wir im Talk erwähnt haben

• Hacker*innenethik

Software

• WordPress (ein Content Management System)
• Moodle (eine Lernplattform)

Sicherheitslücken

• Log4Shell
• Heartbleed

Achtung

• NDA (= non-disclosure agreement; Geheimhaltungsvertrag)
• Bug-Bounty-Programm

Eigene Forschungen

• Schnelltest Berlin
• Lernkarten-App StudySmarter
• Bisherige zerforschungen im Überblick

Offizielle Anlaufstellen

• BSI-Schwachstellenmeldeformular
• CERT-Bund
• BSI

Kontakte

• disclosure [at] ccc.de
• hallo@zerforschung.org
• zerforschung auf Twitter
• Linus auf Twitter

Rechtliches

• DSGVO Art. 9
• StGB 202a, der “Hackerparagraph”
• Hintergrund zum Hackerparagraphen
• Talk von Udo Vetter: “Sie haben das Recht zu Schweigen” von 2018
• Talk von Linus Neumann und Thorsten Schröder: Du kannst alles hacken, du darfst dich nur nicht erwischen lassen von 2018

Besonders unfreundliche Menschen

• CDU
• Frontex

Wissenschaftliche Beiträge

• Rechtlicher Reformbedarf aus Sicht der angewandten Sicherheitsforschung
• Tassilo Thieme, Masterthesis: Heureka! Von der Schwachstellenfindung bis zur Veröffentlichung: Entwicklung eines Coordinated Vulnerability Disclosure Prozesses für kleine und mittelständische IT-Unternehmen

Weiterführende Links

• Blogbeitrag bei Jugend hackt: Wie gehe ich mit einer Sicherheitslücke um, die ich entdeckt habe?

Skript

Wer sind wir eigentlich?

Hey, wir sind pajowu und Lilith von zerforschung – Teil eines großartigen Kollektivs. Dieses Jahr gab es ja einige unschöne Momente für Finder*innen von Sicherheitslücken. Daher wollen wir uns heute mal anschauen, wie der Umgang mit Sicherheitslücken richtig funktioniert – für Finder*innen und die Organisationen, bei denen Lücken gefunden werden.

Viel Spaß – MAZ ab.

Richtig melden

Full disclosure vs. responsible disclosure

Stopp – so nicht! Das, was wir jetzt gesehen haben, das war “Full Disclosure”. Das bedeutet, dass jemand eine Sicherheitslücke findet und diese dann einfach vollständig veröffentlicht. Das kann euch in richtig krasse Schwierigkeiten bringen und ist vor allem gefährlich für die Menschen, deren Daten dadurch öffentlich werden.

Und es ist auch einfach nicht cool. Es gibt schon einen Grund, warum es ja auch in der Hacker*innen-Ethik heißt: Öffentliche Daten nützen, private Daten schützen. Um diesen 2. Punkt geht es uns heute.

Denn wir beschäftigen uns heute mit Responsible Disclosure. Also dem Prozess, wie ihr dem Softwarehersteller bescheid sagt, dass ihr dort eine Sicherheitslücke gefunden habt. Es spricht nix dagegen, die Lücke hinterher trotzdem zu veröffentlichen. Aber halt erst, wenn der Hersteller sie geschlossen hat und alle Risiken behoben sind.

Und wie man das richtig macht – das schauen wir uns jetzt einmal an.

Was ist ein relevantes Datenleck?

Nicht alles, was im Internet kaputt ist, ist auch direkt ein Datenleck. Trotzdem wollen wir uns heute wirklich nur um die kümmern – also genau diese eine Art von Sicherheitslücken: Wo es Datenabflüsse in Onlinediensten gibt.

Wir fokussieren uns heute auf Dienste, Apps und Webseiten, die nur von einem Hersteller betrieben werden. Also wir meinen damit keine Standardsoftware wie etwa Wordpress oder Moodle, die jeder auf seinen eigenen Servern installieren kann.

Wenn ihr zum Beispiel bei einer Lernkarten-App herausfindet, wie ihr die Namen aller Nutzer*innen abrufen könnt, dann ist dieser Talk genau richtig für euch.

Wenn ihr das nächste log4shell oder Heartbleed findet, dann müsst ihr ein paar Sachen anders machen, als wir euch das jetzt hier erklären. Das wäre für diesen Talk ein bisschen zu viel – aber da kann euch Linus bestimmt weiterhelfen.

Also, wieder zurück zu unserem Thema: Die Datenlücken. Bevor ihr in irgendeine Richtung losrennt, wäre es gut, wenn ihr euch zuallererst überlegt: Wie schlimm ist eigentlich die Lücke. Davon hängt dann nämlich ab, was ihr tun solltet – und wie schnell. Es ist total klar: Jede Sicherheitslücke muss gemeldet und behoben werden. Aber genauso klar ist ja auch: Nicht alle Sicherheitslücken sind gleich schlimm.

Wir schauen uns mal an, wie man das ein bisschen besser einschätzen kann: Dabei gehts vor allem darum, was das für eine Art Lücke ist, wie viele Menschen betroffen sind und um welche Daten es geht.

Zuerst: was für eine Art von Lücke ist es? Könnt ihr die Daten lesen, verändern oder sogar löschen? In unserem Beispiel geht nur das erste:

Das ist schon schlimm genug, denn wir können eine Liste aller Namen, Adressen und keine Ahnung was herunter laden.

Wir können die Liste aber nicht verändern, und zum Beispiel allen den Vornamen pajowu geben.

Außerdem können wir die Liste nicht löschen. Auch das ist wichtig – denn zur Sicherheit gehört auch, dass die Daten nicht verschwinden können.

Wenn es um persönliche Daten geht, dann sind die letzten beiden Punkte, Verändern und Löschen der Daten, auch echt ungünstig – aber es ist eigentlich schon schlimm genug, wenn die Vertraulichkeit der Daten verloren geht. Wenn also Menschen Einblicke in Daten haben, die da absolut nix verloren haben – oder anders formuliert: Datenlecks.

Davon gab es ja dieses Jahr schon genug Fälle. Wir haben zum Beispiel bei vielen Corona-Testzentren, in einigen Audio-Chat-Diensten, sogar in Schul-Apps Sicherheitslücken gefunden. Und überall konnten wir auf die Daten von vielen tausend Personen zugreifen.

Die Lücke vermessen – ein Beispiel

Mal ein Beispiel, vor einiger Zeit haben wir eine Sicherheitslücke bei einem Test-Zentren-Anbieter namens “Schnelltest Berlin” veröffentlicht. Die hatten sich so ein tolles System gebaut, bei dem man sich online für seinen Schnelltest registrieren konnte und da dann auch das Testergebnis bekam. Wir haben uns dort testen lassen und danach mal etwas genauer geschaut, wie das System eigentlich funktioniert.

Und dabei haben wir eine Schnittstelle gefunden, über die wir eine Liste aller im System registrierten Personen abrufen konnten – und über eine weitere Schnittstelle sogar deren Testergebnis.

Das waren insgemant fast 700.000 Tests, mit allen Daten: Name, Adresse, E-Mail, Telefonnummer, Personalausweisnummer und sogar das Testergebnis! 400.000 Personen waren betroffen.

Doch in dem Fall kam es sogar noch schlimmer: Wir konnten nicht nur alle Daten lesen, sondern auch selber Tests im System anlegen und deren Ergebnis speichern. Wir konnten also für beliebige Personen eintragen, sie hätten einen negativen PCR-Test gemacht – ohne, dass sie je ein Testzentrum von innen gesehen hätten.

Wir haben das mal versucht - für Robert Koch, geboren 1843. Gut, dass der Test negativ war. Mit 178 Jahren wäre so eine Corona-Infektion sicher voll gefährlich.

Damit konnten wir also fremde Daten lesen und neue Daten ins System schreiben. Und – ihr ahnt es schon – wir konnten auch Daten aus dem System löschen. Eine Katastrophe aus Sicht der IT-Sicherheit und der Gesundheit.

Wenn ihr nun wisst, was ihr mit den Daten machen könnt, geht’s weiter mit der Einschätzung, wie viele Personen betroffen sind und welche Daten dieser Personen mehr oder weniger frei rumfliegen.

Offensichtlich ist eine Lücke mit vielen Betroffenen schlimmer als eine mit wenigen. Wenn also eine große Anzahl Menschen betroffen ist, sind wir bei Alarmstufe dunkelrot.

Aber so ganz pauschal kann man das auch nicht sagen. Denn wenn es um höchstprivate Daten geht, dann kann auch schon mit wenigen Betroffenen eine sehr schwere Sicherheitslücke vorliegen. Ein paar Beispiele für solche Daten stehen schon in der Datenschutzgrundverordnung, in Artikel 9. Dazu gehören zum Beispiel Gesundheitsdaten, Daten zur sexuellen Orientierung, weltanschaulichen Überzeugung, Gewerkschaftszugehörigkeit und noch ein paar mehr.

Wenn es also auch noch besonders sensible Daten sind, dann sind wir bei Alarmstufe dunkel-dunkel-dunkelrot. Und das ist der Punkt, wo wir allerspätestens anfangen sollten, alles, was wir herausgefunden haben, aufzuschreiben.

“Es war einmal in einer Software vor langer Zeit …”

Report schreiben

Moooment! Ein Report ist doch kein Roman!

Also nochmal einen Schritt zurück: Nehmen wir an, wir haben eine relevante Sicherheitslücke gefunden und wissen durch die Kriterien von eben, wie schlimm sie ist. Und jetzt wollen wir die in einem Responsible Disclosure Verfahren melden.

Um ehrlich zu sein: Das ist uns jetzt schon sehr oft passiert, aber eine ordentliche Portion Adrenalin haben wir dabei immer noch im Blut. Ist ja auch normal: Da hat man höchstwahrscheinlich gerade Daten anderer Leute gesehen, die man nicht sehen sollte. Da geht der Puls schonmal hoch…

Deshalb das allerwichtigste ist in so einer Situation, erstmal Ruhe bewahren. Nochmal nachschauen: Habe ich da gerade wirklich Daten anderer Leute gesehen, die ich nicht sehen sollte?

“Guckt einfach nochmal nach” klingt aber auch einfacher, als es ist.

Ganz wichtig dabei: Müllt nicht in den Daten anderer Leute. Das steht schon in der Hacker*innen-Ethik. Legt euch also, wenn das geht, einen zweiten Account an oder fragt Freund*innen, ob ihr deren Account nutzen könnt.

Wenn ihr glaubt, das ihr Daten verändern oder löschen könnt, bei denen das nicht möglich sein sollte, dann versucht das logischerweise auf gar keinen Fall an den Daten anderer Leute.

Wenn dann wirklich alles so ist, wie ihr es vermutet habt, dann geht’s ans Schreiben.

Ihr dokumentiert die Lücke – und das gleich für mehrere Zielgruppen. So ein Dokument geht nämlich üblicherweise durch mehrere Hände: Zuerst kommt es zu Menschen, die nur die ersten Sätze lesen, die aber dafür verantwortlich sind, dass das Dokument bei denjenigen ankommt, die auch den Rest eures Geschreibsels verstehen können. Deswegen sollten die ersten Sätze für alle Menschen verständlich sein und die wichtigsten Fakten müssen rein. Dazu gehört:

• Wie viele Menschen sind betroffen?
• Welche Daten von diesen Leuten sind betroffen?

Verzichtet dabei möglichst komplett auf technische Details – dafür ist später noch genug Platz.

Wenn ihr die Lücke auch an offizielle Stellen wie das CERT-Bund oder Datenschutzbehörden meldet, ist es super sinnvoll, direkt auch zu beschreiben, um was für einen Dienst oder Produkt es geht. Das hilft den Stellen nämlich, die Lücke schneller einzuschätzen.

Zum Beispiel:
Stellen wir uns – rein fiktiv – vor, die Chaos Cat Community hat eine App veröffentlicht, über die die Mitglieder ihre Daten verwalten können. Und die hat eine Sicherheitslücke, die ihr gefunden habt. Dann könntet ihr zum Beispiel sowas schreiben:

In der Mitglieds-App der Chaos Cat Community können durch eine Sicherheitslücke die Daten aller Mitglieder abgerufen werden. Dazu gehören: Name, Adresse, Bezahlstatus und Impfstatus.

Und den Rest, den schreibt ihr dann für eine technisch halbwegs fitte Zielgruppe. Die wissen, was eine API ist und wie man die benutzt. Schreibt also technisch präzise, aber kurz und verständlich – keine Bachelorarbeit, keinen Roman, eine gute Dokumentation halt. Screenshots können hilfreich sein, das Problem präziser zu beschreiben und nachvollziehbarer zu machen.

Dabei beschreibt ihr

1. was genau die Sicherheitslücke ist

In unserem Beispiel könntet ihr schreiben:

Ich habe die API der Chaos Cat Community Mitglieder-App aufgerufen und herausgefunden dass ich über den API-Endpunkt /members/{id} durch das Hochzählen der Mitgliedsnummer (id) persönliche Daten aller Mitglieder abrufen kann.

ein Profil sieht dabei z.B. so aus:

{
  "first_name": "Linus",
  "last_name": "Neumann",

  "address": {
    "street": "Marienstrasse 11",
    "postal_code": "10117",
    "city": "Berlin"
  },

  "paid_until": "2022-12-31",
  "vaccinated": true
}

2. Die Auswirkungen – auch relativ kurz.

Für diesen Fall zum Beispiel:

Durch diese Sicherheitslücke habe ich Zugriff auf die gesammte Mitgliedsdatenbank der Chaos Cat Community. Kann also von allen Mitgliedern Name, Adresse, Geburtsdatum, Bezahlstatus und natürlich dass sie Mitglieder sind erfahren.

Das ist zum einen wichtig, damit die Gegenseite schnell verstehen kann, wie schlimm die Lücke ist. Zum anderen hilft es den Aufsichtsbehörden einzuschätzen, ob sie gegen das Unternehmen vorgehen müssen.

3. Danach geht es darum, wie man die Lücke nachvollziehen kann.

Beschreibt das in ein paar Sätzen. Wenn ihr ein kurzes Skript habt, das das tut, könnt ihr das da auch einfügen. Sonst beschreibt in klaren Schritten, was man tun muss. Zum Beispiel:

1. Mitglied der Chaos Cat Community werden
2. In der App anmelden, danach den Login-Code merken
3. https://geheim.katzen.ccc/mitglieder/1337?code={LOGIN_CODE} aufrufen
4. Das Profil von Katzi McCatface ist zu sehen

4. und manchmal kann man auch noch ganz gut Tipps geben, wie die Lücke geschlossen werden kann.

Wenn ihr da was habt, dann schreibt auch das in den Report rein. Aber das muss auch nicht sein. Das ist schließlich Aufgabe der Unternehmen und nicht eure.

Nachdem ihr alle Infos für euren Report zusammen habt, muss das Unternehmen davon erfahren. Dafür gibts mehrere Möglichkeiten.

Report goes brrrr – wie eure Meldung ankommt

In den meisten Situationen ist es wohl am einfachsten, über das Schwachstellenformular vom BSI zu gehen – das geht auch anonym. Das findet ihr unter https://www.bsi.bund.de/Schwachstellenmeldung oder https://www.bsi.bund.de/dok/465986 .

Wenn ihr das ausfüllt, schickt ihr die Schwachstellenmeldung direkt an das CERT-Bund – das Computer Emergency Response Team des Bundes. Das ist ein Team beim Bundesamt für Sicherheit in der Informationstechnik. Deren Haupt-Job ist, dafür zu sorgen, dass die Infrastuktur der Bundesverwaltung sicher ist – also, dass zum Beispiel niemand den Bundestag hackt. Daher sind sie auch Ansprechpartner*in für Leute wie euch, wenn ihr Sicherheitsprobleme in der Infrastuktur des Bundes findet.

Aber nebenbei kümmern die sich auch darum, zwischen Sicherheitsforscher*innen und Unternehmen zu vermitteln. Also euren Report entgegenzunehmen, in der Regel innerhalb weniger Stunden zu prüfen und dann dem betroffenen Unternehmen Bescheid zu sagen.

Das macht es für euch ein bisschen einfacher:

• Ihr müsst keinen direkten Kontakt mit dem Unternehmen haben, außer ihr wollt das natürlich.
• Wenn das BSI dem Unternehmen schreibt, kümmern die sich oft ziemlich schnell darum, die Sicherheitslücken zu schließen, denn so ein Bundesadler auf dem Briefkopf macht schon einigen Eindruck.

Ansonsten haben die auch rechtliche Möglichkeiten, können zum Beispiel eine Produktwarnung aussprechen. Damit warnen sie dann öffentlich vor der Software eines Herstellers – und das wollen die auf keinen Fall. Das kam aber erst drei mal vor. Damals wurden Android-Handys verkauft, die bereits mit Schadsoftware ausgeliefert wurden.

Aber immer im Hinterkopf haben: Das BSI ist eine Sicherheitsbehörde, wie Polizei und Geheimdienste, und dem Innenministerium nachgeordnet. Das CERT-Bund arbeitet zwar anders als Polizei und Geheimdienste, und aus unserer Perspektive ziemlich unabhängig. Aber überlegt euch immer, was ihr denen erzählt und meldet – eine Lücke, die sich zum Beispiel für einen Staatstrojaner eignet, wie das nächste Heartbleed oder log4shell – würden wir denen eher nicht melden.

Damit das in Zukunft nicht mehr nötig ist, fordern wir: Das BSI muss eine unabhängige Behörde werden, der Hacker*innen-Paragraph abgeschafft – und Frontex auch.

Dinge, die ihr ganz unbedingt nicht tun solltet

Soweit so gut. Es gibt aber auch einige Dinge, die ihr beachten solltet.

1. direkt alles erzählen was ihr wisst – kein Wissen zurückhalten.
2. keine Forderungen stellen. Keine Frage nach Geld, T-Shirts, oder Geschenken – gar nichts.

Andersrum müsst ihr aber auch aufpassen, dass keine Forderungen an euch gestellt werden.

Zum Beispiel Geheimhaltungsvereinbarungen, die sind häufig Bedingungen bei Bugbountys. Damit geht ihr gerne mal einen Knebelvertrag ein, der euch daran hindern soll, über die Sicherheitslücke zu sprechen oder noch einmal das System zu untersuchen.

Also: Keine Forderungen stellen und keinen Forderungen entsprechen – erst recht keinen Geheimhaltungsvereinbarungen, sogenannten NDAs!

Auch wir machen Fehler

Wir haben diesen Fehler auch mal gemacht und ärgern uns darüber bis heute. Damals hatten wir noch keine Erfahrung und haben eine Sicherheitslücke über das offizielle Bugbounty-Programm des Herstellers gemeldet. Was wir nicht richtig bedacht hatten: Dieses Programm enthielt eine Verschwiegenheitsklausel, sodass wir nichts darüber erzählen oder schreiben dürfen, das nicht vorher vom Hersteller freigegeben wurde.

Genau das ist, was die Hersteller mit solchen Abmachungen erreichen wollen – das Narrativ kontrollieren und euch daran hindern, frei über die Schwachstelle zu sprechen.

Und das ist ein Problem, weil wir auch als Gesellschaft über Sicherheitsprobleme in Software reden sollten. Denn nur so können wir auch über neue gesellschaftliche Maßnahmen sprechen, um diese zu vermeiden.

Versucht auch nicht, dem Unternehmen, dem ihr eine Sicherheitslücke gemeldet habt, danach eure Beratungstätigkeiten zu verkaufen. Geht darauf auch nicht ein, wenn das Unternehmen danach fragt. Das Risiko ist zu groß, dass sie das später gegen euch verwenden.

Wenn ihr euch unsicher seid, ob euer Report, so wie er ist, gut ist oder ihr euch irgendwie unsicher fühlt, dann redet lieber nochmal mit jemandem mit mehr Erfahrung darüber.

Das kann z.B. Linus machen.

Ihr solltet außerdem eine Sicherheitslücke zügig reporten. Das heißt jetzt nicht, dass ihr es überstürzen müsst. Aber ihr solltet z.B. nicht eine Lücke finden, sie testweise ausnutzen und dann wochenlang keinen Report schreiben. Denn wenn das Unternehmen die Lücke in der Zwischenzeit von sich aus findet und dann in den Logs sieht, dass ihr diese ausgenutzt und nicht zeitnah Bescheid gesagt habt, dann wird euch das oft erstmal als böswillig ausgelegt. Da wieder rauszukommen und seine gute Absicht zu beweisen, ist super kompliziert – also meldet die Lücke von euch aus, sobald ihr alles einmal gut durchdacht und formuliert habt.

Seid offen und seid gut

Das heißt übrigens auch: Schreibt alles in den Report, was ihr wisst! Wenn ihr dabei nämlich Infos zurückhaltet, dann kann das auch schnell so aussehen, als würdet ihr das absichtlich machen. Was eine richtige Scheiß-Idee ist, ist dann Geld zu verlangen, um alles zu erzählen. Und wir wissen ja: erpresserisch wirken kann böse enden. Also macht es nicht.

Was auch sowohl bei Unternehmen wie auch Behörden nicht gut ankommt ist, wenn ihr automatisierte Reports mit eurem Schwachstellenscanner generiert und diese dann direkt so verschickt. Nicht falsch verstehen – auch solche Scanner können wichtige Hinweise liefern, aber damit steht ihr erst am Anfang – also springt zurück an den Beginn des Vortrags und fangt an, die Lücke zu bewerten.

Das alles klingt jetzt vielleicht nach viel Spaß – und das ist es auch. Aber es ist wichtig, vor jedem Schritt gründlich nachzudenken, denn es kann auch viel schiefgehen.

Vorsicht Hackerparagraph

Wenn ihr eine Lücke gefunden habt und sie meldet, dann sagt ihr damit implizit auch, dass ihr die auch ausgenutzt habt. Das geht kaum anders, aber in Deutschland könnte das eine Straftat sein – nach dem sogenannten Hacker*innen-Paragraphen, 202 StGB. Der verbietet es, sich Zugriff auf besonders geschützte Daten zu verschaffen. Klingt erstmal sinnvoll, aber der entsprechende Paragraph ist absolut unklar und wird dadurch auch gefährlich für Menschen, die nichts Böses im Schilde führen. Selbst die CDU, die dieses Gesetz eingeführt hat, versteht diesen Paragraphen anscheinend nicht richtig – und hat Lilith neulich angezeigt, nachdem sie eine Sicherheitslücke in der CDU-App gefunden und gemeldet hat. Die Staatanwaltschaft hat dann aber gesagt, dass die Daten so schlecht geschützt waren, dass es nicht strafbar war, darauf zuzugreifen.

Sicherheitsforscher*innen anzuzeigen ist aber trotzdem eine extrem schlechte Idee und nur wirklich sehr … schwierige Menschen versuchen das. Von denen haben wir zum Glück bisher wenige kennengelernt, aber es gibt sie. Daher hoffen wir sehr, dass dieser Paragraph bald abgeschafft wird. Damit sind wir übrigens nicht die einzigen, das haben neulich auch ganz viele IT-Sicherheitsforscher*innen in einem offenen Brief gefordert.

Überlegt euch also gut, ob ihr eure Identität herausgeben möchtet. Melden geht ja auch ohne euren richtigen Namen. Und denkt dran: Im Internet seid ihr in der Regel nicht anonym unterwegs. Schützt euch am besten von Anfang an – denn wenn ihr etwas gefunden habt, dann wurde eure IP schon irgendwo mitgeloggt und es ist zu spät, sich jetzt noch um Anonymität zu kümmern. Dazu haben Linus und Thorsten schon einen sehr guten Talk mit dem Titel “Du kannst alles hacken – du darft dich nur nicht erwischen lassen” gehalten.

Und wenn ihr mit dem Unternehmen kommuniziert, solltet ihr ebenfalls sehr vorsichtig sein. Haltet keine relevanten Informationen zurück, aber passt auch auf, euch nicht unnötig zu belasten.

Erwartet nicht, dass das Unternehmen euch dankbar ist. Gerade zu Beginn sind die Unternehmen oft erstmal im Schock und wissen nicht so recht, wie ihnen geschieht. Dabei dürfen sie euch nicht drohen, anzeigen oder ähnliches – aber vielleicht sind sie erstmal ein bisschen pampig.

Und wie bereits gesagt – seid extrem vorsichtig, auf keinen Fall irgendetwas zu tun, was als Drohung oder Erpressung wahrgenommen wird.

Generell empfehlen wir, eure Wohnung auch stets in einem durchsuchungsbereiten Zustand zu halten. Es ist super scheiße, dass das nötig ist, aber gerade ist es so – und manchmal kommen Bullen ja auch aus anderen Gründen vorbei.

Hierzu empfehlen wir den Talk “Sie haben das recht zu schweigen” von Udo Vetter. Den findet ihr zum Beispiel auf media.ccc.de und dort wird ausführlich erklärt, wie ihr euch am besten schützt.

Kümmert euch um euch selbst

Aber wo wir gerade drüber sprechen, sich selbst zu schützen – das gilt nicht nur für eure Technik. Passt auf euch auf! Aber das ist leichter gesagt als getan. Denn wenn man dann tatsächlich eine Sicherheitslücke gefunden hat und all diese Schritte anstehen, dann kann es stressig werden: So eine Meldung kann viel Zeit, Nerven und auch eine Menge Schlaf kosten.

Deshalb kümmert euch auch um eure Gesundheit – körperlich und geistig. Am besten sucht ihr euch Verbündete – gute Freund*innen, Menschen, mit denen ihr reden könnt, denen ihr vertraut und die euch auch mal sagen, dass jetzt mal Schluss ist mit der Hackerei und Zeit für einen Ausflug, zum Beispiel zu einem hübschen Zug. Gegenseitig aufeinander aufpassen geht nämlich meistens einfacher als auf sich selbst. Und es tut einfach gut.

Für uns ist zerforschung genau das: eine krasse Herde. Und zusammen haben wir es geschafft, dieses Jahr viel mehr zu erreichen, als jede*r von uns einzeln erreicht hätte. Und wir hatten auch noch richtig viel Spaß dabei. Außerdem haben wir die Pandemie (bis jetzt) ein bisschen besser ausgehalten.

Für uns ist klar: Ohne dieses Kollektiv hätten wir das alles überhaupt gar nicht hinbekommen. Schon alleine zeitlich – es ist einfach unglaublich entlastend, wenn man Aufgaben auch mal abgeben kann. Und mehr Köpfe denken immer besser als nur einer – durch das Kollektiv haben wir unterschiedliche Perspektiven und unterschiedliche Skills. Das ist einfach mega praktisch. Und schön.

Natürlich kommt es vor, dass wir überhaupt keine Lust haben. Wenn wir uns beispielsweise an einem Dienstagabend um 23:42 zusammensetzen, und feststellen: Bis morgen um 6 Uhr muss der Text fertig sein. Und Threads für Social Media. Und ein Titelbild für den Blogpost. Das ist wirklich nicht immer spaßig. Aber gemeinsam geht’s dann doch irgendwie und am Ende macht es dann immer wieder sehr, sehr glücklich.

Also: Sucht euch Freund*innen, bildet Banden und meldet eure Sicherheitslücken gemeinsam!

Gut – angenommen, ihr habt jetzt alles richtig gemacht und sagt dem Unternehmen Bescheid. Was passiert jetzt?

Für Unternehmen: Richtig mit Meldungen umgehen

Tja, liebe Unternehmen jetzt kommen wir mal zu euch. Eigentlich sind eure Aufgaben relativ einfach erklärt: Seid freundlich und offen gegenüber den Meldenden, schließt die Lücken und kommt gar nicht erst auf die Idee, uns zu verklagen.

Naja ein bisschen was haben wir doch noch zu erzählen…

Vorweg:
Ihr kommuniziert in einem Responsible Disclosure Prozess oft mit einer Person oder einem Team, die das in ihrer Freizeit machen. Das bedeutet, geht ordentlich mit den Leuten um.

Schraubt das virtuelle Klingelschild an

Aber eigentlich fängt eure Aufgabe schon weit vorher an, lange bevor ihr die “Hacker*innen” am Hörer habt. Der allererste Schritt für euch als Unternehmen ist es, erreichbar zu sein. Denn Fehler passieren, und wenn jemand außerhalb eurer Organisation diese findet, sollten euch die einfach mitgeteilt werden können.

Denn die wichtigste Frage, die sich Sicherheitsforscher*innen da oft erstmal stellen ist: “Wie erreicht man euch?” Da hat es sich bewährt, dass ihr auf eurer Website eine spezielle E-Mail-Adresse für Sicherheitsangelegenheiten stehen habt, wie z.B. security@

Es ist außerdem sehr ratsam, dass diese E-Mailadresse von mehreren Personen gelesen und regelmäßig abgerufen wird. Denn es bringt nichts, wenn ihr eine wichtige Sicherheitslücke gemeldet bekommt, aber die verantwortliche Person gerade im Sommerurlaub ist oder eh nur einmal im Monat nachschaut. Die ankommenden Mails sollten am besten direkt von technisch kompetentem Personal gelesen werden, damit alles möglichst schnell gehen kann.

Ihr solltet auch regelmäßig in den Spamordner schauen. Hacker*innen nutzen manchmal eigene E-Mailserver und da schaffen es die Mails dann nicht immer in den Posteingang – gerade bei Google oder Outlook.

Das mit der Erreichbarkeit klingt erstmal trivial. Aber wir erleben es regelmäßig, dass wir erstmal keine expliziten Ansprechpartner*innen für Sicherheitsprobleme finden. Das bedeutet dann oft: Wir müssen an alle E-Mail-Adressen aus dem Impressum, der Datenschutzerklärung oder der Kontaktseite schreiben. Und das ist natürlich auch für ein Unternehmen suboptimal. Denn dann landet die Meldung direkt bei einer Menge verschiedener Leute. Die sind meist garnicht nicht auf Sicherheitsmeldungen spezialisiert und können diese nicht richtig einschätzen. Dann herrscht erstmal Panik, niemand weiß was zu tun ist. Dann kann alles mögliche passieren: Die Nachricht wird ignoriert oder im schlimmsten Fall wird die Meldung von den falschen Leuten in der Chefetage gelesen und direkt zu den Anwälten eskaliert.

Daher ist eine separate Adresse sinnvoll – und wenn dann dort eine Meldung eingeht, solltet ihr schnell reagieren und zeitnah eine Eingangsbestätigung versenden. Dann wissen wir, dass ihr die Meldung gelesen habt und wir nicht weiter probieren müssen, euch zu erreichen.

Denn wenn wir bei zerforschung auf dem E-Mail-Weg nichts von euch hören, dann suchen wir nach immer neuen Wegen. Vielleicht schreiben wir euch auf Whatsapp, sliden euch in die Twitter-DMs, schicken euch ein Fax, suchen euch auf LinkedIn, rufen eure Investoren oder sogar eure Eltern an. Das klingt jetzt komisch, aber das haben wir alles schon gemacht. Denn wir wollen ganz sicher gehen, dass ihr über das Problem Bescheid wisst und es möglichst schnell behebt.

Genau daher sollte die Security-Mailadresse einfach auffindbar sein. Zum Beispiel im Impressum stehen – oder noch cooler: Ihr veröffentlicht zusätzlich eine security.txt Datei auf eurer Website. Das ist ein offener Standard, um alle relevanten Informationen für Sicherheitsforschernde zu hinterlegen. Darin können sowohl die korrekten Kontaktwege als auch eure bevorzugten Sprachen für eine Meldung, Crypto-Keys und vieles mehr stehen. Damit macht ihr uns und euch die Arbeit einfacher.

Oh, eine Email!

So, ihr habt eine Meldung erhalten. Der nächste Schritt ist zu prüfen, ob ihr die Beschreibung der Lücke nachvollziehen könnt. Wenn das so ist, bestätigt das auch gleich gegenüber den Sicherheitsforschenden. Das ist wirklich wichtig, denn sonst werden wir euch weiter nerven, das kostet uns und euch Zeit!

Am besten erklärt ihr dann auch direkt, wie es jetzt weitergeht, bis die Lücke behoben ist. Hierbei ist sowohl interessant, welche Sofort-Maßnahmen ihr trefft, als auch welche langfristigen Konsequenzen ihr daraus zieht. Zum Beispiel:

Sehr geehrtes Hacker-Kollektiv Zerforschung,

Wir haben die von ihnen beschriebene Lücke nachvollziehen können und gestern Abend direkt den betroffenen Dienst vorrübergehend offline genommen. Wir haben die Lücke geschlossen und überprüfen nun den Dienst noch einmal gründlich.

Vielen Dank für das Responsible Disclosure Verfahren!

Und wenn ihr die Lücke aus der Beschreibung nicht direkt nachvollziehen könnt, dann fragt lieber erstmal nach, ob ihr das alles richtig verstanden habt. Und behauptet auf keinen Fall vorschnell, dass eine Lücke nicht existiert.

Ihr wollt den Menschen, der euch da geholfen hat, auch wirklich auf dem Laufenden halten und keinerlei Missverständnisse in der Kommunikation aufkommen lassen. Deswegen schickt lieber ein Update zu viel als eines zu wenig. Am besten ist natürlich, ihr haltet die Meldenden regelmäßig und unaufgefordert auf dem Laufenden. Schreibt zum Beispiel jede Woche einmal den aktuellen Stand darüber, wie weit ihr mit der Problembehebung seid.

Kommuniziert dabei alles sehr deutlich. Wenn es z.B. eine Verschiebung in der Timeline zur Behebung gibt, dann solltet ihr das explizit so benennen und begründen.

Ihr wollt ja, dass die Sicherheitsforscher*innen ehrlich und vollständig transparent mit euch sind – also seid es auch. Packt alle Karten auf den Tisch und haltet nichts zurück.

Außerdem ist das wichtig, da Sicherheitsforschende manchmal auch selber etwas über die Lücke schreiben wollen. Wir zum Beispiel versuchen danach immer einen Blogpost zu schreiben. Dort beschreiben wir, wie wir die Lücke gefunden haben und was die Auswirkungen davon waren. Dadurch können alle etwas aus dem Fehler lernen und solche Lücken werden in Zukunft hoffentlich seltener.

Die Lücken habt ihr selbst gebaut

Wenn ihr mit Sicherheitsforschenden redet oder schreibt, gilt eigentlich das gleiche wie für alle anderen Menschen: Benehmt euch nicht daneben – Seid freundlich, ehrlich und dankbar gegenüber den Melder*innen.

Bedenkt immer: Da helfen euch Leute in ihrer Freizeit, eure Software sicherer zu machen. Ja, es ist für euch keine schöne Situation, wenn da ein großes Sicherheitsproblem in eurer Software ist. Aber daran sind nicht die Sicherheitsforscher*innen Schuld. Die haben die Lücke nur gefunden und nicht eingebaut.

Also überlegt mal, wie beschissen sich das für eure Gegenseite anfühlt. Da hat sich jemand in ihrer Freizeit hingesetzt, eure Software angeschaut und ein Problem gefunden. Dann hat die Person euch sogar Bescheid gesagt – und von euch kommt nur Gepöbel, Drohungen oder gar eine Strafanzeige.

Damit verschreckt ihr ehrliche Sicherheitsforscher*innen. Das ist der worst case für eure Sicherheit. Denn die Lücken sind ja nicht weg, nur weil niemand sie euch meldet. Stattdessen werden die Lücken dann gar nicht gemeldet, als Full Disclosure direkt dem ganzen Internet bekannt gemacht oder an Kriminelle verkauft.

Das musste auch die CDU lernen. Nachdem sie Lilith angezeigt hat, gab es einen großen Aufschrei und sogar der CCC hat gesagt, dass sie der CDU keine Sicherheitslücken mehr vertraulich melden werden.

Stattdessen wurden in den nächsten Tagen einige weitere Sicherheitslücken bei der CDU gefunden – und direkt öffentlich gemacht.

Also passt sehr auf, dass ihr gut mit den Meldenden umgeht und wirklich nichts macht, was in irgendeiner Form als eine Bedrohung ausgelegt werden könnte.

Es ist selbstverständlich, dass ihr Leute nicht dazu zwingt, irgendwas zu unterschreiben. Weder eine Verschwiegenheitserklärung noch einen Beratervertrag noch sonst irgendwas. Versucht es nichtmal.

Natürlich freuen sich Sicherheitsforscher*innen oft, wenn ihr euch in irgendeiner Form erkenntlich zeigt. Aber sprecht auch das immer ab. Versendet nicht unaufgefordert Geschenke und überweist auch nicht einfach ein Bugbounty. Fragt immer nach, ob das auch wirklich gewünscht ist.

Und ganz wichtig: Macht es, um euch ehrlich erkenntlich zu zeigen. Macht daraus keine Pressemitteilung und bindet es an keinerlei Bedinungen. Dazu zählt auch: Bedankt euch nicht öffentlich ungefragt bei Sicherheitsforscher*innen, die euch die Lücke gemeldet haben. Nicht jede*r will auf eurer Unternehmenswebsite oder euren Social Media Kanälen mit Namen genannt werden.

Das kann an einer politischen Überzeugung liegen – wir würden nicht bei der Bundeswehr genannt werden wollen. Oder man möchte sich nicht mehr mit der Lücke beschäftigen; es könnte Stress auf Arbeit bedeuten. Oder die Leute wollen es einfach nicht – auch das müsst ihr akzeptieren.

Ehrlichkeit ist wichtig – Rücksicht auch

Es hat sich bewährt, nicht nur in der direkten Kommunikation mit Sicherherheitsforscher*innen, sondern auch in der Außenkommunikation immer offen und ehrlich zu sein, also nichts zu beschönigen oder gar zu verschweigen. Seid transparent darüber, was passiert ist und wie ihr das in der Zukunft vermeiden wollt.

Es kann sein, dass Medien über den Sicherheitsvorfall bei euch berichten wollen. Versucht wirklich nicht, die anzulügen oder gar Sicherheitsforscher*innen gegenüber Redaktionen zu diskreditieren. Das geht eigentlich immer nach hinten los.

Es gehört auch zum guten Ton, eine Sicherheitslücke nicht einfach als Pressemitteilung völlig unabgesprochen mit den Sicherheitsforscher*innen, die diese gefunden haben, zu veröffentlichen.

Wir möchten euch außerdem dazu ermutigen, eure Nutzer*innen über den Vorfall zu informieren. Auch das gehört zu einem guten und transparenten Umgang mit der Lücke. Selbst wenn ihr nahezu ausschließen könnt, dass deren Daten abgeflossen sind.

Das, was wir in den letzten Minuten erklärt haben, sind nur die absoluten Basics. Wenn ihr wirklich gut mit Sicherheitsmeldungen umgehen und eure Sicherheitsprozesse verbessern wollt, könnt ihr noch viel mehr tun. Dazu gibt es viel Literatur, mehr als in diesen Talk passt.

Einen Link zu weiterführenden Inhalten und Dingen, die wir in diesem Talk erwähnt haben, findet ihr in den Shownotes unter https://rc3.zerforschung.org/ . (Anmerkung zum Skript: Also hier!)

Happy hacking!

Und mit dieser Handreichung entlassen wir euch in die Weiten des Internets. Happy hacking!