Comment by matthberg
5 days ago
A comment I wrote in another HN thread [0] covering this issue:
Web apps talking to LAN resources is an attack vector which is surprisingly still left wide open by browsers these days. uBlock Origin has a filter list that prevents this called "Block Outsider Intrusion into LAN" under the "Privacy" filters [1], but it isn't enabled on a fresh install, it has to be opted into explicitly. It also has some built-in exemptions (visible in [1]) for domains like `figma.com` or `pcsupport.lenovo.com`.
There are some semi-legitimate uses, like Discord using it to check if the app is installed by scanning some high-number ports (6463-6472), but mainly it's used for fingerprinting by malicious actors like shown in the article.
Ebay for example uses port-scanning via a LexisNexis script for fingerprinting (they did in 2020 at least, unsure if they still do), allegedly for fraud prevention reasons [2].
I've contributed some to a cool Firefox extension called Port Authority [3][4] that's explicitly for blocking LAN intruding web requests that shows the portscan attempts it blocks. You can get practically the same results from just the uBlock Origin filter list, but I find it interesting to see blocked attempts at a more granular level too.
That said, both uBlock and Port Authority use WebExtensions' `webRequest` [5] API for filtering HTTP[S]/WS[S] requests. I'm unsure as to how the arcane webRTC tricks mentioned specifically relate to requests exposed to this API; it's possible they might circumvent the reach of available WebExtensions blocking methods, which wouldn't be good.
0: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
There is a specification for blocking this:
https://wicg.github.io/private-network-access/
It gained support from WebKit:
https://github.com/WebKit/standards-positions/issues/163
…and Mozilla:
https://github.com/mozilla/standards-positions/issues/143
…and it was trialled in Blink:
https://developer.chrome.com/blog/private-network-access-upd...
Unfortunately, it’s now on hold due to compatibility problems:
https://developer.chrome.com/blog/pna-on-hold
Yep! Unfortunately its main method (as far as I remember from when I first read the proposal at least, it may do more) is adding preflight requests and headers to opt-in, which works for most cases yet doesn't block behind-the-lines collaborating apps like mentioned in the main article. If there's a listening app (like Meta was caught doing) that's expecting the requests, this doesn't do much to protect you.
EDIT: Looks like it does mention integrating into the permissions system [0], I guess I missed that. Glad they covered that consideration, then!
0: https://wicg.github.io/private-network-access/#integration-p...
Both Firefox [0] and Chrome [1] are working on successors which rely on permissions prompts instead of preflight requests.
[0] https://groups.google.com/a/mozilla.org/g/dev-platform/c/B8o...
[1] https://groups.google.com/a/chromium.org/g/blink-dev/c/CDy8L...
The Firefox bug referenced in [0] is open since 2018 (https://bugzilla.mozilla.org/show_bug.cgi?id=1481298)?!
What is so difficult about this?
0. Define 2 blocklists: one for local domains and one for local IP addresses
1. Add a per-origin permission next to the already existing camera, mic, midi, etc... Let's call it LocalNetworkAccess, set it false by default.
2. Add 2 checks in networking stack:
2a. Before DNS resolution check the origins LocalNetworkAccess permission. If false check the URL domain against a domain blocklist, deny the request if matches.
2b. Before the TCP or UDP connect check the the origins LocalNetworkAccess permission. If false check the remote IP address against an IP blocklist, deny the request if matches.
3. If a request was denied, prompt the user to allow or disallow the LocalNetworkAccess permission for the origin, the same way how camera, mic or midi permission is already prompted for.
This is a trivial solution, there is no way this takes more than 2-300 lines of code to implement in any browser engine. Why is it taking years?!
And then of course one can add browser-specific config options to customize the blocklists, but figure that out only after the imminent vulnerability has been fixed.
> There are some semi-legitimate uses, like Discord using it to check if the app is installed by scanning some high-number ports (6463-6472)
I would not consider this a legitimate use. Websites have no business knowing what apps you have installed.
I agree, yet at least you can kind of see where they're coming from.
I guess a better example would be the automatic hardware detection Lenovo Support offers [0] by pinging a local app (with some clear confirmation dialogs first). Asus seems to do the same thing.
uBlock Origin has a fair few explicit exceptions made [1] for cases like those (and other reasons) in their filter list to avoid breakages (notably Intel domains, the official Judiciary of Germany [2] (???), `figma.com`, `foldingathome.org`, etc).
0: https://pcsupport.lenovo.com/
1: https://github.com/uBlockOrigin/uAssets/blob/master/filters/...
2: https://github.com/uBlockOrigin/uAssets/issues/23388 and https://www.bundesjustizamt.de/EN/Home/Home_node.html (they're trying to talk to a local identity verification app seems like, yet I find it quite funny)
> the official Judiciary of Germany [2] (???)
That's the e-ID function of our personal ID cards (notably, NOT the passports). The user flow is:
1. a client (e.g. the Deutsche Rentenversicherung, Deutschland-ID, Bayern-ID, municipal authorities and a few private sector services as well) wishes to get cryptographically authenticated data about a person (name and address).
2. the web service redirects to Keycloak or another IDP solution
3. the IDP solution calls the localhost port with some details on what exactly is requested, what public key of the service is used, and a matching certificate signed by the Ministry of Interior.
4. The locally installed application ("AusweisApp") now opens and displays these details to the user. When the user wishes to proceed, the user clicks on a "proceed" button, and is then prompted to either insert the ID card into a NFC reader attached to the computer or a smartphone in the same network as the computer that also has the AusweisApp attached.
5. The ID card's chip verifies the certificate as well and asks for a PIN from the user
6. the user enters the PIN
7. the ID card chip now returns the data stored on it
8. the AusweisApp submits an encrypted payload back to the calling IDP
9. the IDP decrypts this data using its private key and redirects back to the actual application.
There is a bunch of cryptography additionally layered in the process that establishes a secure tunnel, but it's too complex to explain here.
In the end, it's a highly secure solution that makes sure that only with the right configuration and conditions being met the ID card actually responds with sensitive information - unlike, say, the Croatian ID card that will go as far as to deliver the picture on the card in digital form to anyone tapping your ID card on their phone. And that's also why it's impossible to implement in any other way - maaaaybe WebUSB but you'd need to ship an entire PC/SC stack and I'm not sure if WebUSB allows cleaving an USB device that already has a driver attached.
In addition, the ID card and the passport also contains an ICAO compliant method of obtaining the data in the MRZ, but I haven't read through the specs of that enough to actually implement this.
Zoom got busted for something similar five years ago now: https://www.zdnet.com/article/zoom-defends-use-of-local-web-...
IMO browsers should not just block the request but block the whole website with one of those scary giant red banners if something like this is attempted. If all websites get for trying to work around privacy protections is that their attempts might not succeed then there is little incentive not to try.
Your DNS server not resolving to localhost may also serve as an additional line of defense.
What does this have to do with the issue here? A website can just connect to 127.0.0.1 , no DNS needed.
I think what you are thinking of are dns rebinding attacks.