Script Explanation

We'll look at the script below which is from an actual attack on a Magento 2 webstore. The script attempts to inject and execute dangerous commands on your Magento server, potentially compromising your entire system. Here’s a breakdown of what it does:

{{if this.getTemplateFilter().filter(dummy)}}{{/if}} sys{{if this.getTemplateFilter().add%00AfterFilterCallback(base64_decode).
add%00AfterFilterCallback(system).Filter(xxxx/xxxxxx)}}m{{/if}}

Breakdown of the Script

• {{if this.getTemplateFilter().filter(dummy)}}{{/if}}: This is a conditional check using the template filter to apply a function, which is usually used to filter out or transform data. Here, it's used as a disguise.
• 
  sys: A deliberate inclusion to form a recognizable command word within the code snippet, potentially obscuring its malintent.
• 
  {{if this.getTemplateFilter().add%00AfterFilterCallback(base64_decode).add%00AfterFilterCallback(system).Filter(xxxx/xxxxxx)}}m{{/if}}: This segment is more complex and highly obfuscated. It demonstrates the addition of callbacks that decode and execute a base64-encoded command. The obfuscation includes null bytes (%00) and base64 encoding to bypass basic security filters.

This script essentially injects a backdoor into your Magento installation, disguised within seemingly harmless functions, making it challenging to detect. Once executed, it can further compromise your site.

Analysis of the Logs

We have analyzed the following logs to further understand what the script was trying to do:

Line 1: "POST /rest/V1/guest-carts HTTP/1.1" 200 618 "-" "-"
Line 2: "GET /rest/V1/products?searchCriteria[pageSize]=20 HTTP/1.1" 401 702 "-" "-"
Line 3: "GET /catalogsearch/result/?q=%25a%25 HTTP/1.1" 200 804686 "-" "-"
Line 4: "GET / HTTP/1.1" 200 446535 "-" "-"
Line 5: "POST /rest/V1/guest-carts/items HTTP/1.1" 200 767 "-" "-"
Line 6: "GET /checkout HTTP/1.1" 302 8297 "-" "-"
Line 7: "GET /customer/account/create/ HTTP/1.1" 200 73328 "-" "-"
Line 8: "POST /rest/V1/guest-carts/estimate-shipping-methods HTTP/1.1" 200 1058 "-" "-"
Line 9: "POST /rest/V1/guest-carts/shipping-information HTTP/1.1" 200 2289 "-" "-"
Line 10: "POST /rest/V1/guest-carts/payment-information HTTP/1.1" 400 712 "-" "-"
Line 11: "POST /rest/V1/guest-carts/shipping-information HTTP/1.1" 200 2278 "-" "-"
Line 12: "POST /rest/V1/guest-carts/payment-information HTTP/1.1" 400 712 "-" "-"
Line 13: "POST /rest/V1/guest-carts/estimate-shipping-methods HTTP/1.1" 200 1060 "-" "-"
Line 14: "POST /rest/V1/guest-carts/shipping-information HTTP/1.1" 200 2381 "-" "-"
Line 15: "POST /rest/V1/guest-carts/payment-information HTTP/1.1" 200 586 "-" "-"
Line 16: "GET /sys.php HTTP/1.1" 404 65678 "-" "-"
Line 17: "GET /pub/sys.php HTTP/1.1" 404 65683 "-" "-"

Breakdown of the Logs

• Line 1: The attacker starts by posting to the guest cart endpoint. This could be an attempt to gather information about the store's API.
• Line 2: A GET request for products, which is unauthorized (401), suggesting either a brute force attempt or an information gathering step.
• Line 3: A search query, which appears to succeed (200), returning a significant amount of data. The query string indicates an attempt to find specific data on the site.
• Lines 4: The attacker continues to make GET requests to various HTML pages on the site, all of which return status 200, indicating successful retrieval. This is likely reconnaissance to understand the site structure.
• Line 5-6: The attacker attempts to add items to the cart and navigate to the checkout page, then to the account creation page. These actions are successfully executed (status 200 and 302), indicating that the workflow is not restricted.
• Lines 8-15: Multiple POST requests to various endpoints for estimating shipping methods, adding shipping information, and attempting to post payment information. The payment POST requests fail (400), while others succeed (200), suggesting an attempt to manipulate cart and order functionalities.
• Lines 16-17: The attacker attempts to access specific scripts (sys.php and pub/sys.php), which are not found (404). These attempts likely relate to running or checking if their injected script is accessible and executable.

