Stellt euch vor, ihr seht eine Haustür, die sperrangelweit offen steht. Also geht ihr rein und ruft durch das ganze Haus, dass die Tür offen ist und ob die nicht mal jemand zumachen kann. Ach was, ihr ruft nicht – ihr brüllt. Und trotzdem: Keine Antwort. Stattdessen stolpert ihr überall über aufgetürmte und aufgeschlagene Aktenordner mit Namen von drei Millionen Menschen, mit Fotos, Geburtsdaten, Wohnorten und Namen von Schulen oder Unis.

Klingt weit hergeholt? Ist uns aber genau so passiert – virtuell natürlich, in einer App. Dieser Blogpost erzählt von unserem kurzen Besuch bei der Lern-App StudySmarter.

Ende 2017 gegründet, entwickelt StudySmarter eine App für Schüler*innen und Studierende, die mit Lernkarten, Übungsaufgaben, etc. bei der Prüfungsvorbereitung helfen möchte.

Damit wurden sie sogar schon zu Europas bestem EdTech-Startup gekürt.

Wir wurden auf StudySmarter aufmerksam, als wir uns gerade eine andere App für die Back-To-School-Reihe angeschaut haben. Dort wurde uns Werbung für StudySmarter angezeigt. Und weil wir gerade schonmal bei dem Thema Lern- und Schulapps waren, installieren wir uns auch diese App. Wie bei den bisherigen Apps aktivieren wir zuallererst unseren Person-in-the-Middle-Proxy. Damit können wir sehen, wie die Kommunikation mit den Servern der App aussieht.

Ab in den Vorgarten und mitspielen

Wir öffnen also das virtuelle Gartentor, indem wir uns registrieren: Endlich mitspielen! In der App schauen wir uns um, tragen unsere Schule ein, und probieren ein paar Lernkarten und Übungsaufgaben aus.

Nachdem wir ein Nutzer*innen-Profil angelegt haben, sehen wir in unserem Person-in-the-Middle-Proxy den Datenverkehr zwischen App und Server. Dort steht, wie die App unser eigenes Profil abruft:

Hmmm, unsere Erfahrung sagt uns: Wo wir eine URL mit einer Nutzer*innen-Nummer darin sehen, bekommen wir häufig mehr Infos, wenn wir diese Nummer um eins herunterzählen¹ – allerdings nicht von unserem eigenen Account, sondern die unserer “Nachbarn”.

Hoppla, die Haustür ist ja offen!

Und tatsächlich: Auch diesmal bekommen wir das Profil einer anderen Person zu sehen.

Das sah in etwa so aus:²

{
  "id": 2981312,
  "tutorial": { ... },
  "tutorialwebapp": { ... },
  "settings": { ... },
  "user": {
    "first_name": "Alex",
    "last_name": "Mustermensch",
    "username": "alexmustermensch@bnd.bund.com",
    "email": "alexmustermensch@bnd.bund.com"
  },
  "university": "Anarchistisches Bildungs Centrum Neuland",
  "course_of_studies": "Bullshit-Bingo",
  "birthday": null,
  "is_premium": true,
  "user_type": "Referral",
  "last_notified": null,
  "community_username": null,
  "total_ects": 180,
  "planned_grade_remaining_studies": null,
  "studyfield": null,
  "studyfield_name": null,
  "is_professor": false,
  "is_pupil": true,
  "country": 227,
  "state": 2,
  "city": 192,
  "random_number": 0.5643164146823337,
  "email_confirmed": true,
  "semester": null,
  "cost_factor": "1.20",
  "tracking_number": 2342,
  ...
  "detected_country": 227,
  "returning_user": true,
  "token": "f2d897a2c477ad3e05a195786b8c4ca9e145e916",
  "state_name": "Berlin",
  "school_type_name": null
}

Wir konnten so die Stammdaten aller rund drei Millionen registrierten Nutzer*innen abrufen, also:

• Name
• E-Mail-Adresse
• Schule/Universität
• Studienrichtung
• Geburtsdatum
• Stadt, Bundesland, Land
• Profilbild
• ECTS-Punkte

Berge von Ordnern im ganzen Haus

In dem Moment, in dem wir realisieren, dass die virtuelle Haustür weit offen steht, sehen wir auch schon die riesigen Haufen von aufgeschlagenen und wild verstreuten Aktenordnern. Oder technisch gesprochen: In vielen Profilen standen private Daten – Namen etwa, oder Geburtsdaten. Bei einigen war zusätzlich noch ein ’token’ hinterlegt, also eine längere Zeichenkette aus Kombinationen von Buchstaben und Zahlen.

Relativ schnell sehen wir, dass es sich dabei um das Authentifizierungs-Token handelt. Mit dieser Zeichenkette teilt die App dem Server mit, welche*r Nutzer*in gerade eingeloggt ist. Eigentlich sollte diese Zeichenkette geheim sein und am besten gar nicht direkt in der Datenbank stehen – denn wer diese Zeichenkette kennt, kann sich als eine andere Person ausgeben.

Damit hätten wir alles machen können, was diese Nutzer*innen in der App tun dürfen: Wir könnten also zum Beispiel im Namen einer anderen Person Aufgaben erledigen³. Uns für neue Fächer registrieren. Oder eben alle Daten dieser Person abrufen, beispielsweise den Lernfortschritt – inklusive allen Details, wie eventuellen Lernschwächen.

