Skip to content

Vorstellung des Tätigkeitsberichts des Datenschutzbeauftragten

Der Thüringer Landesbeauftragte für den Datenschutz und die Informationsfreiheit (TLfDI), Dr. Lutz Hasse, stellte heute seinen Tätigkeitsbericht für 2014 und 2015 vor. Ich war zu der Veranstaltung mit eingeladen und will die Veranstaltung aus meiner Sicht zusammenfassen.

Derzeit arbeiten im TLfDI 20 Personen und zwei, die von anderen Ämtern abgeordnet wurden. Bei den beiden handelt es sich um einen Lehrer und eine Polizistin. Herr Dr. Hasse ist Vorsitzender des Arbeitskreises Datenschutz und Bildung der Datenschutzbeauftragten. In diesem Rahmen hilft der abgeordnete Lehrer. Insbesondere das Thema Medienkompetenz liegt dem TLfDi am Herzen. Auch die Hauptkommisarin ist in die tägliche Arbeit der Behörde eingebunden. Somit gewinnt sie einen Einblick und kann das später in der Polizei den dortigen Kollegen weitergeben.

Der Tätigkeitsbericht ist über die Jahre immer weiter gewachsen. Als Herr Hasse in das Amt gewählt wurde, gab es lediglich einen fingerdicken Bericht. Die heutige Ausgabe kam in zwei Bänden mit über 1300 Seiten Umfang. Die Bücher sind in den Bericht zum nicht-öffentlichen Bereich (private Firmen, Vereine etc.) und zum öffentlichen Bereich (Behörden, Gemeinden etc.) getrennt.

Im nicht-öffentlichen Bereich hat das TLfDI die Möglichkeit, Beanstandungen und Bußgelder auszusprechen. Davon machte die Behörde reichlich Gebrauch. Die Zahl der Beanstandungen verdreifachte sich im Vergleich zum vorigen Zeitraum und aus ursprünglich weniger als 500 € Bußgeldern wurden im neuen Zeitraum 5.300 € Bußgeld. Aufgrund der hohen Arbeitsbelastung fanden weniger Kontrollen bei Firmen statt.

Insgesamt versucht das TLfDI einen Blick auf zukünftige Gefährdungen zu haben. So spielten in der Veranstaltung SmartTV, Spielzeugpuppen mit eingebautem Mikrofon und WLAN wie auch Datenschutz in (selbstfahrenden) Autos eine Rolle. Die Datenschützer sind an diesen Themen dran und versuchen sich dazu eine Meinung zu verschaffen.

Wie schon im letzten Bericht spielt die Videoüberwachung in verschiedener Form eine große Rolle. Der aktuelle Bericht enthält mindestens 84 Fälle zur Videoüberwachung. Auch in Zukunft wird der Bereich eine große Rolle spielen. Nach einem Urteil des europäischen Gerichtshofs fallen wohl nahezu alle Kameras (auch privat betriebene) unter das Bundesdatenschutzgesetz. Damit sind diese beim TLfDI zu melden. Die Behörde versucht, ein Register einzurichten und dann sollen Kamerabetreiber deren Kameras dorthin melden. Weiterhin sind Dashcams (Kameras in Autos), Helmkameras und Kameradrohnen im Blick. Auch hier könnte es zu einer Registrierungspflicht kommen.

Weiterhin kam das Aktenlager in Immelborn zur Sprache. Dort wurde ein Berg von zum Teil sensiblen Akten in einer Fabrikhalle gefunden. Der ursprüngliche Betreiber des Lagers war nicht mehr aufzufinden und eigentlich hätten die Akten an die Besitzer zurückgehen müssen. Herr Hasse bat damals die Polizei um Amtshilfe, die aber nicht gewährt wurde. Das TLfDI klagte daraufhin. Später fand sich dann doch eine Firma, die die Räumung des Lagers übernahm. Der ganze Vorfall wird mittlerweile von einem Untersuchungsausschuss im Landtag betrachtet. Herr Hasse erzählte heute, dass im Rahmen des Ausschusses festgestellt wurde, dass der Polizeipräsident in der Tat Unterstützung leisten wollte. Das Amt hatte 10 Leute für ca. zehn Tage beantragt. Das Innenministerium fragte jedoch bei der Polizei 100 Leute für einen Monat an. Ein Schelm, wer Böses denkt. Dennoch war die Polizei zur Unterstützung bereit. Aber das Innenministerium pfiff die Polizei dann wohl zurück.

