Archiv des Autors: Tim

Privacy Badger im Vergleich

Hallo zusammen,

im Vortrag zu Web-Tracking auf Klinikwebseiten, den ich schon im vorherigen Beitrag kurz angesprochen hatte, zeigte ich einen Vergleich der Restriktivität zwischen Ghostery, NoScript, Disconnect und natürlich Addon-freies surfen.

UPDATE: Der Inhalt bzw. die Ergebnisse des Vortrags wurden auf Netzpolitik.org nochmal zusammengefasst, was mich sehr gefreut hat!

Blocker_Vergleich_v01

Abbildung 1: Netzwerkverbindungen zwischen Erstparteien (schwarz) und Drittparteien (rot) bei Abruf von 839 Webseiten (jeweils die Hauptseite) von Krankenhäusern und Kliniken.

In Abbildung 1 ist das Trackingnetzwerk als Graph zu sehen und zeigt wie ungewollte Verbindungen zu Drittanbietern durch die entsprechenden Addons blockiert werden. Dies erkennt man insbesondere daran, dass der äußere Rand breiter wird (mehr unverbundene Erstparteien) und der innere Kern schwacher ausgeprägt ist (weniger Konnektivität). Es ist wichtig einzusehen, dass hierbei nur die Restriktivität gemessen wurde, was alleine noch kein Qualitätsmerkmal darstellt. So würde NoScript den „normalen Benutzer“ möglicherweise überfordern. Ghostery und Disconnect bedürfen, abgesehen von einer ersten Konfiguration, sonst keiner weiteren Benutzerinteraktion.

Nach dem Vortrag kam die Frage auf, wie es sich mit dem Privacy Badger verhält. Dies hatte ich leider nicht vorbereitet, ist aber durchaus berechtigt. Aus diesem Grund habe ich heute die Analyse auch mal mit diesem Addon durchgeführt. Aufgrund der Tatsache, dass der Privacy Badger erst noch „Erfahrungen“ sammeln muss, habe ich vor dem Test 200 deutsche Webseiten (.de-Adressen aus der Alexa Top 1M) besucht die dabei entstandene Konfigurationsdatei für die weitere Analyse verwendet. Darüber hinaus wurden keine weiteren (manuellen) Konfigurationen vorgenommen.

In Abbildung 2 ist das entstandene Trackingnetzwerk abgebildet. Dieses unterscheidet sich äußerlich zunächst nur wenig vom Surfen ohne Addon.

Blocker_PrivacyBadger_v01

Abbildung 2: Trackingnetzwerk mit und ohne Privacy Badger.

Ähnliches zeigt sich auch in der Top 20 der am häufigsten eingebetteten Drittparteien und Vergleichswert ohne Privacy Badger (Messung vom 12.08.2016). Es wird gezeigt, wie viele Erstpartien (First Parties) eine entsprechende Drittpartei einbetten (absteigend sortiert).

# Hosts Mit Privacy Badger Ohne Privacy Badger
1 www.google-analytics.com 285 (34.0%) 287 (34.2%)
2 fonts.gstatic.com 209 (24.9%) 210 (25.0%)
3 fonts.googleapis.com 202 (24.1%) 204 (24.3%)
4 ajax.googleapis.com 134 (16.0%) 134 (16.0%)
5 www.google.com 74 (8.8%) 78 (9.3%)
6 ssl.google-analytics.com 47 (5.6%) 49 (5.8%)
7 s.ytimg.com 45 (5.4%) 48 (5.7%)
8 maps.google.com 42 (5.0%) 43 (5.1%)
9 www.youtube.com 41 (4.9%) 45 (5.4%)
10 i.ytimg.com 40 (4.8%) 38 (4.5%)
11 maps.googleapis.com 39 (4.7%) 40 (4.8%)
12 stats.g.doubleclick.net 38 (4.5%) 43 (5.1%)
13 csi.gstatic.com 35 (4.2%) 36 (4.3%)
14 maps.gstatic.com 31 (3.7%) 32 (3.8%)
15 code.jquery.com 29 (3.5%) 30 (3.6%)
16 piwik.sana.aspr.de 29 (3.5%) 29 (3.5%)
17 www.facebook.com 29 (3.5%) 28 (3.3%)
18 code.etracker.com 25 (3.0%) 26 (3.1%)
19 connect.facebook.net 24 (2.9%) 23 (2.7%)
20 cdnjs.cloudflare.com 22 (2.6%) 21 (2.5%)
googleads.g.doubleclick.net 39 (4.6%)
static.doubleclick.net 38 (4.5%)

In der Tabelle ist zu sehen, dass nur sehr wenige Hosts kategorisch ausgeschlossen worden sind. Hier muss man allerdings aufpassen, denn (anders als Ghostery) bietet der Privacy Badger drei Optionen mit Drittparteien umzugehen: Neben An und Aus gibt es noch eine „Mittel“-Einstellung, die das Tracking durch unterdrücken von Referer und Cookies minimieren soll. Diese „Mittel“-Einstellung findet sich häufig, sind jedoch in den oben gezeigten Statistiken nicht sichtbar. Ich halte jedoch die Wirksamkeit dieser Maßnahme für sehr fragwürdig, was allerdings nochmal intensiverer Analyse bedürfte.

