Port Scanning Without JavaScript
For the past few months I’ve been following the ha.ckers weblog, which talks about hacking websites and otherwise internet-connected systems. In the most recent two posts (part 1, part 2) a way to do port scanning without JavaScript is discussed. This all harks back to early August, when SPI Dynamics discussed port scanning using JavaScript. An often heard counter measure to this technique is disabling JavaScript, but it turns out that won’t be enough.
The scan itself is quite ingenious. It relies on the way Firefox parses the document, which by default is sequentially. First, the page itself loads from the attacker’s server. The time is noted. Then, an image is loaded with it’s source set to a server in the local network, say 192.168.0.1. Once finished, another image from the attacker’s server is loaded, the time is again noted.
Because Firefox finishes loading this image before loading the next, it’s possible to determine the time it took to load the image from the local network. If this is a couple of seconds, one can assume the image request timed out, and the port is closed. If it’s faster than that, the port is open.
This goes to show that the browser security model as it is today is not good enough. One idea would be to disallow resources from outside the local network to access resources inside the network. It sounds good to me, but then I’m not a security expert :)
To close with a comment from RSnake, the ha.ckers’ author:
I think we’ve proven a our point. JavaScript isn’t the root of the problem here. Sure it enables bad stuff, but HTML and the client technologies alone can obviate the necessity for JavaScript alone. Do I think anyone is going to use this technique in reality? Probably not when JavaScript is so prevalent and cross browser compatible. But it is nice to know you can call people out when they claim they are safe because they turn off JavaScript.
First off, this won’t really work as a port scanner. As the article notes, the difference between an successful and unsuccessful connection is statistically insignificant. It’s the difference between (if I remember my TCP correctly) two packets for a closed port and at most four for an open port. Even then, it’s possible that instead of getting a timeout for a dead host, you would get any of a number of ICMP packets which would cause the connection to fail without taking long enough to be attributed to a timeout, and since you’re using a side-channel which isn’t capable of discerning between the two, you’ll get a false positive.
Besides, there’s no need to use something like this even if it worked. If you just want a standard connect scan there are plenty of other ways to go about it and retain your anonymity.
Evan | 30 November 2006, 22:54 | link