noun_Email_707352 noun_917542_cc Map point Play Untitled Retweet Group 3 Fill 1

PCI and the return of Javascript supply chain attacks

Timo Ahomäki / September 13, 2018

In February this year, I wrote about the perils of Javascript supply chain, and how compromised external libraries were used to plant crypto currency miners to browsers of visitors of a large number of UK government websites. I also wrote about some techniques to prevent this from happening to your visitors.

What prompted me to revisit the topic now, was the recent hack at British Airways website that resulted in criminals walking away with full credit card information and other personal data of some 380 000 customers who had booked flights between the 21st of August and the 5th of September. This breach - like the breach of Ticketmaster UK earlier this year, likely work of the same actor referred to as Magecart - made use of a very similar Javascript compromise to that I discussed in February. 

This time, however, there is a twist. While the crypto currency miners were planted on plain web sites in the open internet, the breach at BA affected a secure payment page behind customer login.

The BA secure payment site, like many others like it, contains in addition to the actual payment functionality a number of features related to user experience - such as accessibility as was the case in the UK Government sites - as well as components for various tracking purposes. According to a technical report by threat intelligence company RiskIQ, the targeted library in the BA hack was Feedify, a javascript library used to enable web push messaging. But it could have been any of a number of libraries frequently linked to such pages.

A quick scan of a few airline and hospitality websites reveals, however, that most payment sites include a host of linked external libraries. On a secure credit card payment page, presumably falling under the PCI-DSS compliancy regime. 

Now, if this is not worrying, then I do not know what is. As we discussed in February, and as was again displayed with the BA breach, detecting a compromised external library is very difficult even in the best of circumstances. Moreover, having dynamically linked libraries on a credit card payment page begs the question if all these libraries and their delivery mechanisms really are vetted to be PCI-DSS compliant.

And of course, they are not. But they should be.

At minimum, security researcher Kevin Beaumont, among others, recommends organizations to have an inventory of every Javascript library used in the payment flow, and to regularly (and automatically) audit the changes to these libraries. Or better yet, in addition to frequent audits, use the two techniques suggested in my February post; Sub Resource Identity (SRI) and Content Security Policies (CSP). 

As discussed in the previous post, implementing the necessary controls is a bit of work, but I’m sure the alternative is not that much more pleasant. By limiting the functionality on the payment pages to a minimum, and by rigorously enforcing the integrity of the code in use, you can avoid being the next in line for exploitation by cyber criminals. 

Do you want to know more? Get in touch with me and my colleagues!

Timo Ahomäki
Tieto alumni

Timo Ahomäki has over 20 years of international portfolio development experience in telecom and cyber security industries. Before joining Tieto, Timo was the CTO for an international software company specializing in telecom Operations and Business Support infrastructure.

Share on Facebook Tweet Share on LinkedIn