The £60,000 fine earlier this year of Boomerang Video by the ICO is a definite warning shot to all SMEs - if you have a public website that processes personal data, you can no longer live in denial about the site's vulnerability to hackers. It doesn't matter who developed the application, ultimately the 'data controller' (Boomerang in this case) will be liable should the site be breached.
This is an interesting judgement for the penetration and security testing industry. With the ubiquitous GDPR just around the corner, surely it's payday all round?
However, there is a lot more to this story than meets the eye. This judgement and the associated fine were not based on a single failure but rather on a whole catalog of issues: a perfect storm of bad practice that could easily have been avoided.
Here are some of the key points from the ICO judgement:
The Application
The website was developed in 2005 by a third party company (“data processor”). Boomerang Video was unaware that the login page contained a coding error.
The website was (in internet terms) ancient and had what appears to be a very basic SQL injection flaw in its login page. This defect sat latent for 9 years until the site was eventually compromised in 2014.
However, Boomerang, who probably knew nothing about software development let alone SQL injection attacks, were held responsible for the breach, not the 3rd party developer. And whilst this might seem unfair (they were afterall assured by the developer that 'the payment security codes were not stored on the customer database') it is clear that 'data controllers' cannot use ignorance as a defense. More on this shortly.
The Compromise
On 5 December 2014, an attacker exploited this vulnerability by using SQL injection to gain access to usernames and password hashes for the WordPress section of the site. One particular password was shown to be a simple dictionary word based on the company’s name. The attacker then uploaded a malicious web shell onto the site's web server to further compromise the system and gain access to the personal data of individuals stored within.
There were actually two problems here. First, the SQL injection vulnerability but secondly, the application allowed users to enter overly simplistic passwords - even if the vulnerability hadn't existed, an attacker could have used a brute force attack to gain access to the site.
The Further Compromise
On 30 December 2014, the attacker was able to query the customer database and download text files containing 26,331 cardholder details (including name, address, primary account number, expiry date and security code). Although part of the primary account numbers were stored unencrypted, the attacker was able to gain access to the decryption key with ease, using information in configuration files on the web server. Industry guidelines prohibit the storage of the security code after payment authorisation.
As a rule, credit card details should never be stored locally on a server - not even encrypted, as in this case. Instead, an application must tokenize a card's details and use this token when processing payments through the gateway. (Any decent payment gateway will provide a tokenisation service as standard.) Since it is not possible to infer card details from a token, it means that tokens can be stored by the application and therefore used for future payment processing.
But the Boomerang website went further. Not only was it storing card details, it was also storing the decryption key in an application configuration file, in plain text. With minimal effort, the attacker was able to find this file and decrypt the associated customer data. The encryption was for all intents pointless.
This is all reminiscent of a well publicised compromise in 2012 where the keys were also stored on the same server as the data, allegedly in a file called 'encryption key.txt'!
PCI Compliance
Storing card details is not just ill-advised, it is a serious breach of PCI compliance. The fines for non-compliance with PCI certification can be crippling as stated in the PCI Compliance Guide:
The payment brands may, at their discretion, fine an acquiring bank $5,000 to $100,000 per month for PCI compliance violations. The banks will most likely pass this fine along until it eventually hits the merchant. Furthermore, the bank will also most likely either terminate your relationship or increase transaction fees. Penalties are not openly discussed nor widely publicized, but they can be catastrophic to a small business. It is important to be familiar with your merchant account agreement, which should outline your exposure.
Overall, Boomerang (or more precisely the 3rd party developer who developed and hosted their site) made a series of errors which should have been picked up in the 9 years between initial deployment and the eventual compromise. I’m willing to bet there were previous compromises that weren’t picked up in that time.
What Does This Mean for Small Businesses?
The above fines were based on the Data Protection Act 1998. As has been widely publicised the fines for contravention under the upcoming GDPR legislation have the ability to be significantly higher than this. The headline figure of 4% of Annual Turnover/€20M is unlikely to be enforced at this early stage but don't rule it out, especially for long running, significant cases such as this.
The ICO determined that the third party company that created the application were deemed to be the “data processor”. This term has special significance in the upcoming GDPR legislation as the processor may now be held jointly liable for security breaches such as this. Basically, if you develop, manage or host applications that process personal data, you can no longer absolve yourself of shoddy practices.
So what can you do? Well, here are some immediate but essential steps you can take today:
-
Familiarise yourself with the OWASP Top 10 and do everything in your power to minimise these risks. It doesn't matter whether you are 'data controller' or 'data processor', you must treat web application security as a priority one concern.
-
Perform a data audit and data impact assessment of your systems. What data do you have? Why do you have it? How is it stored? How/when is it deleted from your system? Act on the data which you are storing and minimise it.
-
Use an automated security testing service like Detectify to identify potential security issues by simulating hacker attacks on your application. This will help you understand potential issues at a high level and can prove to be extremely valuable.
-
Perform a threat modelling analysis of your application. This is a quick, effective way of helping you understand where to focus your security efforts. Beginning this process will also assist a security tester when you do get the opportunity to work with them.
-
Work with an independent security expert who can help mitigate risk without prejudice (as Instil does with its own software).
The bottom line here is that you cannot continue to plead ignorance when it comes to web application security. If your company manages or develops software that processes personal details then denial is not a defence.
