Peloton’s leaky API has allowed any hacker to obtain any user’s account data — even if that user had set their profile to private.
The vulnerability, which was discovered by security research firm Pen Test Partners, allowed requests to go through for Peloton user account data without checking to make sure the request was authenticated. As a result, the exposed API could let anyone access any Peloton user’s age, gender, city, weight, workout stats, and birthday.
Michael Isbitski, Technical Evangelist at Salt Security, a Palo Alto, Calif.-based provider of API security, explains, "A Peloton API endpoint that is used to provide details about workout classes was not enforcing authentication. Any user with Internet access could query the API and obtain private Peloton user information including user ID, location, workout statistics, gender, age and more."
Isbitski adds, "During the 90 day responsible disclosure period, Peloton changed the authentication mechanism of the API to only allow Peloton users to query the API. While Peloton enabled authentication on the API, they’re still not enforcing proper authorization. Any Peloton user could still view the private data of another Peloton user. Privacy settings for Peloton user profiles were also misleading or not properly enforced. Ultimately, it appears the private data of over 3 million Peloton customers is still at risk."
“Leaky API” is sometimes used to describe an API that serves up too much sensitive data and that is protected with minimal or no access controls. Labels such as weak or broken authentication and authorization are often used to clarify what is technically wrong with a given API. Excessive data exposure is another trait, where a back end API serves up more data than the API caller needs in order to function. The intended design is that the front end, such as a web application or mobile application, filters out unnecessary data or functionality," Isbitski says. "These API design decisions are sometimes quickly dismissed in industry as “poor coding practices.” However, there is often an overriding business driver for organizations to preserve user experience and not challenge customers for authentication material excessively. Attackers inevitably find such inadequately secured APIs through internet searches or reverse engineering of front ends since they are ripe for enumeration, scraping, and other forms of API abuse."
Setu Kulkarni, Vice President, Strategy at WhiteHat Security, a San Jose, Calif.-based provider of application security, says that while APIs promise agility, personalization, and connectivity between services, they are also becoming the most vulnerable point of attack.
Kulkarni says, "Developing API-first software has become easier with developers having access to an abundance of frameworks to do so. As the barrier to develop API-first software has dropped there are is now an explosion in the number of public facing APIs – many of which have not undergone any security assessment in production and nor have they been designed with security based exit criteria. There are at least two immediate steps we recommend taking:
- Test your APIs in production for Application Security vulnerabilities and mitigate those vulnerabilities using API management solutions in production;
- Start adding security based exit criteria for API’s in development."
