Jeremy

‍

Hello and welcome to this virtual session from Black Hat 2022. This presentation is part of the open source arsenal my name is Jeremy Snyder I'm the founder and CEO of firetail you can find

us online at firetail.io.

‍

Today, Riley Priddle and I will be talking about open source inline API call evaluation.

‍

Before we kind of dive into the context and the content today just to give a little bit of background on myself and Riley we're the co-founders of Firetail firetail is an open source API security library that is designed to make it easy for developers to build secure APIs quickly specifically it's designed around a lot of the modern application architectures for Cloud native

applications and are designed around open source popular Frameworks for building APIs. 

‍

I have a background in cloud and Cloud security from time spent working for AWS and then working for an early Cloud security posture management company CPSM called Divvy Cloud that was acquired in 2020. I’m a little bit of a global nomad myself, I've lived in many places around the world. Riley is probably my equal in terms of global nomadism originally hailing from New Zealand Riley has spent time living in New Zealand the UK Estonia now Ireland and he's been building Cloud native applications and working with Cloud native architecture for about 10 years.

‍

So we started working on this project a little while ago primarily kind of observing a trend  around the rise of API security technologies and the rise of APIs in general so some of the data shows that we’re on track to having a trillion programmable endpoints in the near-term future these endpoints really refer to APIs which are kind of programmable end points.

‍

I think one thing that is not widely understood perhaps is that about 80 percent of all traffic flowing over the internet right now is API traffic if you think about kind of any activity like ordering take out food on you know Ubereats just eat whatever the app is where you happen to live you submit that one request over your mobile app first of all your mobile app is firing an API call to the back end and then all the coordination after the order in terms of let's say Payment Processing sending the order to the restaurant sending the delivery request out to the driver or the delivery person all of that is done through any number of API connections. So probably what starts off as one transaction may actually generate over 20 API calls to process that one individual order this is growing steadily we already know that we're kind of on the 200 million plus API endpoints with that kind of 20 year-over-year compounding route so that trillion number really looks to be something like five to six years away we've seen the rise of kind of API native companies whose actual product or data set or service is offered over an API. 

‍

So probably a lot of you here today watching this presentation will be developers and you'll also be customers of platforms like Twilio that allow you to access functionality using any number of API calls and kind of building on that mobile app example that we used just a minute ago what you can think about is that effectively every app on your phone every, say, smart device that you have in your home is really kind of an endpoint client to process an individual piece of functionality in any communication with the back end or the cloud service that it talks to is done over APIs so we've really have APIs all throughout our house we have them all throughout the modern internet and then actually, if you think about kind of modern, let's say, enterprise-oriented apps any apps delivered over the Internet, whether that is things like Salesforce, whether that is things like you know Zendesk, or some let's say homegrown application you might have inside your organization you'll find that the dominant Paradigm in app development today really is kind of a decoupled fronted back end where front end is really more of kind of a display layer communing with communicating with the back end that is doing all of the functional processing so what does that mean? That means APIs are everywhere as we know.

‍

I thought there was a really interesting state of the internet report that came out from Akamai they put these out I think twice a year the one from I want to say it's late 2019 but it could be 2020 really talks about how the API is the attack surface that connects us all because of again these trends of APIs really being kind of the glue for app to app communication and really so much of the back end of the internet.

‍

So what does that mean? So, Gartner predicts that API abuses will move from and currently kind of infrequent to the most frequent attack vector. The prediction is on track for this year I would say, it still remains to be seen whether this really is the year but we have seen a definite rise you'll see any number of statistics around kind of a 300% increase on attacks against APIs in the last half of 2021 so we do know that kind of directionally this is the trend we certainly have seen any number of API based data breaches already start to hit the market.

‍

So if we look at kind of the types of problems that are out there we generally can kind of classify them into let's say bad authentication and authorization problems really focused around identity and then we can say like bad kind of call handling or you know probing and payload stuff. 

‍

So when we look on the identity-based side we have any number of authentication problems these are things like APIs that were designed to be internal facing for instance where let's say you kind of assume that you're inside your network perimeter and you've got a number of security controls in place so you don't necessarily design strong authentication or authorization functionalities into the API and then boom some mistake of configuration some let's say firewall rule update that goes slightly not in the way that you anticipated making those endpoints public that's a common problem. 

‍

Another common problem is kind of the problem of authentications checked no post authentication authorization didn't grab an example here but that's actually a large category of API data breaches as well you'll sometimes see those referenced as either IDOR or BOLA is kind of the new name that has been given specifically to API oriented problems of this type broken object level authorization.

