API Security Need to Know: Lessons Learned From the Peloton Security Incident

By now most have heard about the Peloton data breach incident and no doubt the security team at Peloton is working long, hard hours to pull themselves out of this horrible situation. The damage is done but there are lessons we can, and should, learn from the incident. Peloton was one of the many different web-based service offerings that experienced explosive growth during the pandemic. Fitness buffs worldwide were forced indoors yet were still able to socialize while getting their workouts in. Their growth however had no impact on the security flaw – it likely existed from long before the pandemic began. So looking back what SHOULD peloton have done when the researcher first made contact.

Top OWASP API Security Vulnerabilities That Led to the Incident

The API vulnerabilities that led to the Peloton disclosure can be mapped to the OWASP API Security Top 10 vulnerabilities:

• API2:2019 Broken User Authentication
• API3:2019 Excessive Data Exposure
• API4:2019 Lack of Resources & Rate Limiting. Once discovered, a threat actor could scrape data for most Peloton users by enumerating various IDs in these vulnerable APIs.

Vulnerabilities and leaks like this are not new. Vulnerabilities like these have existed ever since APIs have existed, much earlier than the 2019 OWASP API Security Top 10 List which was published in 2019. For example, scraping personal information of a large customer population was seen as far back as 2014 when the Uber “hell” program scraped Lyft’s driver and customer data using APIs. Since then there have been many such high-profile leaks that have surfaced and made news. But for every high-profile case, there are many that do not get the same media attention. This is not a new problem, but it’s increasingly a widespread problem. Recent vendors that suffered similar challenges include John Deere, Experian, and ClubHouse. Why? APIs are typically connecting directly to a backend resource, like a database and oftentimes, they are not as secure as their traditional application counterparts.

As a security practitioner from the past, I can relate to the Peloton security team and what they have been going through for the past few months. Cequence Security’s threat research team has found similar API vulnerabilities in popular Zoom and WebEx video conferencing software, now ubiquitous in our in-pandemic life. We followed the industry standards in disclosing those vulnerabilities and worked with the vendors responsibly to make sure they were patched before the disclosure. These 90 days given by the security researchers can be challenging.

How to Protect APIs with Shift Left and Shield Right Approaches

So what is a security team to do when they are faced with a situation where a security researcher has found vulnerabilities in your business-critical applications. You have 90 days, and the clock is ticking. The answer – shift left while you shield right. Here is how I would approach the problem.

Engage with the researcher to validate the finding and in parallel, begin applying shift left techniques including:

• Patch all vulnerabilities. In Peloton’s case, this will involve,
  • Ensuring APIs can only be accessed by authenticated users.
  • Validate that enumeration techniques cannot be used against member and class IDs to yield personal information.
  • Ensure that profiles marked as private do not appear in search results.
  • Lockdown API response codes to make sure they return minimal information.
• Once the APIs are patched, Peloton should:
  • Implement a DAST-like tool to look for known vulnerabilities during the DevOps process and integrate it into the CI/CD pipeline to ensure that the vulnerabilities are eliminated before the APIs go live.
  • Conduct a thorough code review from a security point of view. Even consider bringing in external help for this if the team lack expertise in this area.
  • Coding APIs is different than coding a web app so it’s critical that developers and DevOps engineers have been given up-to-date security training.
• APIs are different from traditional apps. They include the transaction and often connect directly to a back end resource, like a user dashboard. So, looking forward they would need to pay close attention to the functionality of the API, what it’s supposed to do and who has access to the data. Then build test scenarios into their quality assurance plan that mimic said functionality – not just PEN testing, but functions. At runtime, a final check by security teams to ensure, in this case, that authentication is strong, data is not leaking and so on.

In many cases, these APIs are integral pieces of a business-critical application so they can’t be taken down while these shift left efforts are being implemented. In parallel, Peloton should strengthen their runtime security protections, something we call shield right, while shifting left.

Shield Right:

• Block any unauthorized access to APIs that require authentication by authorized users. This can be implemented at the edge or close to the APIs. Although it is best practice to keep these unauthenticated API calls out of your public-facing environment.
• Prevent scraping of member information using automated enumeration techniques. These attacks can come hot and heavy or low and slow, so it’s going to be critical that the solution chosen can apply consistent policies for both APIs and web-based apps.
• Look for runtime API security that will complement the security improvements that shift left efforts will bring. The most perfectly coded API is still susceptible to an (unknown) attack.

As the co-founder of Cequence, I do believe we could have helped Peloton avoid the mess they are in. I also believe we still can. Our API Spartan solution is the only offering that can apply consistent policies for APIs and web apps because it does not require ANY application instrumentation. Our latest product, API Sentinel protects public-facing and internal APIs at runtime, complementing shift left efforts and acting as a last line of defense.

See the latest version of Cequence API Sentinel in action in this short overview video: