Hacker News Reader

Comment by mjevans | Hacker News Reader

I'd like to focus on the security issue of 'UDP probes and sending results back over HTTPS'. This is an /inherent security issue/ of running ANYONE else's code within a corporate network.

ECMAscript/JavaScript should NOT be blindly run within corporate networks, and web 2.0 is insane for making all websites expect that.

View on HN

If your underbelly is that soft you have major security issues. There are dozens and dozens of ways to get a network probe behind a firewall. Pretty much anything that can be told to fetch anything anywhere can possibly be used. HTML can do a host scan or even a port scan without JavaScript using maliciously crafted DNS records and img or other tags combined with the use of timing to determine which ones are blocking and which ones got a connection refused or a connection right away.

Firewalls are a much more porous than most people think. It's only a first line of defense to prevent badly configured or broken junk on your network from being instantly exploitable.

http://www.elitefeet.com/wp-content/uploads/wooden-gate-no-f...

Can you elaborate on this? Legitimately curious.

It is allows malicious code to scan ports. It allows easy building of difficult to manage tunnels (never mind corkscrew and port 443 SSH servers breaking out of 90% of corp networks I have been on via their HTTP/S proxy)

Is port scanning dangerous? How can JS in a browser build a tunnel to anything?

Port scanning itself is obviously not dangerous, however I believe the author is imagining a situation where a user on the other side of a corporate firewall views a webpage which then portscans from the inside then sends the results home/starts an attack on specific ports.

edit: To answer your direct question, port scanning is probably not /that/ dangerous. It is just information gathering. You almost always need to take steps after that. But if you can build a port scan you can build any other protocol up via this scheme (possibly even just proxy other UDP tools directly) and attack internal UDP services. It just seems like a glaring network hole considering how most corp LANs are set up.

This would take a few pieces, but port scanning is pretty feasible considering I have already done it more painfully using XSS exploitation frameworks to demonstrate XSS risks for customers before.

1.) You need some javascript running in a browser on the corporate network all set up for the corporate proxy to get out to "the internet". This browser would be on a machine on the internal LAN.

2.) UDP access enabled in JavaScript somehow.

3.) A user wanting to purposefully tunnel traffic would then set up a local UDP listener and build a proxy that would communicate with the JS using UDP. You would then need an HTTPS end point "on the internet" that would make your legitimate requests. You can do long lived streaming connections. The machinery isn't that important.

4.) That is it. [Special HTTP Proxy]<--->[Corp HTTP Proxy]<--->[Browser]<--->[UDP Proxy]<--->[Your apps that want to escape]

5.) You would of course reuse existing protocols and there are a ton of ways to flow all of this at each step. But it is just one more hole.

Side note: You can perform sort of crude TCP port scanning already with a meaty enough XSS exploit. An unfettered UDP connection would let you do UDP scanning to an internal LAN then as well.

Anyway this whole scenario is really complex, it would be much easier to just use Corkscrew and the existing corporate HTTPS proxy, because you need to invent a browser to UDP proxy scheme and a browser to "your HTTP proxy" scheme that can ultimately do generic UDP/TCP requests traffic. But your system listening on HTTP and or HTTP/S on the Internet would get requests and make the actual generic UDP/TCP connections for you. Honestly this whole scheme sounds complex and annoying and there are already other schemes like proxying TCP via DNS that are more accessible for exfiltrating data :)

The general point is code in a browser is inherently "permitted" and easy to get going on an internal corporate network. The more ways that code can reach out of its sandbox the larger the attack and defense surface you have as a corporate network trying to keep machines locked down and "under control".

Parasitic Companies want the ability to run anything they want, on anyone's machine, accessing all of the users personal data, as well as their competitors data if they can get at it, and use it for whatever reason they want, and have the ability to secure those revenue streams by erecting wholly artificial and socially destructive barriers to their removal, such as getting accepted to represent their interests in standards bodies then twisting the standards to do what they want. An example of this is EUI addresses in IPV6 with the Mac address as part of the IP address as a revenue stream maximization method for advertisers.

There was a you tube video awhile ago showing java-script able to run an operating system in a web browser as well as games inside the OS. Recently, Chrome added a task manager and user logins. Chrome is no longer a web browser, it's an operating system, and what enables an entire ecosystem of abuse is java-script.

In a few years hence, someone will figure out a technology that will disable java-script from running on client machines via firewall filter. It will break a lot of websites. Let it.

Each tab runs in its own thread, a page consumes CPU and RAM. I'm not sure why it's a bad thing that a web browser has a task manager. Especially since one of the powerful things about the web is that no extra software is required for debugging / development.

It's totally possible today to create a filter that will scan for JS and remove it from sites with one of those man-in-the-middle corporate proxies.

But it'll break pretty much every site. If you're talking about a company, that's as conductive to security as mandating weekly password changes requiring no repetition, symbols, lower + upper case and 15 characters.

Users will find ways around it. Like bringing unmanaged devices to browse the internet.

In terms of broken websites, corporate users don't have the influence as they did in years past.

Since we're trending towards pretty much every person in more economically developed countries having smart phones.

If a website doesn't work for a business's users I don't see how site owners will care.

On the development of web browsers becoming an OS of their own. Sure there's work to be done to improve security. For example, fingerprinting needs to be properly mitigated [1].

The web is open. Anyone can implement a web browser. Chrome, Safari, Firefox, Edge are trending towards writing one webpage/app and having it run everywhere.

Windows, OSX, Linux, Intel, ARM, Desktop/Laptop, Mobile/Tablet. Aren't a concern past display/formatting.

[1] https://panopticlick.eff.org/

js exploits in major browsers leading to remote code execution

There are known attacks from the last year, and probably a huge pile of 0-days waiting to be used.

Meet DNS rebinding: any JS can probe and interact with all internal services.

The more and more I reflect on it, the greater and greater a mistake JavaScript turns out to have been.

What's a shame is that there is a need for much of what it offers (and, if not a need then at least a desire for much of the rest). If only there were a sane, least-privileged alternative.

Reply on news.ycombinator.com