Auch wenn ich den Privacy Badger als ein sympathisches Tool empfinde, sehe ich die getroffenen Grundeinstellungen als zu schwach an. Sehr viel wird zunächst akzeptiert und die Entscheidung auf den Benutzer geschoben. Diese können auch nicht pauschal getroffen, sondern müssen für jeden Tracker einzeln eingestellt werden. So ist es hier, anders als bei Ghostery, mir (über die Oberfläche) nicht möglich, vor dem Test eine restriktive Konfiguration festzulegen bzw. möglichst viel zu blockieren. Und so sehr ich es begrüße, dass der Algorithmus zur Identifizierung von Trackern so offen einsehbar ist, kann ich mir durchaus vorstellen, dass Web-Tracking Firmen dieses Wissen ausnutzen. Letzteres soll jedoch nicht als Kritik verstanden werden.

Alles in allem ist es sicher eine gute Ergänzung und hilft bei der Entscheidungsfindung deutlich besser als RequestPolicy (was zunächst alles blockiert), stellt jedoch leider kein Wundermittel dar. Ohne aktives Handeln durch den Benutzer ist dieses Tool, in meinen Augen, keine wirkliche Verbesserung zu vorher. Man muss jedoch erwähnen, dass der Benutzer nach der Installation auch darauf hingewiesen wird, dass er tätig werden muss.

Die Ergebnisse der anderen Addons sollten jedoch nicht als Produktwerbung missinterpretiert werden. Andere denkbare Gefährdungen, z.B. die interne Datenweitergabe, können nicht ausgeschlossen werden.

Caching Vorteile bei CDNs

Hallo zusammen,

am kommenden Freitag werde ich auf dem mrmcd 2016 in Darmstadt einen Vortrag über Web-Tracking auf Webseiten von Krankenhäusern und Kliniken halten. Dabei werde ich die Ergebnisse meiner letzten DuD-Publikation vortragen sowie noch einige dafür neu erarbeitete Inhalte.

In Vorbereitung dessen habe ich gestern noch einen Test durchgeführt, was Content Delivery Networks (CDN, auch: Content Distribution Network) eigentlich bringen. Solche Dienste sind darauf spezialisiert, Daten (die in Webseiten integriert werden) mit hoher Geschwindigkeit und geringen Antwortzeiten den Besuchern bereitzustellen. Nicht selten wird jedoch auch hervorgebracht, dass der User die verlinkten Bibliotheken und Schriftarten selbst auf seinem Rechner cachen, über mehrere verschiedene Webseiten hinweg „konservieren“ und die Netzwerklast darüber minimieren kann. So z.B. hier (Nummer 2).

Diesen zuletzt genannten Vorteil wollte ich mir mal genauer ansehen. Es ist weniger eine repräsentative Studie, sondern dient mehr dazu einen Eindruck zu bekommen. So habe ich 150 Webseiten auf zwei verschiedene Wege betreten: mit einem jeweils neuen (unbenutzten) Firefox Profil und mit einem persistenten Profil. Da Selenium persistente Profile eigentlich nicht unterstützt, musste hier noch ein Workaround geschaffen werden.

Die Ergebnisse sind für mich doch sehr überraschend. Die Anzahl der Verbindungen zu den Erstparteien (Webseiten) und darin verlinkten Drittparteien blieb konstant (nur 2 Verbindungen weniger bei ca. 7200 Verbindungen). D.h. die Anzahl der geladenen Ressourcen hat sich nicht (signifikant) verändert. Wenn man sich die HTTP Header der Responses anschaut sieht man, dass nur 16 Ressourcen mehrfach verwendet wurden (304 Not Modified). Dabei überwiegend JavaScript-Dateien von Trackern und ein paar Schriftarten. Die Top 10 der am häufigsten eingebetteten Drittparteien sowie die Anzahl der Verbindungen blieb konstant. Verbindungen spare ich also nicht, maximal etwas Traffic.

Nun könnte man argumentieren, dass 150 Webseiten zu wenig sind um vom Caching-Vorteil zu profitieren. Während jedoch das normale Standardprofil nur 24 MB groß ist, ist das persistente nach den 150 Webseiten auf 222 MB gewachsen. Auch wenn Speicherplatz heute kein so großes Thema mehr ist: beliebig Luft nach oben ist hier auch nicht. Zu prüfen wäre noch, wie die Cache-Strategie von Firefox im Detail aussieht.

Es ist, wie gesagt, nicht repräsentativ. Es erwächst jedoch der Eindruck, dass der Cache Vorteil eines CDN geringer ist als erwartet. Dies ist auch der überwältigenden Vielfalt verschiedener Bibliotheken und Schriftarten geschuldet. Die verbleibenden Vorteile von CDNs bleiben natürlich unberührt.

Mit unsicherem Code ins Weltall

Hallo zusammen,

zur Abwechslung mal was über Krypto. Ein Bekannter hat mir einen Hinweis gegeben, dass in einer Stargate SG1 Folge (S7E09 „Avenger 2.0“) auf einer Tafel etwas geschrieben stand, was recht „kryptisch“ aussieht. Hier ein Bild der Szene (ca. Minute 12):

Bildzitat aus Stargate SG1 Episode Staffel 7 Folge 9 "Avenger 2.0"

Bildzitat aus Stargate SG1 Episode Staffel 7 Folge 9 „Avenger 2.0“

Auf den ersten Blick vermutet man Java, was natürlich recht amüsant wäre: Ob (damals Sun) Oracle wohl eine JVM für Stargates (bzw. Wahlgeräte) anbietet? Tatsächlich ist es jedoch C#, was es nicht weniger amüsant macht. Da es eine über 10 Jahre alte Episode ist, ist dies natürlich auch anderen schon aufgefallen. Es handelt sich bei diesem Quelltext um eine etwas intensiver kommentierte Version einer Klasse zur Entschlüsselung von Dateien auf dem Dateisystem, die man hier finden kann. Analog gibt es natürlich auch eine Version zur Verschlüsselung.

