RunKeeper Stored XSS Vulnerability – Where worms are able to run too!

 

RunKeeper is a GPS fitness-tracking app for iOS and Android with over 40 million users. First launched in 2008 by CEO Jason Jacobs with the help of “moonlighting engineers”. In late 2011 RunKeeper secured $10 million in a Series B financing, led by Spark Capital. In February, 2016, RunKeeper was acquired by ASICS.

In May 2016, the RunKeeper software came to the attention of the Norwegian Consumer Council for breaching European data protection laws. It is alleged to continue tracking user’s locations after the application is terminated and to share this information with advertisers in ways that exceed the bounds of the application’s terms and conditions.
.
About the discovered vulnerabilities:

1. Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page. For more details on the different types of XSS flaws

.

2. Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.
.

The bug(s):

In the proof of concept scenario we found 2 issues, First a stored cross site scripting affecting “RunKeeper user profile name” where the payload is stored in the database and will be reflected whenever the public user profile page called by any user, Sometimes a stored cross site scripting issue is more sever than a SQLi which results in accessing a fully encrypted user data,  Second a site-wide cross site request forgery where users can follow other users via a GET request (since the website is suffering from CSRF issues allover its parts)!
..

CSRF PoC Code:

https://runkeeper.com/relationship?request=&target=36973602

.
PoC Video and attack scenario:

.

Notes on the attack scenario:

As you may noticed in the PoC Video our XSS payload was used to perform a follow request to the owner of the vulnerable profile which turn it into a site-wide XSS Worm behaviour, In the worst scenario we can use this Stored XSS to inject our payload on any potential profile visits ours.

Also we shortened the XSS payload using google shortening service since there is a payload length limitation and the payload reflection in the page source context won’t be executed if it exceeds the limit!

We are aware that a stored XSS can simulate mouse clicks, Reading the anti-csrf token and perform form submits, etc… but we tried here to merge two attacks to demonstrate how attackers are able to perform a more severe impact.
.

Differentiation:

We spotted the vulnerability without the knowledge of it’s existence before, the issue was originally reported by security researcher David Sopas and was fixed on Nov 12, 2013

On Oct 10, 2015 Seekurity team tried to give it another shot while doing some investigations to be sure if we can relay on the service for a personal use we were able to bypass the fix made by RunKeeper Security team.
.

The Fix:

RunKeeper Security Team mitigated the issue root cause totally by doing a proper user input validation and an Anti-CSRF tokened requests!

.

.
Hey!
Building a website? Or already built a one? Think twice before going public and let us protect your business!

(Visited 659 times, 1 visits today)

Also read...