For the specific answer to your question see, https://magento.stackexchange.com/a/72700/361
Background
Firstly, there is no specific exploit - there are a series of articles doing the rounds at the moment that have misread and misunderstood the source article.
The original article merely said (and I'm paraphrasing),
If a hacker were able to get access to your Magento files, they could capture information from your customer
The key part being the hacker needing to actually access your server and modify files.
Don't panic ... this is nothing specific to Magento
In terms of information capture, there is nothing specific to Magento than any other website/platform. If a hacker gets access to your files, its effectively game over - they would be able to capture whatever information they wanted to.
The best you can do (and ultimately, the minimum you should be doing) is to maintain a good security policy that adheres to the payment processing industry's PCI Security Standards, you can find the list here, https://www.pcisecuritystandards.org/documents/Prioritized_Approach_for_PCI_DSS_v3_.pdf
Harden your store
You can really lock down facets of your store that greatly reduce the surface attack area for a hacker, or at the least, slow their progress if they do manage to get in/
Lock down permissions
You can restrict permissions on the document root to only allow writing to essential directories (/var and /media)
This is what we do by default on MageStack,
echo -n "Fixing ownership"
chown -R $SSH_USER:$WEB_GROUP $INSTALL_PATH && echo " ... OK" || echo " ... ERROR"
INSTALL_PATH="/path/to/public_html"
chmod 750 $INSTALL_PATH
find $INSTALL_PATH -type d ! -perm 750 -exec chmod 750 {} \; && echo " ... OK" || echo " ... ERROR"
echo -n "Fixing file permissions"
find $INSTALL_PATH -type f ! -perm 740 -exec chmod 740 {} \; && echo " ... OK" || echo " ... ERROR"
echo -n "Fixing cron permissions"
find $INSTALL_PATH/*/cron.sh -type f ! -perm 750 -exec chmod 750 {} \; && echo " ... OK" || echo " ... ERROR"
echo -n "Fixing media/var file permissions"
chmod -R 760 $INSTALL_PATH/*/media $INSTALL_PATH/*/var && echo " ... OK" || echo " ... ERROR"
echo -n "Fixing media/var directory permissions"
find $INSTALL_PATH/*/media $INSTALL_PATH/*/var -type d ! -perm 770 -exec chmod 770 {} \; && echo " ... OK" || echo " ... ERROR"
Adjust INSTALL_PATH,SSH_USER,WEB_GROUP to suit. What is important is that your SSH_USER is not the same user that PHP uses for the web server process, otherwise, you would essentially be providing full write access to the web server (mitigating any benefits).
Lock down your admin/downloader access
On MageStack, you would set this in ___general/x.conf
set $magestack_protect_admin true;
set $magestack_protect_downloader true;
On Nginx, you could use this,
location ~* ^/(index.php/)?admin{
satisfy any;
allow x.x.x.x;
auth_basic "Login";
auth_basic_user_file /microcloud/data/domains/x/domains/x/___general/.htpasswd;
deny all;
location ~* \.(php) {
include fastcgi_params;
}
try_files $uri $uri/ /admin/index.php ;
}
There's a bit more documentation on how to prepare a .htpasswd file here
Wrap the cron.sh process
I've come across other hosting providers using dedicated machines for cron/admin usage - which means that modifying the cron.sh file would allow for remote code execution on the cron/admin without ever needing to access to it. Wrapping up the process with the right user in a fakechroot can go that bit further to locking down the process.
There's far too much code for me to post, but there's a script here. Its specific to MageStack, but could be adjusted for use on less elegant server configurations :)
Audit, audit, audit
Linux is fantastic in terms of logging and tapping into that will give you a complete insight into what your server is doing.
A fantastic feature on MageStack is the auditing tool which logs all kinds of access and even file changes on a daily basis. You can find the logs here,
/microcloud/logs_ro
|-dh[0-9]+
|---access-YYYY-MM-DD.log.gz
|---backup-YYYY-MM-DD.log.gz
|---magescan-YYYY-MM-DD.log.gz
|---php-differential-YYYY-MM-DD.log.gz
|-acc[0-9]+
|---access-YYYY-MM-DD.log.gz
If you aren't using MageStack, you can replicate some of this with your own hosting provider quite easily, rsync being the simplest tool to do it.
Eg. If your backups are locally available, you could do the following. This will dry-run compare two directories and produce a diff patch list.
rsync -na /path/to/public_html/ /path/to/backup/public_html/ > change.log
grep -E '\.php$' change.log | while read FILE; do
diff -wp /path/to/public_html/$FILE /path/to/backup/public_html/$FILE >> php-differential.log
done
PHP changes are so infrequent that you could schedule this to run daily (or multiple times daily) and notify you by email if there is a PHP file change.
In summary
- Use version control, its easier to track changes
- Just having an SSL certificate is not enough to make your site safe
- Don't wait to get hacked to consider security
- Just because you redirect to your payment gateway provider (vs. capturing information) - it does not mean you can avoid PCI compliance, you still need to comply
- Be proactive, be safe and be thorough - check module code before you install it, check PHP files daily, review logs, check FTP/SSH access, change passwords regularly
Your customers are putting an enormous amount of trust in you when they pass over all their private information - and if you betray that trust by not operating a secure business, you'll lose their custom and all future custom.
PCI forensic investigations are incredibly expensive, time consuming and ultimately risk your ability of ever being able to take card payments again. Don't ever let yourself be put in that position!
Get patched
There were a series of patches released from Magento lately that fixed holes, including some that allowed for remote-code-execution. You can fetch them here, https://www.magentocommerce.com/products/downloads/magento/
But these new articles aren't referring to a new exploit, they are simply stating how hackers are leveraging historic exploits (or any other attack vector) to be able to capture cardholder information.
Sources