Es ist natürlich so, dass die „Macher“ der Serie nur etwas kryptisch aussehenden Programmtext präsentieren wollten und sind dabei über diese Zeilen gestolpert. Aber aus Neugier habe ich mir das Programm etwas näher angesehen. Es besteht aus einer Hilfsklasse StoreCryptoStream, aus einer Klassenmethode zur Generierung des Schlüsselmaterials (GenerateKey) und einer weiteren Klassenmethode zur Vorbereitung und Durchführung der Entschlüsselung (DecryptData).

In der DecryptData-Methode werden Streams eingerichtet und die Entschlüsselung durchgeführt. Aufmerksam wurde ich, als ich mir die GenerateKey-Methode genauer angesehen habe, welche aus einer Passphrase (String) das zur Verschlüsselung (DES) passende Schlüsselmaterial generiert:

          symKey = new byte[8];
          symIV = new byte[8];

          SHA1_CSP sha = new SHA1_CSP();
          sha.Write(bt)
          sha.CloseStream();
          for (int i = 0; i < 8; i++) {
              symKey[i] = sha.Hash[i];
          }
          for (int i = 8; i < 16; i++) {
              symIV[i - 8] = sha.Hash[i];
          }

Das fand ich recht interessant: Hier werden, aus dem Hashwert (SHA1) der Passphrase (String), Schlüssel und Initialisierungsvektor abgeleitet. Da wir bei DES (DecryptData-Methode) eine 64 Bit Schlüssellänge (wovon 56 effektiv sind) und 64 Bit Blocklänge haben, brauchen wir also 128 Bit die uns durch den 160 Bit SHA1 zur Verfügung stehen. Ein Hashverfahren zu verwenden um aus einer Passphrase Schlüsselmaterial zu gewinnen ist ja nicht neu: Dies findet auch bei PBKDF2 statt. Es wird zur Erhöhung der Brute-Force-Resistenz eingesetzt, da die Berechnung eine gewisse Zeit in Anspruch nimmt und nicht abgekürzt werden kann. Dabei werden jedoch sehr viel mehr Iterationen durchgeführt (z.B. 100 000) und nicht nur eine.

Die meisten symmetrischen Blockchiffren benötigen keinen Initialisierungsvektor (IV): so auch der DES nicht. Da allerdings regelmäßig keine blockweise Verschlüsselung sondern ein Betriebsmodus zum Einsatz kommt, hat er einen festen Platz in den Programmbibliotheken. Normalerweise wird der IV vor der Verschlüsselung zufällig generiert und vor/nach der Übermittlung als Klartext mitgesendet. Der Empfänger kann mittels geheimen Schlüssels und mitgesendeten IVs das Chiffrat entschlüsseln. Die Generierung eines IVs aus der Passphrase hat den enormen praktischen Vorteil, dass diese dem verschlüsselten Ciphertext nicht beigefügt sein muss. Der Nachteil ist, dass der IV dann nicht mehr zufällig generiert wird sondern deterministisch vom Schlüssel bzw. der Passphrase abhängt.

So was Ähnliches wird zwar auch im SSH Protokoll durchgeführt. So wird dort unter Einsatz einer Hashfunktion und unterschiedlichen Salt-Werten mehrere Schlüssel und IVs generiert. Allerdings wird hierbei schon zu einem frühen Zeitpunkt der „Zufall“ eingebracht und genau diese Zufälligkeit fehlt beim gezeigten Programm vollständig.

Ist das jetzt gut oder schlecht? Ich habe dazu recherchiert und mir meine eigenen Gedanken gemacht und die Antwort ist: Es kommt darauf an, ist aber fast immer schlecht.

Nehmen wir z.B. Stromchiffren (wie, mittlerweile unsicher, RC4). Hier würde, bei gleichem Passwort, immer der gleiche IV und damit der gleiche Schlüsselstrom generiert werden. Sofern zwei verschlüsselte Texte mit dem gleichen Schlüsselstrom verschlüsselt sind, könnten diese gegenseitig ge-xor-t und damit der Schlüsselstrom herausgerechnet werden. Ebenso bei bei Blockchiffren mit dem entsprechenden Betriebsmodus wie dem Cipher Feedback Mode (CFB) oder dem Output Feedback Mode (OFB): Da hier aus einer Blockchiffre eine Stromchiffre konstruiert wird, haben wir exakt das gleiche Problem. Bei diesen Verfahren hängt die Sicherheit sehr stark an der Zufälligkeit des IVs, welcher so jedoch nicht mehr zufällig ist.

Wie ist es bei einer Blockchiffre im ECB und CBC Modus? Beim ECB-Modus sind wir schmerzfrei, denn dort wird der IV nicht verwendet. Müssen dabei jedoch die allgemeine Unsicherheit des ECBs hinnehmen. Beim CBC-Modus (den ich schonmal erklärt habe) haben wir zunächst auch kein Problem. Allerdings muss man hierbei gut aufpassen: Verschlüsselungsbibliotheken werden beim CBC-Modus den IV ans Ende des Chiffretextes setzen, da dieser üblicherweise zufällig generiert und zur Entschlüsselung gebraucht wird. Das bedeutet aber, dass wir dem verschlüsselten Text ein (Teil)Hash des Passwortes mitsenden! Möglicherweise kann genau dieser Teilhash dann in einer Rainbowtable für SHA1 gefunden und entschlüsselt werden. Ebenso erleichtern wir dem Angreifer die vollständige Schlüsselsuche beträchtlich. Allgemein wird der IV als „öffentlich“ angesehen und wird dementsprechend ungeschützt sein. Eine Klassifizierung, welcher ein einfacher SHA1 Hash der Passphrase nicht haben sollte.

