It’s a fact of life, the moment you log onto the Web, you are giving up some measure of your privacy. Using platforms and products from giants such as Google, Amazon, Facebook and the like ensures even less of it. However, all companies have an obligation to protect user data as best as they can in accordance with their respective terms of services. When that data is compromised it’s reasonable to expect said companies to React quickly to resolve the vulnerability. According to a post from security professional Dylan Houlihan, Panera Bread apparently did not feel the same way and offers a case study in the wrong way to respond to a vulnerability.
The case began in August of 2017 when Houlihan discovered and reported a vulnerability on Panera’s delivery site that allowed anyone to gain bulk access to any registered user’s full name, address, email, phone number, last four digits of a saved credit card, username, birthday and food/dietary preferences. The first misstep for Panera occurred when Houlihan tried to reach out to them via their email@example.com email address only to have his email bounce. The lesson there is that if you take security seriously, you should give your users a way to contact you about any security issues.
Houlihan continued on until he was able to get in touch with Panera Bread’s Information Security Director, Mike Gustavison. After initial contact and follow up for a week, Gustavison replied with acknowledgement that they were working on a fix. However, when Houlihan made periodic checks over the following eight months, he found that no fix was ever made or if it was, that the error got reintroduced. Lesson number two is that if your users let you know of a security vulnerability, you should prioritize finding a fix for it instead of treating it like something to get around to when time allows.
Eventually Houlihan created a Pastebin page (since taken down) describing the vulnerability, to be used as a proof of concept. In the Pastebin he included two API endpoints that demonstrated what information could be gathered. For the Endpoint that worked on user account IDs, he showed how Panera used sequential integers for user account IDs meaning that you could increment the account numbers to get access to each user’s information. Further, the API had no Rate Limiting of any kind put in place allowing you to gather the entire database’s worth of account info. Lesson three, and this is not new, use rate limiting.
Now we’ve seen data breaches in the past where a lack of rate limiting came into play. One notable one was this past fall when Equifax exposed personally identifiable information (PII) of over 143 million people. Here’s the kicker, the Senior Director of Security Operations at Equifax back in 2013 was none other than Mike Gustavison. The same Mike Gustavison who is now heading Panera’s security.
Lastly, after the news had broke, Panera released a statement saying that they “take data security very seriously and this issue is resolved.” However the vulnerability still wasn’t resolved! Brian Krebs, a journalist specializing in security found several more examples of the same vulnerability on different API endpoints and different Panera applications.
Hey @panerabread : before making half-baked statements to the press to downplay the size of a breach, perhaps you should make sure the problem doesn't extend to all other parts of your business, like https://t.co/rSpkwc3y1v, etc. Only proper response is to deep six entire site
— briankrebs (@briankrebs) April 2, 2018
Lesson four then goes back to lesson two, if someone tells you that you have a vulnerability with your API, go ahead and fix it. Further, don’t lie about fixing it, developers are really good at figuring that out.