xssless Update – Self Propagation & Why JavaScript Worms Can Be Very Scary

Well, it’s been awhile since I’ve crashed Firefox due to insane JavaScript usage so I thought I’d write another blog post.

I recently released a new feature for xssless which allows you to make the payload POST itself. Meaning that you can very easily make payloads that will spread themselves via JavaScript to unsuspecting viewers of your unsanitized input.

Example Usage of Self Propagation Feature


So I’ve created for us a little playground to practice our XSS magic. We’ll view it in Firefox with Burp proxy as our middleman (xssless takes Burp traffic exports as input).

Selection_023

Notice how I’ve added a little test to see if the input is unsanitized (gee I wonder?!)

Selection_024

…and would you look at that…

Selection_025

…the page appears to be vulnerable to persistent XSS!

Great, so let’s generate a self-propagating payload using xssless.

We select this request in Burp:
Selection_026

Export it for xssless:
Selection_027

Now we run it through xssless:

Notice that we’ve used the -m option which specifies what POST fields to replace with our payload. In the file we specified the “content” field and the payload was adjusted accordingly.

Now, this line right here:

This is where the magic happens. The “content” field is set to equal:

Which is URL encoded:

JavaScript has the neat ability which allows you to take entire functions and turn them into strings. Which is being done by the “m.toString()” part of the code. Then the “encodeURIComponent()” function is used to make the function content safe for transport by URL encoding it.

But enough explaining, let’s see this in action!

Selection_028

Selection_031

Cool, but did it work?

Selection_030

It did! Notice have we have the initial POST and the response but then we get another POST right afterwards (followed by a response for that POST).

Perfect but I don’t think I’ve really conveyed how out of hand things can get. Let’s refresh the page shall we?

Selection_032

Interesting, so now without doing any form submitting we have two POST requests that run in the background. Which, of course, makes sense. We have our initial payload doing a POST and the payload it posted doing a POST as well.

For those folks keep track at home, that means we will double the amount of payloads on the page every pageview.

After another refresh:

Selection_033

That’s four POST requests being preformed (asynchronously by the way, so they are all being done at once).

A few more refreshes:

Selection_034

Oh boy…things are starting to get out of hand…

Selection_035

After only a few refreshes of the page our database has grown quite a bit!

Selection_036

Bonus points for anyone who figures out how many page refreshes I did to get that many posts in the database ;)

So, in conclusion, we see that JavaScript worms can be very dangerous indeed. Many people write off XSS as a low-risk issue but when situations like this occur it would take a very little amount of time to take even the largest site and grind it to a halt. Not to mention the denial of service attack is being preformed by the users themselves (while they remain non-the-wiser)! This payload only posted itself, imagine if it also preformed another action – like sending a penny to a bank account, or sending a message to your friends on the site!

Folks, be sure to sanitize that input, do your part in defending against super-neato attacks like this one.

Until next time,
-mandatory

4 comments

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">