New malware affecting Zend Framework.

Today, we want to focus on one in particular sample that we’ve been encountering pretty regularly over recent weeks; dubbed simply ‘Zend malware’. It’s a new type of PHP remote code execution, utilizing the Zend Framework to exfiltrate payment card numbers.

The Zend Framework[1] is used in Magento to develop web applications and services and provides object-oriented code. The malicious code has been discovered consistently in the core_config_data of Magento.

It must be noted that this is not a vulnerability in Zend Framework. The vulnerability lies in the fact that some applications based on Zend Framework still use unserialize() on user input and it is through this practice – along with specially crafted input the problem exists. Since PHP allows object serialization, attackers could pass ad-hoc serialized strings to a “vulnerable” unserialize() call, resulting in an arbitrary PHP object(s) injection into the application scope (PHP Object Injection - OWASP, 2015).

The identified code abuses a dangerous feature of the standard preg_replace function call, allowing code execution to be performed on the server. The malicious code is to be evaluated and executed if the regular expression pattern /987654321/e is not detected. This capability relies on the /e argument that instructs the preg_replace function to actually evaluate (execute) the PHP code that is found in the next argument (the replacement string) and use the result of it as the actual replacement string content. The code in our example turns out to be a  php packer.

Unpacking the data we discovered that the data was, in fact, malicious code that would harvest card details, encode them in base64 and then post the data to an external address.

Recommendations:

As previously stated, the malicious code was found in the core_config_data database table, which is only accessible by an administrator account. Our investigations had concluded a significant portion of website compromises stem from exposed administrative URLs.  This coupled with weak, short or generally insecure passwords means threat actors have a fairly obvious and un-challenging attack surface through which to compromise websites. 

The obvious countermeasure would be to either “move” the administration URL to something less obvious or even better, restrict the points of origin that is permitted to communicate with the interface.  In order to make your admin path more difficult to find (thereby making it much harder to locate and attack) we recommend creating an obscure admin path. For example:

You should change your Admin Path from yourwebsite.com/index.php/admin or yourwebsite.com/admin to yourwebsite.com/store/somethinghardtoguess.

Furthermore, passwords can easily be guessed with dictionary attacks and brute force attacks, therefore a password should contain more than 8 characters and use a combination of lowercase, uppercase, numeric and where possible, symbol characters. It should also be updated on a regular basis.  

Additionally, everyone is expecting an “admin” user to be present on these systems, which unfortunately “removes” one variable a brute force attacker needs to evaluate. It is possible to rename the admin user to an arbitrary name, by simply selecting the System -> My Account within the Magento administration panel, then updating the “User Name” field and saving the changes.  Now attackers would need to guess the username and the password….. Simply restricting access to the URL to only known good addresses is by far the most effective solution however.

A final precautionary step would be to inspect the core_config_data table inside your database for anything unusual or indicators similar to those displayed above.

If you'd like to automate the search for this malicious code, sign up for a trial of our FGX-Web solution and we'll be happy to help you out.

Whilst protecting against malware should obviously make up a large part of your security posture, there's more to your security chain than just malicious software. Social engineering is being highlighted more and more as the main cause of breaches. Read more about it in our blog post! 

PHP Object Injection - OWASP. (2015). Owasp.org. Retrieved 16 March 2018, from https://www.owasp.org/index.php/PHP_Object_Injection

[1] https://framework.zend.com/