Im Bereich Gesundheit wurde auf ein Forum verwiesen, an das sich Krankenhäuser wenden können. Die Idee ist, dass ein Krankenhaus eine Datenschutzfrage stellen kann. Diese ist anonymisiert und das TLfDI beantwortet diese, ohne auf das Haus schließen zu können. Das Angebot wird gut angenommen und hat viele Abrufe.

Daneben erzählte Herr Dr. Hasse noch die Geschichte von Krankenakten, die an seine Heimadresse geschickt wurden. Als er den Brief öffnete, waren Krankenakten enthalten. Einen Tag später gab es eine weitere »Lieferung«. Daraufhin wandten sie sich an das betreffende Krankenhaus. Dort gab es eine Mitarbeiterin, die nach dem Namen eines Arztes im Internet suchte und auf die Adresse des Datenschützers stieß. Sie schickte die Akten dann ohne weitere Prüfung an den Datenschützer. :-)

Im öffentlichen Bereich scheinen öffentliche Sitzungen von Stadt- und Gemeinderäten ein Dauerbrenner zu sein. Dort werden immer wieder personenbezogene Daten genannt, obwohl diese in nicht-öffentlicher Sitzung diskutiert werden sollen.

Insgesamt war dies eine sehr interessante und aufschlussreiche Veranstaltung. Ich habe jetzt Lesestoff für die nächste Zeit in der Hand. ;-)

Wie funktioniert eigentlich Heartbleed

Lest ihr regelmäßig Bugreports oder Meldungen über Schwachstellen bei SSL/TLS? Wie fühlt ihr euch so? Zur Erinnerung:

SSL added and removed here!
Ausschnitt aus einer Folie aus dem MUSCULAR-Programm der NSA

Das heißt, drei Monate in Folge gab es schwere Sicherheitslücken in Software zur Verschlüsselung. Ganz unwillkürlich fühlt man sich an die Folien aus dem NSA-Programm MUSCULAR erinnert.

Die letztgenannte Schwachstelle ist vermutlich die bislang schwerste. Denn damit ist es möglich, den Arbeitsspeicher eines Computers auszulesen. Dies funktioniert sowohl auf der Seite des Servers wie auch beim Clientprogramm. Dazu ist es notwendig, dass das Programm OpenSSL verwendet und eine Erweiterung von SSL namens Heartbeat aktiviert hat. Dies ist beispielsweise bei Android in der Version 4.1.1 der Fall. Mozilla Firefox hingegen nutzt die NSS-Bibliothek und ist nicht betroffen. Die Webserver nutzen hingegen recht oft die OpenSSL-Bibliothek und sind damit betroffen, falls die Version 1.0.1 bis 1.0.1f von OpenSSL verwendet wird. Sollte jemand von euch die Software nutzen, so upgraded auf mindestens 1.0.1g oder deaktiviert Heartbeat in OpenSSL. Gerade letzteres kann man aus meiner Sicht problemlos tun. Denn bisher fand ich keinen sinnvollen Anwendungsfall für Heartbeat.

Doch wie funktioniert diese Lücke eigentlich? Heartbeat (RFC 6520) ist eine Erweiterung für TLS. Ein Teilnehmer einer Verbindung sendet beliebige Daten an den Empfänger. Dieser antwortet mit einer Kopie dieser Daten und zeigt somit, dass die Verbindung noch steht und alles in Ordnung ist. Das Problem dabei ist, dass in einer Anfrage zwei Längenfelder vorhanden sind. Ein Angreifer sendet einfach ein Byte Daten und behauptet, er hätte 64 kB gesendet. OpenSSL liest nun die 64 kB aus dem eigenen Puffer und sendet die Daten zurück an den Angreifer. Der Angreifer kann den Angriff immer und immer wieder starten und erhält so eventuell immer wieder ein neues Stück Arbeitsspeicher (siehe Kommentar von Florian Diesch). Bruce Schneier hat mit seinen Worten vollkommen recht:

Catastrophic" is the right word. On the scale of 1 to 10, this is an 11.
https://www.schneier.com/blog/archives/2014/04/heartbleed.html