Zusammenfassend sollte man den IV zufällig generieren und auch genau so verwenden. Nur wenn man ganz genau weiß was man tut, kann man von dieser Regel abweichen.

Wie ist es nun bei diesem Programm? Das ist leider nicht ganz klar, denn der Programmtext lässt sich (zumindest unter Visual Studio) nicht mehr übersetzen: in über 10 Jahren hat sich C# diesbezüglich weiterentwickelt. Man könnte das Programm zwar durch Anpassungen wieder lauffähig bekommen, würde jedoch damit ggf. auch die Funktionsweise beeinflussen. Es ist zu vermuten, dass hier der ECB-Modus zum Einsatz kam und so der IV keine Rolle spielt. Wenn der CBC eingesetzt wurde, müsste man prüfen, ob dem Ciphertext der IV beigelegt war. So oder so war jedoch schon damals (und ist heute weiterhin) von der Nutzung dieses Quelltextes (bzw. einer lauffähigen Variante) grundsätzlich abzuraten.

Dies könnte auch der Grund sein, weshalb der in dieser Episode programmierte „Avenger“ (Computervirus) so unsicher war ;-).

Dunkel wirds

Hallo zusammen,

nach den kürzlichen Vorfällen hat das BKA ein Poster zum Thema Darknet verbreitet, was ich als Bildzitat hier zeigen möchte.

Das BKA klassifiziert dabei das „Surface Web“ als das, was über Suchmaschinen gefunden werden kann. Das „Deep Web“ als das, was nicht gefunden werden kann, da es z.B. zugriffsbeschränkt ist. Es folgt, dass das „Darknet“ ein Teil dieser zugriffsbeschränkten Menge sein muss. Ich sehe dies zwar als technisch fragwürdig an, lasse es aber zur Vereinfachung mal so stehen.

Da ich mich im letzten Jahr viel mit der Messung von Web-Tracking beschäftigt habe, war ich bei diesem Bild sehr verblüfft, da ich mir kein Verfahren vorstellen kann, das zugriffsbeschränkte Internet (Deep Web) zu quantifizieren. Allein die Kriterien fallen mir schon schwer, denn es gibt z.B. auch Webseiten, die nur über IPv6 und nicht über IPv4 erreichbar sind. Ist das dann auch Deep Web? Da brauchte ich einfach mehr Informationen.

Auf kritische Nachfrage von netzpolitik.org wurde bekannt, dass die vom BKA verwendete Datenbasis eine Studie aus dem Jahr 2003 ist. Diese ist sehr umfangreich aber, wenn man nach „Deep Web“ sucht, findet sich folgendes:

Note that we were only able to sample the “surface web”—the static, publicly available web pages which represent a relatively small portion of the entire Web. We were not able to download or measure the dynamic, database-driven websites which comprise the “deep web.” As quantified in a landmark study by BrightPlanet in 2000, the “deep Web” is perhaps 400 to 550 times larger than the information on the “surface.”
[…]
Note that the Web consists of the surface web (fixed web pages) and what Bright Planet calls the deep web (the database driven websites that create web pages on demand).

Es geht also nicht um zugriffsbeschränkte Webseiten, sondern (auch) um dynamisch generierte. Klar: Wenn man z.B. das Auskunftssystem der Deutschen Bahn betrachtet, ist die Datenbasis deutlich größer als das, was man auf der Hauptseite sieht. Hat mit Zugriffsbeschränkung jedoch nichts zu tun. Darüber hinaus, wie im Dokument angegeben, wird die Größe nur geschätzt. Das ist auch verständlich, denn etwas, dass nicht sichtbar ist, kann man nicht messen. Dass die Schätzung so weit in der Vergangenheit liegt, macht es dann auch nicht mehr viel schlimmer.

Auch wenn mir die Polizei grundsätzlich sympathisch ist, finde ich diese „Panikmache“ auf Basis fehlerhaft interpretierter Informationen sehr schade. Ich hoffe wirklich, es war nur ein handwerklicher Fehler.

Unclevere Hardware

Hallo zusammen,

durch einen Beitrag von fefe bin ich auf diese Amazon Rezension aufmerksam geworden.

Bei diesem Produkt handelt es sich, soweit ich dies aus der Produktbeschreibung herauslesen konnte, um eine „smarte“ Steckdose, die über WLAN bzw. eine App gesteuert werden kann. Der Rezension nach basiert dies auf dem ESP8266-Chip, von welchem ich auch ein paar besitze. Sie sind derzeit der günstigste Weg (2-3€), eine (kleine) elektronische Schaltung ins WLAN zu bekommen sofern man keine zu hohen Ansprüche hat und etwas Geduld mitbringt.

Der Rezensionist hat sich etwas Mühe gemacht, das Gerät genauer unter die Lupe zu nehmen. Sofern sich die steuernde Hardware (Smartphone+App) im WLAN befindet, werden die Befehle wohl direkt an die Steckdose übermittelt. Sofern der Nutzer jedoch außer Haus ist, wird das Ganze über einen Server in China gelenkt:

