Einschätzung des SCHUFA-Hacks

Wie Gulli berichtet und die Piratenpartei kommentiert hat, wurde die SCHUFA gehackt (in den Kommentaren bei Gulli gibts/gab es Details). Zunächst betraf das „nur“ den Webserver. Die Lücke bestand laut Beschreibung im Gulli-Forum darin, dass das Skript, was Dateien wie Formulare zum Download ausgeliefert hat, den Download beliebiger Dateien von der Platte des Servers erlaubte. Da die eigentliche SCHUFA-Datenbank natürlich hoffentlich nicht auf diesem Webserver liegen dürfte, ist in der Theorie erstmal keine unmittelbare Gefahr gegeben, weil man über die Lücke ja „nur“ Dateien auf diesem Server herunterladen kann. Diese Position vertritt natürlich auch die SCHUFA, ein Datenleck zuzugeben wäre für ihr Geschäft nicht gerade förderlich.

Der Angreifer konnte also mehr oder weniger beliebige Dateien vom Server herunterladen. So ein Fehler in einer Webanwendung ist ein ziemlicher Anfängerfehler, der auf so einem kritischen Server eigentlich nicht passieren darf. (Das sieht der Experte der Tagesschau übrigens genauso.) Wie schon bei der kaputten SSL-Implementierung bei der AusweisApp sieht man, dass die Annahme „so doof können die nicht sein“ keine Garantie dafür ist, dass in einer kritischen Anwendung solche dummen Fehler wirklich nicht vorhanden sind. Dass es dem kaputten Skript wohl auch möglich war, auf Dateien außerhalb des eigentlichen Websiteverzeichnisses zuzugreifen, deutet außerdem darauf hin, dass mit der Rechte- und Benutzerkontenverwaltung auf dem Server auch eher „locker“ (lies: schlampig und ohne wirklich auf Sicherheit Wert zu legen) umgegangen wurde. Daran, dass für die Schufa Datenschutz und Datensicherheit „seit jeher eine hohe Priorität“ hätten, lässt es genauso zweifeln wie am Sicherheitszustand des restlichen Netzes bei der SCHUFA.

Das wird in dem Moment wichtig, wenn man sich klar macht, auf was für Daten mit der Lücke Zugriff möglich war: Der Server muss irgendwie auf die SCHUFA-Datenbank im Hintergrund zugreifen können. Natürlich wäre es möglich, dass hier irgendein ausgeklügeltes Verfahren genutzt wird, bei dem der Zugriff erst freigegeben wird, wenn der sichere Server am anderen Ende das Login des Kunden geprüft hat. Angesichts der oben genannten Punkte halte ich es jedoch für sehr unwahrscheinlich. Am Wahrscheinlichsten ist es, dass irgendwo auf dem gehackten Webserver die Zugangsdaten für die Datenbank im Klartext herumlagen und darüber die Datenbank ausgelesen werden kann. Ein Angreifer konnte diese Zugangsdaten höchstwahrscheinlich mit vertretbarem Aufwand (configdatei finden) bekommen.

Wenn die Schufa schlau genug war, den Datenbankserver hinter eine Firewall zu stellen (so blöd, es nicht zu tun, kann man eigentlich nicht sein, aber siehe oben), bringen diese Zugangsdaten dem Angreifer aber zunächst nichts, weil er sich zu dem Server gar nicht verbinden kann – das ist dann aber die letzte verbleibende Hürde. Gelingt es ihm, z. B. über vom Webserver geklaute Passwörter in den Webserver einzudringen, oder in einen beliebigen anderen Rechner im Netz der SCHUFA, der auch Zugriff auf den Datenbankserver hat (das könnte eingeschränkt sein – könnte…), kann er sich an der Datenbank bedienen. Vielleicht stehen da „nur“ die Daten der Leute an, die meineschufa.de nutzen, es ist aber mindestens genauso wahrscheinlich, dass der Angreifer sich dann beliebige SCHUFA-Datensätze anschauen und herunterladen kann. Solche Angriffe auf weniger gesicherte „unwichtige“ Rechner, um sie als Brücke ins Netz zu benutzen, sind üblich und bei vielen Angriffen wie z. B. dem auf Google beobachtet worden. Über weitere Angriffe mit dieser Lücke als Einstiegspunkt dürfte also vieles möglich sein.

