26

I recently read a piece by an infosec analyst who observed ebay.com doing a local port scan.

I could not believe my eyes, but it was quickly reproduced by me (see below for my observation).

I surfed around to several sites, and found one more that does this (the citibank site, see below for my observation)

I further see, at least across ebay.com and citibank.com the same ports, in the same sequence getting scanned. That implies there may be a library in use across both sites that is doing this. (I have not debugged into the matter so far.)

The questions:

  1. Is this port scanning "a thing" built into some standard fingerprinting or security library? (if so, which?)
  2. Is there a plugin for firefox that can block such behavior? (or can such blocking be added to an existing plugin)?

Thanks!

ebay.com as seen by me: ebay.com port scanning

citibank as seen by me: citibank port scanning

Other sites I checked that did NOT seem to be doing this:

  • paypal.com: no
  • ups.com: no
  • fedex.com: no
  • https://www.bankofamerica.com/: no
  • twitter.com: no
  • facebook.com: no
  • duckduckgo: no
  • authorize.net: no
  • wellsfargo.com: no
  • 1
    Welcome to the site! You are kind of asking five questions in one. Are you looking for which library does this (if any), which sites do this or which sites this library is included in, or which browser setting or plugin would block this scanning? You should edit your question to ask exactly one direct question. More info can be found in help topics like these: What can I ask about? and What should I avoid asking? Note that product recommendations (addon recommendations) are fairly off-topic. – Luc May 20 at 22:01
  • 1
    Nevertheless gave your question an upvote because you clearly did some research of your own here, that's always nice to see :). But it does need editing to get a good answer and not be potentially closed. – Luc May 20 at 22:02
  • 2
    I figured that it's a crude attempt to checking if you're using a remote computer. Criminals frequently use hacked RDP/VNC/etc to make fraudulent purchases. – Some Linux Nerd May 27 at 1:44
  • @SomeLinuxNerd It appears to be that, but it could easily also be fingerprinting and/or nefarious.... – Jonesome Reinstate Monica May 27 at 15:29
  • 1
    @JonesomeReinstateMonica if that's the case, then it would be interesting to see if the results of the connection attempts to localhost are sent back to the origin (e.g. ebay.com or citibank.com). If so, this is a sneaky way to get around same-origin policy. – mti2935 May 28 at 21:35
3

Blocking WS requests

While looking for a way to disable websockets, I found two native Firefox solutions that do not work any more, then stumbled upon https://github.com/jawz101/TrackersVsFirefox, which mentions that one can block websockets with the uBlock Origin rule:

*$websocket

You can restrict this further to localhost only, but you have to come up with a pattern that matches all possible localhost references (for example, all IP addresses between 127.0.0.0 and 127.255.255.255 refer to localhost as well). I won't try to come up with such a pattern as I am afraid that there may be some exotic aliases that I am not aware of.

Testing the result

In any case, once you have the filter set up, you can try it by visiting https://www.websocket.org/echo.html and clicking the Connect button. To test blocking localhost connections specifically, you can run a dummy server that listens for incoming connections and try to connect it.

For example, on linux you can run netcat -l 4444 to listen on port 4444 and connect to it by specifying wss://localhost:4444 as the location on the WS echo page.

  • Without the uBlock Origin rule, you will see some gibberish showing up in the netcat output and the WS echo page won't show any output (because netcat is not replying to it, just displaying the request).

  • With the rule enabled, you won't see any output in netcat but the WS echo page will display the error "DISCONNECTED, ERROR: undefined".

| improve this answer | |
  • Zoltan, that is the best tip going, but I think it isn't that useful in practice. I think what is really needed is for the browser to treat websocket connections to local DIFFERENTLY than WS to public. Just as my browser asks permission to use my web cam (a local resource), it should ask permission to connect to local WS (who knows what I have running locally? perhaps not even me!). – Jonesome Reinstate Monica Jun 1 at 3:51
  • I agree and hope that browser developers will notice this problem (after all, it got a very wide news coverage) and introduce protective measures. On the other hand, this issue is very tricky to properly address, because not only localhost but local network request can be sensitive too. For example, your home computer can probably access the management interface of your home router, which can not be accessed from the public internet. But browsers can't just block the whole private IP range as that would include web servers on the local network, like a company intranet. – Zoltan Jun 1 at 18:46
  • Please also note that although I provided a more generic rule, you can be more specific and block localhost only. This, however, can be error-prone and I did not provide a more specific rule because I did not feel confident enough that I could come up with a rule that matched all localhost aliases. – Zoltan Jun 1 at 18:55
2

In answer to browser plug-ins that may be able to block this traffic, I would recommend trying uMatrix. There are other plug-ins with similar capabilities (e.g., NoScript), but I find uMatrix more intuitive. It is possible that uBlock Origin (or its derivative Nano Adblocker) can block the traffic, but this will depend from where the scripts load.

uMatrix can block third-party (as well as first-party) scripts (and other elements). If the scripts are loaded from a separate website, then uMatrix may work perfectly. If the scripts are loaded from the origin website, it would be necessary to block first-party scripts which will seriously break website functionality usually. These extensions may leak initial connections. Once blocking rules are created, the browser extensions do appear to work reliably. This behavior of leaking initial connections may be due to the default configuration which permit some elements to load from third-parties (e.g., images and CSS).

Another option, though not one you requested, is an OS-level software firewall, such as Little Snitch for macOS. I have found Little Snitch far more effective than the browser extensions at blocking the kind of behavior you are describing (and have witnessed).

| improve this answer | |
1

It is possible this scan is coming from ThreatMetrix (just a rumor, not confirmed that I know of).

There is now a documented proof of concept that this vulnerability can be used against developers.

This thing is real.

But mitigations are, currently, unknown.

| improve this answer | |
1

To block this, you can use uBlock dynamic filtering (enable advanced user settings to use it and do read documentation):

* [::1] * block
* 10 * block
* 127 * block
* 172.16 * block
* 192.168 * block
* localhost * block

[::1] [::1] * allow
10 10 * allow
127 127 * allow
172.16 172.16 * allow
192.168 192.168 * allow
localhost localhost * allow

This will block connections from anywhere to your computer and local network, but allow such connections from your computer and local network.

As an alternative, you can use uMatrix or firewall.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.