Ich hatte in meinem 30C3-Vortrag schon ein OpenSSL-Beispiel reingenommen. Das sollte zeigen, wie kompliziert es sein kann, mit der Software sicheren Code zu schreiben. Auch andere sind, über die Codequalität gestolpert. Daher sind Leute gefragt, die einen detaillierten Blick auf OpenSSL werfen und die Software verbessern. Dazu zählt auch die bessere Lesbarkeit des Codes oder gute Dokumentation.

Wenn ihr wissen wollt, ob ihr betroffen seit, schaut lokal auf die OpenSSL-Version, nutzt die Zeile openssl s_client -connect example.com:443 -tlsextdebug 2>&1| grep ‘server extension “heartbeat” (id=15)’ || echo safe oder verwendet den Testservice von Lutz Donnerhacke oder Filippo Valsorda.

Weiterlesen:

Passwort und Nutzername im Dump der Daten von Yahoo! Mail

Spamschutz bei S9Y

Im Hintergrund tut Serendipity oder kurz S9Y seinen Dienst. Vor mehr als sieben Jahren stieg ich von Wordpress auf die Software um. Die Software tut im wesentlichen ihren Dienst. Außer, wenn wie heute, ein Plugin merkwürdige Sachen macht.

Ich hatte bis heute abend das Autosave-Plugin installiert. Das speichert die Einträge zwischen und soll eigentlich vor Datenverlust schützen. Bei mir sorgte es dafür, dass die Rezension mehrfach verschwand. Der Grund war, dass ich auf Speichern im Artikelfenster drückte und das Fenster offen liess. Das Plugin wollte einfach alte Werte speichern und löschte so den Beitrag.

Seit dem Jahreswechsel bereitet mir nicht die Blogsoftware Kopfschmerzen, sondern der Spam der eintrudelt. Anfangs hatte ich den Spamschutz aktiviert, den S9Y von Haus aus mitbringt. Dazu setzte ich ein paar Worte auf die Blacklist. Das reichte aus. Nebenan im Datenkanal habe ich noch das Bayes-Plugin im Einsatz. Das wurde von Beginn an angelernt und verrichtet gute Dienste.

Das S9Y Infocamp hat sich nun dem Thema Spamschutz bei S9Y angenommen. In dem Podcast besprechen sie verschiedene Mechanismen. Dabei kommt die Rede auf die SpamBee. Die arbeitet unter anderem mit versteckten CAPTCHAs. Die vier Podcaster sind voll das Lobes. Ich habe den Podcast glücklicherweise zur rechten Zeit gehört. Denn direkt nachdem ich die Biene hier installierte, traf das Blog eine Spamwelle. Von den Lesern hat das vermutlich niemand bemerkt. Die Spambiene hat den Spam wirklich sehr gut abgefangen. Wer also da draußen mit Spam bei S9Y zu kämpfen hat, sollte unbedingt SpamBee probieren. Vermutlich bringt das Plugin Linderung.

Dritte Auflage von »Anonym im Netz«

Der Verlag Open Source Press twitterte soeben: »Neuauflage mit #JonDo-Live-CD für anonymes surfen, mailen, chatten! “Anonym im Netz” (J.Kubieziel) jetzt lieferbar.« Damit ist nun die dritte Auflage meines Buches »Anonym im Netz« draußen. Ich habe die Inhalte wieder aufpoliert, die Struktur einiger Kapitel angepasst. Aber die größte Neuerung ist eine beigelegte CD. Die JonDo Live-CD hat alle wichtigen Anonymisierungsdienste vorinstalliert. Der Leser legt die einfach in das CD-Fach und kann sofort ausprobieren. Ich hoffe, das Buch findet wieder großen Anklang. Solltet ihr Fehler finden, schreibt mir eine E-Mail oder hinterlasst hier einen Kommentar. Die Fehler werden dann in der folgenden Ausgabe ausgebessert. :-)

Neue Ideen zur Internetüberwachung

