Datenschutz an einer Hamburger Schule

Alexander Bondar, 31. August 2012

Während insbesondere die Hamburger Datenschützer vorgeben sich um die Belange der unachtsamen Erwachsenen und leichtsinnigen Jugendlichen zu kümmern, interessiert es sie wohl in keiner Weise, was vor ihren Haustüren vor sich geht: wie eine Hamburger Schule die internen Daten beinahe schutzlos ins Internet stellen. Denn es macht durchaus einen Unterschied, ob man freiwillig sich bei Facebook anmeldet, möglichst viel dort preisgibt und während man eingeloggt ist im Internet sucht; oder aber man wird vom eigenen Lehrer dazu gezwungen, mit persönlichen Daten auf einem Internetportal angemeldet zu sein, um dessen Sicherheit sich niemand ernsthaft Gedanken gemacht hat.

Als ich zufällig auf die Seite gestoßen bin, war ich beeindruckt. Beeindruckt von der laienhaften Aufmachung der „Lernplattform“.

Eine typische URL hatte die Form „/index.php?eineSeite“. Zunächst kam mir in den Sinn, dass man damit jede beliebige Seite einbinden könnte. Ohne die Dateistuktur zu kennen war es mir dann doch zu mühselig zu erraten, welche Daten wie auf dem Server abgelegt wurden. Mit ausreichend viel Langeweile und Durchhaltevermögen wird man sicherlich alles einbinden können.

Beim Durchprobieren der URLs bekam ich bei beinahe jeder Seite die Aufforderung, sich einzuloggen. Da man es von mir wollte, habe ich ein paar Dinge ausprobiert, die nicht funktionierten. So langsam habe ich naiverweise angefangen zu glauben, dass man sich hier um seine Schüler sorgt.

Ich wollte noch kurz sicher gehen, dass die Seite gegen SQL-Injections angesichert ist. Und siehe da, der Server meldet einen Fehler in der Syntax. Und das anstatt zu sagen, dass die Zugangsdaten falsch sind.

Die Faulheit siegte, also googelte ich kurz, wie eine SQL-Injection aussieht. Gleich auf der ersten Seite stand die hilfreiche Zeichenfolge:

nix' OR 'da'='da

Das als Passwort eingegeben, und schon war ich drin.

Da ich keinen gültigen Benutzernamen eingegeben habe (ich kannte ja noch keinen), hat man mir einfach einen erstbesten Account gegeben. Einen Super-Admin-Account.

Mit diesem Account konnte ich praktischerweise mir anschauen, welche Accounts es sonst noch gibt und die gültigen Benutzernamen einsehen.

Ich wollte mich schon mit einem der Accounts einloggen und die Zeichenfolge von oben zur Legitimierung verwenden, als mir auffiel, dass die Eingabemasken der Benutzerverwaltung ein Feld zur Passworteinagabe bereitstellten. Man könnte den Inhalt mit Javascript auslesen, oder sehr praktisch in den Objekteingeschaften einsehen. Dort standen sie ja auch im Klartext.

Wenige Sekunden später hat mich das System als gültigen Benutzer begrüßt. Diesmal als Super-Admin mit Zugriff auf noch mehr Daten. Darunter Klassenlisten, Korrspondenz aus den letzten 12 Monaten, hochgeladene Dateien. Offenbar ist auch eine Möglichkeit vorgesehen, um Noten eintragen zu können. In dem jetzigen Zustand würde es mich nicht wundern, wenn ein Jahrgang plötzlich einen Schnitt von 1,0 hat…

Mal sehen, was als Reaktion auf die E-Mail an den Administrator und die Schulleitung kommt.

Update

Gemeinerweise schickte ich meine E-Mail an einem Freitagabend ab. Und am Wochenende macht die Sicherheit eine Pause genießen die Lehrer ihre wohlverdienten schülerfreien Tage. Gleich am Montag erreichte mich eine E-Mail des System-Administrators.

Die Hintergründe wurden ziemlich detailliert erklärt: das System ist alt, wurde zu PHP4-Zeiten entwickelt und man machte sich – wie damals üblich in den PHP-Kreisen – keine ernsthaften Gedanken um die Sicherheit. Zur Absicherung der SQL-Ausdrücke verließ man sich so auf die „magic_quotes_gpc“-Einstellungen der Servers.

Doch während eines Updates wurde die Option deaktiviert, sodass einer SQL-Injection nichts mehr im Wege stand.

Die Seite wurde sogleich offline genommen, die Einstellungen entsprechend angepasst und Passwörter neu angelegt.

Diese Vorgehensweise ist zwar löblich, aber beseitigt weder die Ursachen komplett, noch geht auf eine der wichtigsten Schwachstellen ein: die im Klartext gespeicherten Passwörter. So oft dies wiederholt wird oder sogar gewaltsam durchgesetzt wird: man verwendet bei sehr vielen Systemen dieselben Passwörter. Und alleine bedingt durch die Menge des Systeme, für die man sich die Zugangsdaten merken muss, verwendet man immer wieder (oder gar immer) dasgleiche Passwort.

Sollte also die Datenbank einmal erneut Unbefugten zur Verfügung stehen, so erhält der (dann vielleicht auch böswillige) Eindringling Zugang zu vielen anderen Systemen.

Update 2

Mit dem Wissen machte ich mich an Sicherheitstests an meinen eigenen Systemen. Erfreulicherweise ließ sich der Passwortschutz lediglich bei einem sechs Jahre alten System aushebeln. Und selbst das nur durch das Hintergrundwissen über den Aufbau der speziellen SQL-Abfrage. Alle anderen Systeme ließen sich mit meinem Wissen nicht umgehen.

Was mich selbst erfreute: die Passwörter lagen in meinen Datenbanken noch nie im Klartext vor. In den ersten Authentifizierungssyteme haben die Passwörter als Hash gespeichert, später kam ein „Salt“ hinzu, das anfangs recht kurz war, heute aber auf 32 Byte angewachsen ist.

Jetzt bleibt nur noch eine mehrfache Hash-Bildung, um das Erraten der Passwörter zu einer zeit- und kostenintensiver Aufgabe zu machen.