Stoppt die Vorratsdatenspeicherung! Jetzt klicken &handeln! Willst du auch an der Aktion teilnehmen? Hier findest du alle relevanten Infos
und Materialien:
Sie sind hier: Startseite Blog

Blog

Deshalb TR-069 ausschalten!

Vor einiger Zeit habe ich gebloggt, wie man TR-069 auf der Fritzbox ausschaltet. Ich habe aber nie geschrieben, weshalb man das tun sollte.

Nun, Anfang der Woche gab es einen groß angelegten Angriff auf Speedport-Router der Telekom – über eine Schwachstellen in deren TR-069-Implementierung. Nun haben diese Speedport-Router nichts mit den Fritz!Boxen zu tun. Dennoch wurde ich in einer Zuschrift gebeten, darauf hinzuweisen, dass, wenn TR-069 ausgeschaltet ist, der Provider keinen Zugriff auf den Router mehr hat und damit auch keine Firmware-Updates mehr einspielen kann.

Das ist korrekt. Und das ist auch genau die Absicht, wenn ich TR-069 abschalte: Der Provider soll keinen Zugriff mehr auf meinen Router haben.

Natürlich kann er damit auch keine Firmware-Updates einspielen. Aber

  1. das tut er sowieso nicht schnell genu, wie der aktuelle Fall zeigt, und
  2. kann das die Fritzbox selbst.

Wenn ich TR-069 eingeschaltet habe, erreiche ich nur eines: Ich habe ein weiteres Einfallstor für Angreifer geschaffen.

Wer ein Fritzbox hat, sollte dort natürlich einstellen, dass sie selbst nach Updates sucht. Wenn Ihre Fritzbox was noch nicht kann, schauen Sie, ob es eine neue Firmware gibt, die das kann. Dazu müssen Sie nur in der Benutzeroberfläche der FRITZ!Box auf "System", dann auf "Update" bzw. "Firmware-Update" und dann auf "Neue Firmware suchen" klicken.

In einem anderen, bislang unveröffentlichten Blogbeitrag nenne ich noch in paar andere Gründe, weshalb man TR-069 deaktivieren sollte.

02.12.2016 16:55

DSL-Fernkonfiguration ist kritisch für den Datenschutz

Vorletzte Woche gab es etwas Aufregung um TR-069, weil Sicherheitsforscher entdeckt haben, dass viele Provider es unsicher implementieren. Siehe hierzu auch mein Blog-Post. Nun stellt sich natürlich die Frage nach der Tragweite von TR-069: Manche Datenschützer befürchten Übergriffe von Strafverfolgungsbehörden auf die Privatsphäre.

Hier meine Einschätzung:

Auf der einen Seite entlastet es technisch weniger bedarfte Nutzer, weil sie sich um nichts kümmern müssen. Auf der anderen Seite entmündigt es Nutzer – insbesondere dann, wenn es keine Möglichkeit gibt, TR-069 auszuschalten. Und die Benutzer werden auch nicht darüber aufgeklärt, dass es eine solche Funktion gibt und was man damit tun kann. Damit verstärkt es den Trend, KundInnen völlig von der Möglichkeit auszuschließen, die Geräte zu konfigurieren – ein gefährlicher Trend durch die ach so bequeme neue Technik.

Das Problem an dieser Stelle ist meines Erachtens das mangelnde Vertrauen: Als Bürger habe ich nicht mehr das Vertrauen, dass die Telkos und/oder staatliche Stellen mich hier vor Missbrauch schützen. Sie tun nichts, um mir dieses Vertrauen zu geben. Aber sie tun viel, um das Vertrauen zu zerstören. Ich muss damit rechnen, dass gerade von staatlicher Seite diese technischen Möglichkeiten genutzt werden, um mich auszuspionieren und mich zu überwachen.

Der Standard ist 230 Seiten lang und bezieht sich teilweise einfach auf andere Standards. Daher kann ich momentan nur erste Erkenntnisse wiedergeben.

