Hacked CE installation (media/dlh/info.php)

[szabobalint]

Greetings,

I have a serious issue with a Magento CE installation: an automatic vulnerabilty check on the domain found a file named info.php in the media/dhl/ folder. I have no idea how this file got there, but it makes the attackers able tu run any scripts on the site (it gets the script as a POST parameter in base64 format). I found some requests made to this file in the access logs, but unfortunately I cannot see the actual script executed since it is in the POST body.

I have updated to the latest (1.9.1.1) version and deleted the file but it still reappears after some time. I've also checked the site with the shoplift hack chacker and it says that the site is fine.

When I delete the file it appears after some time again. In the database I didn't seen any strange records so far and luckily the site doesn't have any actual visitors yet. Could someone help me out to figure out how this file gets on the site and how can I prevent it?

Thanks in advance,

Bálint

[Curt Maybury]

This isn't a solution to fix the hack, but it will solve that recurring hack file problem temporarily.

Edit the file (use cpanel etc), make it blank or:

<?php 

die();

?>

Now chmod it to 000 

Now:

1. Change your FTP password

2. Change your mysql password

3. Download ALL files from your website and search in the same way you would for a wordpress hack (Do you have wordpress installed?)

You're looking for eval( etc - if you don't know what to look for, google for it  

If you're not at least slightly proficient, contact your host - with a few linux commands they should be able to identify anything to worry about

Good luck...

Edit:  I just saw that this was a week ago - hope I'm not too late

[beejhuff]

Unfortunately the scanners seem to only check to see if you have the patch installed and not for the presence of the specific files that are a signature for any existing compromises.  We've spent the last 4 wekes working to remediate several systems that had been compromised, each of which had pretty significant variations in the attack signature, compromise technique and ultimate impeact on the avialbiltity of the site.  Like you reported on several of them, even after we clearned what we KNEW were compromised files or restored from a backup, the site would wind up comprised again in 24-48 hours.

We've remediated many sites since these exploits were released and to assist the community in responding to them we've documented our research to provide a list of 18 known attack signatures so that you can check your systems for evidence of them and respond accordingly.  Keep in mind we've never seen two compromises that are exactly the same, so there's a chance your particular system might be slightly different - if you discover anything on your system that we don't already have documeted, please share that with us so we can update the attack signature guide.

We're working on a toolkit to automate the remediation of these item but it may be a week or two until it's ready for distribution.  In the meantime, we're sharing the knowledge we've acquired working through these compromises with everyone in the community in an effort to make sure everyone is as safe as can be expected.

I'm including a 3-Step Compromise Response Process below that we've worked over and over again to get consistent results.  The key assumption you're going to have to make is that you can't know what has or hasn't been compromised until you diff the files in your system against the default source code provided by Magento or a copy you have made in your (Git / Mercurial / SVN) repository.  YOU SHOULD ASSUME that your database and logins have been compromised and go change them all.

We provide a link to a guide we've uploaded to our GitHub repo that is tracking the 18 signatures we have been able to clearly identify in the wild that relate to these most recent security announcements.  You should go through each and every one of them to see if you can find anything that matches.  If so, you can follow the instructions to either delete or replace the compromised file or delete or update your database to replace the affected data.  It's in PDF format now, but we should have it converted to Markdown by tomorrow.

CRITICAL NOTE: Installing the patches from Magento WILL NOT help you if you have already been compromised.  At best, it will stop ADDITIONAL compromises of the known types, but if you are already compromised then you'll have to BOTH install the patches and remediate your system as we highlight below.

Let me know if you discover anything not included already in that guide - we're trying our best ot keep up with the latest developments on this topic and happily welcome any contributions from the community.

Phase 1: Identify the scope of your compromise.  Each and every one of the items I list below are signatures we've discovered on compromised Magento sites specicifally relating to the SUPEE-5344 and SUPEE-5994 vulnerability announcenments.  You need to go through each one and check to see if you find any evidence on it on your system.  Many of them are enough by themselves to allow an attacker to re-enter your systen after you patch it, so you'll have to be dilligent and make sure you don't skip anything or fail to remediate it.

Phase 2: Delete what you must, and replace what you can : use the original files from your repository or the Magento source files.  If you're not running one of the latest versions, you can still use the Magento download page to grab older version sources from their site.

Phase 3: RESET Credentials: Inventory every use of a login name and password remotely related to your deployment and reset them all, including

1. Merchant Account Loigins and API Keys
2. Magento Admin Logins & Passwords
3. Email account credentials
4. LDAP / AD  / Primary Authentication System Passwords
5. EVERYTHING

- You can be reasonably sure that the preceding steps will help you purge infected fies but you can not know if passwords have been sniffed or key logged or the victim of some other attack, so resetting all related credentials is the safest option if you are going to attempt to remediate a compromised system. 

The guide is too long to post in this response but the PDF can be downloaded immediately at our GitHub reopsitiory.

Sincerely,

Bryan “BJ” Hoffpauir

<< Signature to be setup in your profile >>

[beejhuff]

I recently answered a couple of similar or at least related questions on the Magento Stack Exchange and thought I would follow up with some of the additional insights from a few more recent remediation efforts.

A security incident like this one is a challenge that must be addressed with responses from both the technical and business perspectives and given that the business implications include potential regulatory and contractual requirements that specifically impact the technical actions you may be required to perform, I thought I would outline them together in this answer.