‍

The second category that we classify under the bucket of kind of let's say bad calls really there are two issues there one is on probing and enumeration, very often what that can lead to is kind of exposing the back end API where there is kind of an assumption that the front end of the application whether that be mobile or web-based abstracts that back end away from the end user and so the end user or the bad actor may not see where that API sits at the back end may not be able to kind of expose the routes and methods associated or available to that and then you sometimes also see the a very common paradigm now with modern API development is to kind of move away from rest APIs and move towards GraphQL-oriented APIs and so what you'll see is kind of a lot of graph APIs or sorry GraphQL APIs are meant to be kind of hidden away but again enumeration and probing techniques if not properly handled with giving let's say a 404 error at the HTTP layer sometimes that makes those endpoints discoverable and very often they don't do the last part which is kind of payload inspection.

‍

So we look at kind of payload inspection in a case like John Deere what we saw there is you know you could actually interact with the API in real time issue one character at a type kind of queries there was nothing on the API checking for the valid structure of a query so that could be either in the form of a request parameter or in the form of a payload, in this case it was request parameters so any single character could be passed to the back end to discover more functionality or to try to trigger a response um now their case was actually coupled with a couple other things like some bad authentication protocols. But you can kind of see the categories forming the types of attacks that work against the APIS and attack surface and that expose some of those weaknesses in let's say the design of the API and these are really the types of problems that we set out to solve with FireTail so we're going to get into that now so let's talk about how do we solve this.

‍

So when we started with that approach of kind of understanding where the problems are we realize all of these things come back to the configuration of the API so this is not let's say vulnerabilities in the classic sense of let's say CDES or things like that, it's really vulnerabilities in the way the application was designed and that's the root cause. So what we kind of came to a conclusion of is if the root cause really sits at the design of the application that's the layer that you need to be in you kind of need to be in that application layer of check now you can try to address these problems with things like WAFs or with things like let's say network detection and response type of technologies but there's kind of two problems there one is that with these being a application layer problems most of the time to a WAF just looks like normal traffic against an API um there's not necessarily a set of rules in the WAF to account for let's say all the potential request parameters to kind of weed it out and similarly kind of the responses going back will be passed as kind of you know ordinary responses coming from that API and if we try to address it with network detection and response technologies let's say by aggregating network logs and kind of inferring what where the APIs live on the network and then inferring what normal API traffic looks like, at best we can kind of get you know a sort of post-breach notification that we've been breached.

‍

So we started looking at the problem from the standpoint of (A) thinking about how we could be preventative knowing that we need to be in that application layer and then (B) looking at how developers are building APIs today so we look at kind of the most popular frameworks for building apis we took some data from some AWS developer surveys looked on the list of most popular code languages and then for each language what we found is there is really kind of one emerging corresponding standard for what the most popular API framework is for that code language and we thought about kind of aligning to those now we started with Python and open API because that was actually the number one language coming off of that survey and when we started having conversations with people who were looking at API security and building APIs for their native Cloud native applications this was the overwhelming number one choice. 

‍

So we looked at Python and open API you may know that by Swagger as kind of I guess kind of the former name of a open API it seems like Swagger is kind of becoming a library within a broader framework that's where we started our development and again we we kind of looked at it from the standpoint of where do we need to be at which layer do we need to try to target our solution in order to get full visibility onto the things that we know are problematic again based on those attack vectors that we saw and so when we thought about kind of okay we need to be able to see both authentication and authorization uh we know that that meant we need to say the API call and then we need to say the API header for authentication purposes but then we need to see the full payload to understand the request and to try to do some logical evaluation around authorization in that similarly when we look at kind of enumeration improving type attacks we realize that something like an API Gateway gets you one step closer but you could use like the application layer for that as well and then when we look at kind of payload style attacks where you could let's say you know literally enter one single character as a request parameter there you really need to be at the application layer and that's where you can get the full visibility onto the stack that you need and so again this is kind of where we decided to target FireTail.

‍

So the way FireTail works is that basically you can go to our GitHub repo you can download the repository to start writing an application you grab that open API framework you start building your API on top of that you include the firetail library and that's about 15 lines of code that wrap your application with that Library there is a separate security specification file in the HTML  format that you include and then you deploy your application so then what happens is a FireTail distribute and deploys with your application so it is horizontally scalable will kind of run wherever you're running this it sits in line and then what it does is it does a set of logical evaluations that pass fail in the API request.

‍

