wrkey – FireFox’s eindeutige ID

Wie Google über FireFox das Surfverhalten ausspionieren kann

FireFox macht standardmäßig von Google’s Safe Browsing API Gebrauch. Das bedeutet, dass FireFox in kurzen Abständen eine Liste mit Adressen gefährlicher Webseiten von einem Google Server abruft. Die Abstände betragen meist nicht mehr als 10 Minuten.

FireFox gleicht dann die Adresse jeder angeforderten Webseite mit der lokal gespeicherten Liste gefährlicher Webseiten ab und warnt den Benutzer, falls dieser beispielsweise auf eine Phishing-Webseite gelangen würde. Da der Abgleich mit der Blacklist lokal erfolgt, ist dies auf den ersten Blick hin unproblematisch.

Die Kommunikation mit dem Google Server kann man im HTTP traffic verfolgen, zum Beispiel mit dem FireFox Add-on HttpFox:

Ein HTTP POST Request wird an safebrowsing.clients.google.com geschickt, um die lokale Liste mit gefährlichen Webseiten zu aktualisieren. Dieser Request übermittelt unter anderem einen Parameter wrkey (wrapped key).

Der wrapped key kommt von Google und wird von FireFox einmalig mit einem GetKey Request angefordert (z.B. beim ersten Start nach der Installation von FireFox). Dafür stellt FireFox einmalig eine sichere SSL Verbindung zum Google Server sb-ssl.google.com/safebrowsing/newkey her, über die FireFox den wrapped key sowie einen client key erhält.

Unter Windows werden die beiden Schlüssel derzeit als clientkey und wrappedkey persistent in der Datei urlclassifierkey3.txt gespeichert. Zu finden ist die Datei unter Windows 7 meist in einem Unterverzeichnis von:

C:\Users\Benutzer\AppData\Roaming\Mozilla\Firefox\Profiles

Der Inhalt von urlclassifierkey3.txt sieht dann zum Beispiel wie folgt aus:

clientkey:24:GhoDWEi7rt1mnYwnInRu7J==
wrappedkey:100:ALEgNisfx_qJPmxfsu88zfuINON1683R77snhVvH-Zc6fY58W5pzUdW8zGbuFRCauxaj2OIs9aABKPkJayMllmn2byG1zkpcTg==

Google erzeugt den wrappedkey (wrkey) aus dem clientkey, indem es den clientkey mit einem privaten Schlüssel verschlüsselt. Der wrappedkey ist also die verschlüsselte Form des clientkey und kann nur von Google entschlüsselt und in den clientkey umgewandelt werden.

Der wrkey wird in dem HTTP POST Request mitgeschickt, um für den HTTP Response (die Antwort vom Server) einen MAC (Message Authentication Code) anzufordern. Der MAC dient dazu, alle Antworten vom Server vor Man-in-the-middle-Angriffen (MITM-Angriff) zu schützen. Er stellt also sicher, dass die Blacklist-Updates auch wirklich von Google kommen und nicht mit falschen Daten eines MITM kompromittiert wurden.

Der Google Server erhält den Request und wandelt den wrkey mit seinem privaten Schlüssel zurück in den clientkey um, konkateniert den clientkey mit den eigentlichen Response-Daten, erzeugt aus der Konkatenation einen 128-bit MD5 digest und schickt diesen base-64 enkodiert als MAC mit jedem Response zurück an FireFox.

FireFox kann wiederum ebenfalls aus den Response-Daten und dem clientkey den MAC berechnen und mit dem mitgeschickten MAC aus dem Response vergleichen. Sind die MACs gleich, kann den Daten vertraut werden.

Mit dem Response setzt Google ein Cookie in FireFox. Der bei Google angestellte Product Manager Ian Fette (u.a. zuständig für die Sicherheit bei Google Chrome) rechtfertigt dies in einem Bug-Tracker damit, dass Google’s anti-DoS Infrastruktur unter anderem Cookies einsetzt.

Das Cookie ist aber nur ein Problem bei der Verwendung von Google’s Safe Browsing API durch FireFox. Der wrkey ist das zweite Problem. Er ist im Prinzip nichts anderes, als eine eindeutige ID, die alle paar Minuten an Google übertragen und mit der aktuellen IP des Benutzers verknüpft wird. Der wrkey ändert sich nicht, selbst wenn die eigene IP erneuert wird.

Damit ist der wrkey ein absolutes Datenschutz-Desaster, denn Google kann von einer IP zurück auf einen wrkey und damit auf einen FireFox-Benutzer schließen. Genau genommen sogar auf ein FireFox-Profil. Wird also eine Webseite besucht, welche Dienste von Google verwendet oder nachlädt (z.B. Google+, YouTube, Gmail, google-analytics.com, google.com, etc.), dann hätte Google die Möglichkeit, die besuchte Webseite dem wrkey des jeweiligen Benutzers zuzuordnen.

Hat der Benutzer auch noch einen Google Account, können die besuchten Seiten auch gleich noch mit den dort hinterlegten persönlichen Daten verknüpft werden. Auch der Private Browsing mode von FireFox schützt davor nicht.

Es lohnt an dieser Stelle, die Diskussion der Entwickler bei Mozilla und Google zu lesen. Interessant ist dabei, wie sehr die Google-Seite versucht, die Verwendung des Cookies und des wrkeys zu rechtfertigen und zu erhalten. Da Google der Hauptgeldgeber für das FireFox-Projekt ist, dürfte diese Problematik wohl auch weiter bestehen bleiben.

