WeAct: Datenleck mitgeteilt, verursacht durch kläglich gescheiterten Datenschutzversuch
Vielleicht seid ihr einer von über 2 Millionen Nutzern der Plattform WeAct. Bei denen gab es nun ein Datenleck, über das der Anbieter informiert. Theoretischen Zugriff gab es etwa auf Namen, E-Mail-Adressen und die Postleitzahl von Nutzern, wie der Anbieter informiert. Die Daten stammen aus unterzeichneten Petitionen, wurden also von den Besitzern durchaus bewusst geteilt. Allerdings ist es so, dass jeder Petitonsersteller eben jene Liste herunterladen kann, was ja auch völlig richtig ist.
Problematisch in diesem Fall: Die Dateien waren nicht gestützt abgelegt. So konnte quasi jeder, der den Dateinamen kannte, solche Listen herunterladen. Laut WeAct gibt es keinen Hinweis darauf, dass dies auch geschehen ist. Das Problem sei behoben und man entschuldigt sich für die Panne. Die Information erfolgt übrigens nicht etwa, weil WeAct das so wichtig findet, sondern es wird direkt in der Einleitung betont, dass man nach Vorgaben der Datenschutzgrundverordnung zu dieser Information verpflichtet sei (und deshalb auch eine Mail an Leute schickt, die keinen weiteren Mails von der Plattform zugestimmt haben).
Witzigerwiese liefert WeAct auch den technischen Hintergrund der Panne mit, den man sich durchaus einmal auf der Zunge zergehen lassen kann. Die Sicherheit der Daten wurde nämlich aufs Spiel gesetzt, um – und jetzt kommt der echt schräge Teil an der Story – für mehr Datenschutz zu sorgen. Denn anstatt die Software – wie vorgesehen – auf Amazon Web Servern laufen zu lassen, hat man sie einfach auf eigene Server gepackt. Die Kompatibilität sollte eine Open-Source-Software übernehmen:
Zum “Design-Problem”:
Wer auf WeAct eine Petition startet, hat die Möglichkeit, sie an die Adressat*innen der Petition zu übergeben – etwa verantwortliche Politiker*innen oder Unternehmenschef*innen. So kann der jeweiligen politischen Forderung mehr Nachdruck verliehen werden. Jede*r Petitionsstarter*in kann sich hierfür die Liste mit den Namen und Postleitzahlen der Unterstützer*innen ihrer*seiner Petition als PDF-Datei herunterladen und gegebenenfalls ausdrucken.
Leider wurden diese Dateien auf dem WeAct-Server in einem Ordner abgelegt, auf den auch ohne Identifizierung zugegriffen werden konnte. Das bedeutet: Wer die exakte Bezeichnung dieser Dateien gekannt hätte, hätte auf sie zugreifen können – und herausfinden können, ob und welche Petition Sie unterzeichnet haben.
Zum “Kompatibilitäts-Problem”:
Die für WeAct eingesetzte Software wurde vom Hersteller ursprünglich dafür entwickelt, auf virtuellen Servern der Firma “Amazon” betrieben zu werden. Aus Gründen des Datenschutzes hatten wir uns aber dafür entschieden, die WeAct-Software nicht in der Amazon-Cloud, sondern lieber auf unseren eigenen Servern in einem deutschen Rechenzentrum zu betreiben. Dazu war eine Open-Source-Software nötig, die die Funktionen der Amazon-Cloud ersetzt.
Leider unterstützte diese Open-Source-Software eine Methode nicht, mit der Dateien als privat markiert werden können. Die Namen, Postleitzahlen und teilweise auch E-Mail-Adressen von WeAct-Nutzer*innen, die durch diese Markierung geschützt sein sollten, waren also theoretisch ohne Authentifizierung zugänglich. Die Folge hätte sein können, dass Sie unerwünschte Mails (Spam) erhalten. Für einen Zugang zu den Daten wäre aber auch hier Voraussetzung gewesen, die exakte Bezeichnung der Dateien zu kennen.
Hausgemachter Fehler, der schon ein wenig von Arroganz zeugt. Gekonnt hat man das „Mehr an Datenschutz“ durch Nutzung eigener Server verbrannt, weil man dachte, man könne es besser. Kann man machen, aber dann sollte man halt auch nicht mit Daten von so vielen Nutzern hantieren. Oder die selbst manipulierten Systeme einfach mal besser prüfen. So klingt das alles sehr fahrlässig. Besser machen wollen heißt eben nicht immer auch besser machen können.
Danke Benjamin!
So ärgerlich wie Datenlecks auch immer sind – möchte ich trotzdem Campact für die schnelle und umfassende Information über das Datenleck loben. Da haben sich andere schon viel, viel schlechtere Kommunikation geleistet.
Der Vollständigkeit halber: Campact hat MinIO als Unterbau verwendet. MinIO verspricht Amazon S3 kompatibel zu sein. Naja, eben bis auf ObjectACL.
Dieses Phänomen „man dachte, man könne es besser“ ist leider im IT-Bereich sehr weit verbreitet. Das findet man in praktisch allen größeren Konzernen in verschiedenen Ausprägungen, Aktuelle Softwareversionen installieren? Nö, wir können das besser, wie kennen ja die Lücken und bauen selbst drumherum. Bewährte Open-Source-Libraries verwenden? Nö, dann müssen wir ja nennen, dass wir die verwendet haben, dann kann der Azubi da besser mal schnell was zusammenhacken.
Also ist, um beurteilen zu können, wie schlimm das ist, wichtig zu wissen, wie solche Dateinamen aussehen. Ist es mit endlichem Aufwand möglich, diese zu erraten? Oder hat der Server gar eine Liste von Dateien verraten? Das grundsätzliche Problem besteht durchaus öfter, als man denkt. Viele Dateien sind, kennt man ihren Namen und Pfad, ohne weitere Authentifizierung im Internet abrufbar.
Dennoch sind mir Hetzner und Profihost lieber als AWS. 😀
Mir nicht. Generell halte ich sowas wie „Serverstandort Deutschland“ nicht für ein Qualitätsmerkmal. Ich sehe es tatsächlich so, dass das lediglich den Zugriff auf die Daten durch deutsche Behörden erleichtert. Ob irgend eine US-Institution darauf Zugriff hat, ist dagegen nahezu unerheblich.
Sehe ich genauso. „Deutscher Server-Standort“ ist ein ähnliches „Qualitätsmerkmal“ wie „Deutsche Autos“. Überteuerte Schrottkarren mit Schwindel-Software eingebaut. Ich las vor einer Weile von einem Cloud-Anbieter hier ganz in der Nähe. Einer mittelgroßen Stadt. Es waren auch Fotos der „Cloud-Server“ zu sehen. Das waren stinknormale Synology-NAS. Ich hab‘ ein Weilchen zusammen mit meinem OneDrive-Icon gelacht.
Ach immer dieses einfallslose Gebashe gegen die deutsche Autoindustrie, nur weil das Geld nicht mal für einen Skoda reicht. Echt langweilig.
Die beiden großen Deutschen Autohersteller sind nicht umsonst unter den Top 3 Herstellern weltweit.
Und mal zugegeben, wer fährt denn wirklich (außerhalb der USA) einen Ford oder Toyota wirklich aus Überzeugung und nicht weil der Preis so günstig ist?
Ist zwar eigentlich OT aber nach vielen Jahren Audi und VW bin ich davon überzeugt dass ich Beinfreiheit asiatischen Konkurrenz zwar den gleich Mist, dafür aber deutlich günstiger bekomme. Aber wer zu viel Geld hat darf natürlich gerne auch die einheimische Automafia unterstützen…
Nope. Sehe ich nicht so. Ich arbeite lieber mit Profis als mit Amateuren. 🙂 🙂
Trifft man häufiger die Einstellung dass nur ’selbstgebaute‘ System gut sind und alles andere sind Trottel.
In Wirklichkeit ist es genau anders herum.
Habe ich schon selbst erlebt, O-Ton Kunde ‚ Das sind Linux system, die muss man nicht patchen‘ 🙂
„Profis“ und „Profihost“ in einem Satz zu verwenden war jetzt aber nur ein Scherz, oder? Nach 20 Jahren als Webentwickler markieren die definitiv meine persönlich erfahrene Kompetenzuntergrenze. Das einzig professionelle bei denen sind die Haftungsausschlüsse in den SLAs.
Was für ein beknackter Kommentar. Mit der Nutzung Freier Software statt AWS hat man genau die richtige Entscheidung getroffen — und dabei unterlief nunmal ein Fehler. Das ist daily business.
„arrogant“ ist nur obiger Artikel.
Grundsätzlich hast du ja nicht unrecht, aber auch an diesem Beispiel sieht man, dass durchaus auch was schief laufen kann. Open Source allein ist auch kein Garant für mehr Sicherheit, abgesehen von Fehlern, die bei der Nutzung oder Umsetzung passieren können. Und insgesamt kann man in diesem Fall schon zu dem Schluss kommen, dass es besser gewesen wäre, die Daten einfach auf den Amazon-Servern zu belassen, dann wäre *das* jedenfalls nicht passiert. Auf der anderen Seite ist es natürlich so, dass Fehler nun mal passieren, und vermutlich wird diesem Anbieter das in dieser Form nicht noch einmal unterlaufen. Es ist nun mal wie es ist und nicht mehr zu ändern, und zumindest nach meinem Eindruck geht der Anbieter sehr transparent damit um.
Gegenfrage: Würde man es in Zukunft wieder so machen, für derartig sensible Daten quelloffene Software statt eine AWS-Blackbox zu verwenden? Meine Antwort: Ohne zögern, ja, genau das, das wäre sogar mein Anspruch. Solche Daten haben auf einem Cloudhosting nichts verloren.
Damit ist für mich der Drops gelutscht: Fehlerhaft war die Implementierung, aber nicht die Strategie.
Gegenfrage: Würde man es in Zukunft wieder so machen, für derartig sensible Daten quelloffene Software statt eine AWS-Blackbox zu verwenden? Meine Antwort: Ohne zögern, ja, genau das, das wäre sogar mein Anspruch. Solche Daten haben auf einem Cloudhosting nichts verloren.
Damit ist für mich der Drops gelutscht: Fehlerhaft war die Implementierung, aber nicht die Strategie.
Das ist genau der Punk. Die Strategie ist schon fehlerhaft. Ob die Software ‚quelloffen‘ ist ist da nebensächlich.
Natürlich ist die Software schult wenn das Design schon eine fette Sicherheitslücke hat. Daran erkennt man den Profi 🙂
Dann hast Diu da wesentliche nicht kapiert. Es dreht bei dem Projekt im Kern darum, dass die politischen Ansichten zu einer Email-Adresse zugeordnet werden.
Bei sowas darf ausschliesslich ein Setup zum Einsatz kommen, das komplett transparent ist. Mit Bugs hat das erstmal nichts zu tun, sondern mit Kontrolle.Du willst nicht, dass dir beim nächsten Urlaub in den USA bei der Einreise um die Ohren gehauen wird, dass Du gegen die israelische Besetzung Palästinas bist, oder gegen den Trump-Besuch beim G7 in Hamburg gestimmt hast.
Die Bugquote von Freier zu Closed Software ist da erstmal zweitranging, aber auch da sage ich dir als Softwareentwickler: Du willst gar nicht wissen, was alles vorsätzlich nicht gefixt wird, weil „ja eh keiner drauf kommt“ und keiner die Sourcen sieht.
Wenn man sich aber schon dazu entschließt, eine Individualsoftware anders als vorgesehen betreiben zu wollen, dann sollte man auch den Aufwand betreiben die Software dafür vom Hersteller entsprechend anpassen zu lassen statt da was mit Open Source zu basteln…
So, wie ich den Bericht verstehe, hat man keine Individualsoftware verwendet. Man hat eine Standardsoftware verwendet, deren Vorteil darin besteht, OpenSource statt ClosedSource zu sein. Abgesehen von Bugquoten innerhalb der jeweiligen Software hat man den für diesen Einsatzzweck unschlagbaren Vorteil von Transparenz.
Übrigens läuft der größte Teil des Netzes mit „gebastelter“ Freier Software.
Das sehe ich genau so
Wenn man eine solche Entscheidung trifft, sollte man sie aber auch so ausführen, dass sie auch vorteilhaft ist. Ist sie nicht, folglich wurde hier fahrlässig die Privatsphäre der Nutzer aufs Spiel gesetzt, weil man es besser machen wollte, aber in der Ausführung scheiterte. Ein absolut vermeidbarer Fehler, hätte man die Software wie bestimmt genutzt.