It's why Tor Browser restricts access to localhost by default. This problem was already predicted and considered by Tor developers back in 2014, see ticket #10419 - <i>Can requests to 127.0.0.1 be used to fingerprint the browser</i> [0] and has been fixed since then. Scanning localhost is a dangerous way to fingerprint the user if there are local open ports.<p>If you are not using Tor Browser and want to fix the security hole without disabling WebSocket completely, running the web browser in a separate network namespace is a workaround - you get a loopback interface which is independent from the main namespace, and you create a NAT interface within the network namespace to allow outgoing traffic. It's also a possibility for a website to probe other machines, such as the setting page on your router. For better protection, you should block all the local addresses defined by RFC1918 via netfilter/iptables as well.<p>For developers who needs less restrictive blocking for debugging, you can run multiple Firefox processes in different profiles (<i>firefox -P --new-instance</i>), each running in a different network namespace - to make it easy, you can code everything in a shell script and create desktop icons for them. I normally use an ad-blocked and 3rd-party-cookies-blocked profile for web browsing, but a naked Firefox profile for development.<p>[0] <a href="https://trac.torproject.org/projects/tor/ticket/10419" rel="nofollow">https://trac.torproject.org/projects/tor/ticket/10419</a>
The greater issue is that browsers are allowing code executing from the public Internet <i>scope</i> (scope meaning security domain) network access to the localhost scope or the Intranet scope (RFC1918 addresses.)<p>If anything, this should require very explicit permission granting from the user. I’d prefer it be something more like an undocumented toggle accessible solely to developer types.
> Port Scanning is Malicious<p>Though port scanning can be (and maybe even frequently is) done with malicious intent by looking for misconfigured/bugged servers, I disagree that it's inherently malicious. Port scanning is just about checking to see what services a host is offering you. It's like going to a random shop at a mall and asking what services they provide. Would asking about their services be malicious?<p>It feels like the reason asking about services is considered malicious is because shops frequently give out info to the public that they shouldn't have. It's like:<p>client: What services do you provide?<p>shop owner: Well, I can provide you with a list of all my clients along with their personal information they entrusted to me.<p>So, is the client being malicious for asking or is the shop owner the one that was in the wrong for mistakenly providing that info to the public?<p>I feel the only reason we don't blame the shop owner is because even though he's the one that mistakenly discloses private info, sometimes he's just following a script written by a random programmer unassociated with him. Maybe the response was a mistake on the programmers part, maybe it was a mistake in how the shop owner used the script (a configuration error). In the end, it's simpler to blame the client for asking out-of-the-box questions (after all, most clients just come in to ask if you're giving out flyers/pamphlets because that's what everybody does) and so they don't feel responsible for the response that results.<p>I can provide a shop that also offers things different than http(s) with open access to the public. It shouldn't be a crime/violation to ask me if I offer them.
This raises the question: Is port scanning without consent a violation of the CFAA? Either it is legal, and researchers should face no repercussions for doing so, or it isn't and eBay is non-compliant with CFAA. I recall hearing about someone either being arrested or convicted due to port scanning a courthouse, but it was many years ago and I can't find the case with a cursory Google search.<p>I have to wonder what value eBay would get from port scanning its customers. Is it part of an attempt to detect bots/attackers? Is malware running on their server trying to determine if the client is likely vulnerable to some propagation method?
> Furthermore, when I installed and ran a VNC server, I didn't detect any difference in site behavior - so why is it looking for it?<p>Not an eBay employee, but used to work in fraud detection. Two very obvious related guesses from my experience:<p>1. Fingerprinting a user to help identify account takeover (ATO). Open port signatures is probably a pretty good signal for that kind of thing (and it doesn't seem to be measured in <a href="https://panopticlick.eff.org/" rel="nofollow">https://panopticlick.eff.org/</a>).<p>> However it is also a valid tool used by administrators for remote access to machines, or by some end user support software, so the presence of VNC is a poor indicator of malware.<p>2. In a Bayesian sense, this probably isn't right. I don't know what eBay's traffic looks like but I'm willing to bet that all other things being equal, traffic coming from a machine with an open VNC port is riskier. Fraud detection is a game of probabilities, so the existence of a valid user showing a particular characteristic doesn't mean that the characteristic isn't useful in a fraud model. The example I always give is that when I was doing this (quite some time ago), we could have had a 99% accuracy rate for a simple rule banning IPs from Turkey, Ghana, Nigeria, and Vietnam. It's not because there weren't any valid users from those countries, it's just that the fraudsters where overwhelmingly likely to be using IPs from those countries.
Port scanning from a web page, combined with DNS rebinding, can present a really nasty attack, and can effect an entire private network, not just localhost.<p>Some more info here: <a href="https://medium.com/@brannondorsey/attacking-private-networks-from-the-internet-with-dns-rebinding-ea7098a2d325" rel="nofollow">https://medium.com/@brannondorsey/attacking-private-networks...</a><p>Example code: <a href="https://github.com/brannondorsey/dns-rebind-toolkit" rel="nofollow">https://github.com/brannondorsey/dns-rebind-toolkit</a><p>A malicious DNS rebind server: <a href="https://github.com/brannondorsey/whonow" rel="nofollow">https://github.com/brannondorsey/whonow</a><p>Disclaimer: I performed some of this research a few years ago. So those resource suggestions are my own, but they feel very relevant here.
First of all, fraud detection seems like a legitimate use case here. And WebSockets has many valid uses.<p><i>HOWEVER</i> -- how the hell is localhost port scanning allowed to happen <i>without my permission</i>?!<p>This feels no different from a website trying to check the existence of named directories on my file system or something.<p>Does WebSockets not require permission to function at all, or shouldn't it be limited to some kind of CORS-type policy or <i>something</i> to connect without a permissions dialog? Or <i>even</i> if it's allowed to port scan the entire public internet, at least block your local machine and network without explicit permission?
This use doesn't seem to be covered by eBay's privacy policy <a href="https://www.ebay.com/help/policies/member-behaviour-policies/user-privacy-notice?id=4260" rel="nofollow">https://www.ebay.com/help/policies/member-behaviour-policies...</a>
Lots of chat in the comments about how this is all websockets' fault, but don't forget you can portscan localhost with pure JS as well.<p><a href="https://portswigger.net/research/exposing-intranets-with-reliable-browser-based-port-scanning" rel="nofollow">https://portswigger.net/research/exposing-intranets-with-rel...</a>
Every time I hear about some shiny new feature being added to a browser, I think...<p>1) Will I ever actually use this<p>2) How is this gonna screw me over<p>WebSockets, WebBluetooth, WebAssembly, Web-You-Can-Access-my-Accelerometer-and-Battery, haven't ever wanted to use those. Ever. For anything. For any reason. (Edit 3: Oh yeah, I forgot! WebRTC!)<p>Edit: Fantastic. You can't disable it in Firefox. So what, does Firefox need a freaking iptables implementation now? [1]<p>1 - <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1091016" rel="nofollow">https://bugzilla.mozilla.org/show_bug.cgi?id=1091016</a><p>"The only theoretical reason for the WebSocket pref these days is the possibility to disable it easily in case there is a security issue found in the protocol itself or so."<p>The protocol itself is the security issue. ALL OF IT.<p>Edit 2: So I don't have the time to investigate every new fad when it comes out. I originally thought WebSockets were raw sockets, but they aren't. Firefox blocks access to port 22 -- I was hoping all privileged ports, but it seems just those. Opening a WebSocket to netcat dumps out a HTTP request, so it seems unlikely that you'd be able to talk with anything that doesn't talk HTTP and WebSockets. Firefox also seemingly blocks access to 192.168/24 and 10/8.<p>This makes me less angry. But what STILL make me angry is that I have to sit and research about some stupid thing that I don't want and can't turn off. Sooner or later, some web dev is gonna argue that all sites should be loaded over WebSockets because his bloated javascript stack performs marginally better, and then WebSockets <i>won't</i> be something I can turn off. Websites will just whitepage.<p>Edit 4: Done researching this now. I went to ebay on Firefox, and wasn't getting websocket scans. But I've got a stack of uBlock and NoScript... maybe that's interfering with it some how? Opened up a stock config for google-chrome -- that's my browser for "some dumb new web tech that isn't working in Firefox" -- not seeing any scans when I open up inspector and click "WS".<p>Regardless, his point still stands. You can totally use WebSockets as a port scanner for localhost, assuming the Content Security Policy allows it. Now I gotta go update my nginx configs...
Browsers should be blocking this by default.<p>"This website is trying to access services on your local PC, do you want to allow?"<p>Or at least as blockers should have a rule for it.
My kids complained today that Google Classroom isn't working. After a quick investigation, I noticed that Snort on my firewall blocked the relevant Google server due to incoming TCP port scans. Sigh.
To my knowledge, a lot of effort has been put into the design of CORS (and related APIs) to specifically prevent misuse like that. A well-behaved Websocket implementation should not give the calling script any indication <i>why</i> a connection failed.<p>I know timing oracles are difficult to avoid in many cases - but the technique shown here seems to actually exploit different kinds of exceptions being thrown by the browser.<p>This seems like a straight-up bug and pretty serious security vulnerability to me.
If anyone thinks of implementing this, don't forget to guard against reflection attacks[1]<p>EDIT: revisiting my comment (and the wikipedia article linked), a reflection or amplification attack in this context is sending traffic and generating (perhaps much more) traffic from a different source than yours as part of an attack. For example, you could spoof the IP address of the HTTP packets and cause the server to port scan another machine -> little traffic (HTTP request) causing a lot of traffic (port scanning). As part of a DDOS attack, a botnet for example could use this to amplify their attack and masquerade the source.<p>[1] <a href="https://en.wikipedia.org/wiki/Denial-of-service_attack#Reflected_/_spoofed_attack" rel="nofollow">https://en.wikipedia.org/wiki/Denial-of-service_attack#Refle...</a>
Potentially you can do more than just port scan; it's possible to use/access the servers that you have running on your local machine if they're left open. See my post about this: <a href="https://jameshfisher.com/2019/05/26/i-can-see-your-local-web-servers/" rel="nofollow">https://jameshfisher.com/2019/05/26/i-can-see-your-local-web...</a>
From the title I assumed this was going to be something else. I remember some sites used to port scan you on registration. This was to check if registrations were from an open proxy, which was a very strong bot indicator. I might be misremembering but I think Slashdot used to do it. There were also some plugins for phpBB forums that did it too. I used one back in the day and it helped quite a bit with spam registrations.
This is bad and should be blocked IMO, at least by default, but can a site do anything other than find out which ports respond to a websocket request? AFAIK they can't send arbitrary network packets. The websocket will only open if the port they are trying to talk to speaks websocket back. This is mentioned in the article.<p>I'm not saying that's okay. I still don't want them scanning ports on my machine. There might be some services that offer a websocket connection like Plex for example, or the Kinect driver, or Leap Motion. I also don't want them cataloguing ports that are open.
I can't believe of the 363 comments no one has mentioned Samy K and his awesome Poisontap project. Parts of which did this local scanning and connecting to your internal router management page.<p><a href="https://github.com/samyk/poisontap" rel="nofollow">https://github.com/samyk/poisontap</a><p>See also, <a href="https://www.theregister.co.uk/2010/01/05/geo_location_stealing_hack/" rel="nofollow">https://www.theregister.co.uk/2010/01/05/geo_location_steali...</a>
> Furthermore, when I installed and ran a VNC server, I didn't detect any difference in site behavior - so why is it looking for it?<p>I think behind the scenes they keep log of some sort of fraud risk, e.g. geoip different from billing country, suddenly a new operating system, vnc/teamviewer running would probably flag your account (even for benign purposes, e.g. you can get your money back or purchase cancelled if that info can prove your transaction was actually unauthorized).<p>I worked on a ecommerce where the previous developers implemented a rudimentary "score" system like that so that suspicious orders would be put in queue for phone verification (this was pre gdpr)
Port scanning localhost from a webpage has been possible for a long time and does not require websockets.<p><a href="http://jsscan.sourceforge.net/" rel="nofollow">http://jsscan.sourceforge.net/</a>
I don't follow what this has to do with websockets specifically; they just go over HTTP, so why couldn't you do this with a regular HTTP request?<p>Either way it seems easy to mitigate at the browser level: block all requests to localhost that don't originate from a page served on localhost. It's not that different from the CORS policy.
Yes, a drive by web page shouldn't be able to do this but similarly a native app shouldn't be able to do this and yet I suspect some not insignificant percent of native apps, especially on mobile on both OSes are doing this either directly, the app dev is doing it deliberately, or via one of the many 3rd party libraries they included but aren't aware of the behavior.<p>I really want the OS to prevent this by default and require permission from the user. I want apps (probably only possible on iOS/Android) to have to list the sites they'll connect to, that list will have to be reasonably small 10-30 sites with special exceptions for browsers<p>This would have 2 positive affects. #1 it would prevent the apps from scanning the network. #2 it would effectively force apps to launch the user's browser for external links instead of an embedded browser in which they can spy on all activity.
Interesting, port scanning is illegal in some countries as it's classified as security testing, it can be only performed with permission.<p>How would you feel is someone was walking on busy car parking and checking if doors of the cars are open? It' what port scanning is, checking if the car has open door.
Curious what HN thinks about this hypothetical: Imagine you have a web app designed to talk to a specific backend server API. It's also common for users to run instances of the server on their local machine. How would you feel about the app checking a (single) well-known port to see if there's a local server running, and prompting the user: "we detected you're running a local copy of the server, do you want to connect to it?"<p>This doesn't seem to be done very often, and the public cases usually seem to be pretty ugly (Zoom). But I could see it being useful. Imagine for example an app for browsing S3 directories, that could also detect if you're running a minio server and allow you to connect to it, and transfer data back and forth between your different backends.
This slideshow by an NSA dude seems to go into this, from 2016.<p><a href="https://datatracker.ietf.org/meeting/96/materials/slides-96-saag-1/" rel="nofollow">https://datatracker.ietf.org/meeting/96/materials/slides-96-...</a>
There is an open Chromium bug for this: <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=378566" rel="nofollow">https://bugs.chromium.org/p/chromium/issues/detail?id=378566</a><p>I hope they consider it still valid and not close it.<p>These are the blocked ports: <a href="https://github.com/chromium/chromium/blob/83.0.4103.53/net/base/port_util.cc#L22" rel="nofollow">https://github.com/chromium/chromium/blob/83.0.4103.53/net/b...</a><p>Accessing localhost and LAN addresses works perfectly fine, except for those ports.<p>I am going to patch Bromite so that it doesn't allow any access to localhost nor private networks.
This does suggest to me that browser websocket requests against localhost should at least:<p>1) return the same error message for all failures (unless some opt-in / launch flag is set)<p>2) fiddle with the timing slightly to make timing attacks less useful? (how long is a localhost TLS connection? 100ms? I think devs can wait a handful of frames for their failure response.)<p>I have no idea how many legitimate apps are leveraging some kind of localhost connection -- it sounds like an unusual use case but I can certainly imagine some enterprise app that ties into desktop services or programs by that route.<p>EDIT: Of course banning them outright or requiring specific user whitelisting of domains would work as well. Just trying to get away with the smallest change.
Many questionable Russian sites do full port scans not only on localhost but on all the private subnets. I had to block all access to ports above 1024 for all local subnets. Usually people don't have firewall rules for that.
Allowing ws connections to local addresses can be pretty useful in many cases (admittedly, many of these could be better solved with WebExtensions' native messaging) so disallowing it would not fly.<p>But since this is pretty rare, a message saying: "this website is trying to connect to services running on your computer - allow/deny?" would be pretty easy to implement and solve this for good. Sites that need this already require you to jump through hoops, so one more popup would be fine, but sites that do this for other reasons would probably not want to risk a popup.
See also: BeEF[1]<p>Theres lots of scanning/attacks you can do using the web browser as your scanning tool. Its troubling that major sites are starting to use some of these techniques, but these techniques have been readily available to attackers with open source tooling.<p>I think it's long overdue for browser to find a way to mitigate these sorts of attack vectors. If the security folks can't justify it due to BeEF, maybe the privacy folks can using articles like this.<p>[1] <a href="https://beefproject.com/" rel="nofollow">https://beefproject.com/</a>
When you do this:<p><pre><code> new WebSocket("ws://127.0.0.1:8080")
</code></pre>
An application listening on 8080 is indeed getting a packet delivered.<p>Run this to see the packet:<p><pre><code> nc -lp 8080
</code></pre>
And the page can figure that out via the error returned.<p>I wonder if that is in line with the same origin policy.<p>On the other hand, maybe the same is possible by creating an image with src="<a href="http://127.0.0.1/hello.jpg"" rel="nofollow">http://127.0.0.1/hello.jpg"</a> and looking at the onload/onerror event?
hmmm, so the conclusion is:<p>"Whether the port scan is used as part of an infection or part of e-commerce or bank "security checks", it is clearly malicious behavior and may fall on the wrong side of the law."<p>Though I really don't know what ebay or banks or any site might be doing, it seems like it's almost certainly a defensive thing looking for signs of trouble. I don't know if I'd call it malicious. Isn't this totally harmless in this case? That is, eBay portscans me, how is this malicious?
This guy Just has it wrong when he calls port scanning an adversarial technique. It's Just a way to discover Services. You can then use the result to do malicious things but it's not like the only or even main purpose. I humbly refer to this: <a href="https://koeln.ccc.de/ablage/portscan-policy.xml" rel="nofollow">https://koeln.ccc.de/ablage/portscan-policy.xml</a> (Google translate can help with the german)
This is scary. I've always left locally running services unprotected for convenience given they can't be accessed from outside. I can imagine a lot of people running local apps, servers or databases without any auth that could contain sensitive information. Would a webpage be able scrape data from such services? Any way to disable this completely in Firefox and Chrome?
I can think of a legitimate use case for this. If you watch some of these scammer youtube videos, one common thing they seem to do is get on a screensharing application, and have the user log into their bank account. From there, the scammer inspects the html, and manipulates the values to trick the victim.<p>A bank knowing if someone else is watching your screen is a decent security measure.
in firefox it seems you can disable websocket with network.websocket.max-connections = 0<p>Firefox and the illusion of privacy<p>(1)<a href="https://www.remembertheusers.com/2018/03/0455-firefox-and-the-illusion-of-privacy.html" rel="nofollow">https://www.remembertheusers.com/2018/03/0455-firefox-and-th...</a>
How does it work in practice? It seems in Chrome these errors cannot be caught try-catch blocks.<p><pre><code> try {
var socket = new WebSocket('ws://localhost:808');
}
catch (ex) {
console.log(ex) // control does not reach here
}</code></pre>
Actually , I'm pleased ebay is doing this. It wasn't a new issue but now ebay doing it, it took a lot of attention. It's like disclosing a security issue in WebSocket protocol. Now I'm sure next releases of the most browsers will fix it.
Javascript was a mistake, seriously. The benefit-cost ratio from the user's point of view is disastrous. I'd rather slog through less fancy data entry forms than suffer endless tracking, privacy and security attacks.
Please ELI5 why it doesn't happen for www.ebay.com using Firefox in Debian. I see no websocket connections to localhost in Network Monitor or iftop.
I've noticed many of the survey for cash sites use websockets to scan for running services on your machine
Personally I think its straight up evil
Now scanning for open ports I can do on Linux.<p>But how would I go about monitoring which ports are being scanned on Linux?<p>No tool doing this comes to mind
Poorly written article: mixes facts and opinions<p>> it seems many sites are port scanning visitors for dubious reasons.<p>Claims that in the intro, but then admits ebay is scanning for VPNs, which probably means it's doing fraud detection, which is definitely not a dubious reason, and is probably actually beneficial to the customer.
anyone know the config or flag in Chrome to disable any requests to localhost? Ideally excluding origin=localhost, but if not possible i can dev on a different account
port scanning is fine and should not be illegal.
It's just "looking" at a house to see if there is a door and what type of key (protocol) it uses.<p>Trying to open a connection on the other hand it's like trying to open the door. That should be considered as a violation.
Port scanning isn't malicious behavior. Port scanning is about equivalent to walking down the street and looking at the architecture of the buildings.