DNIP Briefing #48: Dokumentierte Überwachung

Verschlossenes Metallgittertor mit einem Schild, das eine Überwachungskamera zeigt und den Text "Video Überwachung" trägt; im Hintergrund eine mit Graffiti besprühte Wand und grüne Vegetation.
Foto: Claudio Schwarz / Unsplash

Die Redaktion präsentiert jeden Dienstag die Geschichten, die sie bewegt, aufgerüttelt oder zum Nachdenken angeregt hat.

Überwachungskameras im öffentlichen Raum sind schon lange Alltag, oft nimmt man sie gar nicht mehr bewusst wahr. Seit einigen Jahren versuchen Freiwillige, vorhandene (oder besser gesagt «entdeckte») Kameras auf OpenStreetMap zu dokumentieren. Der CCC in Hamburg hat nun eine Webseite bereitgestellt, auf welcher gezielt nach Kameras in einer Region gesucht werden kann. Das beschränkt sich nicht nur auf Hamburg oder Deutschland, entsprechende Informationen sind auch für die Schweiz (z. B. Zürich oder Bern) vorhanden, sowie für viele andere Länder.

Staubsauger als Datensauger

Kameras eingebaut haben mittlerweile auch viele Staubsaugerroboter. Dass diese Geräte mit Internet-Anbindung zumindest latent ein Sicherheitsrisiko darstellen, dürfte hinlänglich bekannt sein. Sei es, dass sie das Passwort zum heimischen WLAN unverschlüsselt abspeichern; sei es, dass sie von aussen angreifbar sind; oder schlicht, dass viele Details über das Layout der eigenen Wohnung (unter Umständen sogar mit Bildern) an den Cloud-Speicher des Anbieters übermittelt werden, um dort die Saug-Route zu optimieren.

Einen besonders extremen Fall hat ein indischer SW-Entwickler aufgedeckt. Er überprüfte nach dem Kauf eines Staubsaugerroboters dessen Internet-Verkehr und stellte fest, dass der Roboter quasi ständig Log- und Bewegungsdaten an den Hersteller übermittelte. Diese Übermittlung war weder dokumentiert noch hatte er seine Zustimmung dazu gegeben. Er blockierte daher den entsprechenden Datenverkehr in seinem Router, nur um einige Tage zu bemerken, dass sein Roboter nicht mehr funktionierte. Das Reparatur-Center konnte allerdings keinen Fehler erkennen, bei Tests funktionierte er problemlos.

Wie sich nach vertiefter Analyse herausstellte, übermittelte der Hersteller aufgrund der ausbleibenden Log- und Bewegungsdaten einen Abschalt-Befehl an den Roboter und machte ihn so funktionsunfähig. Da im Reparatur-Center zuerst ein Firmware-Reset ausgeführt wurde, war der Abschalt-Befehl anschliessend wieder gelöscht. Der Entwickler entdeckte während seiner Analyse auch noch andere Schwachstellen, so war die Debugging-Schnittstelle der Hardware offen zugänglich und das WLAN-Passwort wurde unverschlüsselt auf die Server des Herstellers übertragen. Auch hatte der Hersteller, zumindest technisch gesehen, jederzeit die Möglichkeit, beliebige Kommandos auf dem Roboter auszuführen. 

Der Entwickler hat das Problem für sich gelöst, indem er sämtliche Internetverbindungen des Roboters unterbunden hat. Er weist in seinem Text aber auch darauf hin, dass die verwendete (hackbare) Hardware auch in anderen Robotern von Xiaomi und anderen Anbietern verbaut wird.

Digitale Selbstverteidigung

Gerade wenn es um Datenschutz und Privatsphäre geht, bleibt uns Individuen – leider – häufig nur die Eigenverantwortung und Selbstverteidigung. Die Digitale Gesellschaft hat ihre – öffentlich verfügbaren – Vortragsfolien zum Thema gerade wieder an die aktuellen Entwicklungen angepasst. In diesen werden wichtige Themen rund um Datenschutz und Datensicherheit thematisiert: die Ursachen für Überwachung, wie man seine Geräte gegen Angreifer schützt und wie man privat kommuniziert oder surft.

