API Security Lessons from Sherlock Holmes

What can we learn about API Security from the great detective Sherlock Holmes? If you carefully follow the clues left behind, you can find three principles and best practices that can be valuable to secure your APIs today. Software AG’s API Strategist, Brenton House, presented a keynote address at DeveloperWeek Cloud where he walks everyone through the steps to becoming a master of your own API Security.

---

The first principle we find is: Know your Resources.

Sherlock Holmes had a deep knowledge of who and what resources were available to him. He had contacts in the police department as well as in almost every other community. He also studied constantly and knew what tools would be useful in each situation. He became a master of those tools and leveraged them strategically when needed to solve a case.

The second principle we find is: Know your Situation.

Sherlock Holmes once said: “I have trained myself to see what others overlook“. Holmes was known for his keen sense of observation and deduction. In order to quickly identify the clues that were available to him, he had to hone those skills by observing EVERYTHING in the world around him. He then used that information to make educated deductions based on: data and patterns.

The third principle we find is: Know your Adversary.

Sherlock Holmes was always quick to gain an understanding of who and what he was up against. Whether that was his arch-nemesis, Professor Moriarty, or a common criminal. He studied their techniques, their weapons, and their thought processes.

So how do these three principles help us in securing our APIs and our data? The best way to answer that question is to take a look at these three principles and apply them to a real-world case. Today we are going to look at the Peloton API Breach.

In January of 2021, a security researcher discovered a flow that allowed an unauthenticated user to gain access to Peloton’s API and user data for any user, even those whose profile was marked as private. He gave the company the normal 90-day window to address the issue before going public.

The data exposed by this included:

• User IDs
• Instructor IDs
• Group Membership
• Location
• Workout stats
• Gender and Age
• And more…

Let’s take a quick look at the timeline of this. First, a researcher discovered this vulnerability, which was multiple unsecured machine-to-machine APIs that existed on their system. This issue was reported to Peloton using their reporting system and Peloton was given the standard 90-day window for fixing this before it was going to be made public. There was no response from Peloton to either the researcher or the general public.

A few weeks later, the API was “Fixed”. Meaning that only Authenticated Users could now access the API. Now I use the term “fixed” loosely as this API now had Authentication applied to it but did NOT have Authorization policies applied to it. What this means is that once authenticated as a valid user, you could still access the data for any other user in the system. Peloton was notified that their “fix” was not sufficient.

After 90 days, a member of the press was informed and approached Peloton with the issue. A couple weeks later, the APIs were properly secured and Peloton then publicly acknowledged the issue but by then so much damage had been done.

Now let’s apply the three principles from Sherlock Holmes to this case.

The first principle is: Know your Resources.

There are a lot of great API Security resources that are available to you. There are a lot of good API Security Books, websites, videos, and YouTube channels. But what really stands out is the OWASP Top 10 List for API Security.

OWASP stands for Open Web Application Security Project. OWASP is an international non-profit organization dedicated to web application security. What they are most known for is their re-occurring Top 10 list of Web Vulnerabilities, but they also have a Top 10 list covering API Security. The OWASP Top 10 List for API Security is an essential resource in your API Security Strategy. It includes 10 of the most common security vulnerabilities that are found in APIs today.

Below is a list of the OWASP Top Ten vulnerabilities for API Security and here you can find a more detailed description of the items as well as how you can prevent each one from happening.

• 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 Assets Management
• API10:2019 Insufficient Logging & Monitoring

If you take a look at the Peloton case, you can see that the Peloton API had the following vulnerabilities:

• Broken Object Level Authorization
• Broken User Authentication
• Excessive Data Exposure

To put it simply, their API didn’t check WHO you were, it didn’t check to see if you had permission to do what you were trying to do, and they were sending more information than was needed. In Peloton’s case, this included personal information for all users, even those that had their profile marked as “private”.

Next, we have: Know your Situation.

Situational awareness with APIs is critical. You need to understand the API Landscape and how APIs fit into your company and products. You need to know what kinds of APIs exist and what APIs you consume and publish.

There are a lot of different types of APIs that you might be publishing, integrating with, or consuming. Some might be on this list of common types of APIs:

• Public APIs
• External APIs
• Open APIs
• Internal APIs
• Partner APIs
• Machine-to-Machine APIs
• Third-Party APIs
• Composite APIs
• Beta, Testing, or Staging APIs

If we look at the Peloton case, we can see that this vulnerability used a Machine to Machine API. This is a common API used by servers and IoT devices. It is also a type of API that is often neglected when it comes to API security because it does not have the type of user interaction that some other APIs use.

But these are not the only kind of APIs out there. There are also:

• Shadow APIs: APIs you try to keep off the radar
• Zombie APIs: APIs that work… but haven’t been updated and are missing key security updates
• Frankenstein APIs: External or Internal APIs that are hacked together to try to access data because of an insufficient or non-existent API

We can see that Peloton was using a variation of a shadow API as they kept this API undocumented and off-the-radar. They tried to use a form of “Security by Obscurity” which we know does not work. If you have a public API in use, people will find it.

You also need to know your API Cybersecurity Strategy. Most organizations have cybersecurity as a top priority and have some kind of cybersecurity plan in place but API Security is often a blind spot for CISOs and Cybersecurity experts.

For instance, with the Peloton case, President Biden had a Peloton bike that he was bringing into the White House. Cybersecurity experts locked down his bike and assured him that it was safe to bring into the White House. What they missed was that someone going in through an API would be able to see the private profiles of all users, including the President of the United States. Make sure that API Security is an essential part of the cybersecurity initiative at your organization!

The third principle: Know your Adversary.

As someone that might be involved with API Security at your organization, you are going to need to get inside the mind of your adversary. In order to properly secure your APIs against attackers, you need to understand their techniques, their methods, their tools, and their motivations.

Let’s first look at some of the Blue Team Defensive Tools. These are defensive tools that you need to not only understand how they work but you need to make sure that you understand how to properly configure them. As we saw in the OWASP Top 10, an improperly configured tool is also a vulnerability.

First, we have an API Gateway. Now, this is super critical! A properly configured API Gateway is going to be the core to your API Security solution upon which everything else is going to be built. You can read more here about how to leverage your API Gateway to shield and protect your APIs.

We also have Web Application Firewalls. WAFs can also provide an additional protection layer for your system using AI and ML.

And last we have Dedicated API Security Products. These are products that are dedicated to API Security and can integrate with your API Gateway to provide additional Shift Left features (starting a design-time and development) and Shield Right features (or runtime features that watch for attacks).

There are also Red Team offensive tools. I am not going to go into details on these but it is important to understand the tools that can be used to find vulnerabilities in your APIs.

Sherlock Holmes was legendary when it came to solving cases and if you combine API Security best practices with the three principles: Know your Resources, Situation, and Adversary, you too, can protect your APIs and protect your data, your resources, and your organization.