Here is an article I was asked to write for a magazine regarding the Moonpig incident, which was republished on the work blog here: http://www.mtibytes.com/post/Sweating-Like-a-Moonpig-and-Other-Data-Security-Lessons
It has now been widely publicised that Moonpig, one of the UK’s largest personalised greeting card companies, had a major security vulnerability in its website, which remained unfixed for 17 months. Despite being notified, the company chose not to act for the better part of 2014, leaving the personal data of 3 million customers (including partial credit card details) exposed to the public.
The vulnerability in question is fairly basic and relates to the way individual users are authenticated. For months, the lack of authentication in place allowed access to any users’ accounts by connecting with the Moonpig servers via the API and simply tweaking the customer ID numbers sent in API requests. Without any further authentication, this tactic could have been replicated by hackers 3 million times with a simple piece of software in order to steal personal data, including names, addresses, and credit card details.
One critical lesson from Moonpig’s vulnerability is that data security does not end when the user logs off. Often all that is needed to take control of someone’s entire digital life is a billing address and the last four digits of an associated credit card number. Once a threat is identified, inaction on the part of the service provider can prove just as devastating as causing a security hole in the first place. Moonpig may not have directly leaked their customers’ data, however they made that data directly accessible to any eager parties, capable of writing some simple code.
The ramifications aside, Moonpig severely jeopardised its customers’ trust. As custodians of customer data, companies that process payments have an ethical obligation to fix basic security issues within a reasonable timeframe. Moreover, they have a legal obligation to protect that data. In the case of Moonpig, Price should have contacted an enforcement authority like the Information Commissioner instead of going public with the vulnerability.
Moonpig’s API vulnerability highlights an area that is poorly documented and routinely overlooked in security testing, but there are easy steps that can mitigate against this threat, such as patching operating systems, applications, and known vulnerabilities. When developing code, many organisations believe that a code review or penetration test is sufficient on application completion, however developed applications are often a work in progress, with many subsequent bug fixes, code changes, additional features, and functions added. It is thus necessary to have on-going code reviews during the development cycle, with a code review and penetration test on completion at each stage. In effect, the code review has to be as agile as the development itself.
Many threats and vulnerabilities reside within organisations for months or even years before discovery, and when they are revealed, it is often a third party that blows the whistle. Even after several warnings of the code vulnerability within its Android application, Moonpig seemingly chose to do nothing to resolve the issue. From banks to greeting card companies, when customers give out their data they trust that the vendor will take appropriate measures to encrypt and safeguard their personal information. As the threat landscape changes, many organisations do not seem to have the agility to uphold this implicit trust.