Incident

Adobe APSB22-12 – Don’t panic!

Adobe has released a critical security patch early this week on https://support.magento.com/hc/en-us/articles/4426353041293-Security-updates-available-for-Adobe-Commerce-APSB22-12– and https://helpx.adobe.com/security/products/magento/apsb22-12.html.

Of course, Adobe Commerce merchants and agencies are nervous and want to apply the security patch as soon as possible. However, I believe as long as your admin passwords are strong enough and you have control about your admin accounts, you shouldn’t be worried too much.

Here is why.

Let’s have a look at the content of the security patch.

diff --git a/vendor/magento/module-email/Model/Template/Filter.php b/vendor/magento/module-email/Model/Template/Filter.php
index 1a7c3683820a..586cb485ee1f 100644
--- a/vendor/magento/module-email/Model/Template/Filter.php
+++ b/vendor/magento/module-email/Model/Template/Filter.php
@@ -618,6 +618,12 @@ public function transDirective($construction)
         }
 
         $text = __($text, $params)->render();
+
+        $pattern = '/{{.*?}}/';
+        do {
+            $text = preg_replace($pattern, '', (string)$text);
+        } while (preg_match($pattern, $text));
+
         return $this->applyModifiers($text, $modifiers);
     }
 
diff --git a/vendor/magento/framework/Filter/DirectiveProcessor/VarDirective.php b/vendor/magento/framework/Filter/DirectiveProcessor/VarDirective.php
index f2fe398c3848..78034d70ba51 100644
--- a/vendor/magento/framework/Filter/DirectiveProcessor/VarDirective.php
+++ b/vendor/magento/framework/Filter/DirectiveProcessor/VarDirective.php
@@ -55,6 +55,11 @@ public function process(array $construction, Template $filter, array $templateVa
             $result = $this->filterApplier->applyFromRawParam($construction['filters'], $result);
         }
 
+        $pattern = '/{{.*?}}/';
+        do {
+            $result = preg_replace($pattern, '', (string)$result);
+        } while (preg_match($pattern, $result));
+
         return $result;
     }

diff --git a/vendor/magento/module-email/Model/Template/Filter.php b/vendor/magento/module-email/Model/Template/Filter.php

index 1a7c3683820a..586cb485ee1f 100644

--- a/vendor/magento/module-email/Model/Template/Filter.php

+++ b/vendor/magento/module-email/Model/Template/Filter.php

@@ -618,6 +618,12 @@ public function transDirective($construction)

}

$text = __($text, $params)->render();

+ $pattern = '/{{.*?}}/';

+ do {

+ $text = preg_replace($pattern, '', (string)$text);

+ } while (preg_match($pattern, $text));

return $this->applyModifiers($text, $modifiers);

}

diff --git a/vendor/magento/framework/Filter/DirectiveProcessor/VarDirective.php b/vendor/magento/framework/Filter/DirectiveProcessor/VarDirective.php

index f2fe398c3848..78034d70ba51 100644

--- a/vendor/magento/framework/Filter/DirectiveProcessor/VarDirective.php

+++ b/vendor/magento/framework/Filter/DirectiveProcessor/VarDirective.php

@@ -55,6 +55,11 @@ public function process(array $construction, Template $filter, array $templateVa

$result = $this->filterApplier->applyFromRawParam($construction['filters'], $result);

}

+ $pattern = '/{{.*?}}/';

+ do {

+ $result = preg_replace($pattern, '', (string)$result);

+ } while (preg_match($pattern, $result));

return $result;

}

The patch will update two files only that are responsible to process template variables such as email variables {{var logo_url}} or {{config path=”general/store_information/name”}} or variables within CMS pages or Static Blocks. The change is trivial and will wipe out unwanted content by using the pattern $pattern = ‘/{{.*?}}/’.

It basically means, in order to be able to exploit this issue, you must:

1. Know the admin url of a store
2. Have access to the Magento backend ( ideally admin privileges )
3. Know how to exploit the issue

So, as long as you maintain admin accounts regularly and know who is actively working in your backend, you should be fine.

However, if you have modules installed that add custom variables by injecting Magento\Email\Model\Template\Filter in combination with 3rd party services, you should probably go and install the patch with your next release.

