I heard back from my colleague - this is what he wrote: I didn't write the original version; I found the base code at SPI Dynamics and modified it from there.
Attached is the proof of concept code I was working with. Currently it just scans the ip range given, determines if the host is active, if there is a webserver, and attempts to identify if the webserver is IIS or Apache. This works cross browser as long as javascript is allowed. Something like this could be included into almost any page, it could figure out the host IP address automatically, scan that netblock, post the data back to a host, get further instructions based on what ports/services are available, etc, all via Ajax actions or a hidden Iframe, or probably other ways too. Basically, this could provide a way for an attacker to gain access to information/services that are *inside* the firewall by simply getting you to load a web page. Pretty cool stuff! :) Let me know if you need any more information... On Thu, Jul 10, 2008 at 9:30 AM, Ben Barrett <[EMAIL PROTECTED]> wrote: > Did anyone search for this, or are they too paranoid? :) > There are a number of results, appears to not be unique at all... > http://www.google.com/search?q=javascript+%22port+scan > > One method uses <script src="...."> and typeof on the result to get a > signature; > another uses only HTML, using the link tag to attempt to load what the > browser thinks is a CSS, > and then call upon an IMG which is really a timer script. > > JS: http://www.gnucitizen.org/projects/javascript-port-scanner/ > and http://michaeldaw.org/projects/jsescanner/ > > > ~ben > > > On Thu, Jul 10, 2008 at 9:05 AM, M. Bitner <[EMAIL PROTECTED]> wrote: >> It might have been IE only, I'm not sure. I don't work in the same >> place but I can try and find out some more details from my former >> colleague. >> >> On Wed, Jul 9, 2008 at 10:47 PM, Neil Parker <[EMAIL PROTECTED]> wrote: >>> Another thing worth remembering is that just as Javascript itself differs >>> quit a bit from browser to browser, so do its security issues. A >>> feature (?) that makes it possible to write a port scanner in one >>> browser might not exist at all in another browser. >>> >>> Traditionally Internet Explorer has been considered the worst offender >>> security-wise. In part this is because it lets you say "x = new >>> ActiveXObject(...)", which sometimes makes it possible for Javascript to >>> invoke components that were never intended to be used by a web browser. >>> (Remember last year's Month of Browser Bugs? Most of the IE bugs on that >>> list revolved around ActiveXObject.) >>> >>> ActiveXObject, and its security implications, are completely absent in >>> Firefox. Not that Firefox has been free of Javascript security holes, >>> though...as it evolved from 2.0 to 2.0.0.15, many of the updates >>> included patches for Javascript security holes. Several of these involved >>> ways for Javascipt to elevate its permissions from content (highly >>> restricted) to chrome (unrestricted, with full access to your filesystem >>> and the network). >>> >>> >>> I'd be highly interested to learn how that port scanner worked. Did it >>> depend on one particular browser? >>> >>> - Neil Parker >>> _______________________________________________ >>> EUGLUG mailing list >>> euglug@euglug.org >>> http://www.euglug.org/mailman/listinfo/euglug >>> >> _______________________________________________ >> EUGLUG mailing list >> euglug@euglug.org >> http://www.euglug.org/mailman/listinfo/euglug >> > _______________________________________________ > EUGLUG mailing list > euglug@euglug.org > http://www.euglug.org/mailman/listinfo/euglug > _______________________________________________ EUGLUG mailing list euglug@euglug.org http://www.euglug.org/mailman/listinfo/euglug
