Handling Errors in Modules Caused by Zen Cart 1.5.3’s Change to the mysqli Extension

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);
mysql_select_db(DB_DATABASE);

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.

Posted in Zen Cart | Leave a comment

Only 12 Percent of Drupal 7 Websites Upgraded to 7.32 In First Week

One of the basic measures needed to keep websites secure is to keep the software on them up to date, as that prevents them from being hacked due to a known vulnerability in the software. That unfortunately isn’t something that people are very good at doing. With Drupal you can get fairly good data on how well people are at keeping up to date due to the developers publicly releasing data on what version are in use. When we looked at the data in late March we found that only 33 percent of Drupal 7 websites were up to date and only 72 percent of Drupal 7 websites were up to date or less than year out of date.

With a highly critical vulnerability fixed in Drupal 7.32, which hackers started exploiting shortly after the fix being released, we are curious see how fast websites are being updated. The first week of data, for the week of October 19, has now been released and it shows that only 12 percent of websites have been upgraded to 7.32. We should note that it is possible to patch the vulnerability without doing a full upgrade, so not all websites that have not been upgraded are necessarily vulnerable at this point.

That number is better than with a previous, less severe, security update. We previously look at the rate that Drupal 7 was updated to 7.27, which fixed a moderately critical vulnerability. In that case after a week only about 5 percent had been upgraded and it was only up to about 15 percent at two weeks.

What is more troubling is how few websites have been upgraded to the previous release, Drupal 7.31, which fixed a moderately critical vulnerability. That version was released on August 6, so there has been plenty of time for an upgrade. As shown in the chart below, at this point 62 percent of Drupal 7 websites are still running a version below that:

Drupal 7.32: 12.46%, Drupal 7.31: 25.74%, Drupal 7.30 or older: 61.80%

For those in need of an upgrade we provide one time Drupal upgrades and ongoing upgrades for Drupal 7 (with security updates in a day). You can use our Drupal Version Check chrome extension and Up to Date? Chrome app to keep track of the update status of Drupal websites you manage.

Posted in Drupal, Outdated Web Software | Leave a comment

6Scan Is Bad At Detecting Malicious Code

From dealing with lots of hacked websites one of things that we know is that detecting malicious code through automated processes isn’t very effective. The variety of code makes it difficult, but what makes it much more difficult is that often the code appears to be designed to be able to avoid detection from these automated processes (which in turn usually makes it easy for a human to spot). Unfortunately other companies dealing hacked website haven’t figured this out or are not interested in making sure the websites they deal with get fully cleaned and secured, leading to many instances where we are hired to re-clean up hacked websites after they have failed to get the job done. One of the latest examples we saw was of a web host using 6Scan on a hacked website. 6Scan describes their services as “Powerful Automated Website Protection” and they describe their ability find malicious code with the following, “You might not be aware if your site has already been compromised, but our scanner will recognize the traces hackers leave behind. You’ll see immediate results—as comprehensive as they are easy to understand—displayed on our dashboard.”. Though, from what we saw it is at least a rather poor malicious code scanning tool.

At the point we were brought what had happened is that the web host for the website would detect the website was sending spam emails, suspend it, run 6Scan on it and remove the files they detected as malicious, and then after some amount of time spam email would get sent out again and the process would start over. What a quick check of the website’s files showed was that 6Scan was not detecting much of the malicious code and that meant the hacker still had access after the code they were detecting was removed. Considering that the web host in question is touted on 6Scan’s homepage as one of their “Trusted Partners” we don’t think that they were doing something wrong in use of the tool that lead to the poor detection.

The 6Scan scan that was run right before we did our clean up detected 54 files with malicious code and missed the malicious code in 40 other files, so their detection rate was not very good at only 57 percent. What was more surprising is how easy to spot most of the files they missed were. Many of the files were stored in the wp-admin and wp-includes directories of a WordPress website. Since those two directories generally should only contain files that come with WordPress any additional files would be a red flag. In other cases malicious code was added to core WordPress files that shouldn’t be modified, which also would be a red flag. In both cases someone reviewing the results of a file comparison with a clean install of WordPress would have easily noticed the malicious code, while 6Scan’s automated processes did not.

There are a few of important takeaways from this. First, if someone says they are going to clean up a hacked website with automated tools, you are going to want to find someone else to do it. You might get lucky with a hack that is rather simple and the malicious code gets fully detected, but if you don’t then it is going to mean multiple cleanups and in some cases more problems. It also important to hire someone that will determine how the website was hacked in the first place, as doing that and fixing the vulnerability is the way to protect against the hack happening again (that was certainly important for us to fully clean up the website in this instance). The final one is that you should avoid 6Scan as they either don’t understand that the service they provide can’t do what they claim or they know that it can’t don’t care. Instead you should spend your time and money on making sure you do things that will actually protect your website from being hacked in the first place, so someone like us doesn’t have to clean up after it gets hacked.

Posted in Bad Security, WordPress | Leave a comment