Google selbst versucht natürlich, das Datenschutz-Problem herunterzuspielen und behauptet, alle Logs regelmäßig zu löschen und schon gar nicht mit persönlichen Daten zu verknüpfen. Google wird aber nicht umsonst als Datenkrake bezeichnet, die alle Dienste „kostenlos“ anbietet, um so an möglichst viele Nutzerdaten zu gelangen. Und warum sollte man so naiv sein und Google glauben? Einem Konzern, der mit der NSA zusammenarbeitet und schon zu Rekordstrafen verurteilt wurde, weil er mit einem Cookie-Trick versuchte, Benutzer des Safari-Browsers auszuspionieren.

Bereits die Existenz dieser Funktionalität stellt ein Problem dar, selbst wenn Google sie nicht mißbrauchen würde. Jeder, der Google durch rechtliche, behördliche oder geheimdienstliche Schritte kontrollieren kann, ist in der Lage, die Funktion für seine Zwecke einzusetzen.

Notlösung

Momentan gibt es zumindest in FireFox 11-19 nur eine Notlösung, das Abschalten des Phishing-Schutzes bzw. der Safe Browsing API Requests, indem man die zwei Häkchen in den Sicherheitseinstellungen von FireFox entfernt (ACHTUNG: auf eigene Gefahr!):

FireFox in Sachen Datenschutz und Tracking noch weiter abriegeln

Cookies können und werden ebenfalls zur Verfolgung und Identifizierung von Internet-Usern verwendet. Daher sollte man sie regelmäßig löschen.

HTTP-Cookies

Man behält am besten nur die HTTP-Cookies, die man wirklich braucht (z.B. von Foren und online shops). Alle anderen HTTP-Cookies (z.B. die von Google) sollte man zumindest immer beim Beenden von FireFox löschen lassen. Das geht mit dem Add-on selectivecookiedelete, mit dem man eine „weiße Liste“ anlegen kann, welche Cookies nicht gelöscht werden sollen. Achtung: Die FireFox interne Option zum Löschen aller Cookies muss deaktiviert sein, damit selectivecookiedelete funktioniert! Die Option „Cookies von Drittanbietern akzeptieren“ sollte man übrigens auch unbedingt deaktivieren!

Flash-Cookies (auch Local Shared Objects bzw. LSO genannt)

Diese Art von Super-Cookies landen auf der Festplatte, wenn man das Flash-Plugin im Browser installiert hat und eine Webseite davon Gebrauch macht. Mit dem Add-on BetterPrivacy, kann man sie automatisch löschen lassen.

DOM Storage (auch Web Storage genannt)

Leider können weder selectivecookiedelete noch BetterPrivacy in der aktuellen FireFox Version auch den DOM Storage löschen, vermutlich weil die Datenbankdatei webappsstore.sqlite in den neueren FireFox-Versionen gesperrt ist.

Da sich der DOM Storage ebenfalls hervorragend eignet, um Super-Cookies anzulegen, sollte auch dieser regelmäßig gelöscht oder komplett deaktiviert werden. Deaktivieren lässt sich der DOM Storage mit folgenden Schritten:

  1. about:config in die Adresszeile von FireFox eingeben und bestätigen
  2. Nach dom.storage.enabled suchen und diesen Wert auf false setzen

Sonstiges

Auf dem Computer sollten keine Hintergrundprozesse von Google laufen (z.B. Google Updater etc.), da diese natürlich auch mit der aktuellen IP nach Hause telefonieren.

Die FireFox Add-ons und Plugins sollten natürlich auch nur das Nötigste enthalten. Google installiert auch gerne mal ungefragt FireFox-Plugins, wenn man z.B. Programme wie Google Earth oder Google Chrome auf dem Rechner installiert.

Auch sonstige Toolbars, die gerne mal bei der Installation von Java oder anderen Programmen mitinstalliert werden (wenn der Benutzer nicht aufpasst), sollten aus FireFox entfernt werden.

Empfehlenswert ist auch die Installation von NoScript. Dieses Add-on macht es möglich, Skripte nur auf bestimmten Webseiten zuzulassen. Dadurch kann verhindert werden, dass über Java und Flash weitere Informationen über das eigene System abgefragt werden (z.B. die installierten Schriftarten). Je mehr Informationen gesammelt werden können (gemessen in Bits), umso leichter ist es, eine Art Browser-ID anzufertigen. Die folgende Webseite kann verwendet werden, um die Identifizierbarkeit des eigenen Browsers zu testen:

https://panopticlick.eff.org/

Außerdem kann man mit NoScript das Tracking durch Facebook’s Like-Button unterbinden und ist wesentlich besser gegen attackierende Webseiten geschützt.

Dieser Beitrag wurde unter IT abgelegt und mit , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

Eine Antwort auf wrkey – FireFox’s eindeutige ID

  1. XY sagt:

    http://my.opera.com/community/forums/topic.dml?id=1620322&t=1360417831&page=1#comment13815362
    Ist zwar, nicht gerade das selbe thema, aber in den gleichen Richtung, wollte eigentlich privat Schicken, aber habe nirgendswo gefunden wie.

Schreibe einen Kommentar

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