If your phone is connected to the same network as the socket then this is just done by sending a command directly, but if not you send a command via an intermediate server in China (the socket connects to the server when it joins the wireless and then waits for commands).

Ich denke die technischen Gründe hierfür sind klar. Der Hersteller wollte damit Probleme durch wechselnde IP-Adressen und vor allem notwendige NAT-Weiterleitungsregeln umgehen. Es muss auch beachtet werden, dass insb. im asiatischen Raum die Verwendung von NAT deutlich intensiver ist als in Europa. Daher ist IPv6 dort auch schon weiter fortgeschritten als hier. Wäre interessant, ob die Steckdose hierfür im Sekundentakt (polling) eine Anfrage stellt und mit welchem Protokoll. Sinnvoll gelöst wäre es (mMn), wenn in gewissen Intervallen ein UDP-Datagramm gesendet und damit eine Lücke im NAT geöffnet wird, durch die der Server dann antworten kann, wenn es notwendig ist. Flusskontrolle ist hier ohnehin nicht gefragt und quittieren kann man die Befehle auch manuell.

Weiter geht’s in der Rezension:

The command packets look like they’re encrypted, but in reality there’s no real cryptography here at all. I wrote a simple program to decode the packets and looked at them in more detail. There’s a lot of unnecessary complexity in the packet format, but in the end the relevant things are just a command and the MAC address of the socket. On the local network this is sent directly to the socket, otherwise it goes via the server in China. The server looks at the address and uses that to decide which socket to pass it on to. Other than the destination, the packets are identical.
This is a huge problem. If anybody knows the MAC address of one of your sockets, they can control it from anywhere in the world. You can’t set a password to stop them, and a normal home router configuration won’t block this.

Hier ist natürlich ein Nerv getroffen. Hier scheint einfach die primitivste Form (Security by obscurity) gewählt worden zu sein: Die App übermittelt dem Server einen Befehl bzgl. einer MAC-Adresse und bei einer Anfrage von einer MAC-Adresse wird dieser Befehl weitergegeben. Hier ist natürlich offensichtlich, dass die MAC-Adresse Bestandteil des Protokolls ist, da diese auf dem Weg durch das Internet verloren geht. Eine Überprüfung findet daher nicht statt. Offenkundig kann daher jeder sowohl App, als auch Steckdose spielen.

Aber ich möchte die Sache noch etwas weiter durchdenken und überlegen, wie ICH dieses Problem gelöst hätte. Damit meine ich eine Lösung mit EINFACHEN MITTELN die auf dieser schwachbrüstigen Hardware auch funktionieren kann.

Die Tatsache, dass in der App kein Passwort hinterlegt werden kann, wäre zunächst mal noch kein Indikator für ein unsicheres Gerät. Die App könnte bei erstmaliger „Bekanntmachung“ mit der Steckdose passendes Schlüsselmaterial über WLAN austauschen, ähnlich wie bei Bluetooth: Bei erstmaliger Inbetriebnahme würfelt sich die Hardware einen Schlüssel. Hier muss noch beachtet werden, dass „Würfeln“ für diese Hardware ein schwieriges Problem ist. Daher würde ich bevorzugen, dass sowohl App, als auch Steckdose, gemeinsam ein Passwort ausknobeln. Die Smartphone-Hardware müsste gute Fähigkeiten dazu haben. Ob bei Nutzung mehrerer Smartphone-Apps verschiedene Passwörter Verwendung finden, lasse ich an dieser Stelle mal offen. Besser wäre es, aber notwendig wäre es nicht; kommt auf die Hardware an.

Das gemeinsam gefundene Schlüsselmaterial kann fortan die App verwenden um Befehle an die Steckdose zu verschlüsseln. Hierbei muss man eine Designentscheidung treffen: Möchte man einen Schutz der Vertraulichkeit und Integrität, oder genügt der Schutz der Integrität allein. Bei letzterem würde eine Hash-Funktion zur Absicherung genügen. Ich wähle ersteres, da der Aufwand nicht viel größer ist:

CMD = E(MAC + ZAEHLER + BEFEHL , SCHLUESSEL) + MAC

wobei E(Klartext,Schüssel)=Chiffretext eine symmetrische Verschlüsselungsfunktion (mit ordentlichem Betriebsmodus) und „+“ eine Konkatenation ist. So verschlüsseln wir den Befehl auf Basis des gemeinsam ausgetauschten Schlüsselmaterials. Der Zähler hat den Zweck, dass das Kryptogramm unabhängig vom Befehl (und unabhängig vom Betriebsmodus) nicht immer identisch aussieht. Durch die diffusiven Eigenschaften der Verschlüsselungsfunktion ändert sich das Kryptogramm bei Änderung des Zählers.

Hierbei haben wir jedoch noch das Problem des Replay-Angriffs vernachlässigt. Jemand, der dieses Kryptogramm abfängt, könnte diesen Befehl immer und immer wieder senden. Dies bekommt man mit einem Challenge-Response zunächst gelöst, würde das Protokoll jedoch wieder gegenüber Man-in-the-Middle angreifbar machen: theoreitisch ein Vorteil, aber nicht praktisch. Daher sehe ich hier nur zwei Möglichkeiten:

  1. die Steckdose merkt sich den Zähler im Kryptogramm und ignoriert Befehle die darunter liegen oder
  2. App und Steckdose besitzen synchronisierte Uhren.