Hackers Still Trying To Exploit Joomla 1.5 Vulnerability Fixed Six Years Ago

We were recently checking something in our analytics and noticed that a rather odd URL had been accessed. The URL, http://www.whitefirdesign.com/blog/?option=com_user&view=reset&layout=confirm, was for a section of our website running WordPress but the URL parameter, ?option=com_user&view=reset&layout=confirm, was for something Joomla related based on the “com_user” portion. A quick search identified that this was an attempt to exploit a vulnerability in older versions of Joomla. What is interesting about this is that the vulnerability was fixed in Joomla 1.5.6, which was released in August of 2008. Since most hacking attempt will not show up in analytics – due to them not requesting the tracking code – we were curious to see if there had been other attempts to exploit this that would show up in our access logs. We found that in the last six months there were attempts to exploit the vulnerability on 48 days. So hackers still feel there are enough Joomla website that haven’t been updated in six years to try to exploit it regularly.

There are a couple of quick takeaways from this. One is that is that if you still have websites running Joomla 1.5, for which support ended in September of 2012, you should make sure they have been upgraded to the last version, 1.5.26, and had the additional security fix applied so that they are protected against attempts to exploit any vulnerabilities in older versions. The other is that you don’t need concerned just because there has been an attempt to exploit a vulnerability on your website, considering that in this case a hacker tried to a vulnerability in very old versions of Joomla on a website running WordPress.

Posted in Joomla, Website Security | Leave a comment

Your Website Probably Wasn’t Hacked by a Competitor or Former Employee

When first discussing with a potential client about dealing with a hacking issue on their website what often comes up are questions about who hacked them and why. On a fairly regular basis they suspect it was a competitor or someone previously involved with the website. In reality the person hacking the website is almost always going to be someone who has no knowledge of the specific website, much less has any connection to it. These hackers are not targeting specific websites, instead they are just trying to gain access to as many websites as possible to use for their own purposes. To get a better idea of what is going on lets take a look at a hacking on a fairly high profile company’s website.

A recent hack we looked at involved a website having a set links added to the website’s page when Google crawled them (this is referred to as cloaking). Several of the links stood out, as they were to pages on justborn.com. You might not recognize the company the website belongs to, Just Born, but you probably are familiar with their products, which include Peeps, Mike and Ike, and Hot Tamales. When visiting one of the linked pages, http://www.justborn.com/services.cfm, the website looks normal at the top but then as you look farther down the page it has repeating text about soccer jerseys:

just-born-spam-hack-1

In fact all of the main content of the page is like that (click to enlarge):

just-born-spam-hack-2By comparison the page it looks like the hacker based the spam page on, http://www.justborn.com/mike-and-ike/the-story, has normal content:

just-born-spam-hack-3

Creating a page on their website with a bunch of text about soccer jerseys wouldn’t make much sense for a competitor or a former employee to do, so what is the purpose of this? Well if you come to the page through a search engine you are redirected to http://www.jerseysokbuy.com/, which as the address suggests is selling jerseys. If you do a search on their address on Google the second result is a page on ScamGuard that describes the website as a “Fake merchandise web-store operating from China. Consumers are advised to avoid making purchases from this site.“. Due to how Google ranks pages this type of hacking can lead to getting pages on websites otherwise unrelated to the product to rank highly. For example, earlier this year we found that a hacking campaign was able to get a website to rank in the top ten for UGG boots, the problem as shown in one of the screenshots in that post is that Google will usually catch up with this eventually and label the website as being hacked. That is part of why the hackers try to get access to as many websites as possible so they can switch to new websites when the old websites get labeled or the webmaster catches on and cleans up the hack.

Interestingly, while someone involved with the webiste is hacking other websites to direct to traffic to jerseysokbuy.com, they don’t appear to be interested in getting traffic directly to their website as the listing for their own website in Google says “A description for this result is not available because of this site’s robots.txt – learn more.”.

 

 

Posted in Website Hacked | Leave a comment

SiteLock Doesn’t Do Basic Part of Proper Hack Cleanup

A few weeks ago we wrote about the web security company SiteLock failing to do a basic security check, checking to make sure software running on a website was up to date when labeling before labeling the website as secure. Based on that we weren’t surprised at our next interaction with their work.

A couple of days ago we were contacted by someone who looking for help after their website had been hacked and SiteLock had been hired to clean it up. After SiteLock had said that they had removed all the malware the owner of the website had requested their web host to bring the website back online. The web host told them that they couldn’t do that since they detected files for outdated software, Joomla 1.5.25, on the website (despite the website using Joomla 2.5). At that point we were contacted about finding and removing those files and in reply we told them they should go back to SiteLock since that should be something SiteLock should do for them. In response they let us know that SiteLock told them they “don’t have the capability to remove or update outdated CMS content”. That is rather troubling since getting the software running on a hacked website up to date is a basic part of a hack cleanup, as it is a basic part of making a website secure. In this type of situation, where a proper hack cleanup hasn’t been done we would only get involved if we are going to do a full cleanup, since we don’t want to be involved in leaving a website insecure, so we suggested that since they were only interested in having the Joomla 1.5.25 files removed they could probably find someone else to do it for less than having a full cleanup done.