TR-069 kennt Kommandos, um Dateien auf den Router hochzuladen, umzubenennen und zu löschen sowie eine reboot zu veranlassen (TR-069 Amendment 5, Seite 144). Daneben sind offiziell "hersteller-spezifische" Kommandos möglich. Daneben scheinen noch RPCs (Remote Procedure Calls) möglich zu sein, die noch wesentlich mehr können.

Damit könne ein Angreifer (in diesem Fall: ein staatlicher Dienst) einige Dateien auf den Router hoch laden und den Router rebooten. Damit könnte eine saubere Hintertür installiert werden, über die das LAN ausspioniert werden könnte. Der Benutzer würde davon allenfalls den Reboot mitbekommen.

02.12.2016 16:51

35.000 gegen Vorratdatenspeicherung

Unterstützen Sie die Verfassungsbeschwerde gegen die Vorratsdatenspeicherung

Ich habe die Verfassungsbeschwerde von Digitalcourage gegen die Vorratsdatenspeicherung unterschrieben. Mit der Klage wollen Digitalcourage und 20 Prominente die Überwachung unserer Kommunikation stoppen. Denn ab Sommer 2017 soll gespeichert werden, wer wann wo mit wem telefoniert oder im Internet unterwegs ist.

Die Schriftstellerin Juli Zeh, Kabarettist Marc-Uwe Kling, ver.di-Chef Frank Bsirske, der Ökonom und Jesuit Friedhelm Hengsbach, zwei Bundestagsabgeordnete, mailbox.org und 13 weitere Prominente ziehen dagegen vor das Bundesverfassungsgericht.

30.000 Menschen haben die Verfassungsbeschwerde bereits unterschrieben – 35.000 Unterschriften sind das Ziel. Mitmachen wirkt! Alle Unterschriften werden ausgedruckt und direkt nach unserer großen Pressekonferenz am Montag, 28. November, dem Bundesverfassungsgericht übergeben.

Setzen wir gemeinsam ein Zeichen gegen Überwachung!
Unterzeichne auch du die Verfassungsbeschwerde und leite den Aufruf weiter:

https://digitalcourage.de/weg-mit-vds

(Mitmachen ist möglich bis Sonntag, 27. November 2016, um 24:00 Uhr)

25.11.2016 13:53

Bin "offiziell" Entdecker einer Sicherheitslücke

Anfang des jahres habe ich eine Sicherheitslücke im Programm „Metadata Anonymisation Toolkit“ (kurz: MAT) entdeckt. Diese wurde nun endlich in Form eines „Security Advisory“ von Debian gewürdigt und hat dort Nummer DSA-3708 bekommen. Und mir wurde die Entdeckung der Lücke zugeschrieben :-)

Mehr zu MAT und der Lücke beschreibt der Blogeintrag von Digitalourage.

Der Anlass ist aber traurig: Der Entwickler von MAT hat die fehlerhafte PDF-Säuberungsfunktion nicht etwa repariert, sondern komplett entfernt. Anschließend hat er sich aus gesundheitlichen Gründen von diesem Projekt verabschiedet.

Wer in Python programmieren kann, Lust und Zeit hat, ist herzliche eingeladen das Problem beheben. Das ist nicht einmal so schwer: Mittels des Python-Moduls PyPDF2 das PDF laden, alle enthaltenen Bilder speichern, mit der bereits bestehenden Funktion von MAT bereinigen, das Bild dann durch die bereinigte Funktion ersetzten und das PDF wieder speichern.

16.11.2016 10:51

K-9 mail statt Apps der Mailprovider

Etwas tun gegen Überwachung: Mailprogramm auf dem Smartphone

Die „kostenlos“ Mailprovider web.de, gmx, yahoo und wie sie alle heißen, bieten für Smartphones eigene Apps. Damit bekommt man ein buntes Icon auf dem Startbildschirm  und bequemen Zugriff auf sein Mailpostfach dort. Was sonst noch drin ist, weiß niemand. Zumindest die App von Yahoo möchte den Standort abfragen. Nachtigall ich hör dich trapsen!

Dabei gibt es eine tolle Alternative, die zudem Freie Software ist: K-9 Mail.

