Tampered OpenCart Authentication Aids Credit Card Skimming Attack

Using out of date software is the leading cause of website compromise, so keeping your environment patched and up to date is one of the most important responsibilities of a website administrator. It’s not uncommon to employ the use of custom code on websites, and spend small fortunes on software developers to tailor their website just the way they want it. However, the usage of customised code can sometimes inadvertently lock a website administrator into using an out of date CMS installation long after its expiry date, particularly if they no longer have access to their old developer (or sufficient funds to hire a new one).

We recently had a new client come to us with exactly such an environment, running an ecommerce store on OpenCart 1.5.5.1 — a version originally released over a decade ago. Unfortunately, their customers were reporting credit card theft and fraud after making payments on their website.

While we did uncover the source of the credit card theft we also found a very interesting authentication bypass injection in several of their files that was reminiscent of very similar malware that we wrote about quite a few years ago. Let’s dive in and take a look!

Dissecting the credit card skimmer

Before we get into the meat and potatoes of the authentication malware let’s quickly review the credit card skimmer that was responsible for the theft. Not unlike similar cases we’ve written about in the past, we found it lodged in two files related to payment processing on the website:

• ./catalog/controller/payment/pp_pro.php
• ./catalog/controller/payment/authorizenet_aim.php

Notice the large empty chunk lodged before the injection on line 204: This technique is used to avoid detection if someone is viewing the file in a text editor that does not have word wrapping enabled (so it will load off screen).

Remember folks, always enable word wrapping when investigating potentially suspicious files! Code that is designed to load off-screen is a major red flag and should be treated as suspicious.

Overall this is a pretty standard PHP-based backend credit card skimmer. It intercepts the following information from the processed order:

• Order ID
• Payment first name
• Payment last name
• Payment address
• City
• Postal code
• Zone/State
• Country
• Telephone
• Credit Card Expiry Month
• Credit Card Expiry Year
• Credit Card CVV2
• Credit Card Number

And exfiltrates it in two ways: One through cURL to the following exfiltration domain:

hxxp://anythingpro[.]net/get2.php

It also emails the details directly to the attackers’ email addresses.

All in all it’s a pretty straightforward skimmer, nothing too special about it. So now let’s turn our attention to the more interesting component of this infection.

Authentication bypass allows unauthorized webstore access

In earlier versions of OpenCart (such as the one that our client was using) the authentication mechanism that verifies the users logging into the admin panel is done with a single file:

./system/library/user.php

Needless to say, the importance of this file makes it an attractive target to attackers.

The clean code is pretty simple: It essentially checks whether the entered username exists in the database and if the entered password matches with the hash stored in the database. It uses two hashing methods for password checking: a combination of SHA1 and salt, and md5. Only users with a status of ‘1‘ (typically meaning “active” or “enabled” users) can proceed.

However, if an attacker can obtain edit-access to the file system then this authentication mechanism can be tampered with. In my colleague’s investigation from 2016 of a similar infection, the authentication code was simply commented out entirely, allowing the use of any user name or password to enter into the admin area:

In this most recent example the attackers were a little more creative. In addition to the verification that OpenCart itself does with checking the entered password against the stored hash in the database, it has been modified to allow the user in if the entered password matches the MD5 hash of 4975aa43a280c12ae76a807cf799a1a8.

So essentially the attackers have added a way to bypass the OpenCart authentication entirely by using a custom password of their own choosing, hardcoded into the authentication file. Since MD5 is a one-way encryption method it’s not possible to know what password they chose, but it seems to be an effective method to grant them sustained access without allowing other attackers probing the environment the same privilege.

Arbitrary file upload through account creation

The attackers also left behind another souvenir to give them continued access to the environment in the file responsible for account creation on the ecommerce website:

./catalog/controller/account/edit.php

Again, we see the same old trick of hiding the injection from view if word wrapping is disabled.

Similar to the authentication bypass, the injection specifies an MD5 hash (this time 66b6d63b9634e1159e53e29858de2c2d). This injection is triggered on the account creation page of the website. If the telephone number submitted matches the specified hash then a backdoor uploader file with the name of info.php gets dropped into the environment.

The dropped file in question is a very simple script which allows for arbitrary file upload:

So in the final analysis, this is a creative way for the attackers to maintain access by abusing an otherwise legitimate account creation page on the website.

In fact, this malware in edit.php appears to be exactly the same as the infection described in this post from Astra from 2018, indicating that threat actors are still recycling the same old malware to infect vulnerable websites using old versions of ecommerce platforms like OpenCart.

Keep your ecommerce environment patched

It is unfortunately not uncommon for ecommerce environments in particular to get “stuck” in old versions due to custom code, lack of development resources, or just wanting to leave things as they are because “it works” and are not aware of the security implications. Online stores which have been operating for quite a few years also tend to have massive amounts of products in their roster which can complicate migrations to more up to date versions.

Unlike WordPress, many other popular ecommerce platforms (such as OpenCart, Magento and others) are not as simple as a one-click update and require much more know-how and expertise to do it correctly. Moreover, not all themes and extensions in use on an older version are going to work on a new version, and it can indeed be tricky to get all of the products in the catalog properly migrated over. To migrate an old ecommerce installation to a fully patched, new version can cost thousands of dollars, and that’s not something all small ecommerce website owners have at their disposal.

It’s understandable that ecommerce website owners would shy away from this; after all they tend to be dealing with much smaller margins and profits than larger entities and need to prioritize website uptime and availability above all else. However, we can see from the example in this post and others that we have written about on our blog, that this can come at a steep cost. Websites that have been identified as a “common point of purchase” by financial vendors such as Visa or Mastercard can face serious financial penalties as well as harm to their reputation in the eyes of their clients.

As the security and threat landscape evolves over the years CMS platforms have had to adapt and change. These platforms have implemented new security mechanisms, better authentication practices and user roles, and additional security features such as two factor authentication. Website administrators who stay in old versions for the sake of convenience or cost savings unfortunately render their environments as low-hanging fruit for attackers and, by extension, place their clients and their own websites at risk of compromise.

If you believe that your ecommerce website has been infected with credit card skimmers or other malware and you need help, we have experienced analysts available 24/7/365 to clean up website malware and protect your store.