The Generic XSS Worm
When we think of computer worms, we generally think about operating-system based worms such as the famous Code Red, which replicated itself 250,000 times in approximately nine hours on July 19, 2001. Its replication was made possible by a vulnerability within MS Windows platform. Firewalls and defense in depth help mitigate the spread of worms by providing layers of protection between public and private networks; however, a new age worm is upon us, the XSS Worm aka the Web 2.0 worm.
The Samy XSS Worm – the first of its kind to make headlines carried a payload that would display the string but most of all, Samy is my hero
on a victim’s profile. When a user viewed that profile, the worm would infect the visitor’s profile via a Cross-Site Scripting payload. Within just 20 hours, of its October 4, 2005 release, over one million user profiles were infected, making Samy one of the fastest spreading viruses of all time. In this post, I am going to summarize several publicly discussed JavaScript Malware techniques and depict how future worms may look like, based on what we have today.
XSS is a powerful engine on which to build a platform independent virus and whether we are ready or not, attackers are definitely going to be utilising these techniques in the future and the ground work and education factors must be put into place now. Think about this, an XSS engine has the potential to propagate much faster than an operating-system based worm, requires less effort in many cases (not all), requires little or no authentication and is client-side which means the XSS engine can propagate across network boundaries utilising the user’s circle of trust. This is almost the antithesis of traditional worms, which are server-side meaning it struggles to propagate over network boundaries and they usually require high operating-system level access.
XSS engines will require these fundamentals:
- ability to identify targets (the XSS vulnerability);
- an XSS payload (the purpose or exploit); and
- continuity (the propagation technique).
This article will introduce Scrape, Specific and Generic XSS engines.
Scrape
Scrape XSS Worms utilise external resources to identify targets (i.e. Google, xssed.com) – pdp recently released an article titled, The Next Super Worm which basically uses xssed.com to identify vulnerable targets. Note that this example "scrapes" the targets from a third party resource.
Specific
Specific XSS Worms usually have an individual target – the Samy XSS worm is a perfect example here. It exploited a specific vulnerability in a specific target. Its focus is not to spread across network(s) but rather to remain in once place infecting a particular aspect of a website or service.
Generic
Generic XSS Worms which make assumptions – an example here would be a worm which exploits environment variables in application frameworks like PHP’s $_SERVER['PHP_SELF']. This method is ideal for blind XSS worms, where you do not know what the web server is running ( i.e. my wp-scanner tool uses generic XSS tests to find vulnerabilities in WordPress themes; it doesn’t care what theme the user is running). Another really good example is Solarius’s recently found XSS vulnerability in ASP.NET’s PATH_INFO variable which affects the latest version of SharePoint and possibly many other ASP.NET applications. The Generic XSS engine category could also extend to include web server or application flaws (i.e. XST, Universal PDF XSS etc).
I hope I have given you some fruit for thought, and to encourage the Internet community to move forward in coming up with new techniques, methods and strategies to combat the rise of client-side flaws. Web 2.0 security will require us to lengthen our strides if we are to come up with effective solutions; a number of excellent contributions and ideas have already begun and we encourage these individuals and organizations to continue on.
ntp 
Browser developers should build anti-XSS, LocalRodeo, content-restrictions, and SafeHistory/SafeCache concepts into the browser. Someone (preferably browser developers, but could be administrators) should separate browser profiles (different process id’s) into at least two separate browsers / browser profiles:
1) Firefox for the Internet – will not connect to RFC1918
2) Firefox for your Intranet – will only connect to RFC1918
Jeremiah Grossman suggested a way to make this more transparent, but I suggest this stricter method.
Vulnerability hunters should disclose responsibly to security, cert, noc, hostmaster, postmaster, and webmaster email addresses at top-level domains, preferably to someone who has a GPG public key available in a key server (or use something similar like Hushmail or IBE). They should also check for any incident response policies and vulnerability reporting processes the organization or website owner may already have in place. There is no reason to go to another source or through an intermediary. If all email bounces or there is no response in two weeks, vulnerability hunters should try calling a person by acquiring a phone number of an appropriately titled employee on jigsaw.com, spoke.com, or linkedin.com or from whois as a last resort. If you can find an XSS, you should know how to social engineer or footprint an email address and phone number.
Administrators should respond to and fix problems within 2 weeks (XSS moves faster than buffer overflows) or full-disclosure is fully appropriate. Like I’ve said before – if administrators can respond to an SSL certificate expiring within 2 weeks – then they can also respond to an XSS finding in the same amount of time. The vulnerability researcher can then co-ordinate a fix/disclosure schedule with the vendor and should provide remediation support if necessary. If you can find an XSS with a scanning tool, you should learn how to fix them for others.
IT administrators for users should setup the ability to whitelist URL’s (e.g. http://whitetrash.sf.net ) if they think their environment can support it. They should also ensure OS, browser, and browser plugin automatic updates. Administrators should scan and patch, just like regular vulnerability management. Good administrators will enforce use of a safe browser similar to the one described in my first paragraph.
Most importantly, developers should respond to issue tracking about XSS findings (reported by the administrators / operators) immediately as the highest priority… higher than application availability issues (24x7x365). They should always use validators that are built into their framework properly. Before coding anything, they should have an enforceable coding standard built into their IDE. They should use source and static-file code checkers in their IDE. They should use source checkers (again), static-file checkers (again), and path/code coverage tools (e.g. concolic unit testing) that run fuzz testing across all inputs at build time, including on dependencies. They should combine model checkers and continuous integration tools (especially build schedulers), ensuring a clean release.
Applications should be monitored for security events using application monitoring tools (not network security tools or log management tools) by both operators/administrators and developers.
Web Application Security Scanners and Web Application Firewalls are OPTIONAL but NOT REQUIRED.
I refer to this strategy as NTPolicy. You may use or change it however you like.