Browsing the Intranet Problem

Many intranet threats could be resolved at the browser level, but solutions will require some baking

5:50 PM -- The recent Black Hat and DefCon conferences, which finally wrapped up last week, were rich with Web hacking. It was definitely a first for me, to see so many talks about Web application security -- an area of security that was previously seen as just a narrow niche of security. Now, after all has been said and done, I think there are a few good takeaways that browser companies need to chew on.

First, there are the attacks. DNS rebinding attacks were in full force at Black Hat. At least three talks mentioned this rather obscure and complex attack, which allows hackers to access IP-restricted content behind firewalls. In addition, I participated in a talk on hacking intranets without using JavaScript. Clearly, the intranet is no longer off limits just because a firewall is in place.

So what can we do about it? There’s been some talk about disallowing inbound requests through VPN tunnels to anything that’s not already authorized -- like access to an internal wiki or Webmail, for instance. That’s a pretty flawed mitigation technique, because those targets are often the exact ones the bad guys are after. This is a problem that needs to be solved at the browser level.

There are two ways to handle it at the browser. The first is to leverage the "zones" concept already used by Internet Explorer. The concept is that the Internet zone should never be able to access the intranet zone, but this separation can break some Web apps -- especially things like Google Desktop.

While most people would gladly give up Google Desktop to protect their intranet’s security, it does cause some grief and isn’t seamless. No doubt someone would cry antitrust if this becomes a blanket practice. You could simply whitelist applications or ports that should be allowed -- such as Google Desktop, which runs on a specific, high port.

The other way to fix the problem at the browser level is to allow hooks that plug-in manufacturers can use. Allowing antivirus vendors to do the detection on the browser company’s behalf makes a lot of sense, but because it wouldn’t be automatically built into the browser, it’s not ubiquitous. If the solution isn't everywhere, it doesn’t matter, because all a bad guy needs to do is wait patiently until he finds a target that isn’t protected.

It’s going to be awhile before we see a browser-oriented solution put in place. But at least the browser companies know it’s a problem and are working to find solutions.

— RSnake is a red-blooded lumberjack whose rants can also be found at Ha.ckers and F* Special to Dark Reading