The idea that a company is cleaning up hacked websites without doing such basic part of the work is pretty troubling, so we wanted to double check that it wasn’t just that they were refusing to remove some out of date files and instead that they don’t actually update the software running on the website when doing a cleanup. Since the website is running Joomla it is easy to check if the website is up to date with our Joomla Version Check extension for Chrome. After the website came back online we checked and found that website was running an outdated version:

Joomla version 2.5.22

That confirms that SiteLock isn’t doing some of the basic work of the hack cleanup, which is pretty good reason to not to use them for that or any other service they provide since they don’t appear to actually be interested in properly securing websites.

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

jQuery.com is Running Outdated and Insecure Version of WordPress

Today it was reported that website of the JavaScript library jQuery was recently hacked. When a high profile website like this is hacked what is important to find out is how it was hacked, since a high profile websites are sometimes hit with new exploits that will later be exploited more widely and making sure that others are warned early can help to limit further successful exploitation. Unfortunately that has not been determined so far, the article states that “The bad news is that they still don’t know how the compromised happened, so it just might happen again.”.

Right now the jQuery website has a pretty obvious security problem. They are running an outdated version of WordPress:

The jQuery Website is Running  WordPress 3.9.1

The next version of WordPress, 3.9.2, which was released on August 6, included a number of security fixes and users were “strongly encourage you to update your sites immediately”. We are not aware of a mass exploitation of those vulnerabilities (or any others in older versions of WordPress in years), but some of the vulnerabilities fixed might be exploitable in a targeted attack. Back in WordPress 3.7, a new feature was introduced that automatically applies maintenance and security updates, like WordPress 3.9.2, so most websites that had been running WordPress 3.9.1 would have been upgraded within a day of the release of 3.9.2. That means that either the jQuery web developers disabled that feature or their server has some issues preventing the automatic updates from occurring. (Those automatic updates can be extended to plugins with our Automatic Plugin Updates plugin.)

Unfortunately the use of outdated software on the jQuery website isn’t an uncommon occurrence, when we looked at data from one of our tools earlier this year we found that 60 percent of WordPress were running a version below the then current version (we also found widespread use of outdated version of Drupal and Joomla.). A good way to keep track of the update status of websites you manage is with our Up to Date? Chrome app.

Posted in Outdated Web Software, WordPress | Leave a comment

Trust Guard and the False Security of Trust Seals

The recent massive credit card breach at Home Depot was yet another reminder that whether offline or online, IT security is often lacking. For consumers the question then is how can they know that their information is secure when they provide it to companies? Numerous security companies have created trust seals – that can be placed on websites if they meet certain requirements – that let the public know that a website is secure. The problem we have found with a number of these is that they are not doing basic security checks and therefore their assurances of security are false. Last week took a look at SiteLock’s and earlier this year we looked Norton’s, now we will look at another bad trust seal that we ran across recently.

While visiting the website of a client’s web host recently our Chrome extension Meta Generator Version Check provided an alert that website was running an outdated version of Joomla:

Hostica is Running Joomla 1.5

It obviously isn’t a great sign that web host is running outdated software on their website (especially when that version hasn’t been supported for two years), but what was more surprising was the Trust Guard security verified trust seal at the bottom of the website:

Hostica's Trust Guard Security Verified Trust Seal

In this case it is easy to detect that the website is running an outdated version of Joomla since there is a meta generator tag in the source code of the website’s pages that tells you exactly that:

<meta name=”generator” content=”Joomla! 1.5 – Open Source Content Management” />

With such an easy to detect security issue a trustworthy trust seal shouldn’t claim that the website is secure. We were curious to find out exactly what security checks Trust Guard was actually doing. Clicking the trust seal brought up a page that explained why they are claiming the website has verified security:

In order for www.hostica.com to qualify for the Trust Guard Security Verified Seal, we verify that their website is using at least 128-Bit SSL Encryption on pages where private information can be entered, such as credit cards, Social Security numbers, loan information, etc. and we monitor the SSL certificates expiration.

While using SSL encryption when sensitive information can be entered is important for security it doesn’t mean a website is secure, just that someone cannot snoop on the information as it sent to the website. For example, we have done plenty of cleanups of hacked websites in which the credit card information was compromised once it made its way to the website. Since a web browser’s user interface already provides notice when a secure SSL connection is in use, it isn’t clear what security value the trust seal is meant to provide, but it doesn’t seem that it out ways how misleading it is to claim that a website’s security is verified based only on the fact that it is using SSL encryption.

Posted in Bad Security, Outdated Web Software | 2 Comments

Is it Time to Upgrade to Zen Cart 1.5.3?

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.

Posted in Zen Cart | Leave a comment

Companies Trying to Sell Unnecessary Work Along With Needed Web Software Upgrades

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.

Protecting Yourself

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.

Posted in Magento, Zen Cart | Leave a comment