RC3 2021-Vorspannmusik Herald: Hello and welcome back to the xHain stage. The following talk will be held in German but there will be a live translation which you can switch to now. So, jetzt also weiter auf Deutsch: Willkommen zurück auf der Lichtung der Stage hier vom xHain. Ich bin euer Herald Karl. Aber ich habe heute eine etwas komische Doppelrolle, denn der folgende Talk, da bin ich auch Speaker. Deswegen mache ich jetzt erstmal vor allem den organisatorischen Teil. Ihr könnt Fragen zu dem folgenden Talk stellen auf Twitter und Mastodon unter dem Hashtag #rc3xhain oder auf hackint im IRC im Channel #rc3-xhain. Ja, jetzt switche ich in meiner Rolle als Karl von zerforschung und Lilith, was ist eigentlich zerforschung? Lilith: Genau, also zerforschung, wir sind ein Kollektiv von einer Menge jungen Menschen. Weniger als 10 momentan. So genau ist das nunmal schwer zu definieren. Und wir haben uns im letzten Jahr irgendwie so zusammengefunden, verteilt über ganz Deutschland. Miteinander kommunizierend über Signal und BigBlueButton und ja, wir haben irgendwann angefangen aus Interesse uns Technik anzuschauen. Und seit wir damit angefangen haben oder innerhalb des letzten Jahres vor allem, sind wir dann von Sicherheitslücke zu Sicherheitslücke gestolpert und heute in dem Talk wollen wir uns damit beschäftigen, was wir gerne vor einem Jahr gewusst hätten, bevor uns das alles passiert ist. Linus: lacht Das habe ich euch vor einem Jahr schon gesagt. - Achso, soll ich was sagen? Ja, ich bin Linus vom Chaos Computer Club. Der Chaos Computer Club ist eine Vereinigung von Hackerinnen und Hackern, eine der größten Vereinigungen, wenn nicht die größte Europas. Potenziell haben einige von euch auch schon mal davon gehört. Wir machen Schwachstellensuche und Schwachstellenmeldung schon etwas länger als ein Jahr und ich habe der zerforschung anfangs ein bisschen mit Rat und Tat zur Seite gestanden. Und in diesem Vortrag wollen wir nicht nur das besprechen, was die zerforschung euch mitteilen möchte, darüber, wie man meldet, sondern auch so ein bisschen, wie man auf eine Meldung reagiert. Denn wenn ich eine Sache auf jeden Fall beobachtet habe, ist es so: Ich hatte zwischenzeitlich den Eindruck, dass die Unternehmen oder die Betroffenen besser reagieren und in diesem Jahr haben sie teilweise so besonders ungünstig und doof reagiert und das wollen wir in diesem Vortrag auch ein bisschen berühren. Karl: In dem gesamten Vortrag werden wir immer wieder Verweise auf allerlei Paper oder andere interessante Informationen machen. Dazu haben wir eine Linkliste, eine Shownote zusammengestellt, die findet ihr unter https://rc3.zerforschung.org und da wird dann nach dem Vortrag auch ein vollständiges Skript erscheinen, falls ihr das Ganze nochmal nachlesen wollt. So, dann will ich uns aber nicht länger aufhalten. Eine Warnung noch: Der nachfolgende Film wird ermöglicht durch Cringe-Platzierung und damit MAZ ab! Tastaturgeräusche Lachen Lilith: Oh wow, das sind einfach alle Daten von der Chaos Cat Community. Oh Linus ist auch in den Daten. Hey Karl, soll ich das vertwittern? Karl: Hä? Lilith: Äh, äh, soll ich das vertwittern? Mit der Chaos Cat Community? Ok, dann mache ich das. Lachen Ich tagge mal noch in den Linuzifer. Hey Linuzifer, schau mal deine Daten. Hat er doch gesagt, Sicherheitslücken vertwittern. Klopfen Aufmachen, Polizei! Karl: 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 das ist auch einfach nicht cool. Es hat schon einen Grund, warum es in der Hacker*innenethik heißt: Öffentliche Daten nützen, private Daten schützen. Und um diesen zweiten Punkt geht es uns heute, denn wir beschäftigen uns mit Responsible Disclosure. Also das ist ein Prozess, wie ihr einem Softwarehersteller Bescheid sagt, dass ihr dort eine Sicherheitslücke gefunden hat. Es spricht nichts dagegen, die Lücke hinterher trotzdem zu veröffentlichen, aber halt erst hinterher, wenn der Hersteller sie geschlossen hat und alle Risiken behoben sind. Und wie man das richtig macht, das schauen wir jetzt. Lilith: 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ücke, wo es Datenabflüsse in Onlinediensten gibt. Wir fokussieren uns heute auf Dienste, Apps und Webseiten, die auch nur von einem Hersteller betrieben werden. Also wir meinen damit keine Standardsoftware wie etwa ein WordPress oder ein Moodle, die jeder auf seinen eigenen Servern installieren kann. Wenn wir z. B. bei einer Lernkarten-App herausfindet, wie ihr die Namen aller Nutzer*innen abrufen könnt, dann ist der Talk hier genau richtig für euch. Wenn ihr das nächste log4shell oder Heartbleed findet, dann müsst ihr ein paar Sachen komplett anders machen, als wir das hier heute erklären. Das wäre aber für diesen Talk auch einfach ein bisschen zu viel. Aber da könnt ihr euch dann an Linus wenden, der kann euch da bestimmt weiterhelfen. Linus: Ja, das kann ich machen. Schreibt ihr einfach an disclosure@ccc.de. Lilith: Super, da kann euch Linus weiterhelfen! Linus: Dat habe ich doch gerade gesagt! Lilith: Ganz genau. Also, wieder zurück zu unserem Thema, die Datenlücken. Bevor ihr in irgendeine Richtung losrennt, wäre es gut, wenn ihr euch zu aller, aller erst überlegt, wie schlimm ist diese Lücke eigentlich? Davon hängt dann nämlich ab, was ihr tun solltet und wie schnell. Es ist total klar, jede Sicherheitslücke muss gemeldet werden. Aber genauso ist auch klar: Nicht jede Sicherheitslücke ist gleich schlimm. Wir schauen uns das mal an, wie man eine Sicherheitslücke ein bisschen besser einschätzen kann. Dabei geht es vor allem darum, was für eine Art von Lücke das ist, wie viele Menschen betroffen sind und um welche Daten es genau 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 vom Anfang, da ging nur das erste. Das ist aber auch schon schlimm genug, denn wir können eine Liste aller Namen, Adressen und keine Ahnung, was das noch für Daten waren, 'runterladen. Wir können die Liste aber nicht verändern und z. B. nicht allen den Vornamen Karl geben. Außerdem können wir die Liste nicht löschen. Auch das ist wichtig, denn zur Sicherheit gehört eben auch, dass Daten nicht einfach 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 von Daten verloren geht. Wenn also Menschen Einblicke in Daten haben, die da absolut nichts verloren haben. Oder anders formuliert Datenlecks. Davon gab es in diesem Jahr echt schon genug Fälle. Wir haben z. B. bei vielen Corona- Testszentren, in einigen Audio- Chatdiensten und sogar in einigen Schul- Apps Sicherheitslücken gefunden. Und überall konnten wir auch die Daten von vielen, vielen tausend Leuten zugreifen. Karl: Mal ein Beispiel: Vor einiger Zeit haben wir eine Sicherheitslücke bei einem Testzentren-Anbieter namens Schnelltest Berlin veröffentlicht. Die hatten sich so ein tolles System gebaut, bei dem man sich online für sein Schnelltest registrieren konnte und dort dann auch das Testergebnis bekam. Wir haben uns dort testen lassen und danach mal genauer geschaut, wie das System eigentlich funktioniert. Dabei haben wir eine Schnittstelle gefunden, über die eine Liste aller im System registrierten Personen abgerufen werden konnte und über eine weitere Schnittstelle sogar deren Testergebnis. Das waren insgesamt fast 700.000 Tests mit allen Daten: Name, Adresse, Email-Adresse, Telefonnummer, Perso-Nummer und sogar das Testergebnis. 400.000 Personen waren betroffen. Doch in diesem Fall kam es noch schlimmer. Wir konnten nicht nur alle Tests aus dem System lesen, sondern selber auch neue 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 es weiter mit der Einschätzung, wie viele Personen betroffen sind und welche Daten dieser Person mehr oder weniger frei rumfliegen. Denn offensichtlich ist eine Lücke mit vielen Betroffenen schlimmer, als eine mit wenigen. Wenn also eine große Anzahl Menschen betroffen ist, sind wir schon bei Alarmstufe Dunkelrot. Aber so ganz pauschal kann man das auch nicht sagen. Denn wenn es um höchst private Daten geht, dann sind auch wenige Betroffene schon eine sehr große Sicherheitslücke. Ein paar Beispiele für solche Daten stehen schon in der Datenschutzgrundverordnung in Artikel 9, also z. B. Gesundheitsdaten wie Corona- Testergebnisse, Daten zur sexuellen Orientierung, zur weltanschaulichen Überzeugung, zur 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 sollen, alles was wir herausgefunden haben, aufzuschreiben. So: Es war einmal in einer Software vor langer Zeit ... Lilith: Moment Karl. Ein Report, das ist doch kein Roman. Also noch mal 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 uns an das Responsible Disclosure- Verfahren wagen und die Sicherheitslücke melden. Um ehrlich zu sein: Das ist uns jetzt schon sehr oft passiert. Aber eine ordentliche Portion Adrenalin, die haben wir dabei immer noch im Blut. Ist ja auch völlig normal. Da hat man höchstwahrscheinlich gerade Daten anderer Leute gesehen, die man nicht hätte sehen sollen. Da geht der Puls halt schon mal hoch. Deshalb ist das Allerwichtigste in so einer Situation: Erstmal Ruhe bewahren, noch mal nachschauen, habe ich da gerade wirklich diese Sicherheitslücke gefunden und habe da wirklich diese Daten anderer Leute gesehen, die ich nicht hätte sehen sollen? Ich weiß. Guckt einfach noch mal nach. Das klingt immer einfacher als es ist. Ganz wichtig ist dabei immer: Müllt nie in den Daten anderer Leute. Ich meine, das steht schon in der Hacker*innenethik. Legt euch also, wenn immer es geht, einen zweiten Account an oder fragt Freundinnen, ob ihr deren Account benutzen könnt. Wenn ihr glaubt, dass ihr Daten verändern oder löschen könnt, bei denen es gar nicht hätte möglich sein sollen, dann versucht es logischerweise auf gar keinen Fall an den Daten anderer Leute. Wenn dann wirklich alles so ist, wie ihr es vermutet habt, dann geht es ans Schreiben. Ihr dokumentiert die Lücke und das gleich für mehrere Zielgruppen. So ein Dokument, das geht nämlich üblicherweise durch mehrere Hände. Zuallererst kommt das zu Leuten, die nur die ersten paar Sätze lesen werden, die dann 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 sollten da direkt rein. Dazu gehören z. B. wie viele Leute sind von der Sicherheitslücke betroffen und welche Daten von diesen Leuten sind betroffen? Verzichtet dabei möglichst komplett auf die technischen Details. Dafür habt ihr im Report später noch genug Platz. Wenn ihr die Lücke auch an offizielle Stellen wie das CERT-Bund oder die Datenschutzbehörden meldet, ist es super super super sinnvoll direkt auch zu beschreiben, um was für einen Dienst oder Produkt es geht. Weil das hilft diesen Stellen dann nämlich dabei, die Lücke schneller und besser einzuschätzen. Karl: Stellen wir uns z. B. rein fiktiv vor, die Chaos Cat Community hat eine App veröffentlicht, über die die Mitglieder ihre Daten verwalten können. Die hat eine Sicherheitslücke und ihr habt die gefunden. Dann könntet ihr z. B. 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. Schreibt keine Bachelorarbeit, keinen Roman, sondern eine gute Dokumentation. Da können Screenshots helfen, um das Problem besser zu beschreiben und nachvollziehbarer zu machen. Dabei beschreibt ihr 1., was genau die Sicherheitslücke ist und in unserem Beispiel könntet ihr dann z. B. sowas schreiben wie: "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 [...]" 2. Die Auswirkung: Auch relativ kurz. Für diesen Fall z. B. "Durch diese Sicherheitslücke habe ich Zugriff auf die gesamte 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 diese Lücke ist. Und zum anderen hilft es den Aufsichtsbehörden dabei, besser einzuschätzen, ob sie gegen das Unternehmen vorgehen müssen. Als 3. 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 auch das dort direkt einfügen. Sonst beschreibt in klaren Schritten, was man tun muss. Z. B. 1. Mitglied der Chaos Cat Community werden. Linus: Katzen sind immer gut! Karl: 2. In der App anmelden, danach den Login-Code merken. 3. Diese URL aufrufen. 4. Das Profil von Katzi McCatface ist zu sehen. Lilith: Und manchmal kann man auch noch ganz gute 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 des Unternehmens und nicht eure, das herauszufinden. Nachdem ihr alle Infos für euren Report zusammen habt, dann muss das Unternehmen davon erfahren und dafür gibt es auch wieder mehrere Möglichkeiten. Telefonklingel CEO: Hack, Hack, Hack, guten Hack Hase, wir machen die Bänke für die Daten, wie kann ich Ihnen helfen? Karl: Ja, hier ist Karl von der zerforschung. Wissen Sie, warum ich anrufe? CEO: Möchten Sie eine Bestellung aufgeben oder haben Sie eine Reklamation? Karl: Weder noch. In Ihrem CRM ist durch eine CSRF mit missing authentication full access auf die PPI Ihrer Customers möglich. CEO: Wir haben MDF, HDF, Multiplex, Vollholz. Was Anderes haben wir nicht. Karl: Achso, ne. Da haben Sie mich falsch verstanden. Ich habe da eine Sicherheitslücke bei Ihnen gefunden, durch die ich die Daten all Ihrer Kund*innen abrufen könnte. Hätten Sie 5 Minuten Zeit für mich? CEO: Ja, das ist schlecht. Karl: Ja, genau. CEO: Und was machen wir jetzt? Karl: Und da wollte ich jetzt mit Ihnen sprechen, wie ich mich am besten an Sie wende, damit das möglichst schnell behoben wird. CEO: Das hat, das hat, das hat jemand für uns gemacht. Ich kann Ihnen, wenn Sie dran bleiben, kann ich Ihnen Kontakt 'raussuchen, den Sie anrufen können. Karl: Ja, das ist perfekt. CEO: Super, danke. Bis gleich! Karl: In vielen Situationen ist es wahrscheinlich am einfachsten, über das Schwachstellenformular des BSIs zu gehen. Das geht auch anonym. Das findet ihr unter dieser URL. Wenn ihr das ausfüllt, schickt ihr die Schwachstellenmeldung direkt an, das CERT-Bund, also das Computer Emergency Response Team des Bundes. Das ist ein Team beim Bundesamt für Sicherheit in der Informationstechnik. Deren Hauptjob ist dafür zu sorgen, dass die Infrastruktur der Bundesverwaltung sicher ist. Also z. B., dass niemand den Bundestag hackt. Daher sind die auch Ansprechpartner:in für Leute wie euch, wenn ihr Schwachstellen in der Infrastruktur 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 den betroffenen Unternehmen Bescheid zu sagen. Das macht es für euch jetzt ein bisschen einfacher, denn ihr müsst keinen direkten Kontakt zum Unternehmen haben. Außer natürlich, ihr wollt das. Und wenn das BSI einem Unternehmen schreibt, dann kümmern die sich oft sehr sehr schnell darum, die Sicherheitslücken zu schließen. Denn so ein Bundesadler auf dem Briefkopf macht einigen Eindruck. Ansonsten haben die auch rechtliche Möglichkeiten und können z. B. eine Produktwarnung aussprechen. Dabei warnen sie dann öffentlich vor der Software eines Herstellers. Und das wollen die Hersteller auf keinen Fall. Das kam aber erst 3 mal vor. Damals wurden Android-Handys verkauft, die bereits mit Schadsoftware ausgeliefert wurden. Doch eins solltet ihr immer im Hinterkopf haben: Das BSI ist eine Sicherheitsbehörde wie Polizei und Geheimdienste und ist 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 z. B. 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-Paragraf muss abgeschafft werden und genauso Frontex. Linus: Ja, das fordern wir schon lange. Soweit so gut. Es gibt aber auch ein paar Sachen, die ihr beachten müsst bei eurem Bericht. Erstmal: Von vorne herein alles erzählen, was ihr wisst. Kein Wissen zurückhalten und dann keine Forderungen stellen. Keine Frage nach Geld, nicht nach einem T-Shirt, nicht nach Schokolade, nicht nach irgendwelchen Geschenken. Gar nichts. Ihr verlangt überhaupt nichts und ihr legt alles Wissen sofort mit allen Empfehlungen auf den Tisch. Im Umkehrschluss müsst ihr aber auch aufpassen, dass ihr keine Forderungen an euch stellen lasst. Also irgendwelche Geheimhaltungsvereinbarung, irgendetwas, was ihr unterschreiben sollt, was häufig übrigens auch Bedingungen sind bei Bug Bounties, da muss man sehr vorsichtig sein, weil ihr da gerne mal ungewollt oder unbedacht oder unvorsichtig einen Knebelvertrag eingeht, der euch nachher daran hindern soll, über die Sicherheitslücke zu sprechen oder noch einmal dieses Thema von den betroffenen Unternehmen anzuschauen. Also keine Forderungen stellen und keinen Forderungen entsprechen, erst recht keinen Geheimhaltungvereinbarungen, sogenannten NDAs. Lilith: Wir haben diesen Fehler auch mal gemacht und darüber ärgern wir uns echt bis heute. Damals hatten wir noch nicht so viel Erfahrung und haben Sicherheitslücken über das offizielle Bug Bounty Programm eines Softwareherstellers gemeldet. Was wir dabei überhaupt nicht bedacht haben ist, dass das Programm eine Verschwiegenheitklausel hatte, so dass wir bis heute nichts darüber erzählen oder schreiben dürfen, was der Hersteller uns nicht vorher freigegeben hat. Genau das ist, was die Hersteller mit solchen Abmachungen erreichen wollen. Das Narrativ zu kontrollieren und euch daran zu hindern, frei über diese Schwachstellen zu sprechen. Und das ist ein Problem, weil auch wir als gesamte Gesellschaft, wir müssen über Sicherheitsprobleme in Software reden können. Denn nur so können wir auch darüber sprechen, wie möglicherweise neue gesellschaftliche Maßnahmen aussehen, damit wir solche Lücken in Zukunft nicht mehr so viel haben. Versucht auch nicht, den Unternehmen, denen ihr da gerade eine Sicherheitslücke gemeldet habt, irgendwie eure Beratungsdienstleistung oder irgendwas anderes zu verkaufen. Geht auch nicht darauf ein, wenn die euch danach fragen. Sagt einfach: "Ne, machen wir nicht. Ich habe euch jetzt was gemeldet und damit muss gut sein." Das Risiko ist einfach zu groß, dass sie das dann später sonst gegen euch verwenden. Wenn ihr euch irgendwie unsicher seid, ob euer Report, so wie er gerade ist, gut ist oder ihr euch sonst in irgendeiner Situation irgendwie auch nur ein bisschen unsicher seid, dann frag lieber nochmal jemanden, der damit mehr Erfahrung hat. Das kann z. B. der Linus machen. Linus: Ja, das kann ich machen, schreibt ihr einfach an disclosure@ccc.de Lilith: Genau, das kann der Linus machen. Und das ist auch nichts, wofür man sich irgendwie schämen sollte. Wir haben das auch schon ganz oft gemacht, andere Leute zu fragen. Und statt Linus könnt ihr auch einfach uns, zerforschung, fragen. Ihr erreicht uns unter hallo@zerforschung.org und wir machen das super super gerne. Linus: Ja zerforschung kann das auch machen, dann muss ich das nicht alles machen. Die machen das bestimmt auch sehr gerne. Lilith: Ey Linus, das habe ich doch gerade schon gesagt. Ihr solltet außerdem eine Sicherheitslücke immer zügig reporten. D. h. jetzt nicht, dass ihr es überstürzen müsst, aber ihr solltet z. B. nicht eine Lücke finden, sie testweise mal ausnutzen und dann wert ihr das erstmal in die Ecke und schreibt wochenlang keinen Report. Denn wenn das Unternehmen die Lücke von sich aus in der Zeit findet und die dann über ihre Logs z. B. rausfinden, dass ihr die ausgenutzt habt und nicht Bescheid gesagt habt, dann wirkt das auf die Unternehmen vielleicht erstmal böswillig, weil die wissen ja nicht, dass ihr gute Absichten habt und da wieder rauszukommen und seine guten Absichten zu beweisen, das ist dann manchmal wirklich sehr kompliziert und deswegen meldet Lücken von euch aus, sobald ihr das einmal gut durchdacht habt und den Report formuliert habt, schickt ihn zeitnah raus. D. h. übrigens auch, schreibt alles in den Report, was ihr wisst. Wenn ihr dabei nämlich einfach Infos zurückhaltet, dann kann es auch schnell so aussehen, als würdet ihr das vielleicht absichtlich machen. Und was eine echt beschissene Idee ist, ist dann Geld zu verlangen, um irgendwie alles zu erzählen, was ihr wisst, weil ihr wisst ja: Erpresserisch wirken, das kann ganz schnell böse enden. Also macht das auf keinen Fall. Was auch, sowohl bei den Unternehmen, als auch bei den Behörden, wirklich nicht gut ankommt ist, wenn ihr einfach einen automatisierten Report mit eurem Schwachstellenscanner generiert und den dann einfach direkt verschickt. Also nicht falsch verstehen, auch so Scanner können total wichtige Hinweise liefern. Aber wenn ihr so einen Hinweis habt, dann steht ihr halt immer erst total am Anfang. Also springt ihr jetzt einmal zurück zum Beginn unseres Vortrags und fangt an, diese Lücke zu bewerten. Karl: Das klingt jetzt vielleicht nach viel Spaß und das ist es auch. Aber es ist wichtig, dass ihr vor jedem Schritt gründlich nachdenkt. Denn es kann auch viel schiefgehen. Wenn ihr so eine Lücke gefunden habt und sie meldet, dann sagt ihr damit implizit auch: Hey, ich habe die Lücke ausgenutzt. Das geht natürlich kaum anders. Aber in Deutschland könnte das eine Straftat sein. Nach dem sogenannten Hacker*innen-Paragrafen 202 Strafgesetzbuch. Der verbietet es sich Zugriff auf besonders geschützte Daten zu verschaffen. Das klingt erstmal sinnvoll, aber der Paragraf ist super unklar und wird dadurch auch gefährlich für Menschen, die eigentlich nichts Böses im Schilde führen. Selbst die CDU, die sich dieses Gesetz ausgedacht hat, versteht die Paragrafen nicht richtig und hat Lilith neulich angezeigt, nachdem sie eine Sicherheitslücke in der CDU-App gefunden hat. Die hat sie natürlich richtig gemeldet, aber das war der CDU egal. Die Staatsanwaltschaft hat am Ende gesagt: "Hey, die Daten waren so schlecht geschützt, das war nicht strafbar, darauf zuzugreifen." Aber Sicherheitsforscher*innen sind da natürlich trotzdem in Gefahr. Und liebe CDU und alle betroffenen Unternehmen, es ist eine richtig schlechte Idee, Sicherheitsforscher*innen anzuzeigen. Und nur wirklich sehr 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 Paragraf 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 in der Regel nicht anonym unterwegs. Schützt euch am besten von Anfang an. Denn wenn ihr etwas gefunden habt, dann wurde eure IP-Adresse schon irgendwo mitgeloggt und es ist zu spät, sich noch um Anonymität zu kümmern. Dazu haben Linus und ths neulich schon einen sehr guten Talk mit dem Titel "Du kannst alles hacken, du darfst dich nur nicht erwischen lassen" gehalten. Linus: Oh, da habe ich zusammen mit Thorsten mal einen Vortrag drüber gehalten unter dem Titel: "Du kannst alles hacken, du darfst dich nur nicht erwischen lassen" Karl: Ja genau. Dazu hat Linus und ths neulich zusammen schon einen sehr guten Talk mit dem Titel ... Linus: Habe ich doch gerade gesagt. Karl: 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. Und erwartet auch nicht, dass das Unternehmen euch von Anfang an super dankbar ist. Gerade zu Beginn sind die oft erstmal im Schock und wissen nicht so recht, was da eigentlich gerade passiert. Dabei dürfen sie euch natürlich nicht drohen, anzeigen oder ähnliches. Aber vielleicht sind sie am Anfang ein bisschen pampig. Und wie bereits gesagt, seid extrem vorsichtig, auf keinen Fall irgendwas zu tun, was euch als Drohung oder Erpressung ausgelegt werden könnte. Generell empfehlen wir eure Wohnung einfach immer in einem durchsuchungsbereiten Zustand zu halten. Es ist super scheiße, dass das gerade nötig ist, aber aktuell ist es so und manchmal kommen die Bullen ja auch aus einem ganz anderen Grund vorbei. Hier würden wir den Talk "Sie haben das Recht zu schweigen" von Udo Vetter empfehlen. Den findet ihr z. B. auf https://media.ccc.de und dort wird ausführlich erklärt, wie ihr euch am besten schützt. Lilith: Aber wo wir gerade darüber sprechen, sich selbst zu schützen, das gilt natürlich nicht nur für eure Technik. Karl: Passt auf euch auf. Und ich weiß, das ist leichter gesagt als getan. Lilith: Denn wenn man tatsächlich so eine Sicherheitslücke gefunden hat und all die Schritte anstehen, dann kann das ganz schön stressig werden. Karl: So eine Meldung kann viel Zeit, Nerven und auch eine Menge Schlaf kosten. Lilith: Deshalb kümmert euch auch um eure Gesundheit, körperlich und auch geistig. Karl: 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 stattdessen Zeit für einen Ausflug. Z. B. zu einem hübschen Zug. L: Gegenseitig aufeinander aufpassen geht nämlich viel besser zusammen als jeder für sich alleine. K: Und es tut einfach gut. L: Denn zerforschung, das ist genau das. Eine krasse Herde. K: Und zusammen haben wir es geschafft, dieses Jahr viel mehr zu erreichen, als jede von uns einzeln geschafft hätte. L: Und wir hatten auch noch richtig, richtig viel Spaß dabei. K: Außerdem haben wir so die Pandemie, bis jetzt, ein bisschen besser ausgehalten. L: Für uns ist total klar: Ohne dieses Kollektiv hätten wir das alles überhaupt gar nicht hinbekommen. K: Schon alleine zeitlich. Es ist einfach unglaublich entlastend, wenn man Aufgaben auch mal abgeben kann. L: Und mehrere Köpfe denken immer besser als nur einer. Durch das Kollektiv haben wir unterschiedlichste Perspektiven und total unterschiedliche Skills. K: Und das ist einfach mega praktisch und schön. L: Natürlich kommt es vor, dass wir überhaupt keine Lust haben manchmal. K: Wenn wir uns bspw. an einem Dienstagabend um 23 Uhr 42 zusammensetzen und feststellen: L: Ey, bis morgen um 6 Uhr muss der Text fertig sein! K: Und die Threads für Social Media. L: Und irgendwer muss uns noch so ein Titelbild für den Blogpost basteln. K: Das ist wirklich nicht immer spaßig. L: Aber gemeinsam geht das dann doch immer irgendwie. Und am Ende macht es uns immer wieder sehr, sehr glücklich, wenn wir das Ergebnis sehen. K: Also, sucht euch Freund:Innen, bildet Banden und meldet eure Sicherheitslücken gemeinsam. L: Gut. Angenommen, ihr habt jetzt alles richtig gemacht und ihr sagt jetzt im Unternehmen Bescheid. Wir schauen uns jetzt an, was danach passiert. Musik CEO: 24? Telefonklingel CEO: Hack, Hack, Hack, guten Hack, wir bauen die Bänke für Ihre Daten, wie kann ich Ihnen helfen? Datenabfluss haben wir keinen, wir haben ganz normalen, wir haben einen Industrieausguss einfach und dann Spülausguss. Datenabfluss? Ist das eine Krankheit oder was? Wie Kunden? Was, was soll d. h. Kundendaten? Sind sie na, ne, also. Da rufe ich, nein, da, da rufe ich die Polizei. Das geht so nicht! Ja ich habe einen Notruf. Also ich habe, haben Sie eine Cyber Polizei irgendwas? Ich habe einen Anruf gerade gehabt, der wollte mich erpressen oder sonst irgendwas. Der hat was mit Daten gesagt, Daten Abfluss, wir hätten, der hätte alle meine Kundendaten. Nein, ich weiß nicht, der hat, Namen hat er gesagt, ich weiß nicht, ich habe es mir nicht gemerkt, irgendwas, was adelig es, von zerforschung oder so was in der Richtung. Ja ich bleibe dran. Lil: Tja, liebe Unternehmen, jetzt kommen wir mal zu euch. Eigentlich sind eure Aufgaben relativ einfach erklärt. Seid freundlich und offen gegenüber der Meldenden, schließt die Lücken und kommt gar nicht erst auf die Idee, uns zu verklagen. Naja, ein bisschen was haben wir dann vielleicht 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 wirklich ordentlich mit den Leuten um. K: 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 können passieren. Aber wenn jemand diese außerhalb eurer Organisation findet, dann sollten die euch möglichst einfach mitgeteilt werden können. 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-Mail- Adresse dann auch 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 kompetenten Personal gelesen werden, damit alles möglichst schnell gehen kann. Ihr solltet auch regelmäßig in den Spam-Ordner schauen, denn Hacker:Innen nutzen manchmal ihre eigenen Mailserver und die schaffen es nicht immer in den Posteingang, gerade bei Google und Outlook. Das mit der Erreichbarkeit klingt erstmal trivial, aber wir erleben es regelmäßig, dass wir erstmal keine expliziten Ansprechpartner:In für solche Sicherheitsprobleme finden. Das bedeutet dann: Wir schreiben an alle E-Mail- Adressen, die wir finden. Aus dem Impressum, der Datenschutzerklärung oder der Kontaktseite. Und das ist natürlich auch für euch als Unternehmen suboptimal, denn dann landet die Meldung direkt bei einer Menge verschiedener Leute. Die sind meist gar nicht auf Sicherheitsmeldungen spezialisiert und können diese nicht richtig einschätzen. Dann herrscht erstmal Panik. Niemand weiß, was zu tun ist und dann kann alles Mögliche passieren. Die Nachricht wird ignoriert oder im schlimmsten Fall wird sie von den falschen Leuten in der Chefetage gelesen und dann erstmal direkt zu den Anwälten eskaliert. Daher ist eine separate Adresse sinnvoll. Und wenn 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 euch auf dem E-Mail Weg nicht erreichen, dann versuchen wir es auf immer neuen Wegen. Dann schreiben wir euch vielleicht auf WhatsApp, sliden euch in die Twitter DMs, schicken euch ein Fax, suchen euch auf LinkedIn, rufen eure Investoren an oder sogar eure Eltern. Wenn das nicht gerade das gleiche ist. Das klingt erstmal komisch, aber all das haben wir schon gemacht. Denn wir wollen ganz sichergehen, dass ihr über das Problem Bescheid wisst und es möglichst schnell behebt. Genau daher sollte Security Mailadresse einfach auffindbar sein, z. B. im Impressum stehen oder noch cooler: zusätzlich in einer security.txt Das ist ein offener Standard, wie ihr alle relevanten Informationen für Sicherheitsforschende auf eurer Website hinterlegt. Darin können dann sowohl die konkreten Ansprechwege, als auch eure bevorzugten Sprachen für die Meldung, Cryptokeys und vieles mehr stehen. Damit macht ihr uns und auch euch die Arbeit einfacher. Lil: So, ihr habt nun eine Meldung erhalten und der nächste Schritt ist jetzt zu prüfen, ob ihr die Beschreibung der Lücke auch tatsächlich nachvollziehen könnt. Denn wenn das so ist, dann solltet ihr das direkt gegenüber der Sicherheitsforscher:Innen bestätigen. Das ist wirklich wichtig, denn sonst werden wir euch einfach immer weiter nerven und das kostet uns und auch euch Zeit. Am besten erklärt ihr dann auch direkt, wie es weiter geht, bis die Lücke behoben ist. Hierbei ist es sowohl interessant, welche Sofortmaßnahmen ihr trefft, als auch, welche langfristigen Konsequenzen ihr daraus zieht. Z. B.: "Sehr geehrtes Hackerkollektiv zerforschung, wir haben die von Ihnen beschriebene Lücke nachvollziehen können und gestern Abend direkt den betroffenen Dienst vorübergehend offline genommen. Wir haben die Lücke geschlossen und überprüfen nun den Dienst noch einmal gründlich. Vielen Dank für Ihr Responsible-Disclosure- Verfahren." L: 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 gar keinen Fall vorschnell, dass eine Lücke nicht existiert. Ihr wollt den Menschen, der euch da gerade 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: Haltet die Menschen regelmäßig und unaufgefordert auf dem Laufenden. Schreibt z. B. jede Woche einmal den aktuellen Stand darüber, wie weit ihr mit der Problembehebung seid. Kommuniziert dabei sehr, 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 Sicherheitsforscherin ehrlich sind und vollständig transparent. Also seid es auch. Packt alle Karten auf den Tisch und haltet nichts zurück. Außerdem ist das wichtig, da Sicherheitsforschernde manchmal auch selber etwas über diese Lücke schreiben wollen. Wir z. B. 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 diesem Fehler lernen und solche Lücken werden dadurch in Zukunft hoffentlich seltener. K: 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. Das wäre eigentlich eurer Job. Und ja, es ist keine schöne Situation, wenn da ein großes Sicherheitsproblem in eurer Software gefunden wird. Aber daran sind nicht die Sicherheitsforscher:Innen schuld. Die haben die Lücke nur gefunden, nicht eingebaut. Don't shoot the messenger! 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. Und dann hat die Person euch sogar Bescheid gesagt und von euch kommt nur Gepöbel, Drohung 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 im ganzen Internet bekannt gemacht oder an Kriminelle verkauft. Das musste auch die CDU auf die harte Tour 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. Lin: Das ist natürlich ein dramatischer Fall. Wir können niemandem mehr reinen Gewissens dazu raten, der CDU Sicherheitslücken zu melden. Wir werden das auf jeden Fall auch nicht mehr tun. Wir wünschen der CDU viel Glück oder dass sie die Sicherheitslücken vielleicht selber findet oder hofft, dass niemand anderes sie findet. K: Stattdessen wurden dann 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 die Leute nicht dazu zwingt, irgendwas zu unterschreiben. Keine Verschwiegenheitserklärung, kein Beratervertrag, nichts. Versucht es nicht mal. Natürlich freuen sich Sicherheitsforscher:Innen oft, wenn ihr euch in irgendeiner Form erkenntlich zeigt. Aber auch das spreche immer vorher ab, versendet nicht unaufgefordert Geschenke und überweist auch nicht einfach ein Bug Bounty. Fragt immer nach, ob das wirklich gewünscht ist. Und ganz wichtig: Macht es, um euch ehrlich erkenntlich zu zeigen. Das ist keine Gelegenheit für eine coole Pressemitteilung und bindet es auch nicht an Bedingungen. Dazu zählt auch: Bedankt euch nicht einfach öffentlich. Nicht jede Person will auf der Unternehmenswebsite genannt werden oder auf euren Social Media Kanälen. Das kann an der politischen Überzeugungen liegen, so wie wir z. B. nie bei der Bundeswehr genannt werden wöllten. Oder man möchte sich nicht mit der Lücke beschäftigen weiter, es könnte Stress auf Arbeit bedeuten und manchmal wollen die Leute es auch einfach nicht. Das müsst ihr akzeptieren. Lil: Es hat sich bewährt, nicht nur in der direkten Kommunikation mit den Sicherheitsforscher:Innen, sondern auch in der Außenkommunikation immer offen und ehrlich zu sein. Also nichts zu beschönigen oder sogar zu verschweigen. Seid immer transparent darüber, was passiert ist und wir das in Zukunft vermeiden wollt. Es kann sein, dass Medien über den Sicherheitsvorfall bei euch berichten wollen. Versucht wirklich nicht die anzulügen oder sogar Sicherheitsforscher:Innen gegenüber Redaktionen zu diskreditieren. Das geht eigentlich immer für euch 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 die 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 Sicherheitslücke. Selbst wenn ihr nahezu ausschließen könnt, dass deren Daten abgeflossen sind. Das, was wir in den letzten Minuten erklärt haben, das sind nur die absoluten Basics. Wenn ihr wirklich gut mit Sicherheitsmeldungen umgehen und eure Sicherheitsprozesse verbessern wollt, könnt ihr noch so viel mehr tun. Dazu gibt es viel Literatur. Viel viel mehr als in diesen Talk passt. Ein Link zu weiterführenden Inhalten und Dingen, die wir an diesem Talk erwähnt haben, findet ihr in den Shownotes unter https://rc3.zerforschung.org K: So, mit dieser Handreichung entlassen wir euch jetzt in die Weiten des Internets. Lil: Happy Hacking und bis bald! Musik CEO: Das Schlimmste sind die Aufträge von den depperten Berlinern. Läuft die Kamera? Gut! Die gehen mir dermaßen auf den Sack. Wollen Sonderfarben! Dieses, jenes! Smarte Bänke – kannst alles die Hasen geben! Gelump! Des Gute ist bloß, du kannst Geld verlangen! Du nimmst deine alten scheiß Paletten, spaxt die zusammen, die zahlen dir 500 Euro! So der deppert sind die! Und in ihrer unsanierten Altbauwohnung stellen sie das rein. Blanke Ziegel, das ist in! Kannst ja gleich zum Fenster raus heizen. Ich verkaufe denen jeden Müll! Herald/Karl: So und mit diesen Worten sind wir wieder zurück hier live auf der xHain Lichtung. Zuerst noch mal etwas Organisatorisches: Jetzt ist ein kurzes Q&A geplant und falls Ihr noch Fragen habt, dann könnt ihr die Stellen entweder auf Twitter und Mastodon unter dem Hashtag #rc3xhain oder im hackint IRC im Channel #rc3-xhain. Auch nochmal der Hinweis auf die Shownotes und das bald zur Verfügung stehende Script des gesamten Films, den wir gerade geschaut haben unter https://rc3.zerforschung.org . Und falls ihr mehr Cringe von uns sehen wollt, dann folgt uns auf Twitter und natürlich auf TikTok und Instagram. Lil: Da gibt es all die Crintge-Videos, die wir übers Jahr hinweg produzieren. K: Und jetzt muss ich mich einmal an dir vorbeidrängeln zu unserem schlauen Q&A Pad. Und da ist auch schon die 1. Frage aufgelaufen: Frage: Unterscheidet ihr zwischen echter Sicherheitslücke, also z. B. irgendwie einer fehlerhaften Authentifizierung und einem offenen Scheunentor? Also wenn man eine API hat, die einfach gar keine Authentifizierung jemals hatte. Lil: Also, man ärgert sich natürlich mehr über das Scheunentor. Aber so grundsätzlich ergibt das für uns erstmal einen Prozess und was wir so machen überhaupt keinen Unterschied. Lin: Ja man müsste vielleicht noch ergänzen so: Es gibt ja auch teilweise Sachen, so eine Information-Disclosure oder so, die ist dann, es wird häufiger mal, dass Leute sagen: Ah, da ist aber jetzt hier Debugging an oder so was. Und da ist ja halt der Unterschied: Findet man darin etwas, was einen weiteren Angriff ermöglicht oder nicht? Das spielt natürlich schon teilweise in der Priorisierung eine Rolle und irgendwie so absolute Kinkerlitzchen meldet man ja dann vielleicht auch nicht unbedingt, wenn sie jetzt nicht unmittelbar halt sich weiter verwerten lassen. Lil: Genau und wie man vielleicht auch während des Vortrags selbst jetzt gerade gemerkt hat, geht es bei uns ja vor allem darum, wenn wir tatsächlich Datenabflüsse haben. D. h. nicht, dass es nicht ganz viele andere Arten von Sicherheitsproblemen gibt, aber wir sehen halt relativ viele Datenabflüsse und das ist das, was wir auch immer ziemlich problematisch finden. Und da bewerten wir natürlich nach den Daten, die da irgendwie rausfallen und nicht so stark danach, wie schlimm, wie diese Lücke zustandekommt. Also ob da irgendwie ein Debug Modus an ist und wir bekommen dann Credentials aus dem Service raus oder ob da eine API ist, wo wir hochzählen oder was viel komplexeres. K: Und was damit auch ein bisschen zusammenhängt – was wir jetzt schon öfter gehört haben – Unternehmen, die sich dann damit verteidigen, dass das ja nur 2 Wochen offen war oder nur einen Monat. Und dann müssen wir auch sagen: Ja, schön, dass die Lücke nur so kurz war, bis jemand sie gefunden hat und irgendwie ein Responsible-Disclosure-Verfahren gemacht hat. Aber wenn die Daten einmal abgeflossen sind, dann ist das relativ egal und das dauert oft nur wenige Sekunden. Dann wo wir gerade schon über Zeiträume sprechen, ist hier die nächste Frage: F: Was sind denn vernünftige Zeiträume zwischen einer Meldung und einer Veröffentlichung? Linus? Lin: Also die ich glaube, die übliche Regel ist ja so 90 Tage, die sich so als ein Standard mal entwickelt hat. Aber jetzt in diesem Sonderfall, wenn Kundendaten, also Personendaten betroffen sind, kann man jetzt nicht sagen: Hier, in 3 Monaten muss das aber weg sein. Ja? Du du du! Also da, ich denke, dass man das so von Fall zu Fall ein bisschen anhand der Dringlichkeit entscheidet und die Antwort, die man ja eigentlich haben möchte ist, das es halt schneller gefixt ist, als man jetzt überhaupt bereit wäre zu veröffentlichen. Wenn das nicht der Fall ist, dann kann man ja schon sagen: Ok, passt auf, so in ein paar Minuten muss es und dann und dann muss das weg sein. Aber auf jeden Fall kann man ja eigentlich erst veröffentlichen, wenn es gefixt ist, weil sonst würde ja die Veröffentlichung quasi anderen den Zugriff auf diese Daten erklären. Das ist halt besonders dieser Sonderfall, betroffene Kundendaten, den ihr ja sehr viel behandelt. Lil: Ganz genau. Also was bei uns immer so der allerwichtigste Zeitmaß ist, dass wir immer versuchen, nachdem wir den Report fertig haben, innerhalb von 48 Stunden eine Rückmeldung vom Unternehmen zu haben, in Sonderfällen sogar noch deutlich schneller. Und dann hängt das halt ein bisschen vom Fall und vom Unternehmen ab. Aber ja, es sollte sehr, sehr, sehr zügig gehen. Genau. K: Aber man sollte den Unternehmen natürlich trotzdem auch irgendwie die Möglichkeit geben, zumindest sinnvoll reagieren zu können. Also irgendwie 12 Stunden ist ein bisschen sehr kurz, von irgendwie einer Meldung bis zu einer Veröffentlichung. Aber wenn man jetzt mit einem Unternehmen spricht, ist hier die nächste Frage: F: Was macht man, wenn die Betreiber:Innen einer Software das Ganze bagatellisieren wollen und z. B. gegenüber der Presse sowas runter reden? Linus, du hast ja mit Presse viel Erfahrung. Lin: Das machen die ja immer. Also nicht ein einziges Mal habe ich jetzt irgendwas erlebt, wo nicht zumindest in irgendeiner Form versucht wird, das noch so ein bisschen runter zu spielen. Lilith, du sagtest ja gerade schon, das war ja nur für einen kurzen Moment von 2 Monaten war die API offen oder ein kleiner Teil wurde zugegriffen. Das ist so die Lieblingsausrede. Ja, wir haben 5 Millionen Kundendaten ins Feuer gestellt, aber zerforschung hat nur 23 abgegriffen oder so. Und deswegen müssen wir jetzt z. B. auch den Betroffenen das nicht melden. Also eine Bagatellisierung in irgendeiner Form kommt immer. Und es ist ja auch gewissermaßen verständlich, dass Sie auch natürlich den Trost, den tröstenden Teil dazu spenden wollen. Ich finde, es ist schon ok. Schlimm finde ich, wenn es halt irgendwie so negiert wird oder die, die Meldende halt in irgendeiner Form angegriffen wird, ja. Also das die sagen: "Das ist alles nicht so schlimm. Wir haben die Situation unter Kontrolle. Hier gibt es nichts mehr zu sehen", das ist klar und das, finde ich, sollte man ihnen auch nicht übel nehmen. Was sollen sie sonst machen? Aber wenn sie jetzt irgendwie persönlich werden oder sagen: "Ja, die Meldefrist war zu kurz" oder was in diesem Jahr waren wirklich echt viele Vorwürfe, oder? Lil: Also genau für uns hat es sich halt auch so bewährt zu schauen, dass man einen professionellen Medienpartner für die Veröffentlichung der Sicherheitslücke findet, weil wir dann ein bisschen besser das Narrativ für uns auch kontrollieren können. Das wir halt sagen können: Ja, da wird auch, da wird auf jeden Fall die unsere Seite der ganzen Story nochmal erzählt vs das Unternehmen haut eine Pressemitteilung raus und sagt dann euch lieb Dankeschön. Im besten Fall, im schlimmsten Fall zeigen sie euch vielleicht an oder so. Genau, aber haben da das Narrativ völlig inne. Also es ist irgendwie, für uns ist es ganz wichtig, immer einen Weg zu finden, dass wir das so ein bisschen haben. K: Da du gerade schon von Partner:Innen in solchen Verfahren sprichst, kommt hier die Frage nach den Datenschutzbehörden und was unsere Erfahrungen in der Zusammenarbeit mit Datenschutzbehörden sind. F: Wenn wir denen etwas melden, scheinen die kompetent, tun sie ausreichend viel? Lil: Die haben halt einen begrenzten Spielraum in Deutschland. Also so eine Datenschutzbehörde, die kann nicht unbegrenzt viel machen, die kann nicht einfach beim 1. Verstoß einfach so sagen: "Wir erheben jetzt ein sehr hohes Bußgeld", da sind die relativ eingeschränkt und da wird relativ viel Druck auf die auch ausgeübt aus Politik und Wirtschaft usw. und so fort. Deswegen haben die immer so einen relativ begrenzten Spielraum. Auf dieser Arbeitsebene mit den Datenschutzbehörden zusammenzuarbeiten, läuft bei uns im Kollektiv eigentlich immer super gut. Also wir haben da ein sehr gutes Verhältnis und die sind immer nett, die freuen sich über unsere Meldungen. Manchmal helfen wir denen, die nachzuvollziehen. Und dann beginnt bei denen halt ein Prozess. Aber so rein rechtlich kann euch eine Datenschutzbehörde in diesem Prozess nicht immer informieren. Also ihr gebt da als Forscherin was rein und dann passiert irgendwas und vielleicht gibt es irgendwann eine Pressemitteilung. Leider kommt das wirklich, wirklich selten vor, dass ein Unternehmen danach auch eine Strafe bekommt. Z. B. die also der Datenschutz schaut manchmal ein bisschen genauer dann hin bei diesem Unternehmen und kümmert sich drum, dass die Lücke wirklich geschlossen wird. Strafen sind leider relativ selten. Lin: Ganz kurz, weil, ich höre da so ein leichtes Missverständnis aus der Frage heraus. Es gibt halt IT-Sicherheit und Datenschutz. Und Datenschutz ist erstmal ja nur ein rechtliches Gefüge. Also nur weil du eine Sicherheitslücke hast, heißt es nicht notwendigerweise das du jetzt einen Datenschutzverstoß hast. Du hast den dann, wenn du die zu spät meldest, wenn du die Leute nicht informiert oder oder oder. Oder wenn z. B. im Rahmen der Sicherheitslücke klar wird, dass du da Daten auf dem Server hast, die da nach Löschfristen gar nicht mehr sein dürfen, ja solche Dinge. Das ist dann das, das berührt dann das juristische Gefüge Datenschutz und dann können die auch sofort was machen. Aber nur bei einer Sicherheitslücke ist es halt so na ja, die, also die kommen ja auch häufig vor und das ist halt ich glaube, es ist auch sinnvoll, dass sie jetzt nicht jedes Unternehmen, das eine Sicherheitslücke hat, unmittelbar halt datenschutzrechtliche Probleme hat, aber trotzdem finde ich das genau sinnvoll, das zu melden, weil dann sind die schon mal aktenkundig ja. Und wenn das nächste Mal wieder etwas passiert, dann wird da sicherlich auch von Seiten der datenschutzrechtlichen Perspektive ein bisschen mehr Aufmerksamkeit draufgelegt. Aber am Ende geht es darum: Die Sicherheitslücke muss weg. Und ja, solange es keine Hinweise gibt, dass die Daten wirklich gestohlen wurden oder irgendwelche Fahrlässigkeit in besonderem Maße da war, machen die Datenschutzbehörden halt verhältnismäßig wenig beim ersten Vorfall und ich würde sagen das ist wahrscheinlich auch schon richtig so. K: Naja wir würden uns, also wir als zerforschung, würden uns glaube ich wünschen, dass die Datenschutzbehörden ein bisschen proaktiver sind. Das hören wir auch teilweise aus Datenschutzkreisen sozusagen, dass die Datenschutzbehörden eigentlich viel mehr machen wollen. Die wollen eigentlich auch proaktiv auf Unternehmen zugehen und ich meine viele der Sachen, die wir gefunden haben, das ist jetzt nicht die mega krasse Sicherheitslücke so. Das ist nicht hier irgendwie so eine NSO Lücke, die wahrscheinlich kaum jemand im Raum hier richtig versteht, sondern es sind oft Sachen, die relativ easy findbar sind, aber da haben die einfach nicht genug Ressourcen. Also wenn für Gesundheitsdaten in Berlin irgendwie weniger als eine Handvoll Leute zuständig sind, dann können die halt nicht alle Corona-Testzentren überprüfen. Und deshalb fordern wir natürlich auch, dass die irgendwie besser ausgestattet werden und diese Möglichkeiten auch bekommen, die sie rein rechtlich schon lange haben. Lin: Im medizinischen Bereich finde ich es absolut, ist es auch. Ich war jetzt auch bei der CDU connect App. Ja ich meine, da wird jetzt nicht irgendein Datenschutz großartig rumstehen und sagen: "Du hast da irgendwie eine App..." Wobei ich glaube, dass die sogar datenschutzrechtlich nicht in Ordnung war, oder? Lil: Ja die war datenschutzrechtlich tatsächlich nicht in Ordnung, weil da politische Meinungen von Menschen erfasst wurden. Und das Spannende im Fall von der CDU war, ist ja, dass implizit darüber politische Meinungen, also Artikel 9 DSGVO Daten, also besonders schützenswerte Datenpunkte sogar, erfasst waren. Lin: Ohne das die Erfassten das wussten. Lil: Genau. Und deswegen ist das schon wieder so ein sehr interessanter Fall für den Datenschutz. Also wo ich neben Gesundheitsdaten, würde ich halt sagen, für sämtliche Datenarten, die unter Artikel 9 fallen, sollten halt auch besondere Schutzmaßnahmen und besondere Prüfmaßnahmen von Datenschutzbehörden gelten. K: Das gibt die DSGVO ja eigentlich auch her. Lil: Richtig. K: Aber dann würde ich mal, eh wir jetzt in so ein Kleinklein mit Datenschutzbehörden abdriften... Lin: Also immer mit dazunehmen und nicht traurig sein wenn da jetzt nicht eine Millionenstrafe bei rumkommt, würde ich als Fazit…ja oder? Lil: Ja. K: Genau, aber super oft werden sie halt aktiv, das haben wir jetzt auch erlebt, und gehen da zumindest auf die Unternehmen zu. Und dann lernen die Unternehmen was und verhindern solche Fehler oft. In Zukunft. Lil: Und gerade wenn es größere Probleme sind, dann besucht die Datenschutzbehörde auch mal das Unternehmen und dann sind die da wirklich dahinter, dass die Lücken geschlossen werden. Und deswegen der Datenschutz ist immer ein guter Partner, aber erwartet nicht, dass ihr das entweder mitbekommt oder das da sofort irgendwas super krasses passiert. K: Die nächste ist eine rechtliche Frage, die wir, glaube ich, auf der rechtlichen Ebene nicht beantworten können. Aber ich finde die Frage trotzdem spannend. F: Darf man Probleme, die man jetzt gefunden hat, an kompetentere Person überhaupt weitergeben? Also ist es ist es ok? Ich würde das mal von der rechtlichen Ebene nehmen und mehr auf die moralische Ebene schauen. Ist das ok z. B. auf den CCC zuzugehen und zu sagen: Ok, hier gibt es dieses Problem. Ich habe das jetzt gefunden. Wie können wir das sauber lösen? Lin: Ich habe da, guck mal, ich vergesse das immer wieder. Da gibt es doch diesen, vor allem, wenn das jetzt irgendwelche Daten sind, da gibt es diesen Paragrafen. Wie gesagt, wir sind alle keine Juristinnen. Wo du jetzt die erste Person, die Kenntnis erlangt, ist quasi straffrei. Aber wenn sie es dann weitergibt, dann ist diese Weitergabe irgendwie strafbelastet. Aber wir reden ja hier nicht davon, dass man sich strafbar macht. Und wenn wem man, welcher anderen Person man das weitergibt, um die Frage vielleicht vorsichtig zu beantworten, ist ja dabei entscheidend ja. Also man kann nicht sagen, es ist grundsätzlich falsch, das jemand anderem weiterzugeben, aber wenn jemand anderem weitergeben in diesem Fall heißt twittern und von vielen tausend Leuten weitergeben, dann ist das ein Problem. Wenn man jetzt z. B. sagt – das passiert jetzt bei disclosure@ccc.de sehr häufig – dass Leute irgendwie sagen: Ja, ich habe das und das gefunden, und ich würde sagen, 50% meiner Fälle ist mal der Fall, ist meine Antwort: Ok, du musst mir das vollständig beschreiben, damit ich nachvollziehen kann und beurteilen kann. Wenn du, wenn du einfach nur irgendwas schreibst, kann ich dir nichts dazu sagen und das melde ich auch so nicht. Dafür muss ich natürlich dann die komplette Sicherheitslücke mitgeteilt bekommen und werde die dann auch prüfen. Und würde ich dann jetzt damit Mist machen, wäre das sicherlich für mich schlecht und für die Person, die mir das mitgeteilt hat schlecht. Insofern glaube ich, beantwortet sich diese Frage am sinnvollsten, das man halt überlegt: Ok, vertraut ihr der Person, dass die nach den gleichen ethischen Maßstäben arbeiten wird, wie ihr? Und dann kann man sich ja, dann seid ihr quasi eine Einheit und dann würde ich das nicht als juristisch riskant sehen. Lil: Genau. Vielleicht noch eine kleine Anmerkung dazu: Bei zerforschung haben wir in der Zusammenarbeit mit Datenschutzbehörden jetzt auch schon erlebt, dass wir Lücken gemeldet haben und Unternehmen und die Datenschutzbehörden gesagt haben, es gab keine Datenabfluss, weil wir als zerforschung eine vertrauenswürdige Instanz sind, was ein bisschen witzig ist, weil wir haben einerseits diese Kriminalisierung in Deutschland, andererseits haben wir Sicherheitslücken gefunden und man weiß ja häufig nicht, ob zuvor irgendwie schon Daten abgeflossen sind, bevor wir diese Lücke gefunden haben usw. und so fort. Aber zumindest so in der gelebten Datenschutzpraxis, also auch selbst von dieser Perspektive bemessen, nicht von Hackerparagrafen und Co. kommen, haben wir jetzt irgendwie schon gesehen, dass zumindest man Sicherheitsforscher:Innen auf in der gelebten Praxis schon so vertraut, dass die Leute das jetzt da nicht so super problematisch finden. K: Aber da muss man halt auch super aufpassen. Lil: Ja. K: Also ich glaube, diesen Vertrauensvorschuss sozusagen kriegt nicht jede Person, die jetzt zum 1. Mal da irgendwie in Erscheinung tritt. Deshalb wie wir schon sagten, lieber irgendwie Hilfe suchen, lieber irgendwie kompetentere oder erfahrenere, kompetent sind wir ja alle, aber erfahrenere Person fragen eben, z. B. Linus oder auch uns, wenn ihr das gerne wollt. Und ich glaube, da das jetzt so die rechtliche Frage ist, können wir da nur unsere übliche rechtliche Forderung nochmal anschließen, nämlich der Hacker:Innenparagraf muss weg! Zumindest in der jetzigen Form. Der muss so formuliert werden, dass so IT- Sicherheitsforschung, wie wir sie alle tun, legal möglich ist und man nicht immer Angst haben muss, dass plötzlich die Bullen vor der Tür stehen. Oder man eine Strafanzeige bekommt. Lin: Das muss man ja vielleicht auch nochmal kurz sagen: So nach meiner Kenntnis – ich muss jetzt wirklich überlegen – aber mir ist kein Fall bekannt, wo jetzt mal jemand wirklich verurteilt worden wäre, die man nicht hätte verurteilen sollen, ja. Aber das mit diesen Strafanzeigen ist halt deswegen so ein Nerv, weil die euch die Computer wegnehmen, weil ihr dann da jahrelang Ärger mit habt, weil der Anwaltskosten, also Kosten für die juristische Auseinandersetzung, anfallen. Und das ist einfach total nervig, wenn die irgendwie in die Wohnung kommen, wenn man die nicht eingeladen hat ja. Und deswegen ist das jetzt wenn das am Ende nicht zu einer Verurteilung kommt, ist das halt ein riesiger Nerv einfach und deswegen macht das halt Sinn teilweise einfach mit dem CCC z. B. gemeinsam das zu machen oder als CCC, weil irgendwie glaube ich, dass sich inzwischen zumindest so ein bisschen rumgesprochen hat, dass man eine Hausdurchsuchung beim CCC schwierig, schwierig. K: Ja, ich glaube, dann haben wir diese Frage wirklich sehr ausführlich beantwortet. Hier ist noch die Frage, ob wir, ob wir von Fällen wissen, die wir gemeldet haben und bei denen es, wo die Datenschutzbehörden an Strafen oder Ähnliches verhangen haben? A: Ich kann jetzt aus der zerforschungspraxis sagen: Uns ist nichts bekannt. Aber uns ist auch bei denen, bei vielen Fällen nicht bekannt, wie das Verfahren bei den Datenschutzbehörden am Ende ausgegangen ist. Denn das ist halt so ein Problem. Du hast, wenn du eine Beschwerde erstattest, als Einzelperson, die betroffen ist, dann hast du weitgehende Auskunftsrechte, dann sagt die Datenschutzbehörde dir auch weiter Bescheid, wenn wir das als Kollektiv tun, hingegen nicht. D.h., eigentlich müsste dann irgendeine Person die diesen Dienst nutzt, nochmal gleichzeitig als Privatperson sozusagen da eine Beschwerde erstatten, wo dann auch unter Umständen wieder Informationen an Unternehmen weitergegeben werden können usw. Das ist super komplex und schwierig und ich glaube, am Ende ist der beste Weg, ein Haufen IFG-Anfragen zu stellen. Lin: Oder ihr macht halt einen öffentlichen Aufruf: "Wir haben da wieder ein Datenleck. Wir brauchen jemanden, der da drin ist! Könnt ihr da mal schnell einen Account machen?" K: Das haben wir ja auch schonmal gemacht. In dem Artikel, wo das Unternehmen nicht richtig reagiert hat. Da haben wir, da war dann die Telefonnummer bei uns im Blog veröffentlicht und da haben auch Leute anrufen und erreichten die dann den, was war es, den Geschäftsführer, der gerade in der Autowaschanlage stand und überhaupt nicht wusste, worum es gerade geht und so Geschichten. Lachen Ja, aber ich glaube, das sind auch schon alle Fragen, die jetzt in diesem Pad gelandet sind. Und da ich da keine Veränderung mehr sehe, würde ich sagen: It's a wrap, so. Vielen Dank Linus, dass du hier warst! Lin: Ich danke euch! K: Und diesen Quatsch mit uns gemacht hast. Lin: Ja, war doch ein sehr schöner Vortrag. Hat mir sehr gefallen. Ich fand es. Ich habe mir immer gewünscht, dass beim rC3 die Vorträge vorproduziert sind Lachen Lin: Und ich finde das super, wie ihr das gemacht habt! rC3 nowhere Abschlussmusik Untertitel erstellt von c3subtitles.de im Jahr 2022. Mach mit und hilf uns!