No, Panera Bread Doesn’t Take Security Seriously

tl;dr: In August 2017, I reported a vulnerability to Panera Bread that allowed the full name, home address, email address, food/dietary preferences, username, phone number, birthday and last four digits of a saved credit card to be accessed in bulk for any user that had ever signed up for an account. This includes my own personal data! Despite an explicit acknowledgement of the issue and a promise to fix it, Panera Bread sat on the vulnerability and, as far as I can tell, did nothing about it for eight months. When Brian Krebs publicly broke the news, other news outlets emphasized the usual “We take your security very seriously, security is a top priority for us” prepared statement from Panera Bread. Worse still, the vulnerability was not fixed at all — which means the company either misrepresented its actual security posture to the media to save face or was not competent enough to determine this fact for themselves. This post establishes a canonical timeline so subsequent reporting doesn’t get confused.

1. First, the proof that I reported this, and the beginning of the timeline. I reported this vulnerability in August 2017, which is shown by the following email exchange with Panera Bread’s Information Security Director, Mike Gustavison. After attempting to contact them through a generic security@panerabread.com email address (which bounced), Twitter and even LinkedIn and email messages to Mike Gustavison (whose information I found on LinkedIn), I was formally introduced by an industry contact who had a mutual connection.

In which I am accused of being a scam artist after sending a polite email informing a security professional of a security vulnerability in their software. Note that I do not, at any time in any email, solicit services or try to deceive.

I receive a PGP key, great.

I send the encrypted report, then follow up. Notice the days passing.

Following up again. More days pass. Finally an explicit acknowledgement. Note — still August, 2017.

I want to take a moment to say something important. I have worked internally as a security engineer responsible for fielding random security reports like this from the outside. I have also submitted reports like this to companies, in bug bounties and as a courtesy with no expectation of a reward. I have been on both sides of the table. The response I received is not appropriate whatsoever. There is never a reason to begin a conversation like that by being so defensive. I know people send lots of superfluous security reports, because I’ve had to receive them. But I’ve never started the conversation by being antagonistic — this is not an excuse for reacting like that.

Now, after I was reassured this would be fixed, I checked on this vulnerability every month or so because my own data is in there, which means I’m personally affected by it. So I personally know for a fact that it was never patched in the interim. And even if it was, that it would be fixed and inadvertently reintroduced is nearly as bad as not fixing it at all. But I held off on doing anything, deciding to let them proceed. Eight months go by.

2. Fast forward to today. I’m fed up with the lackluster response, so I decided to publish it. First I created a Pastebin page describing the vulnerability, to be used as a proof of concept. Then I email and Twitter DM both Troy Hunt and Brian Krebs with the Pastebin page, asking for their help to escalate this so it would actually be fixed, and telling both that I reported this over six months prior. The Pastebin describes the vulnerabilities as follows:

Also for the tech savvy, note `echo -n "my name is Dylan Houlihan helloworldfoobar" | openssl dgst -sha256` => 7682200f0cd27a4f1a3c2301941d959aae7abf89136c38a4f1ded4d2bb7a67d7

So this is just reiterating what I’ve already said at the top of this post. Then I gave two specific API endpoints to illustrate what I’m talking about as a one-click proof of concept:

That note there is very important, because it means that you don’t need to target any specific user or interact with them whatsoever to collect this information. You don’t even need to be logged in. You can just increment that number sequentially, and you’ll grab every single user in the database.

Krebs takes me up on this, and he proceeds to get through to the Chief Information Officer at Panera Bread as a pre-publish courtesy. Then he writes his article:

…which led to this:

Panera Bread’s ordering portal was down for an hour to patch the issue. By the time it came back up, news sites were already running with the story based on Krebs’ article and statements from the company. See if you can spot a familiar statement.

A company is incompetent enough to leave a gaping hole like this trivially open for eight months after initial notification, yet it’s competent enough to review it logs definitively within two hours of the publicity?

Again, “no evidence of intrusion”, which is parroted from Panera Bread.

This is just incorrect. Most people only ever read the headline, yet this one completely obscures the fact that Panera Bread sat on the vulnerability for eight months.

And there it is, in bold letters and emphasized in quotation — “Panera take data security very seriously and this issue is resolved.

But it wasn’t resolved! It was clearly, definitively, not resolved,despite the fact they clearly said it was:

Note the time (Eastern) — this is well after Panera was back up.

This discovery made this tweet by Krebs much more interesting:

So did they just make it up?

Then the flood gates were open. Krebs managed to find several more examples of the same exact vulnerability, indicating the company had not, in fact, resolved it:

That link demonstrates the same same vulnerability on a different API endpoint.

Righteous pun, for what it’s worth.

Again, same vulnerability, different API endpoint.

Then Krebs did more digging and found out that this vulnerability extends to an entire other application:

And the absolute kicker! Mike Gustavison, the Director of Information Security who I reported this to, used to work at Equifax from 2009–2013:

Check it out:

Obviously, Panera Bread couldn’t have known Equifax would be breached in 2013. But after all of the foregoing, does this seem quite so surprising?

After Krebs unleashed a flurry of counterexamples disproving that the vulnerability was actually patched, Panera Bread ended up like this again:

“Resolved”

But now it looks like this:

“Resolved”

Originally I was content to wait eight months for Panera to fix this on their own. But this is ridiculous. I’m not going to stand for reporting that sweeps all of this under the rug. While Panera Bread’s website remains down due to several specific examples demonstrating the “resolution” didn’t resolve anything, news reports are not updating this fact.

Until we start holding companies more accountable for their public statements with respect to security, we will continue to see statements belying a dismissive indifference with PR speak. In the words of Troy Hunt, when Panera Bread says “We take security seriously”, they mean “We didn’t take it seriously enough.”

UPDATE: This received more attention than I thought! I’d like to take the opportunity to add something to this. It’s easy to bully Panera Bread for this, but in my opinion we need to take Panera Bread’s actions as symptomatic of a much larger issue with security reporting and compliance. This is not a problem unique to any particular type of company. This has happened before and it will continue to happen. The lesson to take from this is the following:

1. We could collectively afford to be more critical of companies when they issue reactionary statements to do damage control. We need to hold them to a higher standard of accountability. I honestly don’t know what that looks like for the media, but there has to be a better way to do thorough, comprehensive reporting on this.
2. We need to collectively examine what the incentives are that enabled this to happen. I do not believe it was a singular failure with any particular employee. It’s easy to point to certain individuals, but they do not end up in those positions unless that behavior is fundamentally compatible with the broader corporate culture and priorities.
3. If you are a security professional, please, I implore you, set up a basic page describing a non-threatening process for submitting security vulnerability disclosures. Make this process obviously distinct from the, “Hi I think my account is hacked” customer support process. Make sure this is immediately read by someone qualified and engaged to investigate those reports, both technically and practically speaking. You do not need to offer a bug bounty or a reward. Just offering a way to allow people to easily contact you with confidence would go a long way.