The recent reported data leak at Panera Bread potentially exposed the personal information of anyone who had ever signed up for an account on the company's site. The vulnerability that caused the data leak was related to APIs on the Panera site, and security researcher Dylan Houlihan first reported the issue to the company in August 2017. Decipher spoke with Houlihan about how he discovered the flaw, the company's reponse, and whether there are larger lessons to be learned from the leak.
Decipher: How did you discover this issue?
Houlihan: I initially found the issue because I was doing research on companies with online delivery portals in the quick service restaurant (QSR) industry. Think Chipotle, Buffalo Wild Wings, Panera Bread, etc. I found that the login interface for Panera Bread’s website presented you with a name if you entered a phone number or email address into the username field before you logged into the account. So I found that odd, and looked into the dev console to see what the API was like.
Decipher: What was Panera's initial response?
Houlihan: It took about four days to reach Panera Bread. I tried an email to security@panerabread.com, Twitter, LinkedIn messages, email to Mike Gustavison directly, etc. Once I finally received an intro through a mutual connection, the initial response is exactly as was presented in the email screenshots from my Medium blog post.
Decipher: Did the company give you status updates on fixing the problem?
Houlihan: They did not give me any status on fixing it after the initial email thread screenshots. The email in which Gustavison told me that he was working on a fix was the last email I received from them.
Decipher: How complicated is the fix for this problem?
Houlihan: The fix should not have been very complicated. The root issue was that a backend web service containing this data was not checking that users were both authenticated and authorized for the data they were requesting through the API. The API endpoints themselves were not so much of a problem, it’s rather than the service being called to by that API should have been checking users’ session keys to ensure that they were associated with the data already. As a secondary measure, they should not have had integer account IDs for customers because those are easily enumerable. UUIDs, 32 digits or so with alphanumeric characters, would have been better and made the vulnerability less exploitable en masse.
"The larger issue with these kinds of APIs is that they need to be secured using an approach that covers the entire API."
Decipher: What kind of data was exposed and how many people were affected by this?
Houlihan: The data exposed included the full legal name, username, email address, home address, loyalty card number, credit card number (last four digits), dietary preferences, phone number and whether or not the person was part of an organization. As for how many people were exposed, there is a distinction to be made between exposure and access. Because the account IDs were integers, we could simply check number 37 million or so and figure out that at least that many customers were exposed. This part is pretty much inarguable unless Panera Bread comes back and says that a significant number of those accounts were simply fake. So that’s how many customers were exposed/at risk, and the data could be siphoned out of Panera Bread’s system in a fully automated and non-targeted manner. As for how many customers actually had their data accessed from this vulnerability, there isn’t any way to be sure. Both of us think the 10,000 number is extremely premature, and Brian Krebs has publicly speculated on his Twitter that that may just be the number they could see the day this was disclosed. It is suspicious that they had such a number ready to go within 2 hours of this going public. So if we’re being very charitable, we have to go along with what Panera Bread has publicly stated. The issue there is that there is no accountability for that number, meanwhile there is a lot of justification for questioning both their competence and thoroughness in reviewing access logs for the vulnerability. So succinctly: at least 37 million were affected/exposed, of that number we cannot say how many records were accessed and actively exploited.
Decipher: Is there a larger issue with exposed APIs like this?
Houlihan: The larger issue with these kinds of APIs is that they need to be secured using an approach that covers the entire API. Securing individual API endpoints is error-prone and inefficient. Rather, the authorization and permissions boundaries for these APIs should be designed at the service level; i.e. at the service the API is calling to, rather than haphazardly across individual endpoints. Unfortunately, API authorization bypasses are a very common type of security failure, especially as time goes on and the low-hanging fruit like SQL injection and cross-site scripting become less common.