The Peloton API Security Incident & Data Breach: What Happened and How You Can Protect Yourself

What do you do when your exercise equipment leaks your personal information? Why is exercise equipment storing sensitive data, or more accurately, how do associated services make use of APIs to get to that data? And how might such APIs inadvertently leak personally identifiable information (PII)? These questions and more arose after the latest case of a leaky API reared its head with Peloton a couple weeks ago.  

A security researcher and consultant for Pen Test Partners, Jan Masters, found that he could make unauthorized requests to back-end APIs used by Peloton exercise equipment and related subscription services. Querying the Peloton API endpoints returned a great deal of user data, much of which qualified as PII and resulted in privacy impacts for Peloton customers. The leaked data included user IDs, instructor IDs, group membership, location, weight, gender, and age. The back-end APIs were used by the Peloton web and mobile applications as a companion to the Peloton exercise equipment to book classes and provide workout statistics. Peloton ultimately remedied the API issues after an initial misfire with vulnerability disclosure and remediation process. It’s unclear how many Peloton customers had their private information disclosed.

The incident highlights the prevalence of modern application design, where back-end APIs provide data and functionality to a number of front-end applications. It also spotlights how those same back-end APIs might lack appropriate authentication and authorization, leak sensitive or private data, and be directly targeted by attackers. Front-end API consumers include web applications executing in user browsers, mobile applications running on smartphones or tablets, and embedded code powering connected IoT devices. The last of these consumption scenarios is also sometimes referred to as headless browsing, machine-to-machine communication, or direct API communication, but the result is the same — code that exercises (no pun intended) an API to provide data or functionality to an endpoint device.

Details of the API weaknesses

The leaky APIs from Peloton exhibited the following weaknesses:

• Broken authentication
• Broken object level authorization
• Excessive data exposure

Broken authentication

When the security researcher initially discovered the Peloton APIs and prior to disclosing the vulnerability, Peloton had no authentication in place. Any user or attacker with Internet access could query Peloton APIs directly and obtain volumes of PII. This specific API issue maps directly to OWASP API2:2019 Broken User Authentication. Unlike some incidents where we see authentication is insufficient or weak, in this case, the company had no authentication in place at all. Simply knowing the API endpoint URL and how to query it allowed anybody to obtain the data. 

The broken authentication flaw was present in multiple API endpoints, which were as follows:

1. Workout details API
2. User search API
3. GraphQL data access APIs

Workout details API

The URL of the vulnerable API endpoint was https://api.onepeloton.co.uk/stats/workouts/details. This particular API endpoint provided personal details about Peloton workout participants. 

What follows is an example of an unauthenticated API request that the Peloton web application generated automatically, which was, in turn, intercepted by the researcher: 

The following screen capture shows the resulting API response which included PII for Peloton users (some of the sensitive data is masked to protect the identity of the individual):

User search API

The researcher also found a Peloton API endpoint that could be queried to find other Peloton users. The URL of that API endpoint was https://api.onepeloton.com/api/user/search/.

An example of an unauthenticated API request that could be used to find other Peloton users was as follows:

The resulting API response returned the user ID of a given Peloton user, along with some other personal data as seen here:

It’s important to note that this API could be used by an attacker to determine if a Peloton user existed and obtain the associated user ID. Once attackers had this information, they could query the workout details API to gather full details on a given Peloton user. 

GraphQL data access APIs

For the trifecta of broken authentication, two GraphQL API endpoints used by the front end also provided user data and leaked PII. Those API endpoints were gql-graphql-gateway.prod.k8s.onepeloton.com and gql-graphql-gateway.prod.k8s.onepeloton.co.uk. 

An example request sent to the US host for the GraphQL API endpoint can be seen here:

The resulting API response returned the ID, username, and location of a given Peloton user as seen here:

Note that these screen captures reveal another critical exposure — the HTTP headers included other information disclosures. We know that this endpoint was likely hosted in Kubernetes infrastructure based on the URL and host header, since K8s is the shorthand for the Kubernetes container platform. And the GraphQL infrastructure is likely powered by Apollo as indicated by the X-APOLLO-OPERATION-TYPE header. Given this level of detail, an attacker would likely pivot to attempt other infrastructure attacks. It’s also possible non-production instances of the GraphQL endpoint would follow similar URL naming conventions and might be less protected or monitored, providing another fruitful area to abuse the Peloton APIs.

Broken object level authorization

When the researcher disclosed the vulnerability to Peloton, the company confirmed receipt of the issue via email but provided no further communication. Eventually the deadline for response and remediation as outlined in Peloton’s coordinated vulnerability disclosure program passed. When the researcher checked the APIs again, he found that Peloton had restricted access to the back-end APIs to Peloton members. Members, as a reminder, include those customers who purchased exercise equipment or subscription services. Any user could subscribe to the monthly service for a trivial dollar amount. 

Though Peloton finally implemented authentication on these API endpoints, the company failed to implement authorization. Peloton effectively traded one flaw, OWASP API2:2019 Broken User Authentication, for another, OWASP API1:2019 Broken Object Level Authorization. Any authenticated Peloton user could view the data of another Peloton user, regardless of whether the user was authorized to do so.

Excessive data exposure

This API flaw is a result of returning too many details in an API response with the intent that such data would be filtered by the front end. This flaw is defined as OWASP API3:2019 Excessive Data Exposure. Such design flaws are often a byproduct of disconnected, siloed back-end and front-end development. Peloton would need to review the complete system design and the resulting threat models, or it would need to invest time in application security assessments to uncover such defects that lead to excessive data exposure, often of sensitive data. 

Another example of a Peloton API response with excessive data exposure can be seen here:

The API responses include many forms of PII, resulting in clear privacy impacts to Peloton customers. Peloton user privacy controls also did not restrict what data one could query for in the APIs. API requests for data on Peloton user profiles that were marked as private still returned private information and PII.

Top recommendations to avoid an incident similar to the Peloton leaky API

Specific recommendations to avoid the API security incident at Peloton include:

1. Assume your APIs are a known quantity and can be called directly. Security through obscurity is never a good security strategy. Attackers will find the URLs of API endpoints and how to exercise them by sniffing application traffic and reverse engineering front-end code. While the bar for attackers to discover APIs in mobile or IoT channels may be slightly higher than web channels, it’s a trivial jump at best. Attackers also move between channels and target the most vulnerable path. If you have weaker security controls for a particular channel, it’s always a prime attack vector. 
   

2. Always authenticate and authorize your API consumers. OWASP lists broken authorization and authentication as the highest priority flaws in the API Security Top 10 for a reason — these API flaws are highly prevalent and destructive. You should always authenticate API callers where data or functionality is sensitive or private. It’s also critical that you continuously validate authorization of authenticated users to ensure they are entitled to given data or functionality. 
   

3. Provide only the data that is necessary for a front end to function. Attackers easily expose the API communications of front ends through the use of intercepting proxies on endpoint devices they control. This reality holds true even in cases where encrypted transport — such as TLS — is in use to protect data in transit. 
   

The Salt Security API Protection Platform is built to stop attackers that aim to abuse API weaknesses including broken authentication, broken object level authorization, and excessive data exposure. These weaknesses are core traits of leaky APIs, which attackers regularly target to scrape data.

Have a vulnerability disclosure program and stick to it

As we saw with the recent Experian leak, organizations must keep security researchers on their radar in addition to other attacker archetypes. Organizations suffer significant brand damage when a researcher finds and discloses an issue, particularly if the disclosure experience is poor. The time it takes to respond to a reported security issue is critical. Expectations must be clearly set for the entire process from initial disclosure, through remediation stages, and to final publication. While Peloton scored points for having a documented vulnerability disclosure program, it didn’t stick with its own processes in this incident. This incident handling included some misfires and resulted in extra frustration for the security researcher. In many cases, a researcher would opt to go public with findings when communications with the vulnerable entity go dark. 

Peloton’s statement regarding the incident and disclosure process was:

It’s a priority for Peloton to keep our platform secure and we’re always looking to improve our approach and process for working with the external security community. Through our Coordinated Vulnerability Disclosure program, a security researcher informed us that he was able to access our API and see information that’s available on a Peloton profile. We took action, and addressed the issues based on his initial submissions, but we were slow to update the researcher about our remediation efforts. Going forward, we will do better to work collaboratively with the security research community and respond more promptly when vulnerabilities are reported. We want to thank Ken Munro for submitting his reports through our CVD program and for being open to working with us to resolve these issues.

Discounting the risk of scraping is disastrous for organizations

The company line that incidents like this Peloton data exfiltration case are “not a data breach” simply doesn’t hold water. Customers don’t care about the fine line between a breach and an abuse of an API. The explanation that the APIs involved are doing what they are intended to do, and the resulting problem is the fault of malicious API callers abusing those APIs, is simply not a defensible position. When a leaky API exposes sensitive and personal data, the event clearly compromises user privacy. When security researchers uncover a leaky API and disclose the findings, taking a “this is not a breach” response not only causes brand damage but can also expose an organization to other regulatory penalties. GDPR is a perfect example of this reality — this EU-specific regulation aims at protecting the privacy of EU citizens that reside or consume services anywhere. GDPR impacts US companies if they operate globally or do business with EU customers. 

A security researcher finding and disclosing an issue can also be a best-case scenario for an organization, as opposed to waiting for bad actors to find them. When attackers identify these types of leaky APIs, they enumerate the endpoints and scrape them for as much data as possible. Sensitive and private data often become part of other fraud activities and are frequently resold on the dark web or other underground markets.

Conclusion

The Peloton case marks yet another excellent example of a leaky API.  The API flaws ultimately trace back to inadequate authentication and authorization, which resulted in exposure of customers’ private data. These failings are common, particularly as organizations embrace digital transformation and as multi-channel application designs look to support many consumer types. In this incident, we have a mashup of web application, mobile application, and connected home device all interacting with web APIs to provide data and functionality. 

Unfortunately, while Peloton did fix the API flaws quickly, the company didn’t adhere to its own documented vulnerability disclosure program. This misstep resulted in escalation and disclosure within mainstream media by the security researcher and the pen test firm. Peloton was fully transparent after the fact, acknowledged the failures in the process, and aimed to do better after the incident. 

If you’re interested in seeing the Salt Security API Protection Platform in action, contact us for a customized demo today!

Sources:

https://techcrunch.com/2021/05/05/peloton-bug-account-data-leak/

https://www.pentestpartners.com/security-blog/tour-de-peloton-exposed-user-data/