No, Panera Bread Doesn't Take Security Seriously

https://medium.com/@djhoulihan/no-panera-bread-doesnt-take-security-seriously-bf078027f815

Dylan Houlihan

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.

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 mailto: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` =>
7682200f0cd27a4f1a3c2301941d959aae7abf89136c38a4f1ded4d2bb7a
67d7

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 20092013:

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:

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.
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.
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.
Posted on RetroBBS II

First of, thanks for sharing.
Secondly, I agree with you that this behaviour will not
change unless it starts to hurt (for the company doing it).
Today, it does not hurt them at all.
Thirdly, why are you still their customer ? This would have
been my response after > 2 weeks of no reaction. This will
hurt them the most.

Posted on RetroBBS II

Yes it most likely won't change. It's easier to hide the
issue than address it.

The way the financial industry works also is that the one
whos data was stolen ends up getting screwed, not the ones
who didn't secure the data.

Note: I posted the article, but I did not write it, it was
written by Dylan Houlihan

Posted on RetroBBS II

>Note: I posted the article, but I did not write it, it was
>written by Dylan Houlihan

lol. I read that as an original post.
Posted on: def3.i2p