Sophos Cloud Optix
Greetings card maker Moonpig has closed its mobile apps to stop customers’ personal details from leaking out after learning of a vulnerability.
That vulnerability was discovered in August 2013.
No, that is not a new-year date-glitch typo: The hole has been open for almost 17 months.
It was discovered and reported to the company by developer Paul Price, who says he initially disclosed it to Moonpig privately on 18 August 2013.
What has Moonpig been doing since then?
According to Price’s responsible-disclosure timeline, after some email back-and-forth, the company blamed legacy code and told the developer they’d “get right on it.”
After 13 months, as of September 2014, the issue was still unresolved, but the company said the issue would be sorted “before Christmas.”
As of Monday, the hole was still open.
Price decided he’d given the company ample time to fix the problem, so he went public to force Moonpig to deal with the hole.
That did the trick – or, at least, it spurred Moonpig to take down its non-secure API.
On Tuesday, Moonpig took the API offline and tweeted that all is, and has always been, well with password and payment data:
We are aware of claims re customer data and can confirm that all password and payment information is and has always been safe.
According to Price, the vulnerability is found in the spot where Moonpig’s mobile apps communicate with its servers, also known as the application programming interface (API).
As Price describes it, rather than sending customer and payment data securely, as protected by customer ID and password, there’s actually no authentication taking place at all.
Instead, the API sends all requests as protected by the same credentials, regardless of what user is signed in.
The only way the API differentiates between user accounts is with the use of a nine-digit number, which it transmitted unencrypted.
All Price had to do to access another user’s account was to change that number and resend the request.
Customer IDs are sequential, he said, so it would be easy for an attacker to cook up a long list of valid customer IDs.
I hit my test users a few hundred times in quick succession and I was not rate limited. Given that customer IDs are sequential an attacker would find it very easy to build up a database of Moonpig customers along with their addresses and card details in a few hours - very scary indeed.
Price found that an attacker could impersonate a customer and then “easily” place orders on their accounts, add or retrieve payment card information, view saved addresses, view orders, and “much more”.
The information up for grabs, he said, included postal addresses, birthdays, email addresses, phone numbers, the last four digits of credit card numbers, and card expiry dates.
Moonpig says its apps will be offline for “a time” while it investigates the issue:
A message to our customers
You may have seen reports this morning about our Apps and the security of customer details when shopping with Moonpig. We can assure our customers that all password and payment information is and has always been safe. The security of your shopping experience at Moonpig is extremely important to us and we are investigating the detail behind today’s report as a priority. As a precaution, our Apps will be unavailable for a time whilst we conduct these investigations and we will work to resume a normal service as soon as possible. The desktop and mobile websites are unaffected.
Twitterlandia is pointing out that investigations that get under way after nearly 17 months are a teensy bit overdue:
@MoonpigUK investigations you should have done in August 2013, by the sounds of it.
…but better late than never!
Where do we draw the line? Responsible disclosure at 17 months is probably too long, and 1 month is probably too short. But, any number we pick is going to cause some to think “too high” while others think “too low”.
Perhaps it needs to be based upon the type of threat? A threat that’s both an EoP and a remote-control is obviously worse than either of them separately. But, does a critical threat warrant a significant lowering of the definition of responsible disclosure.
How do we (security practitioners) decide what’s “right”?
Think it is disgusting the amount of time MP left this vulnerability open!