Update: 2022/02/16

Code could possibly injected by using the customers billing or shipping address ( e.g {{trans “%name,” name=$order.getBillingAddress().getName()}} ) depending on how strong form validation is in the front-end ( My Account > Addresses or Checkout ).

Find Malware in Image Files

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.

$ cd /var/www/{{{MAGENTO}}}/
$ find . -iregex '.*\.\(jpg\|gif\)' -exec grep -o -P 'base64_decode' {} \;

1 2	$ cd /var/www/{{{MAGENTO}}}/ $ find . -iregex '.*\.$jpg\\|gif$' -exec grep -o -P 'base64_decode' {} \;

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

Binary file ./media/test.jpg matches

1	Binary file ./media/test.jpg matches

5 useful commands for your daily work with Magento

1. Backup your media/catalog

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

$ cd /var/www/{{{MAGENTO}}}/media/
$ tar -czf ~/catalog.tar.gz catalog --exclude 'catalog/product/cache/*'

1 2	$ cd /var/www/{{{MAGENTO}}}/media/ $ tar -czf ~/catalog.tar.gz catalog --exclude 'catalog/product/cache/*'

The same with the current date in the filename.

$ tar -czf ~/"catalog_$(date '+%Y%m%d').tar.gz" catalog --exclude 'catalog/product/cache/*'

1	$ tar -czf ~/"catalog_$(date '+%Y%m%d').tar.gz" catalog --exclude 'catalog/product/cache/*'

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.

$ cd /var/www/{{{MAGENTO}}}/
$ find . \! -group www-data \! -user www-data

1 2	$ cd /var/www/{{{MAGENTO}}}/ $ find . \! -group www-data \! -user www-data

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 “.

$ cd /var/www/{{{MAGENTO}}}/
$ find -iregex '.*\.\(sql\|tar\|gz\|zip\|csv\)'

1 2	$ cd /var/www/{{{MAGENTO}}}/ $ find -iregex '.*\.$sql\\|tar\\|gz\\|zip\\|csv$'

4. List report files created in the last 24 hours

$ cd /var/www/{{{MAGENTO}}}/var/report/
$ find . -type f -ctime -1

1 2	$ cd /var/www/{{{MAGENTO}}}/var/report/ $ find . -type f -ctime -1

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

# find files created greater than 24 hours ago
find . -type f -ctime +0

# find files created between now and 1 day ago
# (i.e., in the past 24 hours only)
find . -type f -ctime 0

# find files created less than 1 day ago
find . -type f -ctime -1

# find files created between 24 and 48 hours ago
find . -type f -ctime 1

# find files created more than 48 hours ago
find . -type f -ctime +1

# find files created greater than 24 hours ago

find . -type f -ctime +0

# find files created between now and 1 day ago

# (i.e., in the past 24 hours only)

find . -type f -ctime 0

# find files created less than 1 day ago

find . -type f -ctime -1

# find files created between 24 and 48 hours ago

find . -type f -ctime 1

# find files created more than 48 hours ago

find . -type f -ctime +1

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.

$ cd /var/www/{{{MAGENTO}}}/var/log
$ truncate -s 0 system.log

1 2	$ cd /var/www/{{{MAGENTO}}}/var/log $ truncate -s 0 system.log

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

$ truncate -s 10M system.log

1	$ truncate -s 10M system.log

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.

SQLSTATE[HY000]: General error: 145 Table './magento/log_visitor_info' is marked as crashed and should be repaired

1	SQLSTATE[HY000]: General error: 145 Table './magento/log_visitor_info' is marked as crashed and should be repaired

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.

mysql> repair table log_visitor_info;
+-----------------------+--------+----------+----------+
| Table                 | Op     | Msg_type | Msg_text |
+-----------------------+--------+----------+----------+
| magento.log_visitor_info | repair | status   | OK       |
+-----------------------+--------+----------+----------+
1 row in set (0.54 sec)

mysql> repair table log_visitor_info;

+-----------------------+--------+----------+----------+

+-----------------------+--------+----------+----------+

+-----------------------+--------+----------+----------+

1 row in set (0.54 sec)

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.