Zwischen den Feiertagen werden ja gern mal unausgegorene Ideen in die Welt hinaus geblasen. So fühlt sich die Meldung an, die bei ZEIT Online zu lesen war: Kinderporno-Fahndung bei allen Internetnutzern. Kai Biermann schreibt dort, dass die Initiative White IT die Internetanbieter dazu bringen will, selbst auf die Suche nach Mißbrauchsbildern gehen soll. Dazu gibt es eine Datenbank, in der alle Bilder vermerkt sind und zu jedem Bild existiert eine Prüfsumme (Hash). Der Internetanbieter berechnet seinerseits die Prüfsumme von Bildern aus dem Datenstrom seiner Kunden. Falls es eine Übereinstimmung mit dem Eintrag in der Datenbank gibt, so schlägt die Software Alarm.

Doch wie sinnvoll ist eine derartige Idee? Oberflächlich betrachtet klingt das vielversprechend. Aber schaut euch mal die vier Bilder unten an. Entdeckt ihr einen Unterschied?

>

Die Prüfsummen (SHA-224) der Dateien sind 7fab23221b7a000ec0ab18431d58e2e58c16e3093bbf54084f22e802, c33230b4341d8b1f08a90382e27a145dff1d8208b5c25195674ee2e8, 69ff77157382503ae68d1cf4354034b640c7593465e383a0db51df9b und 87426dcee42ceb7f507eac515f5620bcb359364405a0abbd240364d8. Also rein technisch sind diese verschieden. Der Screenshot wurde in verschiedenen Formaten gespeichert und mit unterschiedlichen Qualitätsstufen. Wenn man das Spiel weitertreibt, könnten mehrere tausend (eventuell sogar Millionen) Varianten des Bildes angefertigt werden, die alle gleich aussehen, aber unterschiedliche Prüfsummen besitzen. Das Prüfprogramm müsste eben alle diese Varianten kennen oder die Änderungen intelligent erkennen. 

Aber selbst im letztgenannten Falle bieten sich derartig viele Möglichkeiten, dass Erkennungsprogramm zu umgehen, das die Idee besser schnell wieder beerdigt gehört. Denn während bei der Vorratsdatenspeicherung  „nur“  auf die Verbindungsdaten zugegriffen wurde, schauen hier beliebige Internetanbieter direkt in die Inhalte der Kommunikation hinein. Der Plan geht also wieder einen Schritt weiter in Richtung Vollüberwachung.

Fingerprints von SSL-Seiten prüfen

Das Desaster um die niederländische Zertifizierungsstelle DigiNotar zieht derzeit immer noch seine Kreise. Mir scheint es noch zu früh, um hier etwas dazu zu schreiben. Vielmehr will ich ein paar Worte verlieren, wie ich „meine eigene CA betreibe“. Denn schon seit längerem vertraue ich nicht, den von den Browsern mitgelieferten Zertifizierungsstellen (CA). Zumeist lösche ich alle und gebe dann einzeln Vertrauen.

Der beste Weg, um einem SSL-Zertifikat zu vertrauen, wäre, sich bei dem Betreiber zu melden und über einen sicheren Kanal den Fingerprint des Zertifikats zu klären. Mein Browser zeigt mit für die Seite Wikipedia-SSL-Seite den Fingerprint (SHA-1) BA:8A:BE:34:B1:34:3B:AF:06:05:4B:48:A9:27:AA:D9:B4:75:45:6E an. Wenn ich bei der Wikipedia anrufe und diese mir denselben nennen, so habe ich das korrekte Zertifikat. Dabei nehme ich natürlich an, dass das Telefon ein sicherer Weg zum Austausch der Informationen ist. Aber beispielsweise druckt die lokale Sparkasse eben diesen Fingerprint auf ihre Dokumente. Damit kann ich das als Kunde leicht verifizieren.

Wie das Beispiel Wikipedia aber schon zeigt, ergibt sich da ein Problem.Woher bekomme ich den Fingerprint? Muss ich bei Jimmy Wales direkt anrufen oder gar nach FloridaKalifornien¹ reisen? Hier kam nun meine Idee ins Spiel.

Ich habe auf diversen Servern einen Zugang, d.h. ich kann mich von der Ferne einloggen und dann dort arbeiten. Die Rechner stehen in verschiedenen Netzen und zum Teil auf verschiedenen Kontinenten. Nun logge ich mich auf den Servern ein, lade das Zertifikat herunter und lasse mir den Fingerprint anzeigen. Wenn dieser auf allen Rechner gleich ist, dann gehe ich davon aus, dass ich das korrekte Zertifikat angezeigt bekomme. In dem Fall akzeptiere ich das und vertraue dem. Sollten die Fingerprints abweichen, dann akzeptiere ich das nicht und recherchiere dem in der Regel ein wenig hinterher.

