British Airways has released no technical details on how attackers managed to get 380,000 people’s personal information – including payment card numbers – from their systems. I’ve done some reading, though, and wanted to share my thoughts – and those of the wider ethical-hacking community – on this kind of breach and try to explain, in layman’s terms, how this was possible.
Believe me, hacking a PCI DSS-compliant application is difficult
Sites like British Airways and Ticketmaster have to comply with the PCI DSS (Payment Card Industry Data Security Standard), just like the rest of our clients. If you work with the PCI DSS, you’ll understand what it takes to compromise an application, the cardholder data environment (CDE) and the database where card details are stored encrypted. It’s also worth noting that the card number is not stored with the CVV number (the digits on the back), making it all much more complex.
Believe me, it’s going to be remarkably difficult. But in the attack that compromised Ticketmaster (and most likely British Airways), the weakness was the JavaScript at the point of entry, where the user enters their card details on the website.
Everyone using JavaScript is vulnerable to cross-site scripting
JavaScript is code that is sent from a web server to your and makes the web page you are accessing functional, responsive and pretty. Most importantly for a hacker, it’s always executed on a user’s browser – which is what’s exploited in a common JavaScript attack called cross-site scripting.
When your browser loads a page, it downloads a number of files – often HTML, CSS and JavaScript. Most of the time, these files are downloaded from the same source (i.e. the same web server), but it’s also common practice to download them from a third-party library. For example, in order to embed Google ads into your application, you need to add JavaScript from Google’s servers.
Hackers targeted Ticketmaster’s third party
Ticketmaster (and, I suspect, BA) was using JavaScript from third parties on its site to collect customers’ data. In the breach, it was the third-party JavaScript code that had been compromised.
With the third-party JavaScript executing on every customer’s browser, when they inserted their card details, the rogue JavaScript sent a copy to an attacker-controlled server to be used for malicious purposes. This means that the attackers didn’t need to gain access to Ticketmaster’s and didn’t have to compromise Ticketmaster’s PCI-compliant systems they only had to compromise the small third-party company that hosted the JavaScript!
Enter: the penetration tester
This kind of breach is a prime example of how vulnerable any organisation is to the wrath of the criminal hacker. Yes, by demonstrating compliance with the PCI DSS’s requirements, you show your customers, stakeholders and competitors that your organisation takes data protection and security seriously, but it’s no good stopping there. To ensure actual security, it’s vital to assess the gaps in your security regularly and test how secure your systems and applications really are. This can easily be done with penetration testing, where an ethical hacker like me pretends to be the criminal hacker and attempts to find weaknesses in your security.
Our team is experienced in infrastructure and web application penetration testing, and can help you take all the necessary actions to protect your cardholder data, so you can be sure that your web applications aren’t vulnerable to the same threats that other, breached organisations have been.
Read more about penetration testing and the PCI DSS in our free green paper >>
