The Nduja Job: Into The World Of XSS Worms

Cross-site scripting (XSS) is as a type of vulnerability typically found in web applications, which allows code injection by malicious web users into the web pages viewed by other users. An exploited cross-site scripting vulnerability can be used by attackers to bypass access controls such as the same origin policy.

One of the older stories of XSS worms dates back to 2002, where there were claims of XSS flaws in hotmail which could be exploited to broadcast e-mail to all the people in the address book of the infected user. Last year there was a surge in worms targeting websites with XSS flaws like Samy and Yamanner.

With the advent of many popular websites that post XSS cheat sheets online and its constant updates could make the hackers cognizant of the XSS filters and the possible ways of evading them. To add to the woes are “Javascript XSS Scanners” which are automated tools for finding cross-site scripting vulnerabilities in web pages.

XSS worms are becoming more and more sophisticated. Lately there’s been a lot of attention on this POC worm which goes by the name Nduja. The worm spreads by exploiting cross-site scripting vulnerabilities in 4 leading webmail providers.

The life cycle of Nduja worm is similar to a classic e-mail worm and is capable of:

1. Harvest e-mails present in the Inbox.
2. Collecting the contacts email addresses from address book.
3. Self Propagate to the contacts.

Recent advancement towards this side is the creation of a hybrid worm which involves client side and server side component. The technology uses XSS tunneling. Portcullis Computer Security have published a whitepaper describing in detail about XSS tunneling. A typical attack scenario (also described in the paper) is as follows:

1. An attacker infects a website with a persistent or reflected (temporary) XSS attack which calls remote XSS Shell JavaScript.
2. The Victim follows a link or visits the page and executes the JavaScript within that domain.
3. The Victim’s browser begins to perform periodic requests to the XSS Shell Server and looks for new commands.
4. When the victim browser receives a new command such as it is processed and returns the results to the XSS Shell.
5. The Attacker can push new commands to victim(s) browser and view the results from the XSS Shell administration interface.

Could this technology transform into a XSS based botnet? Keep your eyes peeled on this space while we will keep you posted with updates as it happens.