Archiv

Posts Tagged ‘datenbank’

Einschätzung des SCHUFA-Hacks

2011-06-13 10 Kommentare

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).

Werbeanzeigen

Wahlstatistiken, nicht anonym – dank Wahlcomputern?

2007-11-15 17 Kommentare

Wozu sich Wahlcomputer noch einsetzen lassen, hat Venezuela eindrucksvoll gezeigt. Vermutlich mithilfe von Wahlcomputern wurde das Wahlgeheimnis nicht nur völlig abgeschafft, sondern auch direkt eine Datenbank über die Wahlentscheidungen aller Wähler angelegt, sodass Chavez weiß, wer ihn abwählen wollte. Ergänzung: Soweit ich weiß wurde die Liste noch ergänzt mit der Liste der Teilnehmer an der Petition für einen Rücktritt, enthält aber auch das Abstimmungsverhalten bei angeblich geheimen Wahlen. In der direkten Datenbank konnte ich diese Angaben nicht finden, allerdings gibt es noch eine große, offenbar in meiner Version defekte Datenbankdatei. UPDATE: Ich habe keine verlässliche Quelle dafür gefunden, dass außer der Unterschriftenliste bei der Petition, die Chavez‘ Rücktritt forderte, auch noch die Wahlergebnisse von Wahlcomputern verwendet wurden – damit ist die Vermutung zwar noch nicht widerlegt, aber von einer gesicherten Annahme kann man nicht mehr sprechen. Es bleibt auf jeden Fall trotzdem eine komplette Liste mit Adressen und IDs politischer Gegner, und die Befürchtung in der Bevölkerung, dass Wahlcomputer für die Erstellung solcher Listen eingesetzt werden (dazu siehe unten). Und damit der Spaß vollkommen ist, ist diese Datenbank inzwischen auch in diverse Filesharingnetze gelangt, ist also völlig öffentlich. Wie so eine Datenbank missbraucht werden kann und in diesem Fall auch wurde, ist ja wohl offensichtlich:

Many people have complained about the existence of a list, compiled by chavista assemblyman Luis Tascon with a group of collaborators, that is widely utilised by government officials at all institutional levels to deny passports, contracts, IDs, employments, benefits, etc.

Immerhin haben die Schlägertrupps jetzt eine äußerst hochwertige Liste aller Personen, die „überzeugt“ werden müssen, das nächste Mal „richtig“ zu wählen. Mit Adressen. Übrigens gibt es in der Datenbank ein Ja/Nein-Datenfeld „Oppositor“ (frei übersetzt: politischer Gegner) damit man Personen der „falschen“ Meinung richtig schnell findet.

Die Screenshots lassen einem kalte Schauer über den Rücken laufen. Wenn einfach dagegen protestiert wird, dass alle Bürger mit Identifikationsnummern versehen werden sollen, ist das ein abstraktes, unverständliches Etwas, was einen nicht unbedingt wirklich stört. Wenn man sowas aber mal im Einsatz sieht („Hiermit authorisiere ich Herrn Luis Tascón Gutierréz, Identifikationsnummer 9.239.964, …“), in Verbindung mit derartig großen Zahlen, begreift man erst, was so ein System bedeutet. Vor allem, wenn irgendwann eine Liste „unerwünschter“ Personen angelegt wird, die bei jeder Gelegenheit anhand ihrer Nummer schikaniert werden. Am Beunruhigendsten finde ich: Wenn so eine Datenbank in 10 Jahren in Deutschland erstellt wird, werden Fotos und Fingerabdrücke auch gleich mit dabei sein.

Das Ganze soll übrigens mit der Verfassung und den sonstigen Gesetzen Venezuelas völlig konform sein. Es ist nicht schwer, auch die besten und demokratischsten Gesetze durch „richtige“ Auslegung weit genug zu dehnen, um fast jeden Unsinn zu legitimieren, undemokratische oder nicht gegen sowas gesicherte Gesetze machen es nur leichter und unauffälliger. Offiziell dient die Datensammlung übrigens unter anderem dazu, den Zugang zu Informationen zu demokratisieren und Wahlbetrug zu vermeiden! (Jeder Wähler soll überprüfen können, ob nicht jemand in seinem Namen unterschrieben hat – dafür würde aber auch die Identifikationsnummer allein reichen.)

Die Präsentation, mit der für die Wahlcomputer geworben wird, sieht aus wie von Grundschülern gemacht (unscharfe Logos, dutzende verschiedener Schriften – größtenteils wohl versehentlich, massig Clip-Arts, vermutlich alle Animationen die Powerpoint zu bieten hat, usw.) und ist überall mit dem Logo der Kampange versehen, mit der direkt für den Machterhalt von Chavez geworben wird – eine recht klare Aussage über die Neutralität der Verantwortlichen. Die Wahlcomputer hatten eine „voter-verified paper audit trail“, d. h. zu jeder Stimme gab es einen gedruckten Zettel, den der Wähler prüfen konnte. Das erschwert Wahlbetrug immens (ohne diese Maßnahme reicht eine manipulierte Software, was äußerst einfach ist) – die Wahl wird quasi auf eine Papierwahl zurückgeführt. Wenn die Papierstimmen dann auch wirklich gezählt werden, ist jeder Vorteil der Computerwahl verloren – aber auch die meisten Nachteile verschwinden. Betrogen wurde in Venezuela (EDIT: ob da betrogen wurde, weiß ich nicht) wird bei dieser Methode dann eben nach dem klassischen Schema, die Urnen mit den Zetteln wurden werden dabei dann verschwunden, ausgetauscht oder falsch gezählt. Zahlreiche „fortschrittliche“ Länder der 1. Welt, die Wahlcomputer einsetzen oder einsetzen wollen, verzichten übrigens auf Papier-Protokolle.

