Hacker News Reader

Comment by mehrdadn | Hacker News Reader

I asked this earlier and nobody had a response, so thought I'd ask it again: is there an extension to block this?

Edit: @Windows users: pip install pydivert and then try to write a script to block connections from Chrome to non-Chrome processes. you might need GetTcpTable2() or something. (Looking into this now. Check out http://stackoverflow.com/a/25431340)

View on HN

As far as I know these port scans are done using WebRTC. Using a browser extension[0] it is easy to deactivate it on the go. Personally, I always have WebRTC disabled by default (as it has several nasty security implications), and only activate it if I explicitly need it for something.

[0] https://addons.mozilla.org/en-US/firefox/addon/happy-bonobo-...

irrc, eBay uses websocket connections [0] to scan the ports. Firefox doesn't offer an option to disable websockets in the about:config page. However, I have read about workarounds by setting

  network.websocket.max-connections=0

This is a global setting and is applied to all websites. I also wasn't able to test this myself yet. Are there any good extensions for blocking websockets on for specific domains?

[0] https://nullsweep.com/why-is-this-website-port-scanning-me/

To people reading this, many websites rely on websockets for real-time information. They would likely fallback to per-refresh HTTP requests, but it also may break a bunch of sites.

As a developer on a product that uses websocket extensively, I'm afraid that this will lead to the already huge distrust in the technology.

If IT admins get wind of this they'll just block it (or never unblock it since it's been blocked by some from day 1) and our product gets degraded experience.

like dropping ICMP replies on firewalls. idiotic because it gives a very false sense of security. it's been a useless "security" practice since the 90s.

But don't firewalls drop everything inbound by default? So it's more that people don't know they should create rules to allow ICMP, no?

Connection comes from your browser i.e. localhost to yourself, firewall is not setup to block such connections in most cases.

Yes, false sense of security hits the nail on the head.

Fits right there with unnecessary password rules too.

Zonealarm's "!1ALERT!! x.x.x.x is h4x0r1ng you with ICMP packets!" sold $millions worth of placebo in early 2000.

http://download.zonelabs.com/bin/media/pdf/ZA_Manual.pdf

You could say that about JS and I am not running that shit either.

Surely the websockets angle is a bit of a red herring?

Ebay will have your IP from your request so they can run nmap against your machine from their server without your browser ever knowing about it.

I also know of a bank that does similar via an old school sort of way, their online banking login page tries to load images from urls made up of your IP and various ports.

Presumably these are targeting known ports for online banking malware C&C http traffic rather than remote desktop services though.

And this is a bank that still uses frames 'for security', so it must be an old technique!

Websockets bring them past the router and any other hardware firewall or NAT. Also various software only listens to localhost, on the assumption that local traffic is trustworthy.

They could still portscan from afar and it would still be sketchy, but using Websockets makes it worse

So does using websockets allow you to scan local IP ranges and find other devices on the LAN?

By the rule of all web technology sucks and is untrustworthy, they block 10.0.0.0 and 192.168.0.0, but inexplicably allow 172.16.0.0-172.31.255.255.

(Or at least, that was what someone else claimed last time this came up on HN)

Who's "they" in this context? It's unclear to me if this refers to eBay or browser vendors.

My understanding is it allows them to check for things listening on loopback, given they appear to be checking for SSH tunnels.

This won't actually disable websockets if I recall.

There's a blocklist that may make it into uBO in the future that blocks 3rd party access to localhost and other IANA reserved IP addresses, though.

https://github.com/uBlockOrigin/uBlock-issues/issues?q=is%3A...

That link is incorrect.

https://github.com/uBlockOrigin/uBlock-issues/issues/1070

That thread was a fun rabbit hole. !/s

This is the kind of thing the webkit team at apple raised as privacy problems with webrtc. They got called IE.

But seriously, many new specs are very obviously abusable, yet on HN people seem unwilling to accept "this feature is trivially abusable" as a reason to not give developers a new feature, even when it is user hostile.

Web specs, and the webdevs he frequently want them, need to consider abusive developers being the default users of the API.

When working on WebGL it took an absurd amount of work to get non-web folk to understand that the spec had to be very tight and verifiable. I literally had to deal with people arguing that "developers won't ship shaders that crash the machine". It was painful.

"IE". Difficult to search for what that means.

Internet Explorer. A much maligned legacy browser for legacy windows desktop platforms.

Aside from being intensely maligned and full of security holes, it doesn't (or didn't?) support WebRTC.

So being called IE is sarcastic like ha ha if you're so concerned about security downgrade to IE which doesn't support WebRTC.

I don't think that's what the poster meant by "They got called IE". IE is notable for - along with the things you mentioned - being about a decade behind in web specification support and taking non-standard approaches to whatever features it did have.

The implication being in this case that people were calling Safari too "conservative", so to speak.

The "safari is the new ie" is basically any time apple doesn't implement a web spec it's because they're trying to kill the web, and the privacy complaints are nonsense that doesn't matter. All that matters is developers having shiny new toys.

No. It uses Web Sockets.

uBlock Origin on Firefox, at least according to a previous article[0] I read on HN. Doesn't work on Chrome/Edge because they never provided the API.

[0]: https://news.ycombinator.com/item?id=23361823

https://github.com/uBlockOrigin/uBlock-issues/issues?q=is%3A...

Previous discussion mentioned a filter rule for uBlock Origin like

$websocket

to override this for sites which break use e.g.

@@gateway.discord.gg$websocket

https://github.com/uBlockOrigin/uBlock-issues/issues?q=is%3A...

uMatrix will usually stop things like this because you haven't explicitly turned them on, but I prefer to just use uBlock origin...we have a discussion and a blocklist for internal IP's here:

https://github.com/uBlockOrigin/uBlock-issues/issues?q=is%3A...

WebRTC network limiter: https://chrome.google.com/webstore/detail/webrtc-network-lim...

If this it WebRTC, uMatrix. Don't allow 127.0.0.1 anything, but specifically UHR requests in the UI. This is a fingerprinting technique I believe. My guess is they'll claim it's to prevent fraud.

uBlock Origin blocks this specific threat (and it's added a few extra filters since this article was posted), however as I noted near the end there are a bunch of other companies running these exact same scans and uBlock only has the ability to block one at a time as they pop up.

I've heard with uMatrix you can block all sites from trying to access localhost/127.0.0.1, which should stop the fingerprinting in its tracks. You may need to enable on a few sites that use localhost for legit things, but those aren't super common.

Is there a way to make Chrome ask permission before allowing a site to utilize WebRTC?

Similar to how you can make it prompt to store Cookies, provide Location, use the Camera/Mic, etc.

I'm not aware of any extension for this but i think we run browser in some kind of docker containers we could avoid this.

One thing that could break due to this could login via XYZ network which opens a new tab in the default browser for authentication.

Reply on news.ycombinator.com