Deine Software, die Sicherheitslücken und ich

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 [e-mail].
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 [e-mail]
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 [e-mail]

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

[e-mail] 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!