Da Lösung 2 vermutlich über die Fähigkeiten der Hardware hinausgehen, muss man sich wohl mit 1 begnügen. Dabei muss man ggf. aber auch noch im Kopf behalten, dass dies beim Zugriff von mehreren Geräten/Apps gleichzeitig zu Problemen führt. Die bekommt man aber in den Griff.

Vermutlich wird man das Replay-Problem (oder ein verzögertes Senden) nicht mit einfachen Mitteln in den Griff bekommen. Jedoch wäre schon allein die Tatsache, dass nicht jeder in der Lage ist die Steckdose zu schalten und jeden Schaltprozess beobachten zu können. Ein Gewinn, der nur etwas mehr Implementierungsarbeit gekostet hätte.

Die Frage danach, inwieweit Personen mit Zugriff auf das WLAN auch (langfristig) Zugriff auf die Steckdose haben, lasse ich an dieser Stelle ebenfalls unbeachtet. Derzeit ist mein WLAN auch noch eine absolut vertrauenswürdige Zone für mich und die kürzliche Änderung des Telemediengesetzes wird daran wohl auch zunächst nichts ändern. Aber das ist eine andere Geschichte.

Verwundbarkeiten beim Autoupdate

Hallo zusammen,

derzeit scheinen Audits von automatischen Update-Funktionen (wieder) hoch im Kurs zu sein. So aktuell auf heise.de zu Keepass 2. Auch ASUS-Geräte ziehen ihre Updates über unverschlüsselte HTTP-Verbindungen. Vor wenigen Tagen fand man auch etwas bei Lenovo-Geräten auf golem.de – wobei Lenovo bzgl. unsicherer Bloatware häufiger in der Kritik steht. Die Frage ist, woher diese Probleme stammen.

Eine unverschlüsselte Verbindung ist auf den ersten Blick nicht zu entschuldigen, denn immerhin werden hier Daten übertragen, die bzgl. ihrer Integrität geschützt werden müssen. Viele Security Consultants werden in so einem Fall empfehlen, man soll (einfach!) mittels SSL/TLS die Verbindung schützen, das Zertifikat (Signatur, Common Name, etc.) innerhalb der Applikation auf Gültigkeit prüfen und nur über eine solch geschützte Verbindung das Update beziehen. Damit hat man sowohl Vertraulichkeit als auch Integrität erschlagen. Anschließend werden die Findings im Audit-Bericht von rot auf grün gesetzt und eine Rechnung geschrieben. Während der Umsetzung wird man jedoch schnell merken, dass es doch nicht so einfach ist.

Ist SSL/TLS erstmal aktiviert muss man sich nämlich der Frage stellen, welche Settings beim Web-Server eingestellt werden. Je restriktiver und damit „sicherer“ ich diese Konfiguration vornehme, desto eher nehme ich Inkompatibilitäten mit alten Browsern in Kauf. Sind die Settings „zu stark“, schließe ich Clients aus und sind sie „zu lasch“, ruft dies wieder Kritiker hervor. Ein Beispiel ist z.B. Perfect Forward Secrecy was bei Windows XP-Nutzern zu Problemen führen kann. Auf ssllabs.com (wer möchte, kann es mit dieser Domain testen) können diese Settings geprüft werden und man erhält im Anschluss ein Rating. Dabei werden auch Verbindungstests mit Clients durchgeführt und zeigt, welche Betriebssystem/Browser-Kombinationen mit den aktuellen Settings ausgeschlossen werden. Natürlich muss diese Abwängung stets durchgeführt werden, wenn man eine Webseite im Internet anbietet. Allerdings kann man hier ggf. auch einen HTTP-Fallback bereitstellen. Dies ist im Autoupdate-Fall nicht möglich.

Die Software kann natürlich mit allen notwendigen Software-Librarys ausgeliefert werden, damit ein „immer funktionieren“ garantiert ist. Aber ob es tatsächlich wünschenswert ist, dass jede Kleinstanwendung Bibliotheken für einen SSL-fähigen Webclient beinhaltet ist sehr fraglich. Denn so müsste die Anwendung auch für alle Sicherheitslücken in diesen Librarys aktualisiert werden. Das zieht einen riesigen Rattenschwanz hinter sich her.

Noch schwieriger ist die Überprüfung des Zertifikates. Entweder man verlässt sich hierbei auf die PKI oder man führt eine manuelle Überprüfung des Fingerprints durch. Die Nutzung der PKI hat den Vorteil, dass ich nur (einem oder mehreren) Wurzelzertifikat(en) vertraue und so jederzeit ein neues Zertifikat ausgestellt werden kann. Der Nachteil ist, dass andere dies ggf. ebenfalls können: ich also gezwungen bin, der organisatorischen Sicherheit einer PKI zu vertrauen. Ein manueller Fingerprintvergleich führt zu dem Problem, dass sobald das eigene Zertifikat kompromittiert oder verloren ist, die Anwendung manuell aktualisiert werden müsste.

Eins ist sicher: Viel kritischer als ein fehlendes Update-Verfahren ist ein implementiertes, dass nicht (mehr) funktioniert. Und auch wenn der Einsatz von HTTPS mittlerweile ein Standard ist, führt es leicht zu unvorhersehbaren Problemen, die man vorher nur aufwendig testen kann. Bei so einem wichtigen Mechanismus möchte man jedoch nur ungern Fehler riskieren.

