4 X Security Team

Date: 01/10/2008

Abstract: This paper is the product of a week long contest to write the most diminutive self replicating XSS worm.
This was a controversial contest, where there were no prizes awarded,
and the goal was to build the worm that would fit in the fewest bytes
possible. In the end there were two people, Giorgio Maone and
Sirdarckcat who tied the contest at a stunningly small 161 byte cross browser compatable XSS worm. However, the journey was as interesting as the result.

To date there has been little to no research done in the methods of

propagation and optimization. The lack of research is in part due to
the relative infrequency of these worms in the wild, as well as
scarcity of real-world worms.
Each example found had three problems with them. 1) They contained site
specific code 2) they contained obfuscation for filter evasion and 3)
they contained a payload. Also, cross browser compatibility was not
always present, making it harder to diagnose exactly what propagation
code looked like. Rather than attempt to triage code that was not
designed with these issues in mind, a contest was built to gather
sample code that could be used for more in depth analysis.

Browser companies have not yet, to date, constructed a way to

display user submitted content in a way that protects the website and
users from malicious behavior, but still allows feature rich user
submitted content. People sometimes say that certain social networking
sites don't write secure code. That's not always the entire truth.
Often the code is highly secure and could be made more secure with the
flip of a switch, it's only that the business landscape requires the
code to do insecure things for economic and user satisfaction reasons.
Those things combined require that we search for alternatives to the
problem, and give ourselves opportunities to build more secure websites
based on our findings, having seen the output of the diminutive proof
of concept worm code.

Assumptions: The theoretical social networking site we will

be discussing in question is vulnerable, not because they are unaware
that they are vulnerable, but because consumers demand rich content. It
is assumed that companies want to do the right thing, in terms of
security, but often cannot as a result of the business rules by which
they must obey. It is also assumed that the attacker has prior
knowledge of the domain. The code that they built must fit within a
certain length field (like a name field, or a title) and will be
rejected if it exceeds that length (there are reasons this limitation
was put in place that will be discussed later in the paper).

Worm Problems: There are some major issues when building a

self propagating worm which were intentionally avoided using contest
rules. One of the most important and difficult rules to abide by was
the issue of growth. One of the rules stated that the worm could not
grow in length once it was submitted. There are three reasons this rule
was critical to adhere to.

The first reason is probably the simplest and also least likely to
be a real issue. HTML input lengths, code based data size limitations

and most importantly database field lengths all may introduce hard size
limitations of only the size of the worm. The second semi unlikely
reason that this would be a factor is the worm author may want to limit
the negative impact of the worm until it had reached maximum
propagation by reducing the utilized database space increase, and
bandwidth required for propagation. The latter also has the benefit of
increasing the rate of propagation.

The last and single most important reason to limit growth was this example by Ronald:

While Ronald's example could have actually won the contest, sans the
growth rule, it had the flaw of linear growth. Let's use an illustrated
example using smaller byte count for demonstration purposes only.
First, let's assume there is a hard limit of a database field of 50
characters, however, instead of rejecting the content it simply chopped
off anything greater than 50. A sample page may look like so:

Site content here - 17 chars

attacker's vector here - 23 chars

More site content here - 23 chars

So after the first iteration of worm propagation, the site would
chop off anything greater than 50 chars, which has the effect of
chopping off the last part of the page. That's not an immediate
problem, because the vector is still there. Let's look at the second
page on which the worm was now posted to:

Site content here - 17 chars