Jörg Sommer hat das nun ein wenig automatisiert und ein zsh-Skript (Quelltext weiter unten) geschrieben. Das wird folgendermaßen aufgerufen:

ssl-fp-check [-l] sslsi.te[:port] ssh1 [ssh2] [ssh3] ...

Dabei ist sslsi.te die Webseite, die geprüft werden soll. Ohne die Angabe eines Ports verwendet das Skript standardmäßig 443. Danach wird eine oder mehrere SSH-Verbindungen angegeben. Das Skript wird nun versuchen, sich überall einzuloggen und gibt dann den Fingerprint aus. Für den Fall, dass es auf dem Zielsystem kein OpenSSL gibt, existiert die Option -l. Dabei wird dann ein Tunnel gebaut und das lokale installierte OpenSSL verwendet.

Also für Wikimedia habe ich folgendes eingeben:

ssl-fp-check secure.wikimedia.org a b c d
a: SHA1 Fingerprint=BA:8A:BE:34:B1:34:3B:AF:06:05:4B:48:A9:27:AA:D9:B4:75:45:6E
b: SHA1 Fingerprint=BA:8A:BE:34:B1:34:3B:AF:06:05:4B:48:A9:27:AA:D9:B4:75:45:6E
c: SHA1 Fingerprint=BA:8A:BE:34:B1:34:3B:AF:06:05:4B:48:A9:27:AA:D9:B4:75:45:6E
d: SHA1 Fingerprint=BA:8A:BE:34:B1:34:3B:AF:06:05:4B:48:A9:27:AA:D9:B4:75:45:6E

Die SSH-Server a, b, c und d gaben also denselben Fingerprint aus. Also würde ich dem ganzen doch vertrauen. :-)

Ich werde das Skript jetzt wahrscheinlich immer verwenden. Es macht das Leben doch deutlich einfacher.

Continue reading "Fingerprints von SSL-Seiten prüfen"

Firefox Add-On Ant Video Downloader spioniert Nutzer aus

Ein Add-On für den Firefox, welches 4 von 5 Sternen hat und von mehr als sieben Millionen Nutzer installiert wurde, sollte doch halbwegs vertrauenswürdig sein. Zumindest legt Linus’ Law diese Erkenntnis nahe. Das Add-On Ant Video Downloader straft diese Annahme nun Lügen.

Der Ant Video Downloader soll Videos von Youtube, Facebook und vielen anderen Seiten auf einfache Weise herunterladen. Daneben hat die Software noch einen anderen Zweck. Sie sammelt Daten über jede Seite, die der Benutzer besucht. Dazu wird eine eindeutige Nummer, die so genannte Ant-UID, angelegt. Wenn eine Webseite aufgerufen wird, sendet Ant eine zweite Anfrage mit eben dieser Nummer, der URL der aufgerufenen Seite sowie der Browserkennung an die Adresse rpc.ant.com.  Somit kommt dort jeder Seitenaufruf (also auch interne URLs im privaten Netzwerk) an, den ihr jemals gemacht habt. Damit aber noch nicht genug. Bei der Deinstallation der Software wird die Informationen mit der eindeutigen Nummer, der Ant-UID, behalten. Wenn ihr die Software später neu installiert, wird genau dieselbe Nummer wieder verwendet. Das ist also eine massive Verletzung der Privatsphäre der Nutzer.

Wie ein Witz klingt da die Privacy Policy von Ant.com:

As a responsible member of the community of website owners, Ant.com solutions (Here in after Ant.com) takes the privacy and security of its users with the highest regard.

Insgesamt finde ich in der Policy keinen Hinweis auf diese Spionagemaßnahme. Glücklicherweise haben die Betreiber der Add-On-Seite die Notbremse gezogen. Zunächst wurde der Download der Software komplett deaktiviert und jetzt ist diese als experimentell gekennzeichnet. Damit sollten nur erfahrenere Nutzer diese installieren können.

Das Beispiel zeigt mal wieder, das man sich offensichtlich auf keine Software verlassen kann und insbesondere das die Warnungen bezüglich der Add-Ons sehr ernst zu nehmen sind.

via InterWeb Task Force und The Register

tweetbackcheck