Not long ago, Peloton — the well-known manufacturer of high-end exercise equipment — experienced an unfortunate incident where a long-lasting security vulnerability in Peloton’s API made private user data public. Everything from a rider’s name, age, gender, and location to their workout statistics were made available for any hacker to see, even if that Peloton user had made their profile private.
Around that same time, the company also experienced a series of treadmill product recalls. In conjunction with their failure to adequately address the security breach issue, Peloton shares dropped by more than 13% in 2021.
Regarding the user data exposure, it’s worth diving into what happened as it’s a rather typical API-related security issue with implications for enterprise API management. We’ll provide some context behind the dynamics of the Peloton system first, as well as detailing other similar examples of leaky APIs at Parler, Experian, and Facebook.
The basic operations behind the Peloton system
Born out of the idea to bring exercise classes into one’s home, Peloton started in 2012 with a prototype bike and has since evolved into a fitness sensation with an expanded product line, a growing team of studio locations and instructors, and an ever-growing user base.
When people were suddenly confined at home during the Covid-19 pandemic, the sales of Peloton stationary bikes and treadmills soared. According to one CNN article, Peloton announced a quarterly profit in 2020 — the first in the company’s history. The business saw a 172% increase in its at-home fitness equipment sales, and over 1 million people had subscribed to its streaming classes.
The combination of high-quality exercise equipment and an immersive digital experience that includes subscription services for guided workouts and classes has made Peloton stand out in the at-home fitness industry. Based on Peloton’s model, the stationary bikes and treadmills must be online to operate, and the company features companion mobile and web applications for added user convenience.
Application programming interfaces (APIs) are necessary ingredients for IoT services such as Peloton’s. They are the access points that enable the equipment and the user-facing applications to access information on Peloton’s servers.
But as we’ll see, when improperly secured, APIs can spring a so-called leak.
The technology failure
In Peloton’s case, the APIs in question were not meant to be accessed by someone else’s applications. APIs can be classified as private, partner, or public APIs — and Peloton’s were designed to be private. The intention was that only Peloton applications (either on their equipment or within their user-facing apps) could access the APIs.
At the same time, Peloton’s APIs still needed to serve the higher goal of being reachable by equipment and users worldwide. And so, the APIs needed to be exposed externally, as opposed to internally (for example, just on a company’s private, protected intranet.)
At first, the pull between private and external access may seem contradictory. But, this combination of private/external APIs makes a lot of sense and is used quite widely by companies today. As more connected systems and apps are developed, they need to communicate with APIs meant to be accessible only to them. These APIs have to be exposed externally because they aren’t just accessed from within a company’s private intranet.
In the Peloton case, the vulnerability — first discovered by security research firm Pen Test Partners — allowed API requests to access the profile information of Peloton users. With millions of customers worldwide (2.49 million subscribers as of September 2021), any person in any location could access the profile information of any users on the Peloton platform.
Parler’s API breach and the OWASP Top Ten
Another high-profile example of these vulnerabilities is the Parler API breach. The January 6, 2021 storming of Capitol Hill led to closer inspection of Parler, the conservative social media platform that had been used to discuss and coordinate the riots. In a politically-charged move, AWS shut down hosting for the site soon after, but not before many individuals – including journalists, archivists, and hacktivists – had scrambled to scrape data from the site, exposing severely inadequate API security.
The leaky API left messages, photos, videos, and even geolocation data publicly exposed, demonstrating six of the top ten most common security issues with APIs.
Breaches like this are often caused by a general lack of awareness of API security, and the Open Web Application Security Project (OWASP) Security Project lists ten top issues that help make sense of where things tend to go wrong. They are:
- API1:2019 Broken Object Level Authorization
- API2:2019 Broken User Authentication
- API3:2019 Excessive Data Exposure
- API4:2019 Lack of Resources & Rate Limiting
- API5:2019 Broken Function Level Authorization
- API6:2019 Mass Assignment
- API7:2019 Security Misconfiguration
- API8:2019 Injection
- API9:2019 Improper Asset Management
- API10:2019 Insufficient Logging & Monitoring
I delve much deeper into the Parler API leak and the OWASP top ten with my colleague, Isabelle Mauny, Field CTO and co-founder of 42Crunch, in this blog post.
API vulnerabilities open doors for hackers
Peloton’s vulnerability opened up the door so hackers could retrieve information about specific users and search for users matching certain criteria. What’s more, it was possible to retrieve information about users who had set their accounts to private, assuming that this would prevent any of their data from being viewed by others.
At this point, the API leak was typical to many others we’ve recently seen — the likes of which include other big names like Venmo and Facebook. In these cases, companies assumed that a private API does not need to be secured. But that’s not the correct answer.
If a private API is externally accessible, it absolutely has to be secured. (In fact, it’s worth noting that companies are increasingly securing internal APIs as well because many networking breaches lead to attackers gaining access to private intranets.)
Recognizing the increasing importance of API security, Gartner recently established API security as its own category of securing platform services. While WAFs and gateways protect platforms from predefined, known attacks, APIs are a prime target for hackers and require dedicated protection to eliminate security gaps.
Because APIs are unique to individual organizations, businesses need to have a detailed understanding of API behaviors to navigate the appropriate security measures effectively.
The API leak was first reported to Peloton on January 20th, 2021. The company was quick to react, responding to the report just a little over a week later, on February 2nd.
The fix, however, was grossly inadequate. It simply limited API access to authenticated users, which meant that anyone with a Peloton account (of which there are already millions, with an open door for anyone new to sign up for an account) could still access that user data.
When we say that the initial fix was relatively quick, it’s important to understand why that was the case and where the solution fell flat. Peloton relied on its apps (both on the bikes and its user’s phones) to essentially hide the private information of others. Meanwhile, the APIs themselves remained exposed and open to risk.
From a configuration perspective, it’s relatively easy to customize an API to meet one’s needs. Peloton configured theirs so that certain conditions had to be met before access was granted, with an authenticated user token being one example.
Yet, to properly hide information that shouldn’t be exposed through the API (such as private account details), the application code to implement the API has to be changed. Generally speaking, this is a more complex, time-consuming process as development teams need to first map out and implement the updates. Then the code has to be put into production (or released to the servers) to fix the security issue.
The process failure
This is the point where Peloton ran into a process failure on top of the technology failure noted above. Rather than labeling the initial reaction as a fast band-aid for the situation, the company appears to have considered the security issue resolved. This is a sign of a reporting and issue resolution process that is not properly designed or managed.
The security researchers who initially discovered and reported the vulnerability did not get any updates from Peloton after the initial fix was implemented. Following a 90-day wait period, the researcher contacted a journalist who reached out to Peloton on his behalf.
From there, things escalated. At that point, the process failure on Peloton’s side was likely corrected, and the open API issue was addressed. It was seven days after the researcher issued his report that the leaky API security problem was deemed fixed, and it seems as though the data leakage through their APIs has been stopped.
In a statement to TechCrunch, a Peloton spokesperson shared their perspective on the issue:
“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.”
Given that millions of people use Peloton — a list that includes many high-profile Hollywood celebrities and reportedly even U.S. President Joe Biden — the reported vulnerability should have been fixed long before the three-month mark.
While communication issues may have contributed to some degree, it seems likely that a lack of understanding of core elements of enterprise API management is also to blame. (And to that end, it feels like this might not be the only API-related issue Peloton has.)
Ideally, this security incident has prompted the company to perform a thorough internal security review that checks for potential vulnerabilities — either with the support of their IT team or a third-party security assessor — and overhaul current processes to prevent future security attacks. While such assessments and updates come with a price tag, the fallout of another security breach is far more costly than these protective investments.
What we can learn from high-profile API leaks
This is not the first time an API leak narrative has played out, and unfortunately, it won’t be the last. While many organizations are quick to embrace the potential and possibilities of connected devices and apps, they are often slow to ensure all the right technology and processes are in place to make them secure.
Technology not only means understanding APIs in terms of the differences between private, partner, and public but also understanding that these differences are not the same as the internal and external variables. An API strategy and a well-managed API management platform have to be in place so the teams exposing APIs to anybody will be able to perform a thorough security review before they roll out certain API designs.
The right API management solution should provide the protection, assurance, and proven path to fast-track your digital business initiatives and ensure the security of your APIs, finding and fixing vulnerabilities before they evolve into a costly, publicized issue.
While the cost of treating API security seriously might seem unnecessary at first, the steady stream of API-related security problems shows that ignoring API security comes with considerable risk. Sandy Carielli, a principal analyst at Forrester, elaborated on this point in a recent TechRepublic article:
“If you are making APIs available, you have to secure them. You can’t depend on customers, external partners, or other people making the API call.”
Here’s some food for thought: According to an IBM Security X-Force report released just last year, two-thirds of cloud breaches are tied to misconfigured APIs. And upon review, only 6% of companies reported no API-related security issues over the past 12 months.
Process means that companies must handle reported issues so that the impact and scope of reported security vulnerabilities are fully assessed and that processes are enacted to make sure all problems are resolved promptly.
Security standards should be put in place (the OWASP API standards are a good starting point) while completing a thorough review of authorization and authentication permissions and monitoring what has been deployed in the past. The goal is to find flaws and then implement controls to write secure code for the future.
The cost and benefits consideration is the same on the process side as on the technology side. While investment in API security might seem like unnecessary overhead expenses, the failures of organizations like Peloton or Parler show that poor processes can result in even more significant issues down the road that lead to further costs and reputational harm.
Looking ahead to the future
In the case of the Peloton security breach, it’s unclear if API issues are to blame for the hackers’ ability to exploit data — and without a solid enterprise API management strategy, there may be no way for the company to find out. In the meantime, we can hope for the best and be grateful that this vulnerability did not include more problematic data such as credit card numbers or exact home addresses.
Other companies have not been so lucky. Look no further than the Experian data breach of 2021, when a security researcher discovered a weakness with one of the consumer credit bureau’s partner websites. A lender’s loan eligibility lookup page invoked an unsecured Experian API that let anyone look up the credit score of tens of millions of Americans just by supplying their name and mailing address – information that is publicly available.
Here too, the response was less than satisfactory: the one leaky lender was blocked from using the API, but the researcher who discovered the leak suspects there may be hundreds or even thousands of companies using the same API.
The important lesson is that many companies still do not treat APIs as first-class citizens of the business. Having an explicit enterprise API management strategy and an internal API program to implement the procedure can help avoid costs to companies from a monetary and brand standpoint.
Per IBM’s latest Data Breach Report, the average cost of a data breach in 2021 reached an all-time high of $4.24 million. Organizations that lagged in security were noted as enduring higher costs versus companies with a more mature security posture.
Not every person in an organization has the expertise to fully understand how APIs work, how to design them, and how to manage them securely. But today’s connected companies should have structures in place to ensure API design, implementation, and management are properly done. While this will help ensure that backdoors to APIs are closed, and proper permissions are established, your business will also have the means to operate more efficiently and flexibly.
These security breach incidents were likely an excellent wake-up call for those involved to revisit API security practices and optimize their security posture for the future.
It’s also a telling story for other modern businesses: if you have anything connected to your servers (equipment, apps, partners, etc.), no matter how “private” you think these connections are, it’s critical to make sure you have sufficient API maturity to manage them effectively. That way, you’ll only appear in news headlines for the right reasons.
Do you need help making sure your technology and processes will keep your APIs, your customers’ data, and your company’s reputation safe?