Find Malware in Image Files

Malware

It’s a nightmare. Your production environment was compromised and you actually don’t know how and how much data was stolen. For sure there are different ways to be compromised. In this post I just want to explain, how hackers can get full access to your production environment by using image files.

As explained on Snapfast and Sucuri it is pretty easy to store any kind of PHP code in EXIF headers. Often times it only needs a simple script to create an administrator account. If you are using third-party extensions with an image upload function or if you are late with the last security update, there is a high risk to be compromised.

You can use commands like svn status or git status to find changes, but this is no guarantee to find malicious code, because oftentimes your /media/ or similar folders are not version controlled.

Here is one simple command how you can find infected image files.

In case if any file is infected, you will see the following search result.

5 useful commands for your daily work with Magento

Daily Work

1. Backup your media/catalog

Create a manually backup of media/catalog without /cache/ folder

The same with the current date in the filename.

2. Files not owned by apache

Find files which are not owned by apache group or user. This is useful if you want detect possible permission issues.

3. SQL / CSV files in your document root

You should never left database dump or other export files with sensible information in your document root, because there is a potential risk that those files can be downloaded from outside, depending on your security settings. To make sure your production environment is save, just run a simple ” find ” with the option ” iregex “.

4. List report files created in the last 24 hours

Here are some more options you can use for ” -ctime “.

5. Truncate log files

A fast growing system.log or exception.log can be the cause of a server outage. If you want empty log files on a production environment, the command ” truncate ” will help you.

For further debugging you can keep log data by specifying the size.

Practical grep command examples for your Magento log file audit

Improve your bug fixing routine with some simple grep commands. Run these commands before any production deployment just to make sure your new code is working properly. To reduce the output on your terminal, extend my examples as you can see below.

Count the results with ” wc -l ” at the end.

Display the 1000 rows with ” tail -n 1000 ” at the beginning.

1. System.log

1.1 Access to an array by a key that doesn’t exist

1.2 Use a variable that wasn’t previously defined

1.3 Debug output generated by Mage::log()

1.4 Any kind of permission issues

1.5 Missing Magento template files

1.6 Access to a non-object

1.7 Missing argument in a function call

1.8 Invalid argument supplied to a loop

Find all:

2. Exception.log

2.1 Any kind if XML issues

2.2 Specific Authorize.net gateway issues

2.3 Specific PayPal gateway issues

2.4 Find general curl issues

Find all:

3. Reports

Find the last 10 error report files and grep for any kind of error message.
3.1 MySQL connection issues

3.2 Invalid config field

3.3 Unable to read response

3.4 External urls redirect

Find all:

4. Apache error logs

4.1 Find missing files caused by any reason

Setup cron job for apache user

Cronjob

As soon as you don’t need root permissions in your PHP application / script, it is recommended to set up cron jobs with a web server specific user.

1. Find the apache user

Get the current apache user from the process status.

2. Edit the tab

Edit the crontab with the option -u and the specific apache user. This command will create a user-specific cron file in /var/spool/cron/crontabs/.

Set up your crontab and save the changes with CTRL-O.

3. Check the syslog file

After that, check the syslog file to make sure that the cronjob is running correctly.

Query to get size of database tables in MB

Database

If your hosting environment has no database monitoring, you should be able to monitor it manually once in a while or with your own shell script to prevent rapidly growing MySQL tables, because the result of large MySQL tables ( I am talking about 2 – 10 GB with millions of rows ) are often random performance issues, especially if you are using community modules with not well written MySQL queries.

This is the output of the query.

Table is marked as crashed and should be repaired

Don’t freak out if your Magento is not working and because of the following error message.

The reason of a crashed MySQL table is mostly related to a server issue. For example:

  • Any kind of hard-disk failure
  • Sudden server reboot (power outage in hosting)
  • Hard server reboot (ACPI shutdown)

In most cases you can repair the affected table with a simple repair command, which comes with MySQL.

This command looks pretty easy and safe, but keep in mind that you should always create a backup before you change anything in your database, because probably more MySQL tables are affected.

Useful Postfix Commands

If your server is configured to send emails with postfix, you should be familiar with some basic Postfix commands without any help from your sysadmin.

1. List your default and custom settings

If you have added your custom Postfix settings or set your own email aliases with virtual_alias_maps, you will find it with postconf -n.

If you want to see your Postfix default settings, just change the parameter -n to -d.

It’s a good practise to keep this output as a running configuration snapshot in a simple text file in case you have any troubles with Postfix after server reboot or software updates.

2. List the current queue and email id’s

Check your postqueue frequently to make sure all your emails were delivered correctly. If everything is okay you will see the message “Mail queue is empty”. Otherwise, you will see a list of  undelivered emails.

3. Read emails from the queue

4. Delete emails from the queue