5 ms·

I started a local webserver listening on localhost:80 just to see what happens, but this thing seems to not detect it. It shows me "Scanning localhost ... local

I started a local webserver listening on localhost:80 just to see what happens, but this thing seems to not detect it. It shows me "Scanning localhost ... localhost complete." Edit: My guess is that this thing can only detect servers that send a CORS header that permits cross domain access. It could probably do way better detection if it did not do xhr requests but added script/css/whatever elements to its own page pointing to localhost and detects if those error out.

ratsimihah 7y ago
It's not that it doesn't detect it, but it's not open to external networks, which I guess is a good thing.
- founderling 7y ago
  What do you mean?
  - timvisee 7y ago
    Probably that your browser is blocking access to the local domain, from the context of an external domain. I'm just guessing here, of course.
jensneuse 7y ago
CORS is a security mechanism for browsers to prevent leaking user information (e.g. cookies) when doing cross domain requests from a browser. CORS does not prevent accessing the server at all. You can always curl a CORS protected server but you won't be able to make a requests including the user's cookies from a disallowed domain.
- jeltz 7y ago
  Well yeah, but CROS prevents his demo from working. And you cannot curl something remotely when it only binds to 127.0.0.1.
- dillonmckay 7y ago
  Hmmm... I can see the request in server logs, but it seems CORS is preventing the response. I may be missing something.
  - kbenson 7y ago
    They way this is set up it's enumerating systems and ports on internal networks, not actually accessing those systems and ports. The CORS header (or lack thereof) in the HTTP response of the requested item is what dictates whether it can be accessed, so what happens is the request first sends a HEAD request to get the headers for the endpoint, and then if CORS is set up and allowed for cross-domain access is allows the connection (or if it's a request to the same domain and CORS for the current page isn't too restrictive, it allows the initial request without a HEAD request). What you see in the browser developer tools if you open them up is that a bunch of requests are being made, but are being denied because they are failing CORS checks. Where data is being leaked (in context of security) is that there's a difference in how the responses are handled. Either it's allowed (because the remote side CORS is too loose) in which case the page will show s message that the specific host/port combi is available, or it will get no response and time out, in which case they skip checking that host any more and assume there's nothing at that IP (which is when they print the "unreachable" message), or it continues on with the next port. If at the end there's been no success and no timeout, it prints the "complete" message, and that means there's probably something at that IP. An important thing to note is that CORS is not like a firewall, and it doesn't actually stop all traffic from happening, so that can sometimes be used to get additional information that's not necessarily meant to be exposed. That said, what the page is showing is that the specific way CORS functions (that is, asking the remote side if they accesible), and the fact that Javascript runs locally on your browser, means that there's some interesting ways those interact which can cause security concerns. A as idea of how this could be used to more nefarious ends, if it found listening and accessible servers on localhost or the local network, it could then try to identify them based on the headers/content returned, and try to do something with that. Given that you could possibly even compile some network vulnerability scanner/exploiter to WASM and use it for only the subset of vulnerabilities it could accomplish through plain HTTP requests (a lot of work, it's probably easier to just write your own shim and crib their exploit library), this could be very easily weaponized.
keithnz 7y ago
I started some as well, it didn't find anything.
ozim 7y ago
I started python -m SimpleHTTPServer 5000 and site reports nothing, but I get: 127.0.0.1 - - [28/May/2019 22:14:51] "GET / HTTP/1.1" 200 - each time I refresh page. So it sends request that is received by server but somehow does not register on site.
- Skunkleton 7y ago
  Because your browser is preventing the javascript from accessing the response.
  - lostmsu 7y ago
    I wonder if one can read the response via the time side-channel attack.
nodesocket 7y ago
> Scanning localhost ... localhost complete. Yet I am running Node.js http-server[1], and see the request in the logs: [Tue May 28 2019 23:56:54 GMT-0500 (Central Daylight Time)] "GET /" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36" [1] https://github.com/indexzero/http-server https://github.com/indexzero/http-server

ratsimihah 7y ago

It's not that it doesn't detect it, but it's not open to external networks, which I guess is a good thing.

founderling 7y ago
What do you mean?
- timvisee 7y ago
  Probably that your browser is blocking access to the local domain, from the context of an external domain. I'm just guessing here, of course.

jensneuse 7y ago

CORS is a security mechanism for browsers to prevent leaking user information (e.g. cookies) when doing cross domain requests from a browser. CORS does not prevent accessing the server at all. You can always curl a CORS protected server but you won't be able to make a requests including the user's cookies from a disallowed domain.

jeltz 7y ago
Well yeah, but CROS prevents his demo from working. And you cannot curl something remotely when it only binds to 127.0.0.1.
dillonmckay 7y ago
Hmmm... I can see the request in server logs, but it seems CORS is preventing the response. I may be missing something.
- kbenson 7y ago
  They way this is set up it's enumerating systems and ports on internal networks, not actually accessing those systems and ports. The CORS header (or lack thereof) in the HTTP response of the requested item is what dictates whether it can be accessed, so what happens is the request first sends a HEAD request to get the headers for the endpoint, and then if CORS is set up and allowed for cross-domain access is allows the connection (or if it's a request to the same domain and CORS for the current page isn't too restrictive, it allows the initial request without a HEAD request). What you see in the browser developer tools if you open them up is that a bunch of requests are being made, but are being denied because they are failing CORS checks. Where data is being leaked (in context of security) is that there's a difference in how the responses are handled. Either it's allowed (because the remote side CORS is too loose) in which case the page will show s message that the specific host/port combi is available, or it will get no response and time out, in which case they skip checking that host any more and assume there's nothing at that IP (which is when they print the "unreachable" message), or it continues on with the next port. If at the end there's been no success and no timeout, it prints the "complete" message, and that means there's probably something at that IP. An important thing to note is that CORS is not like a firewall, and it doesn't actually stop all traffic from happening, so that can sometimes be used to get additional information that's not necessarily meant to be exposed. That said, what the page is showing is that the specific way CORS functions (that is, asking the remote side if they accesible), and the fact that Javascript runs locally on your browser, means that there's some interesting ways those interact which can cause security concerns. A as idea of how this could be used to more nefarious ends, if it found listening and accessible servers on localhost or the local network, it could then try to identify them based on the headers/content returned, and try to do something with that. Given that you could possibly even compile some network vulnerability scanner/exploiter to WASM and use it for only the subset of vulnerabilities it could accomplish through plain HTTP requests (a lot of work, it's probably easier to just write your own shim and crib their exploit library), this could be very easily weaponized.

keithnz 7y ago

I started some as well, it didn't find anything.

ozim 7y ago

I started python -m SimpleHTTPServer 5000 and site reports nothing, but I get: 127.0.0.1 - - [28/May/2019 22:14:51] "GET / HTTP/1.1" 200 - each time I refresh page. So it sends request that is received by server but somehow does not register on site.

Skunkleton 7y ago
Because your browser is preventing the javascript from accessing the response.
- lostmsu 7y ago
  I wonder if one can read the response via the time side-channel attack.

nodesocket 7y ago

> Scanning localhost ... localhost complete. Yet I am running Node.js http-server[1], and see the request in the logs: [Tue May 28 2019 23:56:54 GMT-0500 (Central Daylight Time)] "GET /" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36" [1] https://github.com/indexzero/http-server https://github.com/indexzero/http-server