Site content here - 17 chars (original variant's header)

attacker's vector here - 23 chars

More site - 10 chars (chopped off from the first iteration of the page)

More site content here - 23 chars

In the next iteration the last 7 bytes of the worm code would be
chopped off as the site content continues to grow, which will break the
attacker's worm. It would now look like this:

Site content here - 17 chars

Site content here - 17 chars (second variant's header)

Site content here - 17 chars (original variant's header)

attacker's vect - 16 chars (broken vector)

More site content here - 23 chars

Even if the vector worked without the missing seven bytes, on the
next iteration of worm propagation it wouldn't because it would cut off
the next 17 bytes, leaving only headers of pages from previous
propagation. So in this way, a hard limit of n bytes with linear growth
before the worm begins will eventually cause the worm to discontinue
propagation, unless there is no other content on the page prior to the
worm.

Note: The word growth is not really correct, as in reality it

will continue to stay a static size (the maximum that the script
allows) so although the information before the worm is linear growth
until code breakage, the actual content submitted does not grow beyond
the limits of the website.

Ultimately, though, the reason to limit length though was to reduce

the three things mentioned earlier - obfuscation, site specific code
and payloads. This leads us to the next issue. As mentioned before
there is a theory that to make a worm small it will inherently become
obfuscated due to the coding tricks necessary to reduce the size. While
this is mostly a red herring, because this is not the same form of
obfuscation referred to (rather filter evasion obfuscation) there were
examples of this that caused one of the other issues that we had
attempted to avoid (the site specific coding issue).

One of the rules of the contest was that the submissions must POST

to "post.php". The goal here was to give them a requirement of posting
to another page than the page they were on. Early on, oxotnick asked a good question;
which is should we assume that the page you are submitting to is in the
same directory or relative to the base directory. For the purposes of
the contest, people were asked to assume they were in the same
directory, however, this and the contest naming conventions used within
the rules caused an interesting site specific coding optimization:

While the code is entirely valid for the rules, in reality, it's not
portable. If the name had been anything but a string beginning with the
word "post", like the word "test" this code would not have functioned.
So while this code is interesting from an optimization perspective, it
needs to be ignored for analysis.

Worm Best Practices: At one point Ronald pointed out

that images may be a better universal vector for XSS worms, than things
like iframes, or scripts. This may be a true statement, given that many
sites do allow images by default. Without any real numbers to back this
up, it's speculative, but possible. At the very least, the visual
fingerprint is less without sizing. Ultimately, in another thread DoctorDan proposed an interesting question regarding wheter XMLHttpRequest is a better propagation method than the other prevalent method, which was submission of a form.

The benefits of XMLHttpRequest are many. Firstly, it's much more

silent, because it doesn't actually force the user's browser to
visually change to another page. It's not just visually silent though,
as the auto-submit method also can make a clicking sound if the user's
browser is set up to do this (which is often default). Also bwb labs had a great point
regarding a looping effect of the submission method. Let's take a
specific example of a site that upon submission automatically shows you
the content you just submitted.

In doing so it would show the victim the payload and would

automatically post the content back once again - putting the user's
browser into an infinite loop. While this type of setup isn't
universal, it was worthy of note, and could easily lead people to be
more interested in using the XMLHttpRequest method for propagation. For
the purposes of the contest, submission based worms were not forbidden,
as there are many sites that don't have this setup, and even if it may
spiral a user's browser out of control with submissions, that may be
the attacker's intent, or it may be inconsequential to the attacker.

Worm Defense: Two interesting problems stopped a number of

variants, which resulted in a new rule during the contest. While they
are not considered good worm defense, they did stop a number of worm
variants, requiring further work. The first is the declaration of onfocus and onload event handlers in the body tag. Also early on ritz found a problem with his code on pages that had a DOCTYPE assigned.
So it would appear, using these would stop a certain amount of worm
variants. Clearly both of these issues were eventually worked around,
after the new rule requiring the worm code to work despite them. Either
way these issues were worthy of mention.

Let's take a step back for a moment. The above comment, "Browser

companies have not yet constructed a way to display content in a way
that protects from malicious behavior, but still allows feature rich
user submitted content" is an over statement. In this case, the browser
companies have provided a single useful tool. In fact it is a fairly
powerful tool - the iframe. This is not in reference to the on-page
iframing that was proposed with content restrictions. This is in reference to the normal off domain iframe.

One of the reasons people don't use iframe is because they are

concerned about the search engine value of the page they are
constructing. If a company dices up their page into iframes, they will
lose search engine value. The major search engines of the world haven't
figured out a way to keep SEO (search engine optimization) value the
same when you split your page into two different pieces (the protected
content on your domain, and the potentially dangerous user submitted
content on another domain). The one exception to that rule is using
cloaking - where you display both the site content and the user content
on the same page, only when the search engine spiders your site.

Note: Google has been hypocritical about the corporate opinion on

cloaking, telling small companies it is not okay, and telling
enterprises it is. So Google has created an unfair market place and as
such use of cloaking is potentially dangerous to your business, given
Google's pre-disposition to blacklisting based on that. Cloaking is
deemed blackhat SEO based on rules that are still, as of yet not
communicated publically; at least not in their entirety. The use of
cloaking, even to protect consumers may get a website banned, so its
use is not recommended unless there is an agreement made with Google
prior to implementing this technique.

To get real value out of this worm analysis we shouldn't ignore our

history lesson. The first and biggest XSS worm in history, was the MySpace Samy worm. One of the site specific things that Samy wrote in his worm was the following:

The reason this is important is because Samy was trying to overcome
a basic principle in browser security - the same origin policy. Samy
knew that the bulk of his code, which used XMLHttpRequest wouldn't work
unless he switched domains to the one that allowed his worm to
function. This leads us to the next part of defenses. One thing that
has been mentioned a lot in defeating cross site request forgeries
(CSRF) is the use of a nonce, or a one time token. Nonces can be read
if they are on the same domain, by XMLHttpRequest. So it would stand to
reason that it is better to omit a nonce on another domain that sites
know are completely free of XSS vulnerabilities. That is because
XMLHttpRequest must obey the same origin policy.

Note: Please note that Mozilla has discussed a cross domain version of XMLHttpRequest.

It is unclear if this would open this up further to attack or not, but
clearly any technology that allows for cross domain reading whether
intentionally or not would break not only this technique but many other
security protections built into websites.

So it would make sense to omit the nonce in a button on another

domain since that domain is not readable by the JavaScript worm. This
lends itself to a different sort of attack, like the one against Google Desktop
where an attacker floats a small or even invisible iframe beneath the
user's mouse. So the button can still be pressed. Although this does
require some user interaction mouse clicks are so commonplace, it
wouldn't be any surprise if this were used in a real worm.

However, if there is an anti-framing script that detects if the post

page is being framed and then un-frames itself before the user has an
opportunity to be subverted, that could easily protect the page from
being clicked on. There is, however, a snag. In Internet Explorer
iframes can be tagged with security=restricted. This turns off
JavaScript on the iframe. That would stop the script that did frame
detection from running.

Note: Please note that Firefox does not have an equivalent to

security=restricted in off domain iframes, so this technique will work
as described for Firefox users.

Although it appears all hope may be lost, there is an additional

possibility. If the button is not a static button, but rather a button
that itself is at least partially rendered using JavaScript, an
attacker's use of security=restricted will not only cause the page
frame detection script to fail to load, it will also cause the button
to not include the nonce. This is problematic for users who don't have
JavaScript installed though, so an alternative must be provided. For
those users, the button instead may point to a login page, where the
user is requested to log in to post their user content. This JavaScript
alternative is only a minor inconvenience and effects approximately
0.1% of user population (based on the number of users who surf without
JavaScript enabled).

Note: It is important to address the non JavaScript version of

this technique due to concerns over lawsuits initiated by the National
Federation for the Blind on behalf of the Americans with Disabilities
Act.

This technique, combined with some sort of state management between

the two domains should help thwart XSS worms. It must by restated that
this paper is authored with the assumption that dynamic user content
must be allowed for the site's business operations to continue, but
that all other site code is designed to be as secure as possible.

Note: Please note that this technique does not protect against

any browser bugs that allow a browser to break the same origin policy
(Eg: the now-defunct mhtml bug or DNS rebinding).

Items Not Covered: There are several items missing from this

paper. They include things like filter evasion, payload and command and
control. Both filter evasion and payload have been covered by countless
posts over the last several years in various forms and forums. Command
and control is still widely debated, and no concrete observations can
be discussed at this point beyond some of the requirements for a solid
command and control structure for polymorphic XSS worms and for worms
that have delayed payloads, based on a certain density of infection.

Additionally, while there has been some talk about tracking worm activity and at least one project attempting to help mitigation with the assumption that any potentially dangerous content is disallowed,

this paper did not discuss either of these issues as they are far more
in depth and will almost certainly require more thought and research by
a larger audience.

Summary: While XSS worms are hardly a solved issue, some of

the findings of the diminutive XSS worm replication contest definitely
help construct the solutions outlined in this paper. This is anything
but a definitive list of all ways to thwart XSS worms, but it should be
a good primer on some of the findings that came from the XSS worm
contest, and should help. Without browser modifications, this appears
to be the best software agnostic solution to worm propagation, however,
no doubt revisions on this technique and others will yield better
results.

Thanks: Special thanks to everyone who helped contribute to

our understanding of worm propagation over the last week (in
chronological order): .mario, thornmaker, digi7al64, Gareth Heyes, Matt
Presson, sirdarckcat, ritz, Alex, barbarianbob, BlahBlah, arantius, bwb
labs, ma1, Spyware, Reiners, Spikeman, Ronald, Torstein, dev80, amado,
shawn, hallvors, DoctorDan, oxotnick, dbloom, Kyran, tx, 4909, beNi,
backStorm, badsamaritan and anyone else I may have missed. Without
these people and their talent, this research would never have been
possible. Also thanks to thrill and id for providing edits and feedback
on this paper.

[Source: ha.ckers]