The key here are NATs. You would have to forward ports to receive incoming connections.
– marshal craftJan 13 '18 at 5:03

1

@marshalcraft: NAT is irrelevant as are most firewalls. The access to internal sites is not done directly from the outside. If the user browses an external site this site can make the browser visit internal resources. Access is thus done from the browser, i.e. from the inside.
– Steffen UllrichJan 13 '18 at 5:32

4 Answers
4

Most browsers don't distinguish between WAN, LAN and local host. This means they apply the same policies and restrictions for cross-site requests from WAN to LAN as between different sites on the WAN or between different sites on the same LAN.

And while CSRF can only cause unwanted actions (like change DNS settings of a router) but not be used by itself to exfiltrate data from inside other attacks can: if you have an internal site which is accessible by WebSockets it can also be accessed by default from outside by using the browser as a trampoline (Cross-Origin WebSocket). The internal site would explicitly need to check the Origin of the request in order to stop this access (i.e. open and insecure by default). Other attacks which make exfiltration possible are XSS attacks against internal sites or DNS rebinding. Also, explicitly set insecure settings of Cross-Origin Policies (CORS) on internal sites can be used for exfiltration too. And there might be more possible by using Flash.

Preventing this access is hard since most browsers do not distinguish between internal and external sites. This means it is expected that internal sites have the same protection as external sites. Even a perimeter firewall which is used to protect the internal LAN from outside attacks will usually not prevent such access since these attacks work at a layer not visible to most firewalls.

One way to restrict such access is to use multiple browsers (or profiles) - one for internal and one for external sites. The access could be restricted by allowing internet access only through an explicit proxy: One browser will have the proxy configured for all sites and can thus only access external sites providing that the proxy does not allow access to internal sites. The other browser has no proxy configured and can thus internal but no external sites. This strict separation stops cross-site access between external and internal through the browser. But it probably impacts usability in most environments.

While browsing internet, can websites execute code through my browser
that access websites or services that are hosted on Localhost or LAN?

There is some good information about DNS rebinding, CSRF, etc. in other answers. However, I'm surprised that nobody mentioned network scanning. JavaScript can be used to scan your entire local network, and can determine what ports are open on which hosts.

Note that a website could do this without your permission or knowledge.

Additionally, if you are running any local services (e.g. redis, memcached, elasticsearch), they can often be attacked from the browser as well, as shown in this post: https://bouk.co/blog/hacking-developers/

Data can be written to these services, but CORS prevents reading data from them, so this is where the DNS rebinding attacks come in.

Also, can data from intranet websites/services be
scraped/hacked/stolen through code that is run by remote site through
my web-browser?

Similar to above, this depends on the CORS policy set by the target webserver. This can be bypassed with DNS rebinding.

Do modern web browsers protect from these kind of attacks and how?

Not really; as others have said, the browser doesn't really distinguish WAN from LAN, nor should it necessarily do this. While CORS helps, we have seen that it can be bypassed with DNS rebinding.

How to isolate Localhost and Intranet access from browser?

The only real solution is to disable all untrusted JavaScript. The NoScript extension is available for major browsers and is fairly configurable.

I suppose you could also attempt to segregate your PC from the rest of the network, and there may be a way (with iptables) to prevent your browser from accessing local services. However, I suspect this will be tedious.

Yes, sites and services run off your LAN or localhost can (sometimes) be accessed via a malicious attacker in the browser. In addition to the bugs in the browser mentioned by cybernard, there are other (far more common) attacks that make this possible.

Remember that malicious javascript runs in the browser and so it can attack anything your browser can reach: this includes localhost and your LAN. It's up to applications there to reject crafted requests.

DNS Rebinding Attacks

In a DNS rebinding attack, the attacker uses a hostname that will refer to two different IP addresses. First, it will refer to their server and they will load a malicious page containing javascript from that server. The javascript will wait and then make another request to the same hostname, but in the meantime, the DNS server will have changed the IP address in use by that hostname to localhost or an IP on your LAN. Since the hostname remains the same, the malicious javascript has no trouble accessing the local resource and can read data from your localhost or LAN.

Some DNS servers (including those built into some routers) offer protection against this by not accepting "local" IPs (RFC1918 & localhost) in responses from the internet.

Cross Site Request Forgery

If the attacker only wants to change state on your webapp and the application is vulnerable to Cross-Site Request Forgery (CSRF), then they can make requests to that site without even being able to read the contents of pages. CSRF is in the OWASP Top 10, so this is hardly an uncommon bug to occur.

Bad CORS Settings

Applications that make use of CORS to allow cross-origin requests might be mis-configured and allow cross-origin requests from malicious sites running in your browser. While certainly not unique to your LAN or localhost, they can still be affected.

Question 1: While browsing internet, can websites execute code through my browser that access websites or services that are hosted on Localhost or LAN?

Yes, not easily and only through some kind of hacking.

Hacker are very clever, and are constantly working to exploit vulnerabilities in web browsers. If they hit your browser with a zero day they could very well inject code and get it to execute. Thus leveraging greater and greater access with each attempt. Most hacker will inject a remote desktop virus so they can see and interact with the desktop, but not always.

Question 2: Also, can data from intranet websites/services be scraped/hacked/stolen through code that is run by remote site through my web-browser?

Yes, not easily and only through some kind of hacking.

Question 3: Do modern web browsers protect from these kind of attacks and how?

Hundreds,thousands, or more of man hours of testing. Having teams of security research poke each browser in every possible manner to see what breaks. Then having them report on it so the browser team can fix it. They also sponsor events at hacking convention where real money bounties are paid for exploits. If the exploit is good enough it can bring in 10,000's or even a million dollars for the researcher or team that bring the hack in.

They even have fuzzers, throwing random data at the web browser to see if anything break or behaves in an unexpected way.

High level zero days are becoming more rare, but very clever people are still working on them. Treasure troves of zero day exploits are being hoarder by evil doing hacker group willing to sell if the price is right.

Question 4: How to isolate Localhost and Intranet access from browser?

The top web browser have all been thoroughly test and are constantly patching their code. While the answer is YES they can get in, it is incredibly difficult now a days. It usually takes teams of people to find and exploit vulnerabilities the top browser firefox,chrome, and edge. It often takes months of dedicated research to even find a weakness. Even then it can take additional months to turn that into a working exploit. In the meantime the whitehats, good guys, inch closer and closer to either finding the same thing and fixing the problem. This can nullify months of hard work for hackers. It is not a trivial task anymore.

I think this answer is wrong. Notably CSRF can be used to execute unwanted actions even on internal sites from outside. And this is actively used in attacks - see for example threatpost.com/…. And Cross-Origin WebSockets can not only be used to cause unwanted actions but also to exfiltrate data. Most browsers do not distinguish at all between WAN and LAN and local host.
– Steffen UllrichJan 13 '18 at 3:56

@SteffenUllrich It can't be done through normal channels. However, hackers usually find ways to inject their own evil doing code which bypasses the normal order of things. Just look at the 3 recent CPU vulnerabilities if they can get a foot hold, and your not patched they can exploit it. Their is even a proof of concept video for stealing passwords using these vulnerabilites
– cybernardJan 13 '18 at 4:08