Possibility of Blocking Requests to localhost and Reserved IP Addresses by websockets?

[ilikenwf]

I'm currently using a rules list from here, which should do this, however in theory someone suggested a hostname could be assigned to an internal IP to bypass it (not sure how true this is):

https://github.com/gwarser/filter-lists/blob/master/lan-block.txt

Are there any solutions to restricting websocket access to local network IP addresses?

For more specific targeting, it appears ebay uses check.js from some threat assessment company:

http://ghacks.net/2020/05/25/ebay-is-port-scanning-your-system-when-you-load-the-webpage

[gorhill]

What are the possible issues adding https://github.com/gwarser/filter-lists/blob/master/lan-block.txt to uBO's default lists? (maybe even importing it in the project as a uBlock list).

||::1^$third-party needs to become ||[::1]^$third-party though.

I imported the list and I see no impact on performance as per built-in benchmark.

I did see a request from the benchmark which is being blocked by that list and which was not blocked:

url=http://127.0.0.1:3033/__webpack_hmr
docOrigin=https://hltv.gainskins.com

[ilikenwf]

What are the possible issues adding https://github.com/gwarser/filter-lists/blob/master/lan-block.txt to uBO's default lists? (maybe even importing it in the project as a uBlock list).

||::1^$third-party needs to become ||[::1]^$third-party though.

I imported the list and I see no impact on performance as per built-in benchmark.

I did see a request from the benchmark which is being blocked by that list and which was not blocked:

url=http://127.0.0.1:3033/__webpack_hmr
docOrigin=https://hltv.gainskins.com

@gwarser could probably comment...

But what if a site assigns a hostname to one of these IP addresses? In such a case, would these IP blocks by regex still catch those? If not we may need to think about that too...

[gorhill]

Well it's possible to block at onHeadersReceived() time and the ip address information is available at this point, so theoretically uBO could ensure the ip address is not a local one. In that case that would not be a matter of filter list, but maybe a per-site switch.

[ilikenwf]

The amazing thing is that this is apparently a feature and not a bug in most browsers...

So I guess the question is whether it would be worthwhile to just use the list, or as your suggested per-site switch...

The author of this article, which discusses and shows some of the more malicious possibilities with a stock Firefox:

https://medium.com/@stestagg/stealing-secrets-from-developers-using-websockets-254f98d577a0

Has provided a websocket portscan test here, but it uses IP and not hostnames...still, useful for peace of mind on that front...minus domains:

http://frontend-overflowstack.com/

[ganego]

NoScript had "ABE (Application Boundaries Enforcer") enabled by default which basically blocked access from non-local domains to local domains (so opening 127.0.0.1 could still access 127.0.0.1, but internet websites could not). This helped against attackes like https://chaoswebs.net/blog/timebleed-breaking-privacy-with-a-simple-timing-attack.html (using pictures that are by default never blocked in uMatrix).

Since NS removed this feature I had no use for it anymore and switched to uMatrix with a blocklist like this: https://www.privacy-handbuch.de/handbuch_21g.htm
For a long time I wondered why uMatrix (or uBlock) does not come with this feature by default & enabled since it's just a few rules that need to be added.

Are those giant regex even necessary @gwarser ? The 127.xxx one for example is written in this guide only as ||127.0.*^$important,third-party whereas you have some giant regex that is probably much slower? Same with 172 where it might be faster just adding those 16 prefixes separately?
I once coded some script that used similar giant regex - it was painfully slow. I speed it up immensely by breaking the regex apart in smaller ones (not possible here of course) and then even more by replacing some regex with simpler string matchers.

As what does a WSS register in uMatrix? Fetch/XHR?

[ilikenwf]

I think the regex is there to protect all of the IANA reserved IP range...

…

