feat image

The browser was the accomplice

Ebay has recently been in the press recently for port-scanning your home. It turns out they have implemented a device finger-printing and tracking tool called ThreatMetrix. This is intriguing because it means they are fingerprinting not just your browser, but also the rest of your OS (and theoretically your home). The rationale appears to be fraud dection (and the tool is from LexisNexis).

But this got me thinking. A few years ago DNS Changers were all the rage as malware. These were little snippets of JavaScript that guessed you were too lazy to have changed the password on your home router. So they would do an HTTP post there, from your own browser, and try to change the name server, thus trapping all your traffic. I wonder what else lurks around that is protected only by the obscurity of running on your own desktop?

It turns out lots of things. Its very common for developers to run Container Registries, random containers, tools, etc., and have no password on them. They are bound to ‘localhost only’ for security. I bet your mysql or postgtres or mongodb server is like that right now.

The one that got most of my attention was SyncThing. Its a great tool to synchronise multiple machines together. And, its kind of magic, you just open http://localhost:8384/ and you are in and able to configure. Now, this is secure since of course its only available to you on your machine, right?

But, now that we see that the browser is capable of treating it no differently than any other website, we worry. The firewall does nothing. What if I am enticed to click on something bad? What if some web site I use has an upstream <script> tag to a CDN that gets compromised? What if a malicious ad happens?

Well, it would be bad. They could add a new endpoint to SyncThing and scoop up all your data there, in real time, always.

Tinfoil hat here I come.

Can I fix this with Cross-Origin-Request-Scripting (CORS)? No, that is just the destination. With the XSS headers? No, same reason.

I guess maybe the site could create a cookie, set to httpOnly, and, if not present, refuse to talk. Turns out there is a technique, called CSRF, and some applications (including my worry here, SyncThing) have a header called X-CSRF-Token- for this purpose. Does everything on your network have this? Do they implement it properly? Can it be guessed? Is it not httpOnly? Hmm. Looking into SyncThing, it won’t fix the problem, it doesn’t use httpOnly, it does this:

Set-Cookie: CSRF-Token-OFKBD=UWdyJsExyfFbC...

So, better get a password.

or better yet, get no password and use OpenID Connect.