Thursday, November 21, 2013

3 Open Redirect on Google - UNFIXED

In the last couple of weeks I discovered three Open Redirect security issues on Google.
For those who don't know what is a Open Redirect vulnerability, OWASP has a section about it (https://www.owasp.org/index.php/Open_redirect):
An open redirect is an application that takes a parameter and redirects a user to the parameter value without any validation. This vulnerability is used in phishing attacks to get users to visit malicious sites without realizing it.
Open Redirects are very attractive for spammers. Why? With the increasing importance of URL and domain reputation in SPAM filtering, spammers may not care so much about tricking the user into believing their link is secure, but they may care about filters not seeing their malicious websites.

# Google Helpouts

Proof-of-concept:
https://helpouts.google.com/opener?url=http://labs.davidsopas.com
Proof-of-concept with the URL encoded with hex with the same destination - http://labs.davidsopas.com:
https://helpouts.google.com/opener?url=%68%74%74%70%3A%2F%2F%6C%61%62%73%2E%64%61%76%69%64%73%6F%70%61%73%2E%63%6F%6D




# Google Doubleclick 1

Vulnerable code present on http://stats.g.doubleclick.net/u/post_iframe_dc.html:
(function() {
var b = decodeURIComponent;
var c = window,
d = function() {
var a = b(c.location.hash.substring(1));
/^https?\:\/\//.test(a) && c.location.replace(a)
},
e, f = c.XMLHttpRequest;
if ("undefined" != typeof f) e = new f;
else for (var g = ["MSXML2.XMLHTTP.6.0", "MSXML2.XMLHTTP.3.0", "MSXML2.XMLHTTP", "Microsoft.XMLHTTP"], h = 0; h < g.length; h++) try {
e = new c.ActiveXObject(g[h])
} catch (k) {}
(function(a) {
a ? (a.open("POST", ("https:" == c.location.protocol ? "https://stats.g.doubleclick.net" : "http://stats.g.doubleclick.net") + "/p/__utm.gif", !0), a.setRequestHeader("Content-Type", "application/x-www-form-urlencoded"), a.onreadystatechange = function() {
4 == a.readyState && d()
}, a.send(b(c.name))) : d()
})(e);
})();

Proof-of-concept:
http://stats.g.doubleclick.net/u/post_iframe_dc.html#http://labs.davidsopas.com
Proof-of-concept with the URL encoded with hex with the same destination - http://labs.davidsopas.com:
http://stats.g.doubleclick.net/u/post_iframe_dc.html#%68%74%74%70%3A%2F%2F%6C%61%62%73%2E%64%61%76%69%64%73%6F%70%61%73%2E%63%6F%6D
# Google Doubleclick 2

This second open redirection works by adding the destination URL on adurl parameter.
You need a valid sig parameter but this value can be found by searching Google.

Proof-of-concept:
http://pubads.g.doubleclick.net/aclk?sa=L&ai=CVX_P9w1EUqOqEs-pigbasoH4BqTY8LkCAAAQASCUh8cWUO_F-bIDYO3c3IWYG8gBBOACAKgDAaoEWU_QCnBEa2tgTStWRYttDqi7d0s6uWsJDHSreAFvGE0ZiTo_mgVBIhLYaWniW4fUMgOpcXTUs_kxkhB8zkV9-z3LD9QNe14TSe7ZgNjja8PfgUFROjGNbD3N4AQBoAYV&num=0&sig=AOD64_1FE7vwsql9N-pKDvb9skYoC3ikrQ&client=&adurl=http://labs.davidsopas.com
If don't add a valid sig, it will warn the user before redirecting:
http://pubads.g.doubleclick.net/aclk?sa=L&ai=CVX_P9w1EUqOqEs-pigbasoH4BqTY8LkCAAAQASCUh8cWUO_F-bIDYO3c3IWYG8gBBOACAKgDAaoEWU_QCnBEa2tgTStWRYttDqi7d0s6uWsJDHSreAFvGE0ZiTo_mgVBIhLYaWniW4fUMgOpcXTUs_kxkhB8zkV9-z3LD9QNe14TSe7ZgNjja8PfgUFROjGNbD3N4AQBoAYV&num=0&sig=&client=&adurl=http://labs.davidsopas.com
What risks poses these security issues to a user?
- Phishing: The user may be confronted to phishing attempts by being redirected to an untrusted page
- Spreading malware: The user may be redirected to an untrusted page that contains malware which may then compromise user information
- CSRF: Using a URL specially crafted to explore a Cross-site request forgery (https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)) on Google

Google doesn't reward or fix this issues. They believe the usability and security benefits of a well-implemented and carefully monitored URL redirector tend to outweigh the perceived risks.
Personally I don't understand why Google don't follow the same steps than other companies, like Facebook and Yahoo, which give the right credit to Open Redirect issues.

Tuesday, November 12, 2013

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

Wednesday, November 6, 2013

Google Bots doing SQL Injection - The Proof-of-Concept

When reading this article about Google Bots doing SQL Injection from Sucuri, I remember that I already saw this somewhere on my Google researches... I was right.
If you use a special tool included on Google Analytics, located on Behavior - Experiments, a malicious user could launch SQL Injections, or other web attack, on remote websites using Google as a proxy.
   
Enter your website in the form (example: http://www.yourwebsite.com/index.php?id=1' OR 1=1--)


Check out your access log:
66.249.93.25 - - [06/Nov/2013:13:23:47 +0000] "GET /index.php?id=1'%20OR%201=1-- HTTP/1.1" 404 - "http://www.google.com/search" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.4 (KHTML, like Gecko; Google Web Preview) Chrome/22.0.1229 Safari/537.4"
If you resolve the IP address you will see google-proxy-66-249-93-25.google.com.

I believe this is not directly a Google security issue. Just keep your website secure and no trouble will come in your direction.