A closer look at getting Firefox to scan for you
Yesterday, I discussed an attack posted to Full-Disclosure by mark@bindshell.net, that expanded upon the usual technique of JavaScript scanners by using PASV responses to the FTP client portion of Firefox (other browsers exhibited similar behavior, but turned out to not be nearly as useful for this sort of scanning). I ended the post on the note of wanting to see how it would look if one were being scanned by someone’s web browser. Since the Mozilla developers seem to be working on a fix, I figured I’d better go ahead and do my analysis before things got stale :) .
The thought occurred to me after reading the paper that using the PASV technique would make the scan less obviously show up as a web browsing client to a target that’s paying attention. The previously used techniques of making HTTP connections to the targets’ ports results in the web browser sending a request header each time. I’ve set up a test environment for looking at this:
- 172.16.185.1 – The VMWare host. The Firefox browser is running here, which will be the apparent source of the scans
- 172.16.185.129 – Linux guest OS. Contains the “malicious” javascript on its web server, and is running the perl FTP server supplied with mark’s paper.
- 172.16.185.131 – Linux guest OS. Acting as the target of the scan. Ports 22 (ssh), 80 (apache), and 8080 (just a netcat listener) are open.
For the “old” technique, I used the code available from gnucitizen. This is, of course, limited, as Firefox won’t allow the HTTP connection to a low port, like 22. Here is a packet capture of how it looked when it hit the netcat listener:
As you can see, the browser dumped the following header into the netcat listener:
GET / HTTP/1.1 Host: 172.16.185.131:8080 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2) Gecko/20061201 Firefox/2.0.0.2 (Ubuntu-feisty) Accept: image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://172.16.185.129/pasv/ps.html
Taking a look at this, you can see that it could be pretty obvious to the target that they are being scanned using this method, if they’re looking for this sort of thing. Elements of this header could wind up in the listening daemon’s logs or a Snort rule could easily catch this sort of behavior occurring on the wrong ports.
The FTP PASV technique however, makes the web browser connect to the port specified by the server, and wait for incoming data. This makes it behave much more like a traditional full-TCP-connect type scan, only perhaps a bit slower and with no attempts at sending data to elicit a banner. Here are a couple of pcap dumps of what mark@bindshell.net’s technique looked like when it hit SSHD and HTTPD:
As you can see, the browser sends nothing. The SSH server responds with its banner without any prodding, which works out nicely, while the web server sits there in a stalemate with the PASV connection, both waiting on the other to say something. As the paper says, determining whether a port is open or not is a matter of timing.
So, it may be harder for a target to determine that they are being subjected to a scan of this nature. An nmap scan would likely run much faster, so it’d be easy to tell it’s not nmap, but it’s not nearly as obvious that it is a web browser scanning as it was with the older JavaScript scanning technique. It could result in the source of an attack being misidentified, with the blame being placed on an innocent web browser.
Also, the paper isn’t kidding about the banner-grabbing taking a looooong time. If you use this technique in a pen-test, you might want to have the page load up a flash version of bejeweled or something to keep the user’s attention while their web browser scans for you ;) .
As a final note, I’ve been told that the reason there was no response to mark from security@ Mozilla was due to his notification email being filtered as spam. I think that this is an excellent illustration of the difficulties one can face in filtering security and abuse contact emails. While mountains of garbage pile up in addresses like this, I can only recommend that the bar should be set very low for emails to come through. It’s better to spend some time sifting through the crap than to miss something like this.
A new version of Firefox should be released soon that fixes this vulnerability.