[WEB SECURITY] JavaScript Malware, port scanning, and beyond

[Jeremiah Grossman <jeremiah@xxxxxxxxxxxxxxx>]

As RSnake said, we've been working together on JavaScript port  
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  
when XSS has become the new Buffer Overflow and JavaScript Malware is  
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.

The assumption here is the victim is in the thread of JavaScript  
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  
Style Sheets (CSS) and JavaScript includes. Such as <link src=....,  
<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  
JavaScript Malware. If a target web server has a default u/p basic  
auth, like so many DSL routers, and the victim is running Firefox/ 
Mozilla, your gold. Firefox/Mozilla support the url notation (http:// 
user:pass@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.


XSS Chaining:
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:
http://ha.ckers.org/blog/20060718/attacking-applications-via-xss- 
proxies/


JavaScript Vulnerability Scanner:
After JavaScript Malware has port scanned the intranet for web  
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  
in JavaScript, which should present its own set of unique set of  
design challenges. As yet, nothing like this has been built, but  
should be possible.


DOM-Based XSS:
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  
JavaScript includes from other locations such advertising banners,  
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
http://www.webappsec.org/projects/articles/071105.shtml


There is more, but I'll leave it at that for now. Plenty more to talk  
about after Black Hat. See ya there!



Regards,

Jeremiah Grossman
CTO, WhiteHat Security
www.whitehatsec.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]