4

We are running a magento site 1.8.1.0. For the last couple months, we keep getting customers' complaint about their unauthorized charges on their credit cards. We have applied all the security patches (including the newest supee-6788), magereport.com all pass. And also passed PCI compliance scan. Magmi removed, wordpress removed. However customers are still losing their credit card info. Can someone point us what we should do to locate the problem, is there a possibility that certain extension massed up our site? How can we find it out. Thanks.

  • where is your system administrator? he will check everything. also just to be safe for now, move CC processing off site. – MagenX Nov 11 '15 at 8:20
4

The problem is that you've only outlined remote tests, which perform a series of basic tests for known vectors - what they can't do identify signs of a compromise.

You almost certainly have a backdoor in place, you need to check your codebase and DB to ascertain where this may be.

The simplest way to do this is to fetch a clean copy of the Magento codebase, then do a recursive diff against your installation.

Take action

Whenever a compromise is suspected, you need to put an action plan in place.

  1. Reset your entire hosting environment (ie. wipe it back to a fresh/new state), a good hosting provider can do this instantly without cost
  2. Lock down file permissions and prevent the web server being able to write to anything other than media and var (this will avoid your future efforts being negated)
  3. Check that every Magento patch is installed
  4. Remove any other web apps you have installed alongside your store (eg. Wordpress)
  5. Remove any encrypted or obscuficated code, if you can't see the source, its not safe
  6. Remove any unused 3rd party modules/themes, and remove/reinstall anything that remains with a fresh copy from the vendor
  7. Perform a recursive diff on the Magento code and identify a list of changed files and files not within the Magento base install. Then inspect each of these files one at a time. I would specifically focus on,
    • PHP files
    • phtml files
    • JS files
  8. Set up a daily change audit log that performs a diff of your codebase against your previous days backup codebase

Security is hard enough when you've got a phenomenally secure environment, but if you don't have an environment that provides all the tools above natively - it can be near impossible.

In hindsight

A good Magento hosting provider can and should be doing most of the above for you as standard. If they aren't, make moving hosting provider your first priority.

Addressing a compromise is an expensive process (both in terms of customer confidence loss, investigatory costs and fines) - so invest in expertise that will help minimise this.

I can't stress enough how important security is when it comes to hosting, and this is really what tears your typical "Magento Optimised" server, from a platform built for Magento in every respect.

  • I just read this on one of the websites ..... but thank you. – Rob D. A. Sep 14 '17 at 13:40
2

If your site was compromised prior to installing the latest patches, installing those patches does not fix the existing compromise.

In the modern world of PCI compliancy, with liability as expensive as it is, my recommendation would be to contact a Magento professional, particularly one well schooled in Magento server administration.

These scans you are running are looking for vulnerabilities that someone can exploit, but they don't look for exploits that already exist.

Ideally, someone who knows what to do would not only fix the issue, but have a report of how it happened so you can be 100% sure that it is fixed. However, with you already patching and modifying things, it somewhat muddles up the crime scene and often times ruins valuable clues that could lead to the exact culprit so you may now never know exactly what caused it.

If you are dedicated to tracking this down yourself, you need to identify any files that exist on your server that do not exist in a stock Magento installation (other than your custom files such as themes, etc). After that, look for any stock Magento files that vary in size from the one's provided by Magento or files in modules that don't belong or vary from the module provided files.

  • I just read this on one of the websites ..... but thank you. – Rob D. A. Sep 14 '17 at 13:41
  • "...it somewhat muddles up the crime scene and often times ruins valuable clues that could lead to the exact culprit so you may now never know exactly what caused it..." probably the best part. – DarkCowboy Jun 1 '18 at 8:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.