How it was possible to run a XSS worm on RunKeeper

Do you know RunKeeper?

RunKeeper is a GPS fitness-tracking application supporting more than 23 million users, launched in 2008. RunKeeper is a Boston-based company, which raised $10 million in a Series B financing, led by Spark Capital. It also hosts a built-out Health Graph displaying health and fitness related data, specific to the user. This application also has an online social network of users that share progress, goals, training programs and mapped routes. What makes this application unique is having released an open API for outside developers to plug into RunKeeper users feeds. (in Wikipedia)

When I was using this nice web application I stumble across some vulnerabilities that could be used by malicious users to create a XSS worm.
This could be achieved by using two type of vulnerabilities.

CSRF on Accounts Settings
It was possible to launch a CSRF attack (http://pt.wikipedia.org/wiki/Cross-site_request_forgery) on Account Settings. Using a external HTML form, a crafted site with a auto-submit JavaScript, a malicious user could modify all the information on a authenticated RunKeeper user without them knowing. This happened because RunKeeper forms lacked a security token or any other validation which allowed a user to POST a request on external sources.

Persistent XSS on name field - Account Settings
This was very dangerous and a major security risk. In the wrong hands it could be used to launch dangerous attacks and infect millions of users.

The XSS was automatically executed on user Account Settings and on the profile page of the user affected - http://runkeeper.com/user/dsopas/profile. Even the public profile was affected with this issue (no need for authentication).

When saving the profile, the POST request to http://runkeeper.com/settings?saveProfile= submits the following:

username=dsopas&fullName=David+Sopas&gender=M&birthday=May+01+2000&location=&athleteType=CYCLIST&goal=Sports&achievementGoal=MAINTAIN&workoutFrequency=FIVE_PLUS&skillLevel=INTERMEDIATE

Imagine a specially crafted site with a auto-submit form taking advantage of the CSRF I mentioned with the "fullName" parameter:

CLICK HERE "><img src=x onerror=prompt(document.cookie)><div x="

This would save the authenticated user new "fullName". Each time a user visited his profile would launch the attack (in my proof-of-concept it shows the victims cookie).

Modifying this POC a little bit, a malicious user could have a worm propagating on RunKeeper - stealing users cookies, gathering private information, propagating malware, ...

How dangerous?
In 2005, a XSS worm called Samy carried a payload on MySpace that would display the string "but most of all, Samy is my hero" on a victim's profile. When a user viewed that profile, they would have the payload planted on their page. Within just 20 hours of its October 4, 2005 release, over one million users had run the payload, making Samy the fastest spreading virus of all time.
This was also possible to achieve with this RunKeeper security issues.

I would like to say that RunKeeper handled this security issues very serious and they seem to really care about security and their clients.
I'm glad I helped them.

Timeline
10 Oct 2013: Got first contact with RunKeeper and sent the advisory
11 Oct 2013: RunKeeper replied that they're working on both issues
21 Oct 2013: RunKeeper gave me a detailed information on patching plan
05 Nov 2013: RunKeeper confirmed that both issues are fixed
12 Nov 2013: Full disclosure

Prestashop persistent XSS and CSRF vulnerability

Continuing to test Prestashop security I just found out a vulnerability on the latest version (and maybe prior versions).
Logistician, translators and other low level profiles/accounts could inject a persistent XSS vector on TinyMCE to affect users and even admins.
This is possible due to a flaw on TinyMCE which doesn't filter some events (blocks only a couple of them) on HTML.

Proof-of-concept on a combined CSRF attack (logged in as logistician):

On a CMS page, enter the following HTML in TinyMCE (on HTML mode) <img onmouseover="window.location.href = 'http://www.website-example.pt/loja/admin9050/index.php?logout'" src="x" alt="" />

When the admin hover the image, he will automatically logout from the admin panel.
With a little imagination this issue can be used to spread malware or grab users credentials (popping up a screen to login) to visitors, authenticated users or even admins. (CVE-2013-4791)

Also logout GET request should also have a token protection. Just to prevent CSRF attacks. (CVE-2013-4792)

Keep in mind that the latest version of TinyMCE it's patched against this issue.
By the way I tested under PrestaShop 1.5.4.1.

Prestashop developing team replied:

We have fixed this problem in our 1.4.11 release, and we will also put this patch in our next 1.5 release before the end of July.

Timeline:
05 Jun 2013: Reported to Prestashop
11 Jun 2013: Replied that their team were working on it
02 Jul 2013: Prestashop released a fix to this issue
08 Jul 2013: Full disclosure

PrestaShop <= 1.5.1 Persistent XSS

When installing and analyzing PrestaShop on a secure environment I discovered that it's possible to bypass isCleanHtml() function, used in many places, in this case in particular the Contact Form. 

A user could use this vulnerability, a Persistent Cross-site Scripting, to execute malicious payloads on admins message box.

Proof of concept:
In the message field a user could write:

<objectdata='data:text/html;base64,PHNjcmlwdD5hbGVydCgid2Vic2VndXJhLm5ldC14c3MiKTwvc2NyaXB0Pg=='></object>
or


<embed src='data:image/svg+xml;base64,PHN2ZyB4bWxuczpzdmc9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIiB2ZXJzaW9uPSIxLjAiIHg9IjAiIHk9IjAiIHdpZHRoPSIxOTQiIGhlaWdodD0iMjAwIiBpZD0ieHNzIj48c2NyaXB0IHR5cGU9InRleHQvZWNtYXNjcmlwdCI+YWxlcnQoIndlYnNlZ3VyYS5uZXQgeHNzIik7PC9zY3JpcHQ+PC9zdmc+' type='image/svg+xml' AllowScriptAccess='always'></embed>
Both Base64 strings are mainly alert() encoded.

Those XSS vectors bypass the filter on isCleanHtml() and execute automatically when the admin check the messages on the admin area. This is critical and could be used to implement very bad scenarios.

Keep in mind that on some webmail variations, the code is also executed. A user can even play with heading h1 and other HTML on message box.


<a href="#" target="_blank"><img src="http://www.prestashop.com/images/logo.png" width="800px" height="600px" border="0" /></a>
or


<a href="#" target="_blank" style="font-size: 30px">Click here</a>
Again, encoding with Base64 could also obfuscate a little bit.

I think that in this case in particular, HTML should be stripped out because it has no meaning in my opinion on the contact form.

Solution: Vendor reported that upgrading PrestaShop to version 1.5.2 will fix admins message box bug. 
HTML on email accounts still a possibility in the latest version. According to the vendor, it will be fixed on the next version.

Hootsuite labels XSS

You guys use Hootsuite? It's a social media dashboard web app that is used by millions of users.

Well I found that label section on Hootsuite analytics is vulnerable to a persistent XSS (self XSS).
A user could inject any HTML or JavaScript code that will run on the active window.

Proof of concept:

<script>alert(/xss/)</script>

It's important to sanitize every user input to prevent this kind of issue.

Hootsuite security team fixed this very fast showing that some companies still care about web security.