11

http://webkay.robinlinus.com/

It was on Reddit. In the middle is a Scan My Computer button. Yeah, I clicked it. It already knew my internal IP anyway without my permission. But I was never prompted to allow or disallow what it is doing. I am using Chrome.

How does this work? I am guessing from reading it is WebRTC, but this was finding other computers on the network. That was something that I needed to understand to defeat.

How can I turn this off?

EDIT: I have read this, Why is my internal IP address (private) visible from the Internet?

but the scanning was most important to me here.

Community
  • 1
johnny
  • 641
  • 1
  • 7
  • 13
  • 2
    the 'site' isn't scanning, your computer is - the scan is initiated from your browser – schroeder Dec 14 '16 at 22:03
  • 3
    Yes, it is running on the browser, but it is still scanning. Isn't it capable of reporting back to the website if it finds a machine? – johnny Dec 14 '16 at 22:05
  • 1
    https://en.wikipedia.org/wiki/Cross-origin_resource_sharing is one mitigation against unwanted access in this manner, which is often enabled by default. – Peteris Dec 15 '16 at 01:25

1 Answers1

19

On the application layer, your browser has no notion of internal and external IP addresses. So any website can simply tell your browser to request a resource from your internal network. This wouldn't get blocked since for the browser it's just an ordinary cross-origin request. Note that the requesting site won't be able to read anything, it could just conclude that something is there.

For example, a website could try to find out if your router has a web interface at 192.168.1.1 by using a snippet like this:

<img src="http://192.168.1.1/favicon.ico" onload="alert('Yay')" onerror="alert('No')">`

Similarly, a website can make you request resources from internal IP addresses (and at almost arbitrary ports) and measure the response times to conclude that there is a service running: E.g., if a request to http://localhost:8080 has a short response time, you might be running a local proxy or similar.

If you cascade such requests, you can somewhat make the browser conduct a basic network scan and infer about existing IPs, hostnames and services.

This idea is also used for actual attacks. Even if your router interface isn't accessible from outside, an external attacker could execute an attack like the recent Netgear router arbitrary code execution exploit by tricking you into visiting a prepared website that makes you conduct the attack yourself by issuing a specially crafted request to the router interface. (Essentially a CSRF attack on the intranet.)

One way to mitigate the risk of intranet access is the ABE (Application Boundaries Enforcer) module of the NoScript extension that can be configured to block particular hosts.

Can an attacker really not read any content?

Often they can read the content of an intranet site by conducting a DNS rebinding attack. Say, your router interface is accessible at 192.168.1.1/info.cgi. In a DNS rebinding attack, the attacker makes you visit attacker.com which they first point to their own server's IP, load some Javascript, and then point it to 192.168.1.1. When the Javascript then requests attacker.com/info.cgi, it's instead resolved to you router interface and the script is able to read the response content. This doesn't violate the same-origin policy because all requests are on the same origin (the domain attacker.com), although the DNS entry switches in the background. (As a countermeasure, sites should verify that the Host header contains either the IP or the intranet name. But lots of routers don't do that.)

Arminius
  • 44,242
  • 14
  • 143
  • 138
  • On mind it found a web server. Why couldn't it try different things to that web server and see what comes back? – johnny Dec 14 '16 at 22:23
  • 4
    It could, and probably doesn't just because the author hasn't bothered to write that logic. – Xiong Chiamiov Dec 14 '16 at 22:26
  • @XiongChiamiov and why do browsers have this? I can't imagine anything (well, I can) dangerous that comes *stock* with browsers. I was aware of WebRTC, but not the hacking implications. – johnny Dec 14 '16 at 22:38
  • 3
    It's a fairly fundamental part of web 2.0 to be able to make requests to web servers - that's how anything Ajax works. – Xiong Chiamiov Dec 15 '16 at 00:59
  • 3
    @johnny It can't see *what* comes back unless your local webserver includes a CORS header allowing it. That's effectively what the last sentence of the first paragraph in this answer says. – Bob Dec 15 '16 at 05:34