Web-Based Worms: How XSS Is Paving the Way for Future Malware

I first became aware of cross-site scripting (XSS) nearly a decade ago. At the time, despite being an all too prevalent bug in Web applications, the risk posed by the flaw was of limited value. It was the go-to vulnerability for any pen tester that was having trouble digging up a meaningful vulnerability to add to his audit report.

That has all changed now. Today, XSS represents a meaningful threat — a threat that is not only leveraged by attackers to harvest authentication credentials, but also is enabling a new generation of malware in the form of Web-based worms.

What Is XSS?

Depending upon whom you listen to, the statistics may be different, but virtually all agree that XSS remains the most prevalent Web application vulnerability that we face today.

In its latest security statistics report, White Hat Security found that 65 percent of the sites it tested had XSS vulnerabilities. Why is it that after nearly a decade in the spotlight, XSS remains so prevalent?

There are three reasons: First, XSS can exist anywhere user-supplied input is accepted and used by an application. In today’s Web, where user-supplied content is not only allowed, but also encouraged, that leaves plenty of opportunity to introduce a flaw into an application.

Second, we have failed to educate developers when it comes to security. To this day, most development textbooks actually teach insecure coding practices and largely ignore the concept of input validation.

Finally, product managers, development leads or those tasked with prioritizing engineering resources continue to treat correcting XSS vulnerabilities as a low priority, if they even recognize the threat at all.

Figure 1 – Likelihood of Web Application Vulnerabilities by Class – WhiteHat Security, December 2008

(click image to enlarge)

What is XSS? In short, it is a vulnerability caused by improper input validation, which permits executable content to be embedded within a dynamically generated Web page. Now, that same definition could be used to describe a fairly broad array of vulnerabilities, so let’s break it down further.

Consider for example, a search page. An end-user searches for the word ‘apple’ and the Web application returns a dynamically generated page stating something like “your results for the search term: apple” followed by the results themselves. In this case, the word ‘apple’ in the previous statement represents user-supplied input that was used by the application and embedded into a dynamically generated page.

Now, this is standard functionality, but what happens if the Web application fails to validate user-supplied input? What if the user inputs active content such as JavaScript? If no validation occurred, the JavaScript would be embedded in the page returned, and the user’s Web browser would interpret and execute the code.

While any form of active script could be leveraged in the attack, JavaScript tends to be the language of choice for XSS attacks, given its near universal implementation among modern Web browsers.

While others may argue that there are multiple flavors of XSS, I prefer to focus on two primary categories: reflected and persistent. As a general rule of thumb, think of reflected as a scenario where one attack equals one victim, while persistent permits one attack to target many victims. Let’s begin by focusing on reflected XSS.

Figure 2 – Reflected XSS

(click image to enlarge)

All client-side attacks involve social engineering. In this case, a victim must be coerced into sending the initial request, which triggers the XSS attack. This is generally accomplished by sending HTML-formatted spam email. The message will include a link that has the malicious JavaScript embedded as a parameter in the request.

When the victim clicks on the malicious link, a request is sent to a page vulnerable to XSS. The page accepts the malicious JavaScript due to improper input validation.

The malicious JavaScript is embedded in the response and returned to the victim’s browser.

When received, the victim’s Web browser interprets the page and executes the injected JavaScript.

The attack will generally complete when information is returned to the attacker. Most commonly, the attacker is after the victim’s cookie contents. With this information — assuming a password protected Web application — the attacker will then be able to impersonate the victim for as long as the session remains active.

Persistent XSS follows a very similar path, with the difference being the injection point of the malicious JavaScript. With reflected XSS, the JavaScript is embedded into a URL, which is sent to a single potential victim. With persistent XSS, the JavaScript is instead embedded into a page that permits and stores user-supplied content (e.g. a Web forum), where it will be accessible to multiple potential victims. Spam email may still be sent to victims to convince them to visit the page in question, but this time around, the malicious JavaScript is not directly sent to the victim.

What Has Changed?

As mentioned, the severity of XSS has increased over time. Why? For one thing, past recommendations for combating XSS attacks are no longer realistic. We used to tell people to simply disable active scripting — or, most notably, JavaScript — within the Web browser in order to avoid falling victim to XSS.

While this still holds true, it’s simply not realistic if you want to enjoy the modern Web. The technologies that permit user-friendly Web design, such as Ajax, have now become so commonplace that many Web applications would simply become inaccessible should you chose to follow such advice.

A more important change involves the type to applications that we’re seeing on the Web today. At the turn of century, we referred to content on the Web as a ‘Web site.’ At that time, Web content was nothing more than an electronic brochure — a way for entities to advertise.

As Web technologies evolved, the term ‘Web application’ became commonplace. The Web was no longer static. Rather, content was dynamically generated based on user-supplied inputs. This also marked a surge in Web-based attacks, as the Web became interactive, opening up potential attack vectors.