Wenn Sie, wie ich, Mail-Konten bei mehreren Providern haben, können Sie die in K-9 Mail gemeinsam verwalten. Sie können sogar die "Posteingang"-Ordner der Mail-Konten in einem  gemeinsamen Posteingang anzeigen lassen. Wer viele Mails bearbeiten muss oder viele Ordner angelegt hat kann die in K9 zügig bearbeiten.

Sie müssen also – anders als bei den Apps der Provider – nicht mehrere Apps durchsuchen, auf dem Startbildschirm ist ein einziges Icon und die behalten die Kontrolle.

K-9 Mail gibt es in F-droid, dem App Store für Freie Software, oder im Gockel Store. Falls Sie F-droid noch nicht nutzen: Wikipedia hat einen Artikel zu F-droid und Digitalcourage erklärt, weshalb Sie F-droid nutzen sollten und wie die es einrichten.

06.11.2016 18:45

Das Fass ist voll: Gründe, Linux' ‚systemd‘ zu meiden

Meine positive Meinung zu ‚systemd‘ muss ich leider revidieren.

Ursprünglich dachte ich, ‚systemd‘ bringt Linux voran. Ein neues ‚init‘-System war lange fällig. Nachdem ‚systemd‘ aber mehr und immer mehr Features bekommen hat, wurde mir schummrig.

Vor einige Wochen hatte ich dann entdeckt, dass der ‚systemd-timed‘ standardmäßig die Zeit-Server von Google fragt. Ich möchte aber nicht, dass alle meine Systeme ständig mit Google in Kontakt treten! Der „Fix“ dafür war auch bemerkenswert halbherzig: Die Macher einer Linux-Distribution bekommen nun zwar eine Warnung, wenn Sie keine eigenen Zeit-Server angeben, aber ‚systemd-timed‘ benutzt dann munter einfach die von Goolge. Und die Warnung geht in hunderten von Log-Meldungen sowieso unter.

Das spricht nicht dafür, dass die Programmieren von ‚systemd‘ sensibel für Datenschutz sind – und auch nicht für die Qualität ihrer Software sprechen solche halbherzige Lösungen nicht.

Nun habe ich einen Blogeintrag von Andrew Ayer entdeckt ("How to Crash Systemd in One Tweet"), der das Fass voll macht. Der Autor beschreibt nicht nur einen Fehler, sondern auch, wie ‚systemd‘ systematisch gegen best-practices der IT-Sicherheit und ‚good coding practices“ verstößt. Außerdem bekommt ‚systemd‘ immer mehr Features, die ein ‚init‘-System gar nicht braucht. Beispielsweise eben diesen ‚timed‘ - das gehört nicht in zum ‚Initialisieren‘ eines System. dafür gibt es eigene Software, die das seit langem und besser kann. Das ‚init‘-System muss allenfalls dafür sorgen, dass diese Software läuft.

Aber der Blogeintrag hat noch schlimmere Beispiele: ‚systemd’ bringt einen sogenannten DNS-Resolver mit, der Fehler enthält, die schon vor acht Jahren für sehr, viel Aufregung gesorgt haben und mit großer Anstrengung bei allen DNS-Resolvern behoben wurden.

Mich beschleicht das Gefühl, das den Programmierern von ‚systemd‘ der Erfolg zur Nase gestiegen ist und sie sich für unfehlbar halten. Das kann nur schief gehen.

02.10.2016 20:11

Petition gegen das BND-Gesetz

Reporter ohne Grenzen haben eine Petition gegen das BND-Gesetz online. „Wir fordern, dass der deutsche Bundestag Schutzpflichten für Journalisten und andere Berufsgeheimnisträger (…) ins neue ...

25.08.2016 10:31

Totgeburt Volksverschlüsselung

Laden Sie mich ein, das zu diskutieren

Ich halte von der Volksverschlüsselung nichts, sie ist eine Totgeburt, weil viel zu kompliziert und wieder zentralistisch. Ich hatte eine ganze Reihe von Argumente dagegen gesammelt, aber die beste Zusammenfassung fand ich in den Secorvo Security News 07/2016:

