Local network scanner with JavaScript

Some days ago I played around with HTML images and the JavaScript onload and onerror functionsThe onload event triggers when the image is loading, the onerror event triggers if the image can not be loaded. Furthermore I noticed that following:

  • If the image exists, the onload events triggers (obviously)
  • If the image does not exist on the remote server the onerror event triggers (after a very short time)
  • If the  server does not exists the onerror event triggers after a longer period of time.

This behaviour can be used to ‘ping’ a hosts on the local network of the user:

  1. Create image with src attribute pointing to a local IP address.
  2. Set a timeout for the image (~ 1000ms).
    1. The onerror event fires after a short period of time -> the local host exist (because the image is not present)
    2. The onerror event fires after a long period of time -> the timeout gets triggered before -> there is no local host with this IP address.
    3. The onload event fires -> The host is exists, and the image is present.

Note that only hosts running with a open port 80 can be detected this way. In combination with AJAX I made a short PoC, which provides astonishing good results. You can run the live demo here.


Beside the fact that a local network scanner with JavaScript is quite interesting, I think that this offers lots of new possibilities for attackers and trackers. It’s possible to exploit local devices for example routers and loT gadgetry. Its also possible to fingerprint the local devices, finding software versions of routers, IP cams, etc. this offers the opportunity for trackers and the advertisement industry to fingerprint the users based on their local network. Browsers should restrict the “access” to local devices,  and no informations should be leaked by timouts and error events.

Safely.link release

Two month ago I read about the DNC mail account hack – which was probably the reason for the surprising lose of Hillary Clinton. I was really fascinated, about the fact that one hacked mail account could have such a big extent on the election.

But obviously, not only the big extent of the hack is interesting, also the technique this hack was achieved. Due the public release from thousands of DNC mails, some security journalists found out, that the mail account was hacked on astonishing easy way:

in the form a URL shortened by the Bit.ly service.

According to sophos.com the hackers sent a bit.ly link which was linked to a phishing site. These short-links are often used by hackers to hide the original URL of a malicious site. Unexperienced users, who aren’t familiar with short-links, often don’t know about this potential  risk.

Despite this risk, short-links can be handy too, they can shrink a long URL to short one, so you can share it easily. Short-links offer also the opportunity to gain deep insight into your link audience, therefore short-links are often used by companies for advertisement campaigns. So, as you see they can be really useful too.

To eliminate the disadvantage of malicious short-links I developed the first safe short-link  generator: safely.link. Safely.link scans every link with the Google Safe-Browsing API  before redirecting the user. With this technology you can enjoy all advantages of short-links without be “threatened” by malware. And differently to many other short link generators, Safely.link provides lots of other cool functions, for example: a password protection for your links, statistics about your visitors, etc.

Check out the first safe short link generator: safely.link !

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.