On 5/26/20 9:08 PM, ganego wrote: NoScript had "ABE (Application Boundaries Enforcer" enabled by default which basically blocked access from non-local domains to local domains (so opening 127.0.0.1 could still access 127.0.0.1, but internet websites could not). This helped against attackes like https://chaoswebs.net/blog/timebleed-breaking-privacy-with-a-simple-timing-attack.html (using pictures that are by default never blocked in uMatrix). Since NS removed this feature I had no use for it anymore and switched to uMatrix with a blocklist like this: https://www.privacy-handbuch.de/handbuch_21g.htm For a long time I wondered why uMatrix (or uBlock) does not come with this feature by default & enabled since it's just a few rules that need to be added. Are those giant regex even necessary @gwarser <https://github.com/gwarser> ? The 127.xxx one for example is written in this guide only as |||127.0.*^$important,third-party| whereas you have some giant regex that is probably much slower? Same with 172 where it might be faster just adding those 16 prefixes separately? As what does a WSS register in uMatrix? Fetch/XHR? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1070 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADFIOWPSK4FBUZNAUC7GWLRTRY2PANCNFSM4NKQJFZA>.

[liamengland1]

Web devs could get mad if this is implemented. Third-party requests to localhost are often used to detect the presence of an application on a user's computer, which can be malicious, but also serves a purpose. For example, discord uses websockets on localhost to determine if a user already has the discord application installed, and communicate between the website and application. This happens on invite pages like this: https://discord.com/invite/valorant

Another example - website-application communication on localhost also occurs on https://screencast-o-matic.com/screen-recorder. (click the Launch Free Recorder button)

[ilikenwf]

Quite frankly it's none of their damned business because this behavior is in and of itself malicious in the case of checking multiple ports. If we can't address this fully here it should be a permissions system built into Firefox, similar to canvas permissions IMO...as should the ability to embed chrome:// images and CSS fingerprint.

…

On 5/26/20 9:28 PM, LE wrote: Web devs could get mad if this is implemented. Third-party requests to localhost are often used to detect the presence of an application on a user's computer, which can be malicious, but also serves a purpose. For example, discord uses websockets on localhost to determine if a user already has the discord application installed, and communicate between the website and application. This happens on invite pages like this: |https://discord.com/invite/valorant| Another example - website-application communication on localhost also occurs on |https://screencast-o-matic.com/screen-recorder|. (click the |Launch Free Recorder| button) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1070 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADFIOUPTBJRCUD7WIMKTNLRTR3DHANCNFSM4NKQJFZA>.

[ganego]

https://screencast-o-matic.com/screen-recorder

Interesting, they seem to actually use the TimeBleed attack vector whereas discord uses some XHR according to uMatrix.
Firefox network inspector for the site does not show anything. That really sucks.

Are those giant regex even necessary @gwarser ?

Yes. You can have local server hosted on any IP. Does not matter if Ebay is scanning only 127.0.0.1. Other pages can scan for something else.

The 127.xxx one for example is written in this guide only as ||127.0.*^$important,third-party whereas you have some giant regex

This filter is not valid - IP is not equal domain. It will match foo.127.0.com for example.

Replacing || by // will reduce false positives a bit, but can still match in query parameters. [even using start anchor with protocol (|http://127.0.*) will not prevent matching http://127.0.com for example]. Similarly filters like this ||*.local (wildcard next to domain anchor) will match any address with .local in query. ||*.fritz.box^? Why not ||fritz.box^?

that is probably much slower? Same with 172 where it might be faster just adding those 16 prefixes separately?

In uBO these Regular Expressions are tokenized - plain strings are extracted from them. In these filters it will be first octet (172 for example). uBO will use these regexes only when URL contains this token.

Same with 172 where it might be faster just adding those 16 prefixes separately?

@gorhill exposing second octet will help with tokenization?

---

I'm pretty sure ipv6 address filters from https://www.privacy-handbuch.de/handbuch_21g.htm are also wrong. For example fe80::/10 is not [fe80::*] because it ranges from fe80:0:0:0:0:0:0:0 to febf:ffff:ffff:ffff:ffff:ffff:ffff:ffff.

[gorhill]

exposing second octet will help with tokenization?

172 is a good token, it's not a common occurrence in URLs, and if ever it occurs, best to execute a single regex than 16 separate ones.

[ilikenwf]

This has now even made it to Schneier:
https://www.schneier.com/blog/archives/2020/05/websites_conduc.html