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.
Podcast: Play in new window | Download
Very interesting article. I’m setting a robust password on every service installed in my local network, usually.
But how it’s possible to use openID (or similar) with syncthing? I’m migrating a lot of stuff from services like dropbox to a local instance of syncthing then thinking about this kind of attacks make me a little scary.
I don’t know if the local interface password is enough.
So syncthing has two interface: the data plane sync, which is protected / PKI, and the control plane (web).
We can see its CORS setup as follows:
$ curl -I -X OPTIONS localhost:8384HTTP/1.1 204 No Content
Access-Control-Allow-Headers: Content-Type, X-API-Key
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE, OPTIONS
Access-Control-Allow-Origin: *
Access-Control-Max-Age: 600
Date: Tue, 16 Mar 2021 16:32:38 GMT
from here, we can see it cares not where the connections come from, and, allows X-API-Key (a proprietary header), avoiding the use of the credentials part of CORS.
As for integrating w/ openid. One would normally do this w/ either changing the source code, or, adding an authenticating proxy (oauth2 proxy etc). In the latter case it would need to be a side-car pattern to avoid the localhost accessible port 8384 anyway.
as for the strength of the password. With openid you don’t have local passwords. WIthout it, somewhere in your home directory there exists a file that tools like this use to store the password… So it depends on the risks you are protecting against.