Der Beitrag soll NICHT den Eindruck vermitteln, diese Probleme wären nicht lösbar. Es soll nur zeigen, dass es keine ganz einfache Lösung gibt bzw. solche Systeme denkintensiver sind, als sie auf den ersten Blick scheinen. Alternative Verfahren, z.B. Softwaresignaturen, bleiben an dieser Stelle mal out of scope.

Hinweis: Dieser Webauftritt bietet aktuell noch kein HTTPS an. Da weder Cookies verteilt, noch ein Login angeboten wird, gab es bis zum heutigen Tage auch noch keinen Grund für einen solchen Schutz der Vertraulichkeit. Trotzdem soll dies in naher Zukunft geändert werden.

Konferenz „Privatheit und Demokratie“

Hallo zusammen,

am 22.09.2016 werde ich einen Vortrag zu Tracking-Verfahren an der Goethe-Universität FFM halten. Der Slot dazu heisst „Ökonomie der Privatheit in der Informationsgesellschaft“.

Weitere Infos finden sich hier und das Programm gibt es hier.

Kleines Pflaster: Mehr Privacy mit wenigen Klicks

Hallo zusammen,

wenn man sich im Web bewegt, hinterlässt man überall Spuren – das ist schon fast jedem bekannt. Aktuelle Studien aus dem Jahr 2015 zeigen, dass durch Einbettungen (wie z.B. ein YouTube-Video) auf 9 von 10 Webseiten Informationen an Dritte weitergegeben werden [1].

Durch solche Einbettungen in Webseiten werden Drittparteien exakt über die besuchte Webseite informiert. Ein Beispiel um das Problem zu verdeutlichen: Ist auf einer Webseite eine Schriftart, z.B. von googlefonts oder Fonts.com, eingebunden, bewirkt dies eine Weitergabe der IP-Adresse UND der besuchten Webseite an den jeweiligen Anbieter.

Auch wenn ich dies als klaffende Wunde ansehe, möchte ich jedem ein kleines Pflaster in die Hand geben. Während sich aktive Inhalte, wie z.B. der Facebook „Like“-Button oder das JavaScript von Google Analytics, nur durch Browsererweiterungen vernünftig unterbinden lassen, können andere Formen der Datenweitergabe (z.B. durch ein eingebettetes Bild) schon mit einfachen Mitteln reduziert werden. Damit Google & Co. es also nicht ganz so einfach haben, sollte zumindest ein Teil dieser Weitergabe abgeschaltet werden.

Dies geht in Firefox (erstellt für 46.0.1) mit nur vier Schritten:

  • Schritt 1: „about:config“ in die Adressleiste eingeben.

    referer_step_1

  • Schritt 2: Den Warnhinweis akzeptieren.

    referer_step_2

  • Schritt 3: Nach „referer“ bzw. dem Einstellungsnamen „network.http.sendRefererHeader“ suchen.

    referer_step_3

  • Schritt 4: „network.http.sendRefererHeader“ auf den Wert „1“ setzen.

    referer_step_4

Tatsächlich ist die Einstellung „0“ noch restriktiver, kann jedoch zu Komplikationen bei Web-Anwendungen führen, die auf den Referer angewiesen sind (z.B. Formulare). Dies ist bei „1“ nicht zu erwarten. Ich surfe mit dieser Konfiguration schon eine ganze Weile ohne Probleme. Sollte es widererwarten doch Komplikationen geben, kann das Setting zurück auf „2“ und das mit Firefox 28 eingeführte „network.http.referer.XOriginPolicy“ Feld auf „1“ gesetzt werden.

Für Chrome gibt es beispielsweise das Addon Referer Control. Dies ist jedoch, in meinen Augen, unbedienbar. Der eingebaute Programm-Schalter, der den Referer komplett deaktiviert, ist ebenfalls nicht alltagstauglich. Da Google von der Übermittlung des HTTP-Referer profitiert, ist es nicht so überraschend, dass er im Chrome-Browser nur schwer zu unterbinden ist.

Zugegeben ist diese Referer-Problematik schon eine sehr alte. Wie jedoch hier schon erwähnt zeigen meine jüngsten Erkenntnisse, dass dies aktuell problematischer ist, als es noch vor 10 Jahren war [2].


[1] Timothy Libert: Exposing the Hidden Web: An Analysis of Third-Party HTTP Requests on 1 Million Websites. CoRR abs/1511.00619 (2015)
[2] Wambach T. and Bräunlich K. (2016). Retrospective Study of Third-party Web Tracking. In Proceedings of the 2nd International Conference on Information Systems Security and Privacy ISBN 978-989-758-167-0, pages 138-145. DOI: 10.5220/0005741301380145

 

NICHT(kein-APT) im Bundestag

Hallo zusammen,

was macht man an einem Feiertag mit schönem Wetter üblicherweise? Richtig, man sieht sich den vom BSI veröffentlichten Bericht zur Lage der IT-Sicherheit in Deutschland 2015 an! Man muss vorab schon mal sagen, dass der Bericht sehr schön ausgestaltet ist – sowohl optisch, als auch inhaltlich.

Mein persönliches Highlight war der Abschnitt über den Cyber-Angriff auf den Deutschen Bundestag. Nach der Aussage im Dokument wurde dabei nach der „klassischen APT-Methode“ vorgegangen. APT (Advanced Persistent Threat) ist ein Sammelbegriff für professionelle/gezielte Angriffe. Es gibt jedoch keine klare Abgrenzung zu „einfachen“ Angriffen, sondern wird eher über Beispiele definiert: Stuxnet war ein APT – eine Ransomware im Krankenhaus ist kein APT. Durch diese Verknüpfung mit besonders kritischen Beispielen zuckt jeder IT-Verantwortliche innerlich zusammen, wenn er von einem APT hört.

