Slide 1: Introduction
Edward: Hello, everybody. Welcome to today's webinar. Thank you for joining us. I'm Edward Robertson. Will be your moderator for today's webinar, which will be a deep dive into API security, and specifically address the "6 Ways API Security Makes Your WAF Stronger."
As you are aware, API security is a topic that many security professionals are looking to get greater understanding. And one of the most common topics we address is confusion about what does my web app firewall detect in my APIs, and then conversely, what does my WAF miss? Today's session is intended to address that problem.
So, 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 detection and response solution that offers managed threat hunting for our customers. If you want to learn more, please go to neosec.com.
Before we begin, we'll have some housekeeping items. There are some downloads available in the attachments. Please have a look at those. There's "API Security Fundamentals." There's a couple of white papers, and "Critical Capabilities of an API Threat Protection Solution." If you have any questions, I want you to use the question panel and we'll be answering those.
Slide 2: Today’s Speakers
So, now let me introduce today's presenter, Yariv Shivek, who has a strong background from building the Cortex product for Palo Alto Networks and is now the VP of Product at Neosec.
Slide 3: API Security Agenda
So, today's agenda. Today what we're going to do is we're going to talk about today's API security challenges and focus on runtime API security. Yariv will go through some real-world attack examples and open your mind to the problems of API abuse. Then we'll talk about WAF and WAAP strengths and weaknesses, and go through six degrees of runtime API protection with some live attacks thrown in for good measure. So, with that, I'll hand it over to you, Yariv.
Slide 4: API Security Challenges
Yariv: Thank you so much, Edward. And I also want to have a shout-out to Almog for setting us up with the lab and providing the attacks that we're going to go through. So, WAFs and WAAPs, and API security challenges, right? So, we all know that APIs are at the forefront of digital transformation that virtually all organizations are currently going through. And it's basically the way you do business nowadays, whether with your customers directly or with your partners, your suppliers, your resellers, etc.
Now, the API development inside organizations has really skyrocketed in the past three years, and conversely, it has also become the most common data breach attack vector. And as Edward likes to say, you know, data scraping is today's data breach, right? And this happens through APIs. And Gartner has predicted that 2022 will be sort of the inflection point, and it has actually happened, and APIs are now the most common data breach attack vector.
Slide 5: Holistic API Security
Now, the other side of the code, of course, is security. How do we secure APIs? Because that is the topic of our discussion. And the way to do that nowadays is DevSecOps. Basically, security being ingrained into the entire software development lifecycle in an automated fashion with minimal friction so that developers are free to just run ahead, implement business logic, and bring new innovation to the field with the security processes integrated into the development processes.
So, we'll be focusing on the runtime portion, which is the green portion that basically is around the darker blue portion here on the Ops side. But of course, holistic security starts with, you know, planning. So, you have tools today to aid you in securely designing your APIs from the open API specification or swagger file stage and onward. You then move to coding, right, in which you typically secure your code with static analysis tools. You build the code, which is where software composition analysis comes to tackle supply chain issues and ensure that you don't have any, and then you test, which is where both manual and automatic dynamic testing takes place.
You release the API into production, and the release process really is where we move to the Ops side of things, often also where documentation update takes place. So, if you need to update those open API specification files, definitely need to do that and publish them so that the API consumers can use them. You deploy to production. And then the site reliability engineers operate the APIs on a day-to-day basis. And you happily monitor how the APIs are being used in production and often in non-production environments as well when they're subjected to various tests. And then this cycle goes back and you introduce new features and new fixes, etc. So, it's an infinite loop.
Now as we've mentioned, we'll be focusing on the Ops side, on the runtime side. So, we won't be talking about all of those things, generally speaking, WAFs and WAAPs, i.e. web application firewalls and web application and API protection platforms don't do. And those are the design validation, the static analysis of composition analysis and testing, and the continuous discovery of APIs across your entire API estate.
Slide 15: Runtime API Security
So, focusing on runtime API security. The way it's done today, really, if we are focusing on runtime protection, so you secure the infrastructure with cloud workload protection platforms, cloud security, posture management. You have CDNs, which have evolved mostly into WAAPs themselves who provide distributed denial-of-service protection. You have WAFs and WAAPs that basically provide known threat protection via signatures, and today also have bot mitigation features, most of them.
And really when you look at that, the WAAPs, I mean, everybody's calling itself a WAAP nowadays. It's basically a next-generation WAF with DDoS bot protection, CDN, and some API features. And then you have, hopefully, the API gateways, right? And these typically terminate authentication and authorization unnecessarily and they do enforce rate limits typically on the business level, but also the SpikeArrest policies and stuff like that that gets implemented there.
Edward: Yariv, I've got a question here. Do you think that there is confusion among security professionals about API security being covered by the WAF and WAAP?
Yariv: Well, generally speaking, I think so. I mean, most of the organizations I've had the pleasure of working with didn't do very in-depth risk modeling or haven't done it at all for their APIs. Really only the biggest organizations out there, typically the financial sector do that. And so a lot are really lulled by a full sense of security when they see that their WAF vendor or their WAAP vendor says, "Yes, you know, there's OWASP Top 10 protection," but I don't think they've really thought through all of the abuse cases or the bad things that could happen to the APIs.
Edward: Okay, thank you.
Slide 16: Real World API Security Problems
Yariv: So, I wanted to go through just three quick examples, and this is just, you know, one of them for things we've seen fairly recently. So, in one case, we've basically seen unauthenticated data scraping, right? And as I said previously, API data scraping is the new data breach, right? And we don't have to think back too much to think about, you know, the latest T-Mobile breach that happened in late November and was only discovered in January. And when you have that, right, when you have endpoints that are exposed mostly by mistakes, in this case, it was completely, you know, supposed to be an internal endpoint, was sadly accessible from the internet by mistake, then, of course, you're going to get people scraping it. And it's doubly problematic when that could happen without any authentication in place. And this happens so often. It's just mind-boggling, really.
Now, other API security problems. And by the way, APIs are designed to exactly do that, to provide data to the API consumer. So, this is just happening so much with APIs much more so than, you know, in any other case, just because they're designed to give you data. Another case, account sharing, you could say, right? We call those alerts impossible time travel, but we had multiple cases of interleaving logins from the same user from different locations. So, it could be, you know, stolen credentials, could be shared credentials.
Actually, that specific customer found two problematic things, and this is where sort of the insider issue comes into light. Their support people were not actually following procedures pretty well, and when someone was calling support, the support person would just set the password to some very easy and repeatable password. So, everybody was using that same password both the support person and the customer, and actually a lot of other customers as well. So, that was a problem, and they really worked on the processes there.
They also found out that a reseller that was working with them was actually sharing his credentials with multiple prospects and customers, and that was really account sharing, right? Now, the insider angle is something that a lot of organizations don't take into account when they're thinking of APIs. But with everything going through, you know, post-COVID and with all that quiet quitting, etc., I think insider threats are really on the rise and they do warrant more attention.
Now, another, the last example. This is really customer abuse that was discovered via anomaly detection, a gaining platform in which players basically had long sessions, and we found out that they actually were ganging up on other players. And when the company found that out, they changed how the tournament assignment basically worked. So, you really have abuse from your consumers ganging up on other consumers and sort of weakening your brand and making customers unhappy. So, those were my three examples, just to get everybody in the mindset of things that can go wrong and are not very, very trivial, but we will do the SQL injection later, of course.
Slide 19: WAFs and WAAPs
So, when it comes to web application firewalls and web application and API protection platforms, and when it comes specifically to the runtime protection that they offer, what are their strengths? Right? I mean, they were architected in a very, very specific way so that they can detect and block very, very quickly, they're very performant, malicious traffic, right? They can detect and block malicious traffic before it hits the upstream service, before it reaches the API. So, that is their biggest strength and it's a great security control.
And, of course, the customizable rule set is, of course, very useful as well, because you can customize it to your business needs. I can customize it to my business needs, etc. On the other hand, we have some weaknesses that come hand-in-hand with that architecture in those strengths. Firstly, false positives, right? And anyone who's tried to deploy a firewall knows that you get a lot of false positives. Typically, you'd first deploy in a learning mode in which you only get sort of alerts first or logs, then you start fine-tuning the rules because, for your specific business cases, some rules would just trigger lots of false positives, right, and that changes and is different really per organization, per environment, per business case.
Now, firewalls are also easily bypassed by persistent attackers. So, yes, if it's the internet that's scanning you and trying some random new exploit, then that would get blocked. But if there's someone who's a bit more persistent than that, they could get around those rules, so that is definitely an issue. And, of course, the firewalls just don't stop non-signature attacks, which is something we'll look at later on. And, again, this is all stemming from the way they're architected, right?
And lastly, they require ongoing maintenance updates to the rule sets, etc. So, really there's no context, right? They work at the single request level because they have to be very, very performant, and they sort of act as immigration control. I mean, you're either in or you're out, but if you're in, we don't know what you're doing when you're in.
Edward: So, Yariv, I think you've got a question that came in there that I think you might have just addressed it. It says, "Is it another weakness that WAFs look at single requests one at a time?" So, do you want to touch on that? I know you touched on it a little.
Yariv: So, yes, WAFs, in general, don't have any context because they weren't architected in that way. WAAPs, for the most part, have no context, but there are some bot control features that do look for fingerprints that were seen before in their reputation databases, which is sort of a very narrow context at best. But regardless WAFs or WAAPs, there's really no analysis of the API consumer's behavior over time and in comparison with the behavior of all of the other API consumers. So, that is just something that is impossible for WAFs and WAAPs to do.
Slide 20: 6 Degrees of Runtime API Security
Slide 21: Typical Architecture
Yariv: We'll start with the typical architecture just so we'll have something to talk about. And this is typical but, of course, there's so many variants of these changes per customer. But by and large, you have an API consumer on the left-hand side, they send requests to the API implementation, does go through your WAF or your WAAP. If they're not obviously malicious, then they go through, they reach the API gateway, they get authenticated, authorized, probably routed to the correct API, and then they hit the API implementation. Response is generated and goes all the way back. Makes sense.
Now, specifically in the lab that we'll be using to demonstrate some of these concepts, we are using ModSecurity running on NGINX as the WAF. It's actually sending a copy of the data to the Neosec platform. We have a Kong API gateway acting as the gateway. And as the API implementation, we are using VAmPI, which is the vulnerable API implementation. And I think we've made some tweaks and added some use cases to it, but that's the API implementation.
So, this is the lab, right? There's a WAF. We see the traffic there. We could be tapping at multiple location. It really depend on the architecture and the customer, but that's the case in the lab. There's an API gateway, and then there's the API implementation.
Slide 22: #1 Are all your APIs behind a WAF?
So, let's begin, right? What is the first degree of runtime API security? Really, the most basic question is, are all the APIs behind a WAF? Now, it sounds silly, but we've actually seen this happen a lot, right? So, really, I mean, sometimes it's just... I mean, there's, you know, compliance-driven security, and if you don't plug the WAF in, then naturally it's not going to do anything.
But even if you do plug it in, we've seen cases in which, for instance, from an architectural perspective, you know, there's a TLS or an MTLS tunnel that just goes through the WAF. The WAF can't do anything about it because that tunnel is terminated at the API gateway or at the API implementation. And so the WAF is basically sitting there and just routing traffic, but not being able to inspect it at all.
There are also cases in which deploying a WAF or a WAAP is just too expensive for certain APIs due to the volume of traffic, or that the WAAP would end too much latency for certain APIs. If you have APIs that have to be really, really performant, really quick, low latency, then adding a WAAP and specifically WAAPs that are deployed in their own cloud such as CDNs, then that means that the request gets routed to a fairly far away hop, and so that adds some considerable milliseconds. And so sometimes that's a consideration and that's why people wouldn't put a WAAP there, right?
So, really just ask yourself, are all of my APIs behind a WAF? Right? And, of course, you know, you may find that you have various clouds and, you know, you're using some WAFs there, some WAFs in another cloud, and sometimes the processes are not exactly...the security processes are not the same for all the teams. So, maybe they forgot to use one in Azure or in AWS, etc., etc., right? So, are your APIs behind a WAF?
Slide 23: #2 How robust are your WAF Policies?
Secondly, and that's also important, how robust are the WAF policies really? And I like to call those porous WAF policies because you have to have holes in them because of what we talked about earlier, right? You have to disable some rules because they're false positives, right?
And you're also using maybe different WAFs in different clouds, which is a pain, right? But we've seen a lot of organizations who are moving to the cloud and they're saying, "Okay, so I have vendor X securing my on-premises API implementation, but as we move to AWS, yeah, just using AWS WAF is enough," right? So, that's a completely different rule set, and so these two are just not the same. Of course, there are solutions to that problem, too, but it is important to realize, hey, which policies do I have? Which rules are actually coming into play in each of my environments, in each of my data centers?
Now, also, you may find out that you need to completely turn off some features, again due to performance and some reasons like that. For instance, you might want to turn off JSON payload inspection because it's just taking too much CPU, right? And so how robust are the WAF policies? Definitely, a good question to ask ourselves.
Slide 24: Unauthenticated SQLi attack Demo
Now, I'd like to actually stop now and do a very, very quick attack against the WAF. It's the most trivial attack. And this is typically what WAFs look for, right? So, we're going to do an unauthenticated SQL injection attack. And let's look at that. So, actually, let's first look at the API that we're attacking, right? So, we are attacking VAmPI, the vulnerable API implementation. It's a strange API. It has users, and users can log in, and you can list the users, you can delete users, you can manage them.
And it has books, and books really are the resource that is sort of... They contain a secret. So, they're sort of sensitive in a way. So, if you look at the book title and you can retrieve a book by the title, you also get a secret. And so, of course, there's an affinity between which users can access which books, and so that would be sort of the issue with this API.
We're going to try to attack that API. And in order to do that, I'll be using cURL. So, apologies for that. You're going to be seeing some command line. And Almog was kind enough to provide me with some attack scenarios here. And the first thing that we'll do is we'll actually go and try to attack that user's endpoint and we'll be issuing the get request. And notice that we'll actually be adding an apostrophe here. So, we are just testing for a SQL injection, right?
So, we're sending this command, this request, it goes out. You can see that we get an internal server error, right? So, it went all the way through to the API implementation, it went through Kong, through the API gateway, right? We see that here. It seems VAmPI is running on another NGINX server back on the right-hand side, and we're seeing an SQL error, basically, a SQL error from the database telling us, "Oh, my God, the query is broken," right? And this is exactly what the attackers are looking for. So, this is the first thing they'll do is they'll just try to see, is it vulnerable? And this went through the WAF without a hitch, right? There wasn't really any exploitation. There wasn't any very, very clear signature besides adding that apostrophe here. So, of course, that went through and became an issue when the API data implementation actually tried to save that request.
Now, the next thing the attacker would typically do in this case is they would try to say, "Oh, cool. There's a user's table. Let's start doing ORDER BY and look at which columns are there, how can I, you know, work with that, and actually get all the users, maybe the sensitive users like the admin, etc.?" So, it will be issued in this, and this is where the firewall actually does what it's great at. And you can see that we send a request, the request with that apostrophe also has an ORDER BY, right clause, and we are getting a "no, you can't do that." We're getting a 403 forbidden. It's being served by the ModSecurity WAF. The connection is closed. It also gives us a page saying, "No, don't do that." And we are basically blocked, right? So, this is great, right?
How does that look actually in the user interface? Right? So, one of the things before I go into the alert, I want to show you the automated action center that we have inside Neosec. Because one of the things that the WAFs don't do is really do anything other than prevent. I mean, you can log, you can prevent, but that's basically your options because that's the way they're architected.
Now, when you consider that we can actually add very, very granular conditions, right, and I could say if there's a SQL injection, right, and it's happening, you know, I can add all sorts of conditions, then... Oh, let's set an F5 policy, for instance, right? And that could happen on any condition and on any of our alerts and with all sorts of, you know, does the alert description contain this? Are they associated data classification labels? Like, is there sensitive information involved like PII, usernames, or email addresses or what have you, specific endpoints, specific users, or entities, or entity groups? Right? So, you can do all of those things.
And so it's really a mini SOAR, Security Orchestration, Automation, and Response tool that's ingrained here so that you could really write response playbook. So, I think what I'm driving at really is prevention is important, but detection and response give you so much more control over what you're doing. And that is very, very important when you go up the stack into business logic level stuff.
We go to the alerts page. So, we do see the SQL injection alert here as well. We have the ORDER BY clause and everything. So, we do see the alert in the Neosec platform as well, even though it has been prevented by the WAF, simply because we do get the data from the WAF, too, right?
So, back to this slide. The point of this was to show us what WAFs are good at, to show us how preventions looks like, and what you can do when you actually can write very intricate response playbooks, which is where I really think we all should be, right?
Slide 25:#3 Can you leverage a positive security model?
Now, what's number three, the third degree of runtime API security? And that is really the question. It's a very important question. Can you leverage a positive security model? Right? So, a positive security model in which basically the WAF or WAAP would be blocking all non-conformant API requests, right? This is really good because it does prevent a lot of reconnaissance like query parameter enumeration, all sorts of things like that. Someone's trying to find out which query parameters are there, right? Which path parameters are these? Things like that, what paths? It also prevents some forms of exploitation like mass assignment in which attackers would pass new fields or parameters that are simply not there, right? They would try things like, is admin equal one, or is debug equal true? Or stuff like that.
Now, the caveat there, of course, is, you know, it really requires you to have very robust software development lifecycle processes because if you don't, then you will get legitimate requests blocked. So, in this example here, we have an API developer, and they're submitting an inaccurate open API specification to the WAF or WAAP. Now, the WAF or WAAP treats that as gospel basically. So, they're blocking according to what's written there, and there's a legitimate request coming in, but oops, they forgot to document that this new parameter is allowed, and that legitimate request from the new client actually gets dropped by the WAF, right? So, these are things that could happen, and really you should ask yourself, are my software development life cycle processes robust enough? Do I have enough automation so that I can drive this and really leverage positive security model in my organization? And hopefully, you can, and you could leverage that.
Slide 26:#4 Are you inspecting East-West traffic?
Fourth degree, are you inspecting east-west traffic? Now, this is really, really interesting because it really comes down both to architecture and to, are we doing threat modeling and, you know, things like that? So, we have an API consumer, right, and the API consumer goes through the WAF and through the API gateway, through the API implementation. That's the happy paths, and that's the path that everybody was looking at. But what happens when API two goes and talks to API one or API one goes and talks to API I two, or you have your support person or some other insider, you know, Barbra from customer success and they're actually accessing the API? Are they going through the WAF? Are they going through all of these security controls?
And really often the cases they're not. Very seldom are things architected in a way in which the WAF or WAAP is centric to all the requests going in and out of various services. We've seen that, and we're happy when we see that. This is cardinal to zero trust implementation in APIs, right? This is really the way to do that. You want to be able to segment the path so that if someone is breached, someone is basically social-engineered to have malware installed or what have you, then they still have to go through all the security controls, or at least through the WAF firewall.
And really, whether you need it or not, it boils down to the threat analysis that you may or may not have done, and the risk posed by the relevant abuse cases in your risk model, right? So, you need to consider things like insider threats, and we've touched on that previously. What happens if you have malware on some of your machines, whether the servers or, you know, workstations, Barbra's workstation? What if someone is social-engineered and basically their account is compromised, their credentials are stolen, an API key is stolen and someone gets, like, insider inside path to the APIs? What happens if there's a physical breach etc., etc.? Right? So, these are sort of the east-west, the internal traffic flows that often get overlooked.
Edward: Yariv, I've got a question here. Are there any other situations or business scenarios where east-west inspection might be important?
Yariv: So, there's probably a bunch. One that pops to mind is if you just went through sort of a mergers and acquisitions kind of thing, right, and you suddenly have more IT systems that you don't really know talking to your systems and vice versa, then I think that's one of those cases, right, in which you sort of have this insider and that never happened to you before. Now sometimes that insider, for instance, is a partner, and partners have different access to a different proxy than the normal API consumers. So, there's all sorts of ways in which this can play out really depending on the organization and how they conduct their business.
Edward: Thank you.
Slide 27:#5 What happens if an authenticated user attacks?
Yariv: So, the fifth one. What happens if an authenticated user attacks? And this is a big question or the big question I think from a security perspective. Basically, you could think of it as, do you treat authenticated and unauthenticated traffic the same way? Right? And the answer in our experience is many do, even though it doesn't make sense, right? So, what does it mean, do you treat authenticated and unauthenticated traffic the same way? We've seen that SQL injection, right, previously, and that was to an unauthenticated endpoint. And yes, the WAF blocks it, brilliant.
Now, is the policy the same, even if that traffic came from an authenticated API consumer? If so, you really need to consider, hey, why is that API consumer who's authenticated, I mean, that's Barbra or Bob or our partner, why are they issuing blatantly and obviously malicious traffic to our APIs? Do I just need to block that one request or do I really need to do something that's a bit more, you know, severe to address the situation because the situation is so much bigger? Right? And so prevention really works best. Context-less prevention, like what we've seen, really works best when you're thinking, "Yes, I have so much noise coming in from the internet, etc. Of course, I need to prevent everything that's obviously malicious."
But when you start looking at the things that are authenticated, if something is obviously malicious there, then you need to take a different approach, hopefully, a more playbook approach rather than just prevent, because the next request that person's going to do is probably going to be a bit more subtle yet still malicious, right? So, this diagram basically tries to show that, right? I mean, we have an authenticated API consumer, they're getting blocked by the WAF, but then they issue a different request which go through, because it doesn't have any signature hit in the WAF, basically.
Slide 28: Attack from an authenticated user Demo
And this is I think what we'd like to show now in the second demo here, right? So, we are going to show an attack from authenticated user through that flow that we have with the WAF and the Kong API gateway in our vulnerable API implementation. But, of course, now what we need to do is we need to authenticate, right? So, we want to authenticate. We have some very creatively named users. So, we have name1 with the password pass1, and what we're going to authenticate is that user just so that we can access the rest of the API. And we're sending the request, it goes through via Kong to the API implementation, and we are getting a token back. Basically, the token says, "Yes, your name1 is a signed token and you're good.
Now we're going to take that token and we're going to paste it here. So, we're going to use it in the authorization header. Yeah, excuse me. And what we're going to do now is we're going to basically go and we're going to go after one of the books that are in the database. And we know that because we know that. There's a book called "War and Peace," and it has a blurb telling you, you know, what's in the book. And we issued a request, again, as an authenticated user. So, we are name1, we're authenticated, we sent the authorization header with our token. We got the response back via Kong from the implementation, and we do get the blurb. So, one piece broadly focuses on opponents' invasion, etc. Brilliant, a completely benign request.
But we are a nefarious attacker, so we're not happy with that. What we want to do is we want to say, "It looks like the API implementation is actually serving text files," right? And typically, what attackers do is they would decompile your mobile application, they would look at which requests are being sent from your web application, etc., etc. They would sort of reverse engineer what you've written, and if you are actually accessing a file, they would go, "This is nice. I want you to access a different file," right? Whoops, not good. I need to copy that token again. Just a sec.
And so what we are going to do is we're going to ask the API implementation to go get us a blurb called etc/passwd, right, which is, of course, a sensitive file containing all the usernames. And we're getting blocked. Who's blocking us? Right? We're an authenticated user and the firewall is evidently blocking us, sending us its 403 page, which is very, very nice. So, the firewall basically said, "No, there's a path traversal attack here, and you guys are not allowed to do that." So, it's blocked by the WAF. So, this is brilliant, and being blocked by the WAF is, of course, very important.
How does that look like inside the Neosec platform? So, we're going here and we see the path traversal alert this time on an entity called name1, and it's a user-type entity, not just an IP address out there, and it does get blocked. Now, we could actually go and investigate and look at that entity's timeline. We're not going to do that. What I am going to do is I'm going to show you one of our automated action policies, and we talked about those in the previous demo snippet that we've done. And this one is basically block path traversal users in Kong, right? So, if you have an alert that's called path traversal, which we just saw that we do have, then the action that's being taken is you block that consumer in the API gateway.
So, what does that mean, basically? Right? So, what that would mean is that if I were now to go back and run my, give me the "War and Peace" blurb, right, which is completely benign, and I've been given that previously, then I'm getting access walls blocked, right? And this is actually coming from Kong, right? So, the API gateway is now blocking the user because we have set a response policy that's not just looking at each and every request without considering whether it's authenticated or not. It's looking for, hey, there's an authenticated user that did path traversal. I want to block the user from accessing the API for 30 minutes until I do something, right? Of course, this is a very simplistic playbook, but you can do more complicated things with this approach. And so this differentiation between authenticated and unauthenticated is really, really key.
Slide 29: #6 Are you protected against logic attacks?
So, sixth and final degree of runtime API security. Are you protected against logic attacks? Right? And this is really, really cardinal. This is important. Why is that so important? Basically, because there are no signatures for logic attacks. Not only that, when you talk to white hat hackers and you can just go and watch YouTube videos, you can look at, you know, responsible disclosures, disclosures through, you know, HackerOne, Bugcrowd, etc., white hat hackers just say it out loud. They say, "Our number one attack vector for APIs is logic attacks. They're so cool. They're so nice. Nobody's looking for them. You don't have any compensating security control. We're just getting at them," right?
So, whether they're attacking the authorization logic in those BOLA and BFLA attacks, the Broken Object Level Authorization or Broken Function Level Authorization, or they're actually going after the application logic, like trying to get a negative interest rate or something like that, they're going after the logic and there's absolutely no signature. The WAF is completely oblivious to that. It's really business logic? And so API attackers focus on this. There's no compensating security control for this. And architecturally, WAFs and WAAPs just can't do that, again because they don't have the context. They can't store and process and use lengthy context. They don't understand the users. They can't profile long-term behaviors. They also don't classify the data typically being transmitted and which users access which data, right?
So, really logic attacks are the biggest issue that we're seeing with WAFs and WAAPs. And we're going to show a fairly simple one here that's actually going to sort of devolve into BOLA as well I think, and that's going to be parameter fuzzing and then a Broken Object Level Authorization exploitation. And they're going to basically happen sort of together.
Slide 30: Parameter fuzzing and BOLA exploitation Demo
So we know that our, what is it called? Name1 is now blocked. So, we have to now authenticate it as another user with the name name2. So, we're going to do that. Nothing bad here. We're just authenticated as name2 with the password pass2. And it goes through. Everything is good, and we're getting a token, which is, of course, important. So, we're going to take that token on and gonna paste it here. And what we're doing now is we have a file called book-fuzz. And that file, let's cut, book-fuzz, basically has a lot of book titles in it, like "Pride and Prejudice" and bookTitle1 to, I don't know, what, 39. And we're just going to try and get all of those books. This actually happens a lot, right? And don't forget that we're an authenticated user, right? And we're going to do that slowly, sequentially. I mean, this script is very, very simple, right? Until one request is done it's not going to spew out the next request.
So, this is not going to get blocked by any rate limits or SpikeArrest policies or stuff like that. It's very slow fuzzing, and we're basically looking for books. Don't forget books, in our case, have a secret associated with them. So, these are sensitive resources. I mean, it really happens in real life, just not with books but with your users or the user accounts or the resources that the users managed in the API. So, it's really logic-dependent in your API. But here it's books.
So, let's just do that. And so it's going and we are getting the statuses back from the API implementation, status fail, book not found, book not found, book not found, book not found, and so on, and so forth, right? It's going through the firewall. There's no problem there. It's an authenticated user. There's no signature. Nothing is obviously malicious here. It's just a user, an API consumer behaving vis-a-vis the API.
And finally, we start getting access was blocked, right? So, we're getting message "Access was blocked." I believe that this is from our trusted Kong API gateway because of yet another policy that we have set there. So, let's look at that. Let's look at what happened here, right? We have a lot of fuzzing going on, and after I don't know how many, right, between bookTitle14 and 15, suddenly the user, name2, started getting blocked. So, how did we reach that? Because this is really sort of a holy grail thing to reach. So, we reach that by... And let's go to the Alerts page first. Actually, we're already here. Let's go to the Automated Action.
So, we have another action policy here and that action policy says, basically if the alert is any of these, right, so it's an authenticated user doing reconnaissance, then block that user for 30 minutes, right? And so we did have one of these alerts. Let's go look at which alert triggered. And so we have path parameter fuzzing attempt, right? So, what happened here is we have the user name2 used 32 unique path parameters in 10 minutes, whatever, all 32 requests failed, so it's just an attempt, hence it's low, and we're actually seeing that. Now, you'd notice that another alert triggered again on the user name2, and that one is a suspicious data access attempt. And again, it's an attempt, but this is really one of our BOLA detection models. I mean, yeah, it says OWASP API1, which is BOLA.
And so name2 tried to access what might be another user's resource, right? So, what the system does is it establishes that there are relationships between various resources and various users, at least this model does, and then when someone, an API user tries to breach that relationship and go get something that isn't theirs, then this model basically triggers. And you can actually go and you can investigate all the user behavior and see what actually took place. Typically, you wouldn't need to do that. That's why we have our managed threat-hunting service. But I just want to show that, you know, all of the calls are here, all of the information's here, and you can see that the user is actually getting blocked.
Edward: Yariv, so is this fuzzing or data scraping, or could it turn into data scraping?
Yariv: So, this is fuzzing. The terminology is a bit nuanced there. This is fuzzing. Fuzzing is definitely one of the avenues that might lead into a data scraping attack. After the attacker basically establishes which resources are out there for the taking, right? And so then they go and they just start scraping those resources. And those resources could contain, you know, customer records, other types of sensitive information, which in our case was depicted by that secret associated with each book. But definitely, recon often leads to data scraping, because once you know more, you can definitely start downloading stuff, and it also leads to more nefarious things such as destruction of data and things like that. All depends on who's doing the attack.
Edward: Thank you.
Slide 31: Summary of 6 Degrees of Runtime API Protection
Yariv: To wrap up "6 Degrees of Runtime API Protection." Are all of your APIs behind a WAF? How uniform, how robust are the WAF policies? Consider how many WAFs you have, how many data centers, different WAFs, different policies, etc. Can you take advantage of a positive security model? And if that doesn't scare you, you're in a very good place. Are you inspecting east-west traffic against all of those attack vectors that we looked at? What happens when an authenticated user attacks? And even worse, are you protected against logic attacks and behavioral anomaly use?
Slide 32: Summary
So, in summary, you know, signature-based prevention, which we've looked at, and we conflated WAFs and WAAPs here because, from a runtime protection perspective, they're really alike. It's an important security control. You need to have it, and you do need to consider all those things, right? But you may also need to compliment your WAF with dedicated API detection and response, which is a very different approach if APIs are business-critical, if you can't mitigate logic abuse, right, with other compensating security controls, if you have several types of authenticated consumers, which means that they can move laterally and escalate privileges and we see that in more complex APIs where you have various roles, you have admins and support people and you can impersonate some other user, etc.
So, in those complex situations, you definitely need to be able to monitor entities better, authenticated entities, and, of course, if you have other non-runtime protection requirements like a unified API inventory and all of those things that we haven't touched on because they're completely out of scope for this webinar. So, I think that's it for me, Edward.
Edward: Thank you, Yariv. Really, really interesting. Thanks so much for that. We're coming up to the end of the time, but we've got time for one more question. And the question is, in a WAF you just blocked something, is block the right response for API attacks?
Yariv: So, you're asking, is blocking good sort of? So, I think prevention is a good start. I mean, you have to have prevention as I've mentioned previously because the internet's just noisy and attacking you all the time. So, you have to have that, especially for unauthenticated traffic. But in today's world, when you look at the business criticality of APIs, you really need something more. You need an automated playbook. And this is where the industry is going when you look at enterprise security, and this is where the industry needs to be going when it's looking at business-critical things such as APIs. And this is, of course, very relevant when dealing with authenticated users, and this is really where detection and response comes into play. I think that that's definitely the way to go with APIs.
Slide 33: Thank You
Edward: Okay, thank you, Yariv. Thank you for all that information. We're unable to get to all the questions but we'll be answering those in the panel. Now, just wanted you to know that there are some downloads available for you. So, download the white papers that we have in the side panel here. So, please take use of that resource. And also, if you're interested, this recording will be available after this event. You can share it with your teammates if you think it's appropriate. It's available on the neosec.com website. Also, if you'd like to request a free trial of Neosec and test it out, that is available from our homepage at neosec.com. You can just request that there. So, again, thank you very much for your time. Really appreciate it. And thank you, Yariv, for all of the demos and all of the education.
Yariv: Thank you so much.