Before performing any of the earlier recommended technical activities, review the following and determine which, if any, are allowed given the regulations you are subject to in your location and the contracts you have entered into with your issuing banks, gateway providers and processing service partners.

1. You should first take some time to review the Official Magento Security Best Practices Guide. It contains a wealth of information to help you deal with a compromised installation as well as how to prevent it from happening in the future.
   
   It's based on the work of the Magento Security Team as well as knowledge shared by several Magento Security Experts both on Magento Stack Exchange and here in the Magento Community Forums.
   
   
2. If this site generates any real volume of transactions, you should probably not attempt to resolve the issue completely on your own. Contact a Magento Security Expert who is familiar with all of the following:
   
   1) The specific Magento version you are running
   
   2) The laws covering Data Breaches, Privacy Protections, and Customer Notification Requirements that govern Merchants operating in and/or located in your geographical region.
   
   3) Reviewing contracts and business partner agreements with your Merchant's Gateway Provider, Processing Services, and Credit Card Companies

Depending on your location, you may be subject to local, regional, and / or national laws that require you to either perform very specific actions in response to a security event or to engage the assistance of someone (or a company) that is specifically licensed as a forensic information security specialist.

In addition, the fine print of the credit card processing agreements signed with the store's Credit Card Merchant Gateway, Financial Institution, Issuing Bank, and the Credit Companies themselves may require other specific actions be performed and that law enforcement be engaged or the store may be held responsible for any charges incurred by the attacker(s).

Finally, again, depending on your location, your store may be required by law to notify the customers of the data breach in very specific ways and the Nation / States in which your customers reside may impose additional requirements on notifying affected customers. Failure to comply with these requirements might make the store subject liable for fines and penalties outside of any costs imposed by your processing company or gateway provider.

These laws & contractual requirements vary greatly across different geographical regions and also across different financial institution and businesses that offer clearing and gateway services to merchants so it is important to engage the services of someone who is both a Magento Security Expert and also familiar with the laws specific to your geographic location and who can assist you with both the technical effort in remediating your hacked site as well as the business activities required by any contracts that have been entered into by the Merchant.

Once you have identified a suitably experienced partner to assist you in your remediation effort, ask them to confirm the next technical steps to take, including actions such as imaging the compromised system, contacting law enforcement, disconnecting the system from the network and investigating the affected systems.

REMEMBER: You are no longer in possession of JUST a hacked system! Your compromised Magento installation is now also an ACTIVE crime scene, and in many jurisdictions, the crime is a severe one. In the US, it's almost universally a felony (severe crime) with specific prohibitions against tampering with evidence left behind by the perpetuators of the criminal act without proper supervision of licensed personnel and/or law enforcement professionals.

It would be unwise to bring the system back to a working state only to find out that you YOURSELF had just committed a crime punishable by fine and/or jail time. Standard Disclaimer: I am not a lawyer and this does not constitute legal advice.

See Also:

• Visa Data Security Resources for Small Businesses
• MasterCard Rules and Compliance Programs for Processors & Merchants
• American Express US Merchant Security Policies
• Fraud Prevention at American Express
• Data Security Operating Policy & Resources at American Express
• Fraud & Chargeback Knowledge Center at American Express
• Discover Card Fraud & Security Resources for Merchants
• Experian Data Breach and Notification Resources

Note: Most of the links above point to resources specifically written for US Merchants, but they all also contain links for merchants in other regions as well as contact information to engage the specific security support teams to assist you in your own location.

[ok_arrow]

Magento 1

Login to phpMyAdmin, look in “core_file_storage”, select the undesirable entry(s) and delete.

Explanation-

Malicious file appearing or reappearing. 

The “core_file_storage” table is Magento’s database media file storage. If the file is requested and it’s in the table and it doesn’t already exist in the physical file system, Magento creates the physical file.

The media data in that field is binary immune to security or malware scans. Likewise, if the table were exported, you would not see anything unusual, just binary in a field that’s supposed to be binary.

How it occurred?

Most likely a compromised Magento admin user account (current or previous). A Magento admin user can upload media (or anything else) and select the storage type.

How to fix?

Remove the undesirable physical files and data entries. Address all admin accounts as if they were compromised, follow best practices with security and apply patches if available. Change the database password and limit database access to the site (typical). Check or reset file and directory permissions site wide.

Security/malware scans work well but if you’re not sure if other files were added or modified use a diff tool to compare against the box Magento version. Eliminate the same files, review all added and all modified files including media files.

With the media files (assuming you downloaded the media directory to a local machine) navigate to the media directory, delete the cached directories. Search for . the dot search will display all images and files at once without the folders. Make sure there are no unusual file types present and the images are in fact images.

If the site is using and storing media in the database it maybe well populated.

Find the php and htaccess files

SELECT * FROM core_file_storage
WHERE (filename LIKE '%.php' OR filename LIKE '%.htaccess');

Browse suspicious or less common file types

SELECT * FROM core_file_storage
WHERE (filename NOT LIKE '%.jpg' AND filename NOT LIKE '%.jpeg' AND filename NOT LIKE '%.png');

.

If you wish to go a step further-

IP restrict all site admin to only admin users.

IP restrict ports/direct file access ex ftp etc

Magento 2

The media storage works much the same way but M2 uses different table names.