Selbst wenn mehr Schutzmaßnahmen getroffen würden – wenn es einem Angreifer gelingen würde, den offensichtlich mies gesicherten Webserver komplett zu übernehmen, könnte er zumindest die darüber laufenden Daten abfangen, also die Daten derjenigen, die meineschufa.de nutzen, während der Angreifer Zugriff hat. Die Lücke wurde zwar als „Local file inclusion“ bezeichnet, da die Dateien aber scheinbar so wie sie auf der Platte lagen ausgeliefert wurden und PHP-Skripte nicht geparst wurden, würde ich eher von „Local file disclosure“ sprechen. Das ist insofern etwas weniger gefährlich, als über diese Lücke vermutlich wenigstens „nur“ Daten ausgelesen, aber keine Programme auf den Server geschleust werden können. Andere Lücken, die das (und damit die Übernahme des Servers) erlauben, könnten jedoch durchaus existieren.

Meiner Meinung nach kann man die Situation also folgendermaßen zusammenfassen:

  • Der Server wurde gehackt, das hat die SCHUFA bestätigt
  • Die Sicherheit lässt sehr zu wünschen übrig
  • Die SCHUFA-Daten konnten vermutlich nicht direkt ausgelesen werden, aber
  • ich halte es für wahrscheinlich, dass ein Angreifer mit etwas Mühe gute Chancen gehabt hat, auch an die SCHUFA-Daten selbst zu kommen.

Jetzt stellt sich natürlich die Frage: Was nun? Zunächst muss natürlich die Lücke selbst geschlossen werden. Indem die SCHUFA das kaputte Download-Skript gelöscht hat, ist diese Gefahr vorerst gebannt. Dann müssen auch alle potentiell betroffenen Zugangsdaten für die Datenbank und sonstige Server geändert werden – denn sonst könne ein Angreifer die vor kurzem gestohlenen Daten in ein paar Wochen, nachdem die eigentliche Lücke schon geschlossen ist, nutzen, um die Datenbank auszulesen. Hier müssen wir hoffen, dass die SCHUFA sich nicht die Mühe spart und darauf verzichtet, „weil man ja von außen eh nicht an die Datenbank drankommt“. Schließlich – und das ist der schwierigste Teil – muss anhand von Logs geprüft werden, ob die Lücke bereits missbraucht wurde, und wenn z. B. Zugangsdaten gestohlen wurden, ob diese missbraucht wurden. Ich bezweifle, dass es ausreichend weit zurückreichende Logs geben wird, um das für die Zeit seit Bestehen der Lücke ausschließen zu können. Somit dürfte nicht eindeutig zu klären sein, ob Daten geklaut wurden oder nicht. Ganz abgesehen davon muss die SCHUFA natürlich massiv an der Sicherheit ihrer Server arbeiten.

Eines muss man der SCHUFA (bisher) jedoch zugute halten: Sie hat soweit ich weiß nicht versucht oder gedroht, dem ehrlichen Hacker, der die Lücke gemeldet hat, irgendeine Form von Ärger zu machen. Das ist eigentlich eine Selbstverständlichkeit und liegt im Interesse der betroffenen Firma – ehrliche Hacker, die Lücken melden, helfen die Sicherheit zu verbessern. Würde eine Firma einen solchen Hacker bedrohen, werden andere dadurch a) wütend b) angesport weitere Lücken zu finden vor allem c) auf gefundene Lücken nicht hinweisen, sondern sie veröffentlichen oder nutzen um Schaden anzurichten – und das ganze natürlich so, dass sie nicht zurückverfolgt werden können. Leider kommen solche Drohungen immer noch viel zu oft vor.

Der Vorfall zeigt auch einige interessante Probleme auf:

Sicherheit kann nicht nachgerüstet werden. Die Sicherheit muss bereits bei der Entwicklung von Software bedacht werden – nachträgliche Tests und Überprüfungen sind sinnvoll, können das aber nicht ersetzen. Irgendwas wird immer übersehen. Hier haben die Entwickler offenbar nicht ausreichend über Sicherheit nachgedacht, als sie das Downloadsystem entwickelt haben. Das ist gerade in einem solchen sicherheitskritischen Bereich eigentlich völlig inakzeptabel.

Datenschutz lohnt sich nicht. Es gibt keine empfindlichen Strafen, wenn jemand Daten nicht ausreichend schützt. Natürlich ist es nicht gut für den Ruf und fürs Geschäft, wenn solche Lecks passieren, aber das scheint als Motivation nicht auszureichen. Würden für Datenlecks Strafen von ein paar Euro pro Datensatz drohen, wäre gerade bei große Datenbanken die Absicherung plötzlich finanziell sehr attraktiv.