So the first thing is you know reading out of that Swagger manifest we understand the routes and methods associated with your API and as a request comes in we check hey where is this destined for is it using the right method if not let's fail it with either a 404 or the appropriate 40 excuse me I can't remember off the top my head but the appropriate error message for wrong method. Then we do a quick authentication check looking for that looking into the header looking for the type of authentication requested which will again be present in your security spec. And then last but not least we have a regular expression evaluator to look at the request parameters or the request payload and there what it is is it's it's really the only part of the application that is not kind of let's say declarative slash zero trust oriented where with the first two it will only pass if it matches up to what's in your spec, with the security specification with this last point we're looking for prohibited items so generally speaking requests will be allowed to pass unless there is something in a regular expression evaluator that you say should not be present. 

‍

So there there is kind of the overall Logic the quick starts are live on our GitHub right now you can see some sample apps there are some code samples for understanding how to deploy this understanding how to build that security specification there's a couple examples of security specifications up there and with that I'm going to to share the quick repo URL with you and pass it off to Riley for a demo of the product. Thank you very much for my piece.

‍

Riley 

‍

My name's Riley Priddle the co-founder here at FireTail today I'm going to give you a product overview of the Python code library called FireTail so the purpose of this API library is to allow you to define your API within the Open API standard and it to on startup set the API up on flask

so you can define your routes your methods your path parameters and query string parameters and how they should look so here we have a products endpoint that has a kept method has an operation ID and this links directly to the code function so by a request coming into this endpoint it will call main.getproducts so mean is here and this is get products here and this will return back to list of products.

‍

Furthermore with parameters you can specify the required parameters you can specify if they're actually required or not and you can validate on a regular expression pattern this one here will validate with alphanumeric so if a query comes in that does not conform it will return a 400 error code with a message you can also specify the security on this endpoint here we have JWT and API key if I just scroll down to the bottom here that these are defined here for JWT this attribute here Maps it to the code function so this will end up calling JWT decoder.decode token which is here decode token and this function takes the token in validate whether the default is not valid it will raise unauthorized section here which will return a 401 to the forum. 

‍

So what I'm going to do now is I'm going to run this API okay now this API is running what I'm going to do is I'm going to call this API okay so here we have Postman running and we're going to call this endpoint that's running on localhost as you can see here so if I call a get here you can see that it's missing the query string parameter category so we're going to add that in now and now the API is returning as you can see here within the open API document there is a pattern that only allows alphanumeric characters. So what we're going to do is we're going to come back here and we're going to non-alphanumerics here and the clothing app doesn't form to the pattern and this is a 400 request and this response can be modified as well. 

‍

We can also turn off the requirement there and that returns back everything now.

‍

I'm going to now show you a authentication example this endpoint slash products the get method has a security schema of JWT and so in Postman here I'm going to call this with the authorization attribute now and you can see that it returns back a valid response of products now if I remove this see that it says no authorization token provided if I provide the token again but invalid you'll get a 401 response saying that the authorization bearer token isn't downloaded now if I try and call an endpoint that doesn't exist endpoint does not exist you can see that it returns a 404 if I call product standpoint with a method that is not set up the post you can see that the method is not allowed for this request is the response as a 405.

‍

So what I'm going to demonstrate now is how you can have API requests logged to your own custom back-end or a SaaS platform backend. So what you do within the library is you import the cloud logger from firetail.auditor and then you set up the Cloud logger now this means that there is a event that happens for every request it'll put it into  a pool and then it will send in groups those logs or individually if there's not that many requests coming in for your own endpoint you set the custom back into true you set your your own pinpoint and this post uh blogs and align delimited plain text.

‍

Now I'm going to show you this running so to start up the my login point to illustrate and I start the app I'm going to make a request that is bad so we're going to post to the products endpoint which doesn't exist and you can see this is a 405 response and we can see here that there's a request that's coming to the login pointI'm going to copy this into my notepad and as you can see here this is what gets logged so you can see the URL full URL endpoint you can see the headers paths the IP address any um queries from parameters that are passed or any path parameters you also get the full response hitter's body status code and we also extrapolate out the OAuth sub from the token that's provided and this allows you to map the user to the call.

‍

Jeremy

‍

Thank you very much for watching this demo of FireTail’s Open source library for inline API call inspection including the ability to apply preventative blocking measures if calls do not conform to the security specification of the API endpoint FireTail also includes the ability to log API call events to either a local or a cloud-based platform. Enjoy the rest of Black Hat 2022 and keep your APIs safe.

‍