Die Volksverschlüsselungs-Software, die die Fraunhofer Gesellschaft mit Unterstützung der Deutschen Telekom am 29.06.2016 in der aktuellen Version zum Download bereit gestellt hat, um Ende-zu-Ende E-Mail-Verschlüsselung auf Grundlage von S/MIME und PGP mit kostenlosen Zertifikaten für private Endanwender tauglich zu machen, ist gar keine Verschlüsselungslösung – sie kümmert sich allein um die Erzeugung und Einbindung des Public-Private-Schlüsselpaars.

Keine ganz neue Idee: Schon Anfang der 2000er Jahre hatte TC Trustcenter kostenlose S/MIME- und PGP-Zertifikate für Privatnutzer im Angebot.

Vor allem aber kombiniert sie die Nachteile offener und geschlossener PKIs: den aufwändigen Registrierungsprozess einer jedermann offenstehenden PKI mit der Beschränkung auf „mitspielende“ Kommunikationspartner wie bei einer geschlossenen PKI.

Vielleicht sollte man lieber die vereinfachte Benutzerschnittstelle der Open-Source Volksverschlüsselungs-App mit einem Open-Source E-Mail-Client wie bspw. Thunderbird kombinieren – und auf die ebenfalls kostenlosen E-Mail-Zertifikate öffentlicher Trust Center wie Comodo oder StartCom zurückgreifen

Um Verschlüsselung in die Breite zu tragen, ist die Volksverschlüsselung also ungeeignet.

Die in meinen Augen richtige Lösung heißt p≡p (Pretty Easy Privacy), das jetzt endlich öffentlich verfügbar ist. Was pEp will und kann erklärt sehr gut die 10-Minuten-Zusammenfassung eines Vortrags von Volker Birk, dem Kopf hinter pEp. Zu pEp werde ich bald mehr schreiben.

Falls Sie eine Diskussions-Veranstaltung zu diesem Thema planen, laden Sie mich doch ein. Ich bin gerne bereit, meine Position fundiert zu vertreten.

09.08.2016 09:37

Warum Sie nicht Perl programmiern sollten

Ein Freund hatte angekündigt, es wolle jetzt "richtig" Perl lernen. Ich rat ihm dringend davon ab. Hier, was ich ihm geschrieben habe:

Lieber Freund

es lässt mir keine Ruhe, dass Du Deine Lebenszeit mit so schlechten Dingen wie Perl vertun möchtest.

Ich hab schon mit einigen Programmiersprachen gearbeitet und mir viele angesehen. Perl ist eine der schlechtesten! Perl versagt bei der wichtigen Aufgabe, dem Programmierer zu unterstützen. Im Gegenteil: Perl steckt voll Fallstricke und Undurchdachtem.