In kritischen Bereichen wird massiv geschlampt. Selbst bei so kritischen Servern wie in diesem Fall bei der SCHUFA wird an der Sicherheit gespart und es werden grobe Fehler gemacht. Wie viele andere wichtige Systeme genauso schlecht gesichert sind? Hier sei exemplarisch nur auf SCADA verwiesen, die Industriesteueranlagen, die von der Chemiefabrik bis zum Atomkraftwerk alles Mögliche kontrollieren und meist auf völlig veralteter Software laufen, mit kaum vorhandenen Sicherheitsmaßnahmen (siehe Vortrag auf einem CCC-Kongress).

  1. 2011-06-13 um 09:14 UTC

    Nachdem ich davon erfahren habe, habe ich einfach eine Email an die Schufa geschrieben. Ich verwende dafür immer die Kontakt Email aus dem Impressum. Bisher haben die Schufa immer geantwortet.

    Würde jedem empfehlen auch nachzufragen. Dadurch wird allein durch den Bearbeitungsaufwand die Schufa hoffentlich animiert, sorgsamer mit den Daten umzugehen.

  2. 2011-06-13 um 14:13 UTC

    Gut geworden!

  3. jens heinrich
    2011-06-14 um 13:52 UTC

    Hallo Jan,
    die SCHUFA wurde nicht gehackt, sondern es wurde lediglich durch einen Sicherheitsberater aufgedeckt, dass eine Sicherheitslücke dort existiert. Golem.de, Heise.de und Winfuture.de haben korrekterweise im Artikel darüber berichtet und den Namen des Sicherheitsexperten genannt. Hier hat die Piratenpartei einen Fehler gemacht und spricht von einem Hack. Dies sollte hier fairerweise mit erwähnt werden – denn ein IT Sicherheitsberater als Hacker oder Angreifer abzustempeln, ist nicht sinnvoll.

    Siehe auch:
    http://www.heise.de/newsticker/meldung/Sicherheitsluecke-auf-Webserver-der-Schufa-1259383.html
    http://www.golem.de/1106/84154.html

    • Jan
      2011-06-14 um 22:48 UTC

      „Hacker“ bedeutet keineswegs einen böswilligen Angreifer, beim e-Perso spreche ich ja auch von einem Hack. Mit „Angreifer“ ist hier im Blog nicht der Entdecker der Lücke gemeint, sondern ein beliebiger Angreifer der die Lücke ausnutzen konnte. Angesichts der ausführlichen Gulli-Kommentare gehe ich davon aus, dass von der Möglichkeit, Dateien herunterzuladen, gleich einige Leute Gebrauch gemacht haben, da lagen nämlich AFAIK auch Dumps einer /etc/passwd rum bevor sie rauseditiert wurden.

      Bei der Piraten-PM ist das tatsächlich blöd formuliert – sorry dafür, da bin ich mit dran Schuld, an der hab ich nämlich mitgearbeitet. Formal ist natürlich der (gutwillgie) Hacker auf ein Angreifer, aber da sollte das nächste mal eine bessere Formulierung hin.

  4. 2011-06-16 um 08:50 UTC

    Jan, danke für deine Einschätzung!

  5. Hans
    2011-06-23 um 21:34 UTC

    Ich hätte eine Frage zu der Aussage: „Wenn die Schufa schlau genug war, den Datenbankserver hinter eine Firewall zu stellen …, bringen diese Zugangsdaten dem Angreifer aber zunächst nichts, weil er sich zu dem Server gar nicht verbinden kann“: Was genau soll die Firewall zwischen Webserver und Datenbank bringen? Wenn sich die Webapp mit den Zugangsdaten aus einer Configdatei zur Datenbank verbinden kann, dann kann dies auch der Angreifer (da er ja im Kontext der Webapp arbeitet).
    Ich bitte da um Aufklärung, da ich entweder die Aussage falsch interpretiere, oder der Angreifer über einen anderen Kanal als die Webapp ins System eingedrungen ist. Besten Dank

    • Jan
      2011-06-26 um 01:50 UTC

      Die Firewall wäre nicht zwischen Webapp und DB-Server sondern zwischen Internet und DB-Server, d.h. es könnte eben nur der Webapp-Server drauf. Der Angreifer kann mit der genannten Lücke zwar Daten vom Webapp-Server auslesen, aber nicht beliebigen Code drauf ausführen, er arbeitet also eben nicht im Kontext der Webapp. Er muss entweder vollständig in den Webapp-Server einbrechen, um diese Möglichkeit zu haben, oder einen anderen Weg finden, an den DB-Server zu kommen.

  1. 2011-06-16 um 17:03 UTC
  2. 2011-07-09 um 13:47 UTC
  3. 2012-08-11 um 18:26 UTC

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: