The recent breaches at Ticketmaster, British Airways and Newegg that have been attributed to the hacking group Magecart have many e-commerce merchants taking a closer look at any potential exposure. And rightfully so.

Several blogs have well documented the details of the credit card compromise. However, there is still a lack of detail surrounding how the attackers are obtaining access to the environments modify the static JavaScript files. Clearly a huge area of missing information. In each reported case, it seems that the attackers would have obtained access to the file systems where the files were hosted, or some portion of the development and deployment pipeline in order to modify these files.

The inserted code that provided the compromise of credit card data leverages the logical structure of the Document Object Model (DOM) to be able to access and manipulate anything on the page. This includes the ability to send data to a malicious entity behind the scenes of a normally operating payment page as in the case of these Magecart breaches. This is also known as formjacking. With access to the DOM, many common security measures are effectively bypassed. This includes the embedding of iFrames and even the implementation of browser-based encryption in order to better secure payment data upon collection from the customer.

Once the attackers gain access to the source code they own any data that you are collecting from the user.

To make things more difficult, today’s common web pages are loading dozens of scripts from many different locations. This includes scripts loaded from internal systems as well as from third party providers. Any one of these scripts has the ability to manipulate data elements that are being collected from the customer.

I believe that this type of attack will continue to grow due to the number of possible vectors of infection a given page and the value of the customer data that is at risk. I also believe that this will eventually drive changes with the PCI council’s approach to e-commerce guidelines and requirements. Hopefully providing more emphasis on server-based controls and a much needed focus on securing the source code and development pipeline.

What can we do to help reduce the risk of these types of attacks?

Secure the source code pipeline: So much of our technology world these days is powered by code, this includes infrastructure changes, automation and of course our applications. The entire code pipeline should be a focus for security controls to ensure the integrity of the code from source, to build to deployment. Consider implementing hashing checks throughout this process and alerting when hashes do not match. This provides a mechanism to ensure that what was developed at least makes it to the intended destination

Secure the origin servers: Once our servers get the validated source code we should have a way to periodically check the code that is running to ensure that it hasn’t changed. This can be accomplished through various scripting methods, automation tools or open source tools such as OSQuery.

Implement Subresource Integrity checks: The use of Content Security Policies in conjunction with Subresource Integrity can ensure that files that your pages fetch from anywhere (third party, CDN or internally) have been delivered without any changes. This is accomplished by delivering signatures of the known-good scripts that the browser verifies prior to execution. Once again it is important to note that if the attacker has access to the origin source code – all of this behavior can be modified.
The added measures of knowing that the code you authored is what is running on your servers and having visibility when that changes can help to reduce the risk of these type of attacks for your organization. Leverage automation as much as possible to ensure these measures don’t have a negative impact on the efficiencies of deploying often.