Das Vorgehen der Angreifer wird auf Seite 26 beschrieben und kann so zusammengefasst werden:

  • Einzelne Arbeitsplatzrechner wurden infiziert.
  • Tools wurden nachgeladen.
  • Backdoors wurden installiert, sowie weitere Schadprogramme und Keylogger.
  • E-Mail-Postfächer wurden sich angesehen.

Mit anderen Worten: Ein Angreifer erlangt unberechtigt Zugriff, installiert sich weitere Software auf dem System und schaut anschließend was es noch alles gibt.

Man kann natürlich nicht widerlegen, dass es ein gezielter Angriff sein könnte. Ich bezweifle nur ein wenig die Argumentation dafür im Dokument, Zitat:

„Bei der Ausbreitung im internen Netz („Lateral Movement“) setzen die Angreifer auf gängige Methoden und öffentlich verfügbare Tools, wie sie auch von weniger professionellen Tätern verwendet werden. Dies kann dadurch begründet sein, dass man eine Zuordnung des Angriffs erschweren wollte.“

Es war also deshalb ein APT, weil es nicht aussieht wie ein APT. Gut, die Informationen sind hier auch sehr knapp gehalten. Aber ich habe trotzdem die Spur eines Verdachts, dass hier auch politischen Gründe im Spiel waren: Da einfache Angriffe auf einer so kritischen Infrastruktur ja grundsätzlich ausgeschlossen sind, muss es ein professioneller gewesen sein.

Weiteres aus dem Bericht FYI:

  • Schwachstellen. Abbildung 2 (Seite 10) zeigt eine Auflistung von verbreiteten Softwareprodukten und deren Schwachstellen im Jahr 2015. Wenig überraschend ist Flash mal wieder auf Platz 1. Platz 9 wird euch sicher überraschen … Java. Aus der Hardware-Ecke wird ein Angriff vom Juli 2015 beschrieben, welche über ein USB-Stick eine Fernsteuerung des Rechners durch das Intel-Management-System (vPro) ermöglicht.
  • Kryptographie. Hier gab es im Jahr 2015 wohl wenig Neues (zumindest aus Sicht des BSI). Erwähnt werden die Angriffe FREAK (SSL/TLS) und Logjam.
  • Ransomware im Krankenhaus. Das kennen wir natürlich schon. Immerhin wird der Angriff, wie von mir auch, als „heute Alltag“ eingestuft. Das Wort „Cyber-Kriminelle“ hätte man sich jedoch auch sparen können.
  • Social Engineering per Telefon. Auch in meinem erweiterten Bekanntenkreis ist jemand Opfer von einem „Microsoftmitarbeiter“ geworden, der den naiven Nutzer zur Installation von Fernwartungssoftware aufgefordert hat.
  • Statistiken zu Spam und Botnetzen.
  • Eine Drive-by-Exploit Übersicht (Abbildung 10, Seite 32) hat mir sehr gut gefallen. Es zeigt in einer Zeitleiste die kritischen Exploits und die ausgenutzte Schwachstelle (CVE).
  • Außerdem gibt es noch einen Ausflug ins neue IT-Sicherheitsgesetz, welches seit Mitte 2015 in Kraft ist.

Es gibt jedoch noch mehr, mal drüberblättern lohnt sich auf jeden Fall.

 

Virenanfälligkeit

Hallo zusammen,

soziale Netzwerke sind ein endloser Quell der Freude:

[BLOG] 8 wichtige Gründe, warum du Java lernen solltest. → Nr. 6 wird dich überraschen

[…]

6) Durch die Programmierung in Bytecode ist Java weniger Virenanfällig

Java-Programme können vor der Ausführung verifiziert werden, da sie keine Zeiger haben und in Bytecode vorliegen. Die Verifizierung wird von Web-Browsern benutzt, um sicherzustellen, dass keine Viren enthalten sind. Java verwendet nicht Adressen aus Zahlen, sondern Namen für Funktionen und Methoden, die leicht überprüft werden können. So kann kein Java -Applet etwas ausführen oder auf etwas zugreifen, was nicht ausdrücklich im Verifizierungsprozess definiert worden ist.

Quelle: http://www.javavideokurs.de/blog/8-gruende-warum-du-java-lernen-solltest-336/

Es stimmt, 6 hat mich überrascht. Wenn man sich anschaut, dass die Java SRE allein 2016 auf sechs 10er CVE-Ratings gekommen ist, ist das schon sehr bezeichnend. Für die, die es nicht kennen: die Skala beschreibt die Schwere der Verwundbarkeit mit einer Zahl zwischen 1.0 (unbedeutend) und 10.0 (katastrophal).

Es ist zwar schon richtig, dass seit Java 7u51 das Applet gültig signiert sein muss. Aber wenn die darunterliegende Sandbox kompromitiert ist, kann man sich das natürlich sparen. Nicht umsonst bleibt in Browsern wie Firefox das Java-Plugin deaktiviert bis es wirklich gebraucht wird. Außerdem war es noch nie ein Problem an „irgendein“ gültiges Zertifikate zu kommen – man ist ja hier nicht auf ein bestimmtes angewiesen. Sowas kennen wir auch schon aus dem Hause Microsoft.

Es gibt ganz sicher gute Gründe Java zu lernen, die Security würde ich dabei jedoch nicht anführen.