*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!