jeremiah at whitehatsec.com
Mon Jul 31 15:25:27 EDT 2006
scanning and other network attacks for the better part of 2006. Now
that the cat is half-out-of-the-bag and we're days away from Black
Hat, we can add more to the conversation. My belief is that the
recent discoveries around XSS vulnerabilities (Worms and Network-
Based Attacks) mark a turning point in infosec. We're entering a time
the new shell code. During our research we discovered many
interesting capabilities and many things we still don't know how to
do, but would like to. There are several areas waiting to be
explored, both in XSS filter-bypass and also what's possible during
exploitation. Members of the community might find it fascinating to
jump in and perhaps discover some new techniques on their own.
control (XSS optional) and no use of traditional browser "exploits".
Additional Blind Web Server Fingerprinting Techniques:
Fingerprinting of remote web servers can be done using unique image
URL's (capture OnError) The same is also possible using Cascading
<script src=... Many times these files are just as unique as an
image. The technique is to simply use object or class detection.
Brute Forcing Basic HTTP Auth:
HTTP Basic Auth has proven to be a worthy adversary when it come to
auth, like so many DSL routers, and the victim is running Firefox/
Mozilla, your gold. Firefox/Mozilla support the url notation (http://
user:pass at host/), while Internet Explorer (IE) does not. So forcing
an authenticated Basic Auth request with IE is not possible (as best
we can tell). In Firefox/Mozilla, when you get the u/p wrong, it open
a pop-up dialog. It would be nice to find a way to brute force the
basic auth in the background while suppressing the popup, but as of
yet, no known way has surfaced.
Once a user is XSS'ed, or in the thread of JS control, its possible
to automatically XSS them on other domains. Such as using an
invisible IFRAME. A very powerful technique. Of course this requires
the attacker to know XSS vulnerabilities on those domains ahead of
time. This is important to know because when a user is XSS'ed, its
possible to force them to send just about any off-domain HTTP
request, but if the attacker wants to see the response, they need to
have them XSS'ed on the next domain. *some caveats exist*
RSnake tackles this issue in a bit different way:
servers, the next logical step is to begin looking for well-known
vulnerabilities. We can perform fingerprinting in between, but there
is need for a vulnerability scanner. Something like a Nikto written
design challenges. As yet, nothing like this has been built, but
should be possible.
When Amit Klein first wrote about this type of XSS vulnerability it
took me several months to appreciate its impact. While DOM-Based XSS
are not as prevalent as the standard non-persistent variety, but do
have the potential of being a lot more dangerous depending on where
they are located. For instance, millions of websites contain
RSS feeds, and other web page widgets. Many JS includes are hundreds
if not thousands of lines in length. Its entirely possible, if not
likely, for one of these JS includes to have an DOM-Based XSS issue.
The potential exposure could extend to any website using it. Perhaps
millions of websites would instantly contain an XSS vulnerability
while none of "their" code is in fact vulnerable. This is an
especially challenging problem to web security professionals to solve
when protecting their websites.
DOM Based Cross Site Scripting or XSS of the Third Kind
There is more, but I'll leave it at that for now. Plenty more to talk
about after Black Hat. See ya there!
CTO, WhiteHat Security
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