Slide 1: Introduction
Edward: Welcome to today's webinar, "API Threat Hunting: The Anatomy of an API Attack." Thank you to all of you for joining us. I'm Edward Roberts and will be your moderator for today's webinar that will be a deep dive into API security and specifically, API threat hunting. As you are aware, API security is a topic that many security professionals are looking to get greater understanding. First, a little introduction about who is Neosec. We bring XDR techniques and behavioral analytics to continuously discover all your APIs, evaluate their risk posture, and detect abuse. We are also the first API security company to offer managed threat hunting to our customers. If you want to learn more, please just go to neosec.com. Before we begin, I just want to take you through a few housekeeping items. There are some downloads available in the attachments, please go and download those.
There's a white paper on API security fundamentals. And if you have any questions, please use the question panel. We'll be asking questions as they come in, and we'll also have questions at the end.
Slide 2: Today’s Speakers
But first off, I'd like to go and introduce you to today's presenters. Menachem Perlman, who has a strong threat hunting background from his days at Palo Alto Networks, and is VP of Field Engineering at Neosec, and will be introducing the topic today.
And Tal Leibovich, who after spending five years at Deep Instinct, now heads up Research at Neosec, will be taking you on a deep dive into the topic.
Slide 3: API Security Agenda
Now, today's agenda will take you from an explanation of API basics, then show you two real-world API abuse stories, and then Tal is going to show you an attack simulation and explain the state of existing security controls and show an innovative way for you to detect these attacks. So with that, over to you, Menachem, to kick us off.
Slide 4: API 101 for Cyber Security
Menachem: Thank you, Edward. Hi everyone. Welcome to the API 101 For Cyber Security. My name is Menachem, and I will be really happy to take you through this journey.
Slide 5: APIs and Endpoints
Let's start with the basics of API's and Endpoints. All of you probably know that API stands for Application Programming Interface. But when you hear the term "endpoint," some of you might think that endpoint is more focused on computers. But in an API world, endpoint is the single accessible resource in an API.
As an example here, we can see at the bottom section of the slide that the GET/orders/{orderID}, that's the endpoint that we are referring to in an API world.
Slide 6: Why APIs are the next security problem?
Now, you might ask yourself why APIs are the next security problem. The industry today, companies or organizations, have a digital transformation helping them move from what they did so far, to be more digital focused companies. In yesterday’s attacks, the targets, what attackers were looking at, or looking for, was more based upon, "I will find the crown jewels," in the data center for example, "And then I will take this data." But from an API perspective, attackers will go and search for business logic. Companies usually talked about, "How can I see my data? I will look at my packets on my network traffic." But now, these days, companies are talking about, "I need to see my API calls, north-south, east-west." And the way that companies were protecting their crown jewels was, "Oh, let's close the network. Let's do some penetration testing and automation to discover this," but these days, companies will expose data to the outside through an API. And attackers will instead compromise some API credentials and keys.
Slide 7: API attacks in the News
Now, API attacks are here. It's not something that we talk about in the future, it's something that already exists today. There are five different examples here on the screen. Tal will talk more about Scoolio use-case, but if you look at what we have here, there are different use cases and attacks that are happening all over the world, every day, that are specifically related to API attacks. You might ask yourself why the security is basically focusing on APIs. Why companies are really shifting to talk about and think about API security. Gartner is predicting that by 2024, which is just around the corner, API abuse and breaches will have doubled. And Akamai is saying that 83% of the web traffic is based on APIs. That means, almost everything that you do is based on APIs today. And if everything that you do is based on APIs, I can guarantee you that threat actors and attackers know that also, and that's exactly where they are going after. They know that APIs control the world, and companies, not all of them yet, have the right detection, protection and discovery, and that's exactly what they're looking for.
Slide 9: The Anatomy of an API attack
Now that we understand more about the basics of APIs, I wanted to hand it over to Tal who will continue to lead this conversation and talk more about the anatomy of an API attack. With that, Tal, the stage is yours.
Slide 10: The Anatomy of an API Attack - Uber: Account Takeover
Tal: Thank you, Menachem. Great being here, and hi everybody. Thank you for joining us today. So, the first attack that we are going to cover is an account takeover that happened to Uber in 2019. That vulnerability was discovered by a researcher and quickly closed and fixed by Uber. So, let's see what happened there and how the researcher was able to get a full account takeover of any user in Uber. So, the first API call in the attack was an ‘Add Driver’ call, which is used to add the driver to the Uber platform. And the attacker supplied the phone number or an email address of an existing driver. By doing that, of course, the Uber platform returned an error message, because the driver obviously exists already in the platform. And the first problem with that, is that the error message contained the UUID of the user. And then in the second API call, the researcher used an API called ‘getConsentScreenDetails’, and by using the UUID of the user, it was able to get PIIs and access token, which means, an account takeover, as the access token is being used to authorize in the system.
Slide 10: The Anatomy of an API Attack - Uber: Account Takeover (Code snippets)
So, let's see it in more detail. The first API call we can see the phone number of the victim that is being sent in the green box. And the response contains in the red box, the UUID of the victim. Later on, the attacker sends, in the yellow box, the UUID of the victim through the ‘getConsentScreenDetails’ API call. And the response that you can see is a lot of PII and the access token and a lot of data, probably of that user. So, what have we seen here?
Slide 10: OWASP and Excessive Data Exposure
So, before we go into it, let's talk about OWASP and what it means. So, OWASP stands for Open Web Applications Security Project, and it's an online community that produces knowledge in the field of web application security, and specifically in the field of API security.
And OWASP maps the top 10 APIs, a framework we are going to use here. So, the first problem with the exploitation that we saw before, is a vulnerability named, Excessive Data Exposure, API number three in the OWASP top 10 list. And the excessive data exposure basically means that the API has exposed much more data than required to operate. The endpoint exposes too much data. And the attacker chains exploitation of two vulnerabilities in this case that we see in Uber. The API shared too much information and it was used to get the UUID in the first API call. In the second API call, the UUID was used to get more data by utilizing the UUID that was obtained earlier.
Slide 11: OWASP and Broken Object Level Authorization (BOLA)
The second vulnerability is BOLA, or Broken Object Level Authorization, which is API number one, for a very good reason.
BOLA usually, when found, it's easy to exploit and might be devastating, as we just saw earlier, because the attacker could get the access token, which led to an account takeover and PII of any user basically. So, it's devastating, the impact is huge when a BOLA vulnerability is found. So, what BOLA basically means is, a user that can access resources that they don't own. We can see in the chart here on the slide, that we have a user that can access my username, but cannot access the victim username, for example, because it's basically not his user. And in the Uber case, the attacker was able to access the UUID of any user in the second API call, whereas they should be able to use their own UUID only.
Slide 14: The Anatomy of an API Attack: Scoolio: A Massive Data Exposure
The next incident happened to Scoolio.
Edward: I've got a question that's come in, Tal, so sorry to interrupt you there. And I thought it might be appropriate, because you were talking about BOLA, and this is about, "Would an API management gateway prevent BOLA?"
Tal: Yeah. So, that's a great question. In general, the answer is no since many gateways cannot track all entity relationships in real-time. We are going to see a lot of it during this presentation, about entity relationships, and how you can map them in real-time.
So back to the presentation, we have another incident that happened to Scoolio. Scoolio is a student app, it's being used in German-speaking countries, and it collects a lot of data from their users. For example, if they have a personality test, it's used to manage the time. So, there is a lot of data about the interests of the users. And Scoolio, as we can see here, was also vulnerable to a BOLA attack, as well as many other vulnerabilities that we are going to see now.
Slide 15: The Anatomy of an API Attack: Scoolio: A Massive Data Exposure
So, a ‘visit of the basement of horror’ was published in 2021, and it's a very nice exploitation because, again, we can see, as in the Uber example, that by utilizing two API calls the attacker was able...or the researchers actually, luckily in this case, was able to get data and PII of any other user in the Scoolio app.
So, let's see what happened here. The first API call is the ‘Explorer’ API call. It's used to get a lot of profile IDs, again, Scoolio uses UUIDs, so that's the profile IDs. And in a subsequent call, the researchers used the ‘api/v2/Profile/{ProfileID}’ and got a lot of data such as PII and GPS location, that we're going to see now.
Slide 16: The Scope of Scoolio’s 2021 API vulnerability
So, let's see what was the scope of that vulnerability because there are few interesting things to note. So, let's start with the first one. Again, we saw here a BOLA attack because a user was able to access data of a different user in the platform by abusing the business logic of the Scoolio app. And actually another interesting note about BOLA is that using UUID is actually a good practice. So, the profile IDs are implemented using UUID, and that is great. The problem is that a user can access and get UUIDs of other users and the actual vulnerability to BOLA in the second API code, the combination of them is the problem. Like, chaining them together is the problem, in that case. And if Scoolio was to use just regular IDs and not UUIDs, that attacker could enumerate them and collect data of all the users by adding just one. So from 1000 to 1001, 1002 etc., etc. in the ID for each request, and by doing that enumerating and scraping all the data of all the users in the Scoolio app. So, UUID is great, but it's not good in general when you're vulnerable to BOLA.
Slide 17: Scoolio: Improper Assets Management (API9)
Another problem that was exposed, as part of the Scoolio incident, is the improper assets management. Improper assets management is ranked API number nine in OWASP top 10 list. And it's another interesting...well, kind of vulnerability, I would say. Because here we can see that there is an older version of data that was still exposed. And in this case, there was v2, and then the developers upgraded to v3, but they left v2 still accessible to anyone, so the attacker could use v2 instead of v3. And what's the problem with that, you would say? So, let's see what v2 exposes versus what v3 exposes. So, it seems like when they upgraded from v2 to v3, they reduced some of the data that was being exposed because it probably exposed too much data.
Slide 17: Scoolio: Improper Assets Management (API9) - Code snippets
So it's, kind of, again, excessive data exposure that we saw, that we talked about earlier. And we can see here that in v2 there is on top of v3 the user email, the parent email, date of birth and geolocation of the last time the user was accessing the app. So, as part of the research, the researchers published that finding by using v2 for the BOLA. So, both v2 and v3 were exposed to BOLA, but v2 as mentioned exposed much more data and that's the ‘improper assets management’.
Slide 19 & 20 - API BOLA Attack Demo
So, we talked a lot about a few vulnerabilities from incidents that we saw in Uber and Scoolio, from the news. That's great, but I think that it's very important to see it in action and to actually see how it happens. So, what I'm going to do here is to show you a demo that we prepared beforehand, of a BOLA attack. So, what we're going to see now, let's just explain it before we're going to see it. We used a vulnerable lab named, VAmPI. You can find it in GitHub. And what we just did here, is registering a new user, logging into the lab. And then first, we found the vulnerable endpoint. We show the legitimate access to that endpoint and right after it, a non-legitimate action on that endpoint and changing a password of another user. So let's see it in action now. So, we can see that first we are registering a new user. Let's call it, MyDemoUser, and the password is going to be, password1, with just a random email address.
Great. Here is our new user in the system, and now we're going to login and get an access token. So, here is our access token, and from now on we're going to use that access token to authenticate on the API. So, what we're going to do now is to change the password of our demo user. We are using an endpoint, we can see it here, user, v1, and then the best param, and in that case it's MyDemoUser password. And by doing that and putting in a payload the new password, let's call it, NewPass, we can change our password. So, that action is legitimate, because we just changed our own password. We are, MyDemoUser, and we changed the password of MyDemoUser. It makes sense. Oh, sorry for that. So, 204. Great, we changed the password. Now, let's try changing the password of another user. Let's say, the admin. And we can see that the lab, specifically that endpoint is vulnerable to BOLA, because we are able to change a password of another user. And the response code is 204, which means that we successfully changed the password. So, let's see what measures organizations...
Edward: Sorry to interrupt you there, Tal, again. I've got a question about BOLA. "How common is BOLA in your experience of protecting APIs?"
Tal: So, BOLA is very hard to detect, I would say, because you really need to understand the business logic of the app when you are trying to detect those kinds of things and understand the relationships between entities that we're going to see in a few minutes. So it's very common, I would say, but it's not very easy... Like, it's very hard actually, to find those vulnerabilities but after you find it the impact is huge, as we saw earlier, that led to account takeover and exposed PII.
Edward: Okay, Thank you.
Slide 21: What Measures Organizations Take Today
Tal: So, let's get back to the session. What measures organizations can take. So there are three pillars, I would say, that organizations take today. The first one is using centralized authorization. So, by using an architecture that centrally manages all access portals in a centralized authorization engine. It just helps to eliminate most of the development mistakes. The second pillar is API testing, and by testing for broken authorization using both static code analysis and dynamic testing, you can surface issues early on in the development process, which is also a very great and important practice. And the third one is protecting production. So, inspecting user access to production data, preventing exploitation of known vulnerabilities and authorization vulnerabilities such as BOLA. So seeing the data in production environments is also a crucial step to defend the environment.
Slide 22: What Measures Organizations Take Today
So, the next slide. Now we are going to talk a bit about the problems with those approaches. So, let's start with the first one. So, central authorization is great but sometimes development teams fail to maintain authorization from a single component. API testing is important and you can detect problems and solve them early on in the development process. But usually, there are a lot of alerts that you get, and we see teams that suffer from alert fatigue and difficulties to prioritize those alerts. So, that's another problem with that approach. The third approach, protecting production. So, the existing measures also should be in place. But when it comes to business logic abuse, as we saw in the vulnerabilities before, because you need to understand the business logic of the app and the relationships between the entities and what each entity means. So, the current tools that exist in the market are usually not enough because they don't cover those use cases.
Slide 23: A New Approach to Detecting BOLA - The Concept
So, let's propose a new approach to detect BOLA, and we are going to do it by entity mapping, a concept that we developed and that's how we name it. So, let's talk about the problem of BOLA, and let's try to model it. So, we saw an actor, in this case it was a user that is trying to access a resource. And the problem is, the user is accessing a resource of another user, which is sometimes legitimate. We're going to see an example of that, but sometimes it's not. So, how can we know when it is legitimate and when it is not legitimate? So, for doing that, we need to first map the entities themselves. So, let's understand who the actors are in the API, and what resources we have in the API, and the next step is going to be to map the connections between those entities.
So, we're going to see the actors and the resources, and then for each one of them, we want to see the connection between the actor and the resource, if it's a one-to-one relationship, many-to-one relationship, etc. And then we're going to see that some resources are going to be accessed usually by a single user, for example, or a single actor, and then it's a connection that we probably want to enforce.
Slide 24: BOLA Attack Detection - Relationship Mapping
So, let's see now an example of that. We can see here a fake banking app that we just made up for the sake of the presentation. We have two actions. First is to read the account data in the banking app, so you can read your own account data, your balance, etc., and the second action is reading the exchange rate, let's say from dollar to euro, etc. So, in this example we can see that each user probably should be able to access only their own account, and every account probably is going to be consumed by a single user. On the other end, the exchange rate is going to be accessed by a different user, and every user is going to be able to access any exchange rate, because it's public information.
Slide 25: BOLA Attack Detection - Relationship Violation
So, by doing that and understanding the relationship between those entities, in the upper example we can see that there is a single, one-to-one relationship between a user and a bank account or the account ID. And once we understand that, we can talk about enforcing it and detect BOLA, for example, when we see another user accessing an account that they don't own. So, it's annotated here with the red arrow. So, we can see that usually a user can access a single account, and then we see a user accessing two different accounts.
Slide 26: BOLA Attack Detection In Practice
So, let's put our proposal in a test. Let's take the example that we saw earlier with Uber and Scoolio, of the BOLA vulnerability and let's see if our approach stands for it. So, in green we can see the actor identity. So, in Uber, let's say that it's the cookie, and in Scoolio there is the access token of the user. And in red, we are going to see the requested resource in the platform. So, with Uber it's the UUID that is being accessed, because if you remember the second API call was used by using the UUID, we were able to get the access token and the PII. And in Scoolio it's going to be a profile ID, which is sent as part of the endpoint test. So, in green we can see the actor, and in red we can see the resource, and those are the connections that you're going to enforce, because now we are going to see that usually users access only a single UUID, or a single profile ID. And then we're going to see a violation of it, and that's the vulnerability.
Edward: So, some questions about this approach, Tal, and so, I'm just making sure I'm reading it correctly for you. "But this approach only covers resources, which are one-to-one with users. What about the bank account I share with my wife? That's a two-to-one relationship." Does that make sense as a question?
Tal: Yeah, yeah, yeah. That's a great question. So, we basically touched upon the surface of the approach of entity mapping and the relationship mapping. And there are many more steps to take in order to achieve that level of understanding from many-to-one, one-to-many, what to enforce, and how to enforce it. But that's the example, that's the basic idea I would say, and for more advanced use cases it's probably for another day.
Edward: Okay. Thank you.
Slide 27: BOLA Attack Detection - Alert in Neosec API Security platform
Tal: Sure. So, let's finish now by seeing an alert of a BOLA, by utilizing the model or the approach that we just mentioned. So, we simulated BOLA in our vulnerable lab, and now we can see an alert of it on the Neosec platform. So we can see here, MyDemoUser accessing in the timeline on the left, we can see that the first API call was used to access their own user to change its password, the second API call was used to change the admin password. Right after it, we can see a BOLA alert.
Slide 28: Recommendations for API Security
So, some recommendations toward the end. So first, always ensure an up-to-date API inventory, because inventory is the first step when you want to understand what's going on in your environment. You first need to understand your inventory and the posture of your inventory. So, that would be the first step to take. The second step is to monitor non-production and production API environments, because even if you implemented centralized authorization, your developer can still write their own stuff and bypass it completely. These mistakes happen. And the third part is to enforce relationships between entities that we just saw earlier, so modeling those relationships and enforcing the connections that we make.
Slide 29: Thank you
Edward: Great. Thank you very much, Tal. That was really, really appreciated. Some good explanation of some of the problems and some of the issues that can arise with API, and how they get deployed and how they get protected. So, as we build this series of Threat Hunting, we're going to go and take you through different attacks and different solutions, to different security threats in your API, so look out for the next webinar where we will discuss another type of an attack. But I just wanted to refer you to the assets that are in the attachment section, so please download the white paper that's there on the API security fundamentals. And there's also an explanation of Neosec ShadowHunt, which is our managed threat hunting service, to help you learn about this process and how you get that process taken care of using the expertise that Neosec provides.
Slide 30: API Security Q&A
But I do have a few questions that have come in, Tal and Menachem, for you. And so, I wanted to go through those. So, I think this first one I'm going to direct to you Menachem. "Thank you for taking us through the attacks. It was very educational, but I am wondering how to find out how many APIs my company has?"
Menachem: That's actually a great question. And it's something that we see happening all the time. With every customer that we meet, one of the first things they ask is, like, "How can they know how many APIs I have?" They know they have APIs, and they have some rough number, but when you have a room with five people, every person will have a different number of APIs in their head, which is really interesting to see. So, I think that discovery is a key aspect. Discovery and visibility, it's a key aspect to find how many APIs you have.
You can start by mapping your API infrastructure. Close the door, sit by yourself and draw a diagram of how your APIs are structured, and find a few places where most of your APIs traffic go through, and then look at these locations. This can help you get some grasp of how many APIs you have, and I can guarantee you that you will be surprised to see these numbers, because you might think that you have this number, but in reality it is usually a higher number than what you think that you have. And discovery or seeing how many APIs you have, it's a critical part in basically API safety journey and API lifecycle journey, that at least we see in most of our customers.
Most of them start from answering this simple question, how many API they have. Now, regardless of security, or regardless of the attacks this kind of stuff, how many APIs they have, and they're, like, afraid that many people will talk about that, and it's well known in the security industry that what you don't see you cannot protect. So, start from discovery. Like, once you know what you have, then move to the other steps. Like find threats, do prevention, do protection, etc., but try to break it down into steps and pieces. You don't need to start right away with security. Start from the discovery, and then you can move to the other steps. So I hope that answers the question.
Edward: Okay. Appreciate that. And so, some more questions coming in here. This is going more about BOLA, so I'm going to direct this you Tal, but Menachem, please join in if there's anything you want to add. "Why can't my bot mitigation detect the account takeover or BOLA that you just showed?"
Tal: So, the way that we propose to detect those vulnerabilities is available, thanks to user tracking and relationship mapping. And for doing that, you need visibility into the API tracking. Once you get that, and build on the discovery that Menachem just mentioned, you can track the users, you can see what entities are in the platform, and understand the connections between them. And then you can say, "Oh, now I understand the connections, let's see what an enforcement or what a violation of that actually means and what it looks like."
Edward: Okay, thank you. I've got a bunch more questions coming in here. This one I think is probably for you, Menachem. "How would you recommend approaching API security if I don't have the specific expertise in-house?" And I know that that's probably a problem that a lot of companies have is that they don't have a specific expert and they're short staffed in security expertise.
Menachem: Edward, I'm not sure how many questions we got so far, but I feel like you're selecting the hardest one actually. But basically, that's really a good question. Most organizations today are not... Or I will say, maybe not most, but many companies today still do not have many security experts around API security. They have experts in firewall, experts in cloud and endpoint, again, don't forget the endpoint that we talked about at the beginning. It's a different endpoint from an API, but the fact that you are here today in that webinar, you are already doing a major step into developing your knowledge about API security. We have some resources on our website you can go and read. There are other great websites. You can start from OWASP and other resources that I highly recommend, and also leverage tools. Neosec is one of them, but other security API solutions can also be really good for you. But once you have these solutions, it's going to be a good start for you to build more expertise. And I will conclude by saying that using solutions like Neosec that leverage machine learning means that you don't need to be security experts in an API to be able to protect your organization. That’s the whole concept of having a tool that can do that. So, also try to consider that.
Edward: Great. Thank you. So, Tal, I think this one's directed at you. It says, "Thanks for the education on those critical vulnerabilities and they obviously seem pretty easy to achieve. "How should I protect my environment, given that those things are possible?"
Tal: So, I would say that there are things that you can do before production and later on when you're already deployed. So, before production you can with part of the shift left approach, you can test both your API and your codes for finding the vulnerability, and you can use centralized authorization, as I mentioned before. But you will also need that component in production and visibility into what actually is going on under your API and just in production in general, as there are also other categories in production. But in general, I would say that there are a few layers. Like, security should be built on top of different layers. So, yes. There is the central authorization and the testing that we just mentioned, but you will also need something in production. You'll need the user tracking, you'll need to understand your own baselines and your own patterns in the data. And based on that and utilizing behavioral analytics and machine learning, you can find those anomalies within your production data, and finding those BOLA vulnerabilities and many other alerts and problems that happen in reality.
Edward: Great. I'll direct this one at both of you, because it sounds like it's a bigger issue, but what do you consider to be the most dangerous API threat? So, maybe start with you, Menachem, first?
Menachem: Yeah. I will take this question. Maybe I will try to complete the entire answer. But in my perspective, discovery actually. Some people might think, attacks, etc., but what you don't see you can't protect. So, seeing your APIs, it's really important. Once you have the discoveries, then think about things like business abuse cases. So, attackers that will leverage and do other types of attacks that's related to that, also it's really important.
Edward: So, I just want to close today's webinar by saying, thank you for attending. Really appreciated your time and the questions. That's all that we can get to today. We will gladly answer any additional questions if you send us them in the chat, and we'll just get those directly to you. So, we appreciate Tal and Menachem's time here on the webinar, and really appreciated the expertise. The recording will be available on the neosec.com website, so if you want to share this with your team, we will be sending out a link to you, so please use that. And we look forward to seeing you again as we explore these API threats in future "API Threat Hunting" webinars, so please look out for those. And we look forward to seeing you very much in the future and appreciate all of your time.
Thank you very much.