“Hersteller, ihr habt ein Problem!”

Wir halten also fest: Es sind keine 10 Minuten vergangen, seit wir – bildlich gesprochen – gemütlich auf der Straße entlang geschlendert sind und zufällig eine Werbung gesehen haben. Die hat uns in den Garten gelockt, und dahinter haben wir eine sperrangelweit offene Haustür gefunden. Was also tun?

Wir zücken unsere Reiseschreibmaschine und beginnen mit der Dokumentation: Was haben wir vorgefunden und wieso ist das ein Problem. Diesen Bericht schicken wir an den Hersteller, die zuständige Landesdatenschutzbehörde und das CERT-Bund.

Von letzterem bekamen wir auch schnell eine Eingangsbestätigung – von den anderen jedoch: Nichts.

Wenn wir versuchen, ein Unternehmen wegen einer Sicherheitslücke zu kontaktieren, stehen wir immer wieder vor dem gleichen Problem: Wie erreichen wir die richtigen Leute im Unternehmen zeitnah und wie wird das Unternehmen reagieren – überflüssige Anzeigen gab es ja in diesem Jahr genug.

Gebt uns einen Notfall-Kontakt und lest eure Mails

Der einfachste Weg für uns ist eine security.txt-Datei, in der das Unternehmen einen Sicherheitskontakt und weitere nützliche Informationen veröffentlicht. Am besten sollten extra Postfächer für Schwachstellenmeldungen bereitgestellt und diese auch regelmäßig gelesen werden. Außerdem empfehlen wir sehr, dort auch regelmäßig in den Spam-Ordner zu schauen. Denn, oh Wunder, wenn wir E-Mails mit schädlich aussehendem Code schicken, ist es wenig überraschend, wenn diese tatsächlich im Spam-Ordner landen.

StudySmarter stellte uns gleich vor beide Hürden: Wir haben erstens keine direkte Kontakt-Mailadresse für IT-Schwachstellen gefunden. Und zweitens ist unsere Mail an den allgemeinen Kunden-Support und die Datenschutz-Stelle im Spam-Ordner gelandet.⁴

Nachdem wir also auch nach zwei Tagen nichts vom Hersteller gehört hatten und die Lücke nicht geschlossen war, probieren wir es auf anderem Wege. Nach langem Suchen auf der Website fanden wir eine Telefonnummer: nicht vom IT-Team, sondern vom Head of Sales. Diesen haben wir schließlich angerufen und er hat die Meldung dann aus dem Spam-Ordner rausgefischt und intern weitergeleitet.

Gehört, gesehen, geschlossen

Nachdem unsere Hinweise endlich die richtige Stelle beim Hersteller der App erreicht haben, hat StudySmarter die Lücke dann tatsächlich in weniger als einer Stunde geschlossen. Immerhin: Tür zu, Ordner weggesperrt, wir können aufatmen.

Außerdem hat StudySmarter direkt analysiert, wer auf die Daten zugegriffen hat und ein “Sicherheitsupdate” im Firmenblog veröffentlicht. Darüber haben wir uns dann gefreut. Immerhin!

Dieser Anbieter hat, nachdem er unsere Meldung entdeckt hat, also schnell reagiert und das Problem behoben. Das ist gut. Was allerdings nicht gut ist: Dass es zu solchen Konfigurationsfehlern überhaupt kommen kann. Der Fall von StudySmarter zeigt Versäumnisse im Entwicklungsprozess. Das hätten auch die Investor*innen vor dem 30 Mio. Investment im Rahmen ihrer Due Diligence überprüfen sollen.⁵

Security by Design

StudySmarter sagt selbst, dass sie kurz bevor die Lücke eingebaut wurde, einen Sicherheits-Audit der Software machen lassen haben. Das zeigt: Sicherheitsaudits alleine machen noch keine sichere Software. Für sichere Software müssen Entwicklungsprozesse so gestaltet werden, dass solche Fehler nicht auftreten.

Wir sagen stets: Wenn eine Software marktreif genug ist, um Kund*innen-Daten zu speichern, dann muss sie auch reif genug sein, diese für sich zu behalten. Doch das müssen die Prozesse eben auch dauerhaft sicherstellen.

Es hilft nicht, wenn StudySmarter einmal einen Sicherheitsaudit durchgeführt hat oder das von nun an monatlich tut. Wenn solche eklatanten Sicherheitslücken erst bei Audits gefunden werden, ist der Softwareentwicklungsprozess kaputt.

Um die Auswirkungen solcher Fehler zu minimieren, braucht man zusätzlich Konzepte, wie man so wenig wie möglich Daten speichert – denn Daten, die nicht gespeichert werden, können auch nicht abfließen.

🔎

All das fordert die DSGVO auch schon – es muss aber auch kontrolliert werden. Daher muss die Politik die Datenschutzbehörden besser ausstatten, personell und monetär. Dann können diese auch von sich aus nach solchen Lücken Ausschau halten und bei Verstößen angemessene Strafen verhängen.

📰

Wir veröffentlichen diese Lücke zusammen mit Zeit Online. Deren Artikel findet ihr hier