Wie Web Of Trust (WOT) Nutzerdaten ausspähte

Das bekannte Browser Add-on “WOT – Web Of Trust” verspricht seinen Nutzern ein sicheres Surfen im Internet – durch Nachforschungen des NDR ist das Browser-Zusatzprogramm in Verruf geraten, es würde nicht nur die Integrität von Websites überprüfen sondern auch das Surfverhalten des Nutzers aufzeichnen und die gesammelten Informationen verkaufen. Mozilla und Chrome reagierten schon und entfernten das Zusatzprogramm aus ihren “Add-on Stores”. Wie das Plugin diese Daten sammelte, und inwiefern die gesammelten Daten ein Datenschutzproblem darstellen könnten, werde ich in diesem Artikel versuchen aufzuzeigen.

Um WOT einer genaueren Analyse Unterziehen zu können, zeichnete ich den Netzwerkverkehr der WOT Safari Extension auf (welches sich (immer)noch im Offiziellen Apple Safari Extensions Store befindet).

Ich besuchte nun, mit aktivierten Add-On, verschiedene Websites, während ich den Netzwerkverkehr mitschnitt. Nach dieser “Surf-Simulation” wertete ich meine gesammelten Netzwerkdaten aus:

Während der Auswertung des Netzwerkverkehrs wurde schnell ersichtlich das, das WOT-Plugin bei jeder besuchten Website eine Anfrage an die Web Of Trust  Server sendet (orange in der Abbildung markiert) .

 

screen-shot-2016-11-05-at-14-52-37
Informationen werden an die WOT Server übermittelt

Um diese Aufzeichnung besser verstehen zu können, muss man sich die eigentliche Funktion, des WOT Add-On’s wieder in den Sinn rufen: das Plugin soll den Nutzer vor potenziell Schädlichen Websites warnen um somit potenziellen Schaden z.B durch Malware verhindern. Eine Anfrage an eine Externe Datenbank, ist im Anbetracht des Umfangs an verschiedenen Websites, zwingend nötig. Dieser Abgleich der URL von der vom Benutzer besuchten Website mit einer Externen Quelle ist also unausweichlich, um die Funktion des Add-On’s zu ermöglichen.

Interessant ist hierbei aber nicht nur die Tatsache das eine Anfrage an die WOT-Server Übermittelt werden sondern auch die Chronologie der Anfrage. Die in der Abbildung orange markierte Anfrage, wurde erst nachdem die eigentliche Seite, also z.B auch potenziell Schädlicher Code, den es ja abzufangen gilt, geladen. Die potenziell schädliche Website wird bevor eine Abgleich mit der WOT Datenbank stattgefunden hat, geladen, WOT kann rein technisch keine Kompromittierung verhindern, sondern nur auf eine (mögliche) Kompromittierung hinweißen.

Die technische Realisierung sowohl auch der Abgleich mit einer externen Datenbank, ist zwar ungeschickt aber unausweichlich und stellt bis hier hin, wie ich finde, keine Verletzung des Datenschutzes da. Ein genauere Analyse zeigte mir dann das wirkliche Dilemma des WOT Add-On’s auf.

Um dieses Verstehen zu können müssen wir uns dem Inhalt der Anfrage an die externe WOT Datenbank widmen:

screen-shot-2016-11-05-at-15-29-04
HTTPS-Packet Inhalt an Web Of Trust (WOT) Server

Die Anfrage wird verschlüßelt (via SSL) an die Server übermittelt. Der HTTP Header ist soweit unauffällig, allerdings dient der gesetzte Cookie vermutlich zur eindeutigen Identifizierung des Benutzers, was für Gewährleistung der eigentlichen Funktion des AddOns nicht nötig wäre. Im HTTP Body werden die eigentlichen Daten an den Server via POST request übermittelt. Der POST Variable e (blau markiert) wird ein (zweifach) Base64 codierter String zugewiesen. Decodiert man ihn lässt sich folgender Inhalt erschließen:

s=242&md=21&pid=1HmeWXk2zOKKQInd0o85ZI74fXDKU2hg&sess=bL8JAKX3vlgG120ZJ7ni2ioB8kQiZlGC&q=https://www.test.de/&prev=https://www.test.de/&link=0&sub=safari&tmv=1.0&hreferer=https://www.test.de/&ts=1478353985192

Auch hier findet man eine Session ID zur eindeutigen Identifikation des Nutzer vor (sess=). Auch die URL wird, wie wir schon vermutet haben, übermittelt (q=).  Die weiteren Variablen sind für unsere Analyse unwichtig.

In diesem Fall werden zwar alle unsere Vermutungen bestätigt, die URL wird übermittelt und der Benutzer ist eindeutig identifizierbar, dass eigentliche Datenschutzproblem wird aber erst in einem weiteren Beispiel ersichtlich:

s=242&md=21&pid=1HmeWXk2zOKKQInd0o85ZI74fXDKU2hg&sess=jpO3xsopTBFPD2joqPeGaQuxlD94TUeU&q=https://translate.google.com/#en/de/Das%20ist%20ein%20geheimer%20Text.&prev=https://translate.google.com/#en/de/Das%20ist%20ein%20geheimer%20Text.&link=0&sub=safari&tmv=1.0&hreferer=&ts=1478364034052

Auch hier wird wieder eine Anfrage an die WOT Server gesendet, dieses mal versucht das WOT AddOn mit der externen Datenbank abzugleichen ob die Google Übersetzer Seite sicher ist (https://translate.google.com).  Wie in Fall 1 wird die Session-ID Übermittelt sowie auch die URL. Was einem in diesem Fall sofort auffällt ist, dass der gesamte URL Pfad inklusive GET-Parametern übermittelt wird. Hier ist es der Text, den ich mit dem Google Übersetzer, übersetzen wollte (“Das ist ein geheimer Text.”). GET-Parameter werden verwendet um Informationen zwischen Client und Server auszutauschen, oft werden Session ID’s oder andere Benutzer relevanten  Informationen übertragen. In seltenen Fällen werden sogar Passwörter oder noch vertraulicher Daten übermittelt. Um die eigentliche Funktion des AddOns zu gewährleisten würde es reichen nur den Hostname, in unserem Fall translate.google.com, zu Übermitteln, ohne GET Parameter. User-Spezifische Daten werden nicht benötigt um “Bösartige” Websites zu identifizieren!

Das eigentliche Dilemma ist nicht dir Übermittelung von der URL des besuchten Website (welche unausweichlich ist) sondern, die Übermittlung der Nutzer Spezifischen URL (GET) Parameter. Falls die Daten von WOT (die laut NDR aktiv verkauft werden), in die falschen Hände geraten, könnten sensible Daten gestohlen, Nutzer Überwacht, und viel Schaden angerichtet werden.

 

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *