3 ms·

Can you elaborate on this? Legitimately curious.

bitexploder 10y ago
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)
- michaelvoz 10y ago
  Is port scanning dangerous? How can JS in a browser build a tunnel to anything?
  - bmon 10y ago
    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.
  - bitexploder 10y ago
    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".
TheBobinator 10y ago
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.
- Jonnax 10y ago
  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/ https://panopticlick.eff.org/
unabridged 10y ago
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.

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)

michaelvoz 10y ago
Is port scanning dangerous? How can JS in a browser build a tunnel to anything?
- bmon 10y ago
  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.
- bitexploder 10y ago
  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".

TheBobinator 10y ago

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.

Jonnax 10y ago
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/ https://panopticlick.eff.org/

unabridged 10y ago

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.