Ein paar Beispiele:

  • Der Rückgabewert vieler Standard-Funktionen hängt vom Aufrufkontext ab. Mal ein Scalar, mal ein Hash, mal ein Objekt.
  • Durch automatische Typumwandlung fällt man immer wieder auf die Schnauze. Statt der Liste oder dem Hash hast du plötzlich die Anzahl der Elemente darin - oder war es der höchste Index? Damit musst du aber auch denn wissen, was eine Funktion liefert, wenn dich der Wert überhaupt nicht interessiert und du ihn nur an eine andere Funktion weiterreichen willst.
  • Übergeben von Parametern an Funktionen t eine Krankheit, alles muss der Programmierer selbst schreiben:
    • Die Parameter einer Funktion werden als dumme Liste übergeben, man muss sie selbst den einzelnen Variablen zuweisen. Welche Parameter die Funktion annimmt, *kann* man in einem Prototype festlegen, aber trotzdem muss man die Liste der Argumente weiterhin händisch auswerten.
    • "Named parameter" muss man komplett händisch implementieren, siehe das Beispiel in http://docstore.mik.ua/orelly/perl/cookbook/ch10_08.htm. Wenn der Nutzer der Funktion dann zu viele oder unbekannte Parameter übergibt, gibt es keine Fehlermeldung -- außer der Programmierer hat das extra programmiert. Doppelte Parameter werden dabei gar nicht erkannt.
  • Dinge die eigentlich der Normalfall sind, muss man ausdrücklich hinschreiben und der Normallfall ist das, was man nur selten will:
    • Dinge, die man eigentlich immer braucht, um sauber zu programmieren muss man extra einschalten: use strict, user warnings.
    • Unausgereiftes Scope-Konzept: Der Normalfall ist eigentlich, dass man lokale Variablen nutzen möchte. Auch hier muss man den Standard Fall wieder mit „my“ angeben.
  • Eine Klasse zu definieren ist ein religiöser Akt ("bless") und insgesamt umständlich. Es scheint zwar ein Modul zu geben, dass das besser macht, aber da sind wir wieder bei: "einfaches ist umständlich".
    • Zitat vom "perlmaster" aus dem aktuellen Linux-Magazin (8/2016, S. 92): "… niemand, der einigermaßen bei Verstand ist, hätte auch nur in einem mittelgroßen Programm die zu Klassen gestempelten Hashstruktuen […] verwendet."
  • Das Modulkonzept ist der Sprache aufgepfropft.
  • Die gesamte Syntax ist unübersichtlich, es gibt keine EBNF o.ä. der Grammatik, "only perl can parse Perl". Für alles Mögliche gibt es eigene Syntax-Konstrukte, die aber keine wirklichen Vorteile bringen. Man merkt, dass Larry Wall Sprachwissenschaftler ist und keine Ahnung von Programmiersprachen hat. Das Ganze ist zusammengestöpselt aus alten Unix-Tools, und so schaut es auch aus.
  • Kein Exception-Handling, dadurch muss man eval() benutzen, wenn man Fehler abfangen will. Wenn Du einmal erkannt hast, wie elegant man Programmieren kann, wenn es Exception-Handling gibt, möchtest Du es nicht mehr missen. Der Clou ist nämlich, dass man nicht bei jeder Funktion eine Fehlermeldung zurückgeben muss und nicht bei jedem Funktionsaufruf auf Fehler prüfen muss.
  • Nachgestellte Kontrollstrukturen – lassen sich super einfach lesen.
  • Ständig muss man kryptische Zeichen vor den Variablennamen schreiben, teilweise mehrere. Was ich mich damit abgekämpft habe.

Ich habe auch ein halbes Jahr mit Perl programmiert. Das war die unproduktivste Zeit meines Lebens. Zum Glück habe ich dann Python entdeckt, siehe auch die ca. 20 Zeilen des "Zen of Python" [1],[2]. Ich spare es mir, aufzuzeigen, dass alle oben genannten Punkte in Python besser gelöst sind, aber zu Parametern empfehle ich einen Blick auf http://www.diveintopython.net/power_of_introspection/optional_arguments.html

Lieben Gruß
Hartmut

01.08.2016 10:01

Get current locale with Ansible

I just had the problem to get the currently set locate using ansible. This is non-trivial, since one has to consider four environment variables: LC_ALL, LC_MESSAGES (or another one), and LANG. For details see the Locale Categories documentation.

Now here is the solution, included into an ansible playbook:

# -*- indent-tabs-mode: nil -*-
---

- hosts: all
become: yes
gather_facts: false

vars:

env1:
LC_ALL: "de_DE.UTF-8"
LC_MESSAGES: "de_AT.UTF-8"
LANG: "de_CH.UTF-8"

env2:
LC_MESSAGES: "de_AT.UTF-8"
LANG: "de_CH.UTF-8"

env3:
LANG: "de_CH.UTF-8"

env4:
empty: empty


davical_default_locale: '{{ (ansible_env.LC_ALL|d(ansible_env.LC_MESSAGES)|d(ansible_env.LANG)|d("en")).split(".",1)[0] }}'

tasks:

- set_fact:
ansible_env: '{{ env1 }}'
- debug: var=davical_default_locale

- set_fact:
ansible_env: '{{ env2 }}'
- debug: var=davical_default_locale

- set_fact:
ansible_env: '{{ env3 }}'
- debug: var=davical_default_locale

- set_fact:
ansible_env: '{{ env4 }}'
- debug: var=davical_default_locale

20.02.2016 14:48

(0) Kommentare