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 - Can requests to 127.0.0.1 be used to fingerprint the browser [0] and has been fixed since then. Scanning localhost is a dangerous way to fingerprint the user if there are local open ports.
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.
For developers who needs less restrictive blocking for debugging, you can run multiple Firefox processes in different profiles (firefox -P --new-instance), 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.
> 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
Sorry to invoke the meme, but Opera did it first[0], in Opera 9.50 (2008). I don't have a good reference to hand, but [1] is a developer complaining about this. [Edit: [2] covers the feature in some detail.]
Opera also blocked access to private IP addresses (so there were three tiers: public IPs, private IPs, localhost; higher tiers could communicate with lower ones, so the block was only unidirectional).
IE10+/EdgeHTML-based-Edge (and I know there was some talk about blocking this in Chromium-based Edge) also blocks it, so that too is prior art to the Tor change.
To add more about why current browsers don't do this:
One is clearly that you need to communicate the requesting IP deep enough into the network stack to the point where you get the DNS response (if there is one), which means there's a fair bit of work to ensure this is done everywhere;
Another is it's known to break corporate websites (https://internal.bigcorp.com/ on a public IP expecting to be able to access private IPs on their intranet), and smaller browsers are reluctant to lose corporate users by changing long-standing behaviour;
Then there's the WebRTC question: if two users on the same local network start a WebRTC call, do we want all this traffic to go to via first point where the public IP is known? For the majority of users the answer is no. And as long as that's possible, there's a (very limited) means of local communication. (But if it's limited to only things that respond to the WebRTC handshake, we're already in a much better place!)
I feel like uMatrix covers this as well. I've sometimes found myself redirected to some shady Chinese site and seen blocked attempts to localhost or 127.0.0.1 show up in the dashboard.
> 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.
As someone less tech savvy but still concerned, are there any guides available on how to do this?
The greater issue is that browsers are allowing code executing from the public Internet scope (scope meaning security domain) network access to the localhost scope or the Intranet scope (RFC1918 addresses.)
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.
I stand corrected. I think yours is the correct approach.
How shall origin be defined? I can envision the likes of Microsoft which have many, many second-level domains making calls between them.
We can’t allow the site itself to grant access. How would this be managed, other than “please stop and think what a domain name is supposed to be before spraying your product across twelve of them?”
Yeah, that's the best solution. It should be like microphone or camera access. It should say "this web site is attempting to access a resource on your local system / network."
I don't think you need to overdo it in terms of making the warning red, etc. Just a popup will really discourage people from trying to use this for fingerprinting.
BTW the site says:
"Port scanning is malicious." I don't agree. There are many many things that can look like a port scan but are not malicious, most notably NAT traversal attempts by WebRTC, games, chat apps, and so on.
Right.
"it is clearly malicious behavior and may fall on the wrong side of the law."
It's not against the law. It might be _shady_ but it's not illegal. When I'm teaching cyber intro classes, I let folks know portscanning is NOT illegal but shady. It's like going to a business after hours. It's not illegal to rattle doors and windows to see if they're locked. The police might have a different take on it, but it's not illegal.
There are legitimate reasons for port scanning, but I'm not sure most websites out there are using it for noble purposes.
I guess browsers could allow it based on explicit permission from the user, just like it's already done for microphone and camera.
Port scanning from a user’s browser is effectively sneaking behind a user’s firewall. The only legitimate reasons I can envision are security research, and this, to me, is such a small edge case that I’m not sure such access is ever warranted.
I’d be all for a user notification that says “fnord.com wants to access 192.168.0.10 on tcp/443, which seems to be a web server on your home/work network. Are you sure you want to allow this?” I’d want to see this for each new access request, such that port scanning would not be a use case that was supported.
Sure, have an about:config toggle to shut this off, with appropriate warnings.
Yea this is very surprising.
I run a file server in my local network. There is no access control on it because it’s behind my router’s firewall, but everyone in the LAN can access it.
I find it very surprising that now any random website can access it with no oversight.
Why worry about spectre and meltdown when such blatant backdoors are implemented in browsers?!
I'm curious, what would be a good reason to do this? I'm not creative enough to think of anything this enables a site to do that isn't malicious. If I'm running a service on localhost, and that service needs to communicate with the site I'm browsing, surely I could just direct that service to communicate with the site itself.
For instance, if I'm running a local chat application and need it to communicate with the web version, why does the website need to be able to port scan to accomplish this? I can think of other ways to accomplish this that are a lot more secure.
Yes, it's very similar to CORS. They just need to block all localhost requests from non-localhost pages. Maybe carve out an exception for when the dev tools are open.
It shouldn't matter what malware is on a client device as long as the client has authenticated; the server/company/ebay should be protecting their API from abuse at the API layer, not the client layer.
I think what you’re saying is the user might be an employee on some internal trusted company network. The employer should have control of that browser (and entire endpoint), otherwise the network should likely not be considered trusted. So, in this case, no, the user shouldn’t have the ability to authorize this; the administrator of that browser should.
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?
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:
client: What services do you provide?
shop owner: Well, I can provide you with a list of all my clients along with their personal information they entrusted to me.
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?
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.
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.
I think the dynamics of the Internet have shifted from the early days. Basically, HTTPS on port 443 is pretty much the only service that anyone intends to make publicly available. This is different from 30 years ago, when those same sites had HTTP, FTP, Gopher, a public Telnet server, a public NTP server, etc. and they wanted you to use them. It was very reasonable to look around back then, but nowadays anything that is available publicly is probably an accident.
Exactly! And do we want to continue on that trend? Personally, I don't.
I dislike the growing idea that HTTP is a core part of the internet, and not just the most popular part. The difference lies in if we're going to see legislation that dictates proper use of the lower networking layers like TCP/IP by stuff of the upper layers like HTTP. I'd really hate to see something along the lines of "it's illegal to use a TCP port unless it was specified as available to the public in some (possibly js-rendered) part of an HTTP response."
I don't think port scanning and computer intrusions are comparable. As always, I believe, in both state (like CA 502) and federal law (like CFAA), state of mind is what matters. You have to intend to gain unauthorized access (or, in California, the resources of that computer). A port scan by itself can't do that; on the flip side, randomly accessing URLs can do that, so even though you don't need special "malicious" tooling to hit a URL, you can charged with a felony for (say) dumping lots of private information from a URL you simply type into your browser bar.
Even in California, the resources that you can access and consume from a port scan of a browser visiting your site are essentially the same as you'd get from running Javascript on your page. A legal claim based on those scans seems very far-fetched.
Message board nerds seem totally convinced of the idea that computer crime law tracks the state of the art in offensive computer security, but the two concepts aren't directly connected at all.
I speak both for myself and, I think, for a lot of security researchers both academic and professional when I say that I am very, very nervous poking at a website that hasn't given me permission to, say, check if an input that generated a crazy error is, say, letting me inject SQL, while at the same time I am never scared about port scanning things. There are companies, well-respected companies, that do nothing but port scan everything on the whole Internet.
In this case, eBay is the shop, and I'm the customer. It's like walking into eBay and when I walk in I have to empty out all of my pockets and open my phone screen to show them that no one is telling me what to shop for (VNC).
That's a bad analogy. It wrong because you can see what doors, cupboards and drawers are available for the public. Doors that are in-reach but that shouldn't be used by the public have signs like "restricted access" or "employees only". You can't do that with the internet. You can't see that a port is not available to you until you try it.
If you want to continue using that analogy, then you have to consider that everybody is blind and deaf, and checking to see what's locked is the only way to know if something is available.
Port scanning is a brute force, over-reaching probing technique. A better analogy would be like visiting a shopping mall and trying to open every closed door you see, including the ones that say "authorized personnel only", "private", "do not enter" with an excuse like "I was trying to find out which shop was open".
> including the ones that say "authorized personnel only", "private", "do not enter" with an excuse like "I was trying to find out which shop was open".
I don't think this part of the analogy is accurate. There are no "authorized personnel only" ports
> including the ones that say "authorized personnel only", "private", "do not enter"
Basically, to answer you separately, an analogy like that doesn't represent TCP accurately. In your analogy, you can
1) see from afar for visual cues indicating whether access is being given to you, and
2) try opening it.
Your argument is that doing 2 is invasive, because they can do 1.
However, in TCP, you can only try to make the connection. There is no see from afar. If I give you an IP address, there's no standard way for you to tell me whether FTP is available, without trying to connect to the port! That's your only choice!
So, yes, "I was trying to find out which [service is available]" is a very valid reason.
> Port scanning is a brute force, over-reaching probing technique.
It certainly is brute-force, and that sucks. I think there's a network service / protocol called Portmapper/rpcbind[2] that lists the services available and port numbers they're on. I only know that NFS uses it, but nothing else. If that were standard, then I'd agree port scanning is over-reaching. As it stands, though, I don't consider it over-reaching when it's the only TCP mechanism to see what's available online.
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.
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?
When did networking support we often had old code + lower quality equipment that could / would crash if you used off the shelf security software that would go out and scan and then try all sorts of things and then generate a report.
I'd say 90% of the time the powers that be at the company had no idea someone was running that software, or that it was still running at their company, and then someone moved a firewall and the system was exposed to more than intended. Then they'd turn it of ... and find another similar tool running somewhere else.
It could be a simple as a test or security system run amok.
> I'd say 90% of the time the powers that be at the company had no idea someone was running that software, or that it was still running at their company, and then someone moved a firewall and the system was exposed to more than intended. Then they'd turn it of ... and find another similar tool running somewhere else.
This demonstrates the absurdity of the CFAA more than anything else. Sorry for sounding like a broken record but the CFAA is not salvageable and MUST be repealed.
It's probably part of their fraud detection and mitigation strategy. Combined with other info about your transactions it could help raise a flag about changes.
As for the CFAA that's seemingly down to how aggressive the prosecutor is feeling about your case. I don't think it should be there's no real access happening and unless it's extremely aggressive and degrades network connectivity it's hard to argue there's any real damage done.
They're almost certainly doing it as part of a heuristic to detect bots. Hence the VNC / RDP ports. I would assume it's quite common for bots to have those ports open so they can be monitored
Almost certainly not. Commercial unauthorized port scans are utterly routine. There are well-known companies premised on it.
You can get to the same answer axiomatically from the text and case history of CFAA (a port scan literally can't grant you the access a CFAA claim needs to prove you intended), but that's obviously treacherous for non-experts to do; instead, the empirical demonstration should be conclusive here.
I don't know why this scan is occurring, but fingerprinting is the most obvious guess, and intrusive fingerprinting performed by real companies is usually about ATO prevention, which means they're not going to tell you any more about it (ATO defense is an arms race).
> I have to wonder what value eBay would get from port scanning its customers.
From the article:
> Looking at the list of ports they are scanning, they are looking for VNC services being run on the host, which is the same thing that was reported for bank sites.
> VNC is sometimes run as part of bot nets or viruses as a way to remotely log into a users computer. There are several malware services that leverage VNC for these purposes.
No, I think it was probably close to a decade ago, but I likely am misremembering some of the details. Could've been a police department, but I'm not sure.
That one you linked is a messed up case. There is a phenomenal podcast that interviews those guys and walks through their engagement. https://darknetdiaries.com/episode/59/
IANAL but this type of websocket port scan seems inherently different from what Shodan does.
Shodan is outside your network's firewall, therefore only able to access services you've exposed to the wider web.
If I understand the article, the websocket scan eBay is doing is trying to connect to local listeners on your laptop, behind your network's firewall and possibly even behind your laptop's firewall.
> 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?
Not an eBay employee, but used to work in fraud detection. Two very obvious related guesses from my experience:
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 https://panopticlick.eff.org/).
> 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.
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.
First of all, fraud detection seems like a legitimate use case here. And WebSockets has many valid uses.
HOWEVER -- how the hell is localhost port scanning allowed to happen without my permission?!
This feels no different from a website trying to check the existence of named directories on my file system or something.
Does WebSockets not require permission to function at all, or shouldn't it be limited to some kind of CORS-type policy or something to connect without a permissions dialog? Or even if it's allowed to port scan the entire public internet, at least block your local machine and network without explicit permission?
Readit News
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.
For developers who needs less restrictive blocking for debugging, you can run multiple Firefox processes in different profiles (firefox -P --new-instance), 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.
[0] https://trac.torproject.org/projects/tor/ticket/10419
Sorry to invoke the meme, but Opera did it first[0], in Opera 9.50 (2008). I don't have a good reference to hand, but [1] is a developer complaining about this. [Edit: [2] covers the feature in some detail.]
Opera also blocked access to private IP addresses (so there were three tiers: public IPs, private IPs, localhost; higher tiers could communicate with lower ones, so the block was only unidirectional).
IE10+/EdgeHTML-based-Edge (and I know there was some talk about blocking this in Chromium-based Edge) also blocks it, so that too is prior art to the Tor change.
[0]: https://w3cmemes.tumblr.com/post/62942106027/if-you-can-thin...
[1]: https://stackoverflow.com/questions/1836215/access-to-127-0-...
[2]: https://web.archive.org/web/20140302021701/http://my.opera.c...
One is clearly that you need to communicate the requesting IP deep enough into the network stack to the point where you get the DNS response (if there is one), which means there's a fair bit of work to ensure this is done everywhere;
Another is it's known to break corporate websites (https://internal.bigcorp.com/ on a public IP expecting to be able to access private IPs on their intranet), and smaller browsers are reluctant to lose corporate users by changing long-standing behaviour;
Then there's the WebRTC question: if two users on the same local network start a WebRTC call, do we want all this traffic to go to via first point where the public IP is known? For the majority of users the answer is no. And as long as that's possible, there's a (very limited) means of local communication. (But if it's limited to only things that respond to the WebRTC handshake, we're already in a much better place!)
As someone less tech savvy but still concerned, are there any guides available on how to do this?
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.
That's too little. All access from a different origin should be blocked by default, not only to local nets.
How shall origin be defined? I can envision the likes of Microsoft which have many, many second-level domains making calls between them.
We can’t allow the site itself to grant access. How would this be managed, other than “please stop and think what a domain name is supposed to be before spraying your product across twelve of them?”
I don't think you need to overdo it in terms of making the warning red, etc. Just a popup will really discourage people from trying to use this for fingerprinting.
BTW the site says:
"Port scanning is malicious." I don't agree. There are many many things that can look like a port scan but are not malicious, most notably NAT traversal attempts by WebRTC, games, chat apps, and so on.
It's not against the law. It might be _shady_ but it's not illegal. When I'm teaching cyber intro classes, I let folks know portscanning is NOT illegal but shady. It's like going to a business after hours. It's not illegal to rattle doors and windows to see if they're locked. The police might have a different take on it, but it's not illegal.
While it can be used to get information to bad things, it itself can be used for good things too.
I’d be all for a user notification that says “fnord.com wants to access 192.168.0.10 on tcp/443, which seems to be a web server on your home/work network. Are you sure you want to allow this?” I’d want to see this for each new access request, such that port scanning would not be a use case that was supported.
Sure, have an about:config toggle to shut this off, with appropriate warnings.
I find it very surprising that now any random website can access it with no oversight. Why worry about spectre and meltdown when such blatant backdoors are implemented in browsers?!
For instance, if I'm running a local chat application and need it to communicate with the web version, why does the website need to be able to port scan to accomplish this? I can think of other ways to accomplish this that are a lot more secure.
Such as?
It shouldn't matter what malware is on a client device as long as the client has authenticated; the server/company/ebay should be protecting their API from abuse at the API layer, not the client layer.
Know your network.
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?
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:
client: What services do you provide?
shop owner: Well, I can provide you with a list of all my clients along with their personal information they entrusted to me.
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?
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.
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.
I dislike the growing idea that HTTP is a core part of the internet, and not just the most popular part. The difference lies in if we're going to see legislation that dictates proper use of the lower networking layers like TCP/IP by stuff of the upper layers like HTTP. I'd really hate to see something along the lines of "it's illegal to use a TCP port unless it was specified as available to the public in some (possibly js-rendered) part of an HTTP response."
Even in California, the resources that you can access and consume from a port scan of a browser visiting your site are essentially the same as you'd get from running Javascript on your page. A legal claim based on those scans seems very far-fetched.
Message board nerds seem totally convinced of the idea that computer crime law tracks the state of the art in offensive computer security, but the two concepts aren't directly connected at all.
I speak both for myself and, I think, for a lot of security researchers both academic and professional when I say that I am very, very nervous poking at a website that hasn't given me permission to, say, check if an input that generated a crazy error is, say, letting me inject SQL, while at the same time I am never scared about port scanning things. There are companies, well-respected companies, that do nothing but port scan everything on the whole Internet.
In this case, eBay is the shop, and I'm the customer. It's like walking into eBay and when I walk in I have to empty out all of my pockets and open my phone screen to show them that no one is telling me what to shop for (VNC).
If you want to continue using that analogy, then you have to consider that everybody is blind and deaf, and checking to see what's locked is the only way to know if something is available.
I don't think this part of the analogy is accurate. There are no "authorized personnel only" ports
The first half of the analogy is good though.
> including the ones that say "authorized personnel only", "private", "do not enter"
Basically, to answer you separately, an analogy like that doesn't represent TCP accurately. In your analogy, you can
1) see from afar for visual cues indicating whether access is being given to you, and
2) try opening it.
Your argument is that doing 2 is invasive, because they can do 1.
However, in TCP, you can only try to make the connection. There is no see from afar. If I give you an IP address, there's no standard way for you to tell me whether FTP is available, without trying to connect to the port! That's your only choice!
So, yes, "I was trying to find out which [service is available]" is a very valid reason.
> Port scanning is a brute force, over-reaching probing technique.
It certainly is brute-force, and that sucks. I think there's a network service / protocol called Portmapper/rpcbind[2] that lists the services available and port numbers they're on. I only know that NFS uses it, but nothing else. If that were standard, then I'd agree port scanning is over-reaching. As it stands, though, I don't consider it over-reaching when it's the only TCP mechanism to see what's available online.
[1] https://news.ycombinator.com/item?id=23249246
[2] https://en.wikipedia.org/wiki/Portmap
> Though port scanning can be (and maybe even frequently is) done with malicious intent
I agree that it's wrong for eBay to be doing this. What I disagree with is specifically the statement "Port Scanning is Malicious".
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?
I'd say 90% of the time the powers that be at the company had no idea someone was running that software, or that it was still running at their company, and then someone moved a firewall and the system was exposed to more than intended. Then they'd turn it of ... and find another similar tool running somewhere else.
It could be a simple as a test or security system run amok.
This demonstrates the absurdity of the CFAA more than anything else. Sorry for sounding like a broken record but the CFAA is not salvageable and MUST be repealed.
https://www.securityfocus.com/news/126
As for the CFAA that's seemingly down to how aggressive the prosecutor is feeling about your case. I don't think it should be there's no real access happening and unless it's extremely aggressive and degrades network connectivity it's hard to argue there's any real damage done.
Criminal law is usually not this simple, as most criminal laws will take into account the mental state of the person performing the action.
You can get to the same answer axiomatically from the text and case history of CFAA (a port scan literally can't grant you the access a CFAA claim needs to prove you intended), but that's obviously treacherous for non-experts to do; instead, the empirical demonstration should be conclusive here.
I don't know why this scan is occurring, but fingerprinting is the most obvious guess, and intrusive fingerprinting performed by real companies is usually about ATO prevention, which means they're not going to tell you any more about it (ATO defense is an arms race).
From the article:
> Looking at the list of ports they are scanning, they are looking for VNC services being run on the host, which is the same thing that was reported for bank sites.
> VNC is sometimes run as part of bot nets or viruses as a way to remotely log into a users computer. There are several malware services that leverage VNC for these purposes.
Deleted Comment
That’s what these sites are doing.
That one you linked is a messed up case. There is a phenomenal podcast that interviews those guys and walks through their engagement. https://darknetdiaries.com/episode/59/
Dead Comment
Dead Comment
Shodan is outside your network's firewall, therefore only able to access services you've exposed to the wider web.
If I understand the article, the websocket scan eBay is doing is trying to connect to local listeners on your laptop, behind your network's firewall and possibly even behind your laptop's firewall.
Not an eBay employee, but used to work in fraud detection. Two very obvious related guesses from my experience:
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 https://panopticlick.eff.org/).
> 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.
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.
Some more info here: https://medium.com/@brannondorsey/attacking-private-networks...
Example code: https://github.com/brannondorsey/dns-rebind-toolkit
A malicious DNS rebind server: https://github.com/brannondorsey/whonow
Disclaimer: I performed some of this research a few years ago. So those resource suggestions are my own, but they feel very relevant here.
HOWEVER -- how the hell is localhost port scanning allowed to happen without my permission?!
This feels no different from a website trying to check the existence of named directories on my file system or something.
Does WebSockets not require permission to function at all, or shouldn't it be limited to some kind of CORS-type policy or something to connect without a permissions dialog? Or even if it's allowed to port scan the entire public internet, at least block your local machine and network without explicit permission?
Edit: https://defuse.ca/in-browser-port-scanning.htm
There doesn't seem to be a way to access anything locally, just test for open ports. I use SSH tunneling a lot and was having a minor freak out.