Today, we are witnessing the growth of social networking sites such as Facebook, and we’re seeing a new entity emerging. We are witnessing the emergence of ‘Web platforms.’ These are no longer applications with fixed functionality, but rather platforms that empower users to become developers.

Third parties no longer simply supply content. Today, they also provide functionality. Users, on the other hand, no longer interact with such platforms simply as a utility to accomplish a task — purchase an airline ticket, check the weather, etc. Today, social networks have become trusted platforms where users choose to spend a significant portion of their day.

Social networks have evolved into not only the communication medium of choice, but also a gateway to access a multitude of external resources, and a storage medium for sensitive information such as contact lists.

Web-Based Worms

It is the emergence of the Web platform, primarily in the form of social networks, that has paved the way for the future of malware. Traditionally, worms have traveled from desktop to desktop. Today, we are beginning to experience a new phenomenon: the Web-based worm, which instead travels from profile to profile, within a Web platform.

A very real limitation of Web-based worms is that they must live within the ecosystem in which they originated. However, when that ecosystem comprises 300 million accounts, that isn’t much of a limitation at all. Moreover, as sites continue to expose and share Web based APIs, the potential for cross-platform Web-based worms already exists.

Earlier this year, a 17-year-old, self-described “bored developer” provided us with another reminder of the potential of the Web-based worm. On April 11, numerous Twitter users began noticing that their account postings included items that they hadn’t submitted. The mysterious postings were promoting a previously obscure Web site known as “StalkDaily.com.” The culprit? A Web-based worm written by Michael Mooney. Michael had identified XSS vulnerabilities within Twitter — not the first such occurrence — that permitted him to write a Web-based worm.

Figure 3- Propagation of one variant of Michael Mooney’s StalkDaily worm

(click image to enlarge)

1. A victim views a previously infected profile of another Twitter user

2. Malicious JavaScript (persistent XSS) is downloaded to the victim’s browser

3. The JavaScript established an Ajax connection to Twitter

4. The cookie and username of the victim are forwarded to a server controlled by Michael Mooney

5. An image request is made to StalkDaily.com, another site controlled by Michael Mooney

6. Victim’s authToken (authentication token) is identified

7. Automated postings are made on behalf of the victim and the victim’s profile is updated to inject a link to the StalkDaily’s worm’s malicious JavaScript (persistent XSS)

Michael Mooney’s Web-based worm is a preview of what is to come. While Mooney’s worm didn’t do any permanent damage, future attackers may not be as kind. Web-based worms could be used to retrieve sensitive data such as contact information, spoof communication with other users, or even perform financial transactions on behalf of the victim.

Attack scenarios are limited only by the capabilities of the platform they leverage. Sadly, finding vulnerable platforms to create such an attack is all too easy to do, given the prevalence of XSS vulnerabilities.

The fact that most Web-based worms to date have been created by individuals without a profit motive illustrates that the attack technique has not yet matured. Bored and bright individuals are tinkering with the concept, while the true criminals wait on the sidelines ready to move in when traditional techniques fail to achieve desired goals.

This same pattern is repeated over and over again within cybersecurity. Worms were once the realm of those seeking to prove what was possible or to prove their technical prowess. Worms such as Sasser, Blaster and Slammer were big and loud, proudly boasting of their ability to infect millions of machines in the blink of an eye.

Today, malware is much more stealthy, trying to fly under the radar, as bold behavior will only undermine the true goal of financial gain. Web-based worms are sure to follow the same path, so it is wise to use our time to prepare for the threat and not ignore it.

Best Defense

Traditional malware controls including desktop antivirus aren’t focused on emerging threats such as Web-based worms. This next-generation worm exists online, not on the desktop. It travels in HTTP requests, not binary files that can be scanned by signature engines prior to execution.

Tackling Web-based worms requires defending against XSS attacks. As with any protection scheme, a defense-in-depth approach is recommended. At the host level, browser-based defenses are beginning to emerge. Plug-ins such as the excellent NoScript extension for Firefox address XSS, along with a variety of other threats.

Additionally, Microsoft is the first browser vendor to step forward to embed XSS protection directly into the browser with Internet Explorer 8. This is an important step forward. Enterprises that have not yet chosen to upgrade machines running IE, should seriously consider doing so for this very important security feature.

At the network level, enterprises should consider secure Web gateway (SWG) products and services. When doing so, whether choosing a software, appliance or SaaS-based offering, be sure to determine whether XSS protections are included, as such functionality is not universal.

Looking to the Future

Attackers adapt far more quickly than those tasked with defending networks from attack. They follow the money, and that means going where their victims are.

While Web-based worms represent a new attack vector made possible by the existence of XSS vulnerabilities in Web applications, XSS itself is already being leveraged today by attackers, primarily in targeted attacks. Enterprises should seek protection mechanisms that go beyond the basics of desktop AV and URL-filtering, as attackers moved on some time ago.