Wer es lieber klassisch als Text hat, findet hier einen Überblick darüber, welche Punkte man beim Schutz seiner Geräten und Onlinekonten beachten sollte sowie wie man sich etwas gegen das Tracking durch Big Tech schützt.

Cloud ohne Souveränität

Auch dass Europa sehr von einigen Grossmächten abhängig ist, dürfte sich inzwischen überall herumgesprochen haben: Öl und Gas, seltene Erden und Elektronik, IT und Clouds. Entsprechend ist IT-Souveränität inzwischen überall hoch im Kurs. Im Oktober hat die EU passend dazu das Cloud Souvereignty Framework herausgegeben und gleich eine Ausschreibung für souveräne Cloud nach diesem Framework über 180 Millionen € gestartet.

Eigentlich eine erfreuliche, vorbildliche Entwicklung​​​​​​, denn bisher sind in der Schweiz auf Bundesebene noch kaum Entwicklungen in diese Richtung auszumachen, abgesehen natürlich vom jahrzehntelangen, isolierten Engagement beim Bundesgericht oder dem September-Brandbrief des abtretenden Armeechefs gegen M365.

Die Souveränitätskategorien im eigentlichen EU-Dokument klingen grundsätzlich richtig. Seltsam sind aber die relativen Gewichte der Kriterien: Nur 10 % des Schlussergebnisses fallen auf «legal & jurisdictional sovereignty,» also das, von dem gerade alle sprechen. In den Bereichen operationelle Souveränität, Supply Chain, Technologie und Compliance (zusammen 60 %) gibt es aber etliche Punkte, in denen die US-Hyperscaler die 10 % der rechtlichen Souveränität zumindest auf dem Papier locker wettmachen können.

Es ist also gut möglich, dass ein Grossteil der 180 Millionen € dann doch in die USA fliessen; einfach neu unter dem Deckmantel der Souveränität.

Dabei hat Bert Hubert schon im Frühling einen durchdachten 11-Punkte-Plan zum Aufbau europäischer Cloud-Souveränität aufgestellt.

Wir bleiben auf alle Fälle dran.

Der AWS-Ausfall vom 20. Oktober im Detail

Der Ausfall zentraler Teile der Amazon-Cloud am 20. Oktober hat bekanntlich weltweit zu IT-Ausfällen geführt und gezeigt, dass kritische Fehler auch im Cloud-Zeitalter möglich sind, mit weitreichenden Auswirkungen. Amazon hat in der Folge einen zwar langen, aber konkret schwer lesbaren Text zu den Hintergründen veröffentlicht (ist aber damit immer noch transparenter als viele andere Anbieter). Demzufolge hatte die Komponente, welche mittels DNS-Anpassungen den eingehenden Internetverkehr abhängig von der Last auf gespiegelte Systeme verteilt, einen Fehler verursacht. Dieser führte dazu, dass gerade gültige DNS-Einträge gelöscht wurden, obwohl sie noch gebraucht worden wären, und Internet-Zugriffe danach ins Leere liefen.

Eine zumindest für Nerds detailliertere Erklärung hat ein amerikanischer Software-Entwickler veröffentlicht. Diese geht insbesondere auch darauf ein, dass eine Verquickung mehrerer Ursachen zum Ausfall als Ganzes geführt hat, und die Fokussierung auf den Root Cause (die zentrale Ursache) daher wenig hilfreich ist. Softwaresysteme sind weitaus komplexer und fehleranfälliger, als uns bewusst ist. Jedes grössere Softwaresystem (wie zum Beispiel AWS EC2) enthält eine ganze Reihe von bekannten oder latenten (noch nicht in Erscheinung getretenen) Fehlern und Störungen. Die Kunst bei Entwicklung und Betrieb solcher Systeme ist, es nach Möglichkeit zu vermeiden, dass diese Fehler zu katastrophalen Ausfällen führen.

Und schliesslich:

dnip.ch mit Deiner Spende unterstützen

Wir wollen, dass unsere Inhalte frei verfügbar sind, weil wir es wichtig finden, dass möglichst viele Menschen in unserem Land die politischen Dimensionen der Digitalisierung erkennen und verstehen können.

Damit das möglich ist, sind wir auf deine Unterstützung angewiesen. Jeder Beitrag und sei er noch so klein, hilft uns, unsere Aufgabe wahrzunehmen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Weitere Beiträge