UPDATE: Ich hatte nicht damit gerechnet, dass der Artikel so eine Aufmerksamkeit erregt, weswegen ich mir nicht besonders viel Mühe gegeben habe, alle Quellen zu verifizieren und anzugeben (da ich noch anderes zu tun habe und Quellen zu dem Thema schon schwer genug zu finden sind). Übrigens ist das Ganze wohl schon ein paar Jahre her, es ist nur erst jetzt hier in Deutschland bekannt geworden. Auf das Thema gestoßen bin ich über einen Hinweis in Fefes Blog. Dort gibt es einen Link auf eine Seite, die einen Überblick über die Liste und die dazugehörige Software gibt. Im eDonkey-Netz gibt es einige Archive, die die Datenbank enthalten. Es kann wohl davon ausgegangen werden, dass es mindestens die auf den Referendumsunterschriften basierende Liste gibt. In den Kommentaren zu einem Artikel, der die paper-trails lobt, steht:

by Anonymous Coward on Nov 28th, 2006 @ 6:46pm

I’m sorry, but as a Venezuelan I would like to express a completely opposite point of view.

[…]

In our last elections, our Referendum, where we voted ‚Yes‘ or ‚No‘ if we wanted the candidate to leave, we also had a paper trail. BUT, some of the boxes ‚magically‘ disappeared when they were brought back to our capital city. And the rest, even though we asked that they would be fully counted, to verify the results, not a single box was opened.

Another thing I would like to mention, and I would like you to keep in mind the right to a secret vote. Here, in Venezuela, you can buy a Data-DVD called ‚Maisanta‘. This is a database containing most of the voter’s Name, I.D. and who they voted for in this election. Something similar also ocurred in the previous election, although the database wasn’t ‚leaked‘ as far as this one.

Die letzten zwei Sätze behaupten, dass die Ergebnisse mehrerer Wahlen in der Datenbank enthalten sind. Von verschwundenen Wahlurnen ist übrigens auch die Rede. Ja, dabei handelt es sich nur um einen unverifizierten anonymen Kommentar. Da ich trotz Suche keine weiteren brauchbaren Quellen gefunden habe, kann ich nur sagen, dass es zumindest nicht belegt ist, dass Wahldaten genutzt wurden, man davon also nicht definitiv davon ausgehen kann. Ein brauchbarer Beweis wäre wohl eine Kopie der Datenbank, die diese Angaben enthält. Es kann durchaus sein, dass ich mich geirrt habe, da ich – nach Lektüre des Artikels auf Fefes Blog davon ausgehend, dass die Daten von Wahlcomputern standen – übersehen hab, dass das nicht wirklich durch auch nur halbwegs verlässliche Quellen belegt ist. Die Überschrift hat deswegen ein Fragezeichen bekommen und ich habe den ersten Absatz ergänzt.

Die Zuordnung einer abgegebenen Stimme zu einem Wähler könnte z. B. geschehen, indem der Wahlcomputer die Stimme nochmal irgendwohin spiegelt und der Wahlbeamte die Identifikationsnummer des Wählers vorher irgendwo eingegeben/ausgewählt hat, z. B. im Rahmen der Überprüfung, ob der Wähler nicht schon gewählt hat. Die Fingerabdruck-Scanner, die diese Überprüfung sicherer machen sollten, wurden aus Angst vor einem solchen Angriff schließlich um- oder abgebaut. Aufgrund der mangelnden Überprüfbarkeit von Wahlcomputern können solche Angriffe nie zweifelsfrei ausgeschlossen werden. Außerdem habe ich irgendwo (ich weiß dass das keine gute Quellenangabe ist, hat jemand einen Link?) gelesen, dass ein Fehler in den Wahlcomputern behoben wurde, der sich auf das Wahlgeheimnis ausgewirkt hat, sodass klar sein dürfte, dass sowas möglich ist. Offenbar sind Befürchtungen bezüglich des Wahlgeheimnisses (insbesondere aufgrund der aus den Referendumsunterschriften entstandenen „Schikanierlisten“) in der Bevölkerung verbreitet – allein das reicht aus, um das Ergebniss zu beeinflussen (wenn man nicht weiß, ob man beobachtet wird, geht man teilweise sicherheitshalber davon aus, dass es der Fall ist, und traut sich nicht, seine Meinung zu äußern).

Noch ein Hinweis am Rande: An der Diskussion/Schlammschlacht, ob in Venezuela eine Demokratie oder eine Diktatur herrscht bzw. ob die Wahlen tatsächlich gefälscht wurden oder nicht möchte ich mich nicht beteiligen, da solche Sachen wohl nie abschließend geklärt werden können und nur zu ewig langen Flamewars führen. Hier geht es nur um das Beispiel für die „kreative“ Nutzung von Bevölkerungsdatenbanken, ID-Nummern und evtl. Wahlcomputern.

Informationen/Quellen etc. sind immer willkommen!