From the logs, it is evident that the attacker was attempting to gather as much information about the site and its API endpoints before trying to execute or confirm the presence of a malicious script (i.e., sys.php).

How to Check if the Script was Successful

To determine if the malicious script was successfully executed on your Magento server, follow these detailed steps:

1. Check for the Presence of Malicious Files

Navigate to the pub directory of your Magento installation and look for a file named sys.php or any other unfamiliar PHP files. You can use the following command in the terminal:

cd /path/to/magento/pub
ls -l

If you find the sys.php file or any suspicious files, this is a strong indicator that the script was successful.

2. Check the Last Modified Date and Time of Files

Reviewing the last modified dates of files, especially in the pub directory, can help you identify when a file was added or changed. This can indicate whether a file was part of the attack. Use the following command to check the last modified date and time of all files in the pub directory:

cd /path/to/magento/pub
ls -lt

This command will list all files in the directory, sorted by modification time, with the most recently modified files at the top. Look for any files that were modified at unusual times, especially if they align with when you suspect the attack occurred.

You can also check a specific file’s last modified time using:

stat sys.php

This command will show detailed information about the file, including the last modification time.

3. Review Server Logs

Examine your web server logs for any signs of unauthorized access or unusual activity, especially around the time you suspect the script might have been executed. Check both access logs and error logs:

tail -n 1000 /var/log/apache2/access.log
tail -n 1000 /var/log/apache2/error.log

Look for entries that involve the curl command or requests to the suspicious URL (e.g., http://x.x.x.x/sys.php?).

4. Inspect the Magento Database

The script might have been used to inject malicious content into your Magento database. Check your database for any unfamiliar entries, especially in the following tables:

• core_config_data
• admin_user
• customer_entity

To query your database, you can use the following MySQL command:

mysql -u username -p
USE magento_db;
SELECT * FROM core_config_data WHERE path LIKE '%sys.php%';

Replace username with your MySQL username and magento_db with your Magento database name. If you find any suspicious data, it could mean the script successfully manipulated your database.

5. Monitor for Unusual Network Activity

Check your server's network activity to see if there have been any unexpected outbound connections. This can indicate that a malicious script is communicating with an external server:

netstat -an | grep ESTABLISHED

Look for any connections to unfamiliar IP addresses or domains, particularly those matching the URL in the script.

What to Do If the Script was Successful

If you find evidence that the script was successful, follow these steps to secure your Magento store:

1. Isolate the Affected Server

Immediately disconnect the affected server from the network to prevent further damage or data leakage. This will help contain the threat.

2. Remove Malicious Files

Manually delete any malicious files you identified, such as sys.php in the pub directory:

rm /path/to/magento/pub/sys.php

Also, check other directories for any suspicious files and remove them.

3. Restore from Backup

If possible, restore your Magento store from a clean backup made before the attack occurred. This is the safest way to ensure all traces of the malicious script are removed.

4. Change All Credentials

Change all passwords for your Magento admin, database, FTP, and any other accounts associated with the affected server. If the attacker accessed your system, they could have compromised these credentials.

5. Patch and Update

Ensure your Magento installation, as well as any extensions, are fully updated to the latest versions to patch known vulnerabilities. This reduces the risk of similar attacks in the future.

6. Implement Security Measures

Enhance your Magento store's security by installing a Web Application Firewall (WAF), enabling Two-Factor Authentication (2FA), and using security-focused extensions like ScriptGuard Pro.

7. Scan for Malware

Run a thorough malware scan on your server to detect any other potential threats. Use tools like ClamAV or a dedicated Magento security scanner.

8. Monitor for Recurrence

After taking these steps, closely monitor your server and Magento store for any signs of recurring attacks or suspicious activity. This ongoing vigilance is crucial in the aftermath of an attack.

How ScriptGuard Pro Blocks This Attack

ScriptGuard Pro can prevent such attacks by blocking the injection of malicious scripts into your Magento store. It does this by filtering out dangerous characters and commands before they can be executed, ensuring your store is protected from unauthorized code execution.

To find out more details on how to protect your Magento store using ScriptGuard Pro, please visit https://www.lecsoft.co.uk/scriptguardpro.html