4 ms·

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".

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".