Alex Argeris - {"Is API the next top cyber threat to your organization ?"}

Um, that's not mine. I don't know if someone has forgot their clicker. The last presenter. I think this was ours. Yeah someone. Yeah, of course. Just make sure we're uh try to position it so that you're not touching this as much as possible.

This is ours. You can use it if you like. No, no, that's fine. No. Um, is it HDMI only? No, there's Do you have HDMI? Oh, yeah, we do. Okay. There is USBC converters.

Give me a couple of second here.

Okay Mike. Yep.

Quick intro while you're doing that. Yeah, of course. All right. So, um, for our next talk, we have Alex. Correct me if I'm pronouncing your name wrong. Arjurus. Arurus. Arurus. There you go. Alex Arjurus. Um, and we're going to be having some prizes after this, so stick around.

Can you guys hear me? Well, mic is

perfect. Let's start. Let's go ahead. Um, so I if I remember correctly, this summer I did um look at LinkedIn and I saw a post from Robert saying, "Thanks God, right? Bside is coming back on track in person." So, okay, what the heck I'm going to present this year? I'm not quite sure. Uh, for so for those of you who know me, um, I've been a security analyst at Belandanda for many years. Uh and then I moved into the obscure world of sales um with Cisco uh eight years ago. Um so my core business is typically threat from endpoint, email and network security in general. Um so two or three years ago um I decided

to move as well to another world which is um devops or seg devops right uh with xdr um so with this it come everything related to API of course right uh we tend to integrate everything with API um so when I saw a post from Robert I say okay what the heck I'm going to present this year and I say okay I think I'm going to talk about API Um, first of all, I'm not an expert on API security at all. Okay. Um, so I did some research um in prepare to be able to build that uh slide deck. Um, so hopefully for the next 30 minutes or so, we will have a nice discussion on API

security. Um, and of course I came up with a great title. pretty sure you guys are or at least if someone has asked me a couple of years ago or even last year what is the most or the the thread vector right the most thread vector that is used by cyber criminal and so on so forth I would say email right um but I'm not quite sure if this going to still be email in the next couple of years right it may be API in reality so let's let's try to figure this out um so just a little bit about myself for those of you don't know me um as I said I work for

Cisco uh as a security analyst or not security sorry sales engineer uh focusing on security um and I've been presenting at Bside for many years thanks to teams of Bside uh on multiple different uh subject from DNS sync calling u crypto um SSL decryption or not couple of those one as well a fun topic of Right. Um, so I like to do skiing over winter. Um, big fan of road bike as well. Um, and I have very nice family. Okay. Um, you're lucky. That's that's that's part of the story as well. You're lucky because every year Bside is exactly the same week as my birthday wife. Um, so, so it's always a like, am I going,

am I not? So, the end of the story, I'm going to fly tomorrow morning with the flight at 5:00 a.m. back to Montreal. That's uh that's the end of the story. Anyway, um, so typically I consider my talk as sexy, right? Or fun, right? funny with some videos and all that reference to some external stuff that are nice to look at and stuff like that. But unfortunately, API is not sexy at all. It's it's almost boring at some point, right? Um so let's try to um to see what we can come up with for the next couple of uh minutes here. Um so um a couple of warning here of course um I'm here on my own, right? I'm not

representing Cisco at all. Um, and please, please, typically I would say please ask question. So, it's going to be boring, but this year I'm going to say, you know what, don't ask too much question. I'm not a security expert on API. Instead, add comments, right? Raise your hand. Say if Alexander, you're you're totally wrong, right? uh that's not what's going to happen in the next couple of years or here is that the reality of API and so on so forth, right? Um so I can be able to learn from you guys and you also going to be able to share that content as well or that knowledge with the other folks in the room as well. Make

sense? Um so first of all I do have a ton of pigs here. Those of you are familiar with the snark pigs. Uh I didn't know until I walked here what I was going to do with it. But I always have a dream to be able to throw those one right in a room. Um so if Caddyy one for you caddy one for you. So if you guys had any comments that are nice, right, I will do it as well. Ken, one for you over there. Or if you want any of those one after the talk, I'm I'm sure you're too far. Oh, I'm sure that we will have a bunch of those one available at the

booths as well. Okay, so uh let's let's set the table. Okay, make sure that everyone is on the same page. Um, so first of all, when we talk about API that that those statistic essentially are based on on couple of research that I did, they are all available of course. Um, and I have the reference at the bottom of the page as well. Um, so and I was very very impressed by that number on the top. Okay, it's in 2021. So I guess that number has probably increased a lot as well in 2022. But I know I don't know about you guys but at home I have three children that are almost all teenager and and when I

look at my firewall the statistic it's more roughly 99.9% of Tik Tok YouTube and Netflix and so on so forth and not API but in reality if you look at traffic apparently the vast majority of the traffic over the web it's API okay so what we do with that Okay. Um and other statistic that are pretty interesting to look at as well. This is from Radarware they say that most of the organization are seeing a lot of increase into the usage of API. Okay. So I guess and my guess is all your organization are probably using a lot of API to do all kind of funky stuff with it. Um so this statistic is pretty

interesting as well. If you look at that, it's from solid security um based on a report that they are or survey that they did. Um if you look at the percentage of those API attack comp over the the last year comparing to the increase of API traffic and overall for the last with the same period it's it's it's crazy, right? Um so that's why that's one of the reason why I think API is probably going to be a very big problem for us in the next couple of years. Um if you look at the other statistic as well where almost 100% 99 98 99 95 sorry percent of the respondents said that they have been

suffering from a potential threat um leveraging API as a vector right essentially um so there's a bunch of number over here as well if you look at that text uh but essentially um the most important thing in my mind is the documentation right or having API that are well known by your organization or API that at least are known by the organization right it's mean that most of the organization do have API that are leveraging probably on a daily basic that they do not know right so what about if that API is vulnerable for example has a has a security patch need to be applied or or so on so forth So who here thinks that

um microservices and container or whatever SAS application or even low low-level API are secure by default. You're totally reason I'm I'm sure that they're not right. um typically and and if you look at most of the product out there and I consider my product at Cisco or any other product as well with from any any other competitor they are made to be simple right so by default we do not apply too much security right so typically we will say um go ahead and apply this and that to make it more secure same thing apply here with the API that's my Yes. Uh if you look at the other statistic as well, it said that open

source code are more secure. I I would tend to say yes, right? Um it's it's all depend perspective. Some people will say no, some people will say yes, of course. Um but if you look at open-source code, um typically there's a bunch a bunch of people that are looking at that code, the source code, and make it better. So let's take it a step back and and let's look at the base of what API is. I'm pretty sure there are some of you you may uh but don't really know what API is. Okay. Um so if you look at that uh description over here which is coming um it's a little bit old and I say that

there it's not totally true anymore. Okay. It said that API is typically a way to communicate between uh two services um to application to server right without having having a human interact into the communication itself right it's not intend to be um used for user interface so on so forth not anymore so far I think that um if you're using a browser with extension you have application on your iPhone, Android devices, there's a a great chance that behind the scene a lot of API is used to produce that content that you're viewing on those application or viewing on on those extension in your browser as well. Okay. So what there is mainly two u big

uh API um I would say type right um rest API and and SOAP API I have not deal with SOAP API at all. So if there is anyone down here that have been dealing with SOAP API and still do some development around it good for you. uh but the vast majority of the uh of the population around the world are more tend to uh use are more using rest api itself. Um if you're look looking at rest api it's more based on um a web type interaction. Okay it's leveraging and we will look at that a little bit further. It's it's leveraging HTTP method that we're used to uh typically um and it's it's used as well

JSON file that most of the um programmer coder or whatever um are familiar with to exchange data whether to uh um ask for a control ask for um a command or to get a response from a from a a specific request comparing to SOAP where it's used the old makes sense. Um, and most people don't like as well. Um, this is probably a a very old 2020 statistic, but whatever. It's it's just to show you the difference between the usage of SOAP versus uh REST API versus the rest of the type of the all the other type of API. Okay. HTTP or API HTTP method. We're used to pretty used to the first one. All right,

get. But there's many more. And the reason why we're used with the get one is because when we use our browser, um I would say probably 99% of the time we do. So we are asking for some content on our browser using a get and then we expect some some response from the server. most of the time is HTML content to be displayed to our browser. Um same thing apply here with API right so we're using the get uh requests to for some content to be shared with us and there's as well so post um typically will be for command right um so if we uh look at a server or application or router or a

firewall then we will post to change some type of configuration within the the devices itself. Um there is put and patch right? So if you want to change something in a database or or update something then we will leverage the uh or patch um HTTP method. And then the last one delete of course uh it's the the one that we want to use if we want to remove some content from a specific uh application uh where we're using our API. So, let's look at the API security challenge. Um, some of you may be familiar with the OAPS, right? Probably some of you, right? There we go. I see someone knocking his head over here. Too far.

Anyway, um, so um I have and there's there's one guide specifically. There's one guide for um top 10 uh on API. Okay. So those those are the guide to identify some type of vulnerability that can apply to some some sort of system. Um and I have choose to um look at specifically at six or five um five different um vulnerability and we will go over them in the next couple of slide. So the first one is broken access control. Um so of course same thing apply here. So based on the last talk where we were talking about zero trust and entity so on so forth um same thing apply here with API of course right so typically

when you will create an API set key which is typically a secret or whatever um then you will also assign a role to that API set key right or a key set um whether it's um a view role only handmin role or whatever other role that you will have also set or or created within your application. Pretty important to test that right at some point, right? Um, make sure that if you create an API uh an API uh key um that is supposed to have only view access then this API key cannot do a delete on any of your data within uh that application right tested. Um same thing apply as well um with the

evaluation of evol evolution of privilege or or being able as well to do uh things like manipulating the data if you're not allowed to. All right. Security misisconfiguration. Um so like most of the um technology out there there's always default configuration. Okay. Um sometime default configuration are not the best. Um and even if here we're talking about API um there is still application that leverage API um that has a web access for admin right so make sure maybe that the the default user and password has been changed um things like the the one that I like over here um it's the error handling so if you're creating your own API I or if you're um

uh testing an API, it could be a good thing to look at the error that that API is giving back when you're I don't know doing a bad request, right? So, you want to make sure that that uh error handling message is not telling too much, right? Just enough for the developer, for example, to be able to fix that request and not more, nothing more. Um, of course it's all about updated U component all around that API and it's including as well the um the layer of application where that API is right it could be the physical box it could be the OS and so on so forth as well um so make sure to patch all this system make

sure to apply correct fix upgrade it so on so forth identification authentication failure. Um so of course there's multiple things that could apply here. Um I'm pretty sure maybe you have been um you're familiar with URL where you see session ID within the URL itself and even worse sometime you will see API keys directly into the URL as well. Some people will say ah we don't need to worry about that it's GTPS it's encrypted right okay but what will happen if that traffic go to a proxy that dosl encryption right everyone that is access to the log will see the API key within that log okay that could be an issue here um so the

other one as well is how frequently you change those API key right back to the previous talk on zero trust where we were mentioning uh MFA for example so we're pretty good now these days on doing MFA control right um so we ask all our our our employees to use MFA for almost any type of connection authentication to all our application that we have but we're pretty bad of doing something similar with the API key um and worse than that typically when someone are asking asking us to get an API key, we will either send that API key and the secret to email uh to teams or whatever other channel that we're used to use, right? And we will never

change it. That's that's that's the worst part. Um the the other things as well is people will leave or their API key within script and they will publish those script on public GitHub or other public repository as well right don't forget typically when you publish something on GitHub it's almost there for a life right um so that's could be pretty bad so logging in general Uh I'm a big fan of logging uh of course uh but uh important things don't log everything. Um security uh stuff is pretty interesting to look at including auditing logs um access logs. Um there is some commercial offering that can look at all that data and detect trying to to detect a bad behavioral um

tentative of connection. Of course am I missing one point here? No, I'm not. So, an extra one here. Um, and that's coming from my network background, right? Um, DDoS, right? Denial of service. Um, which is not part of the uh top 10 from OAPS, but I think it's it's still one that is pretty important to look at as well. Um, so you want to protect the access to those API resource, of course, right? Um, if you have, for example, a competitor of you that is mad at you, it could try to DDOS your access to your API, right? That could a service that is degraded or or even available for your own customer. Okay. Um, so that's could be pretty bad.

The other thing as well with DDOS or with scraping in general for those of you do understand that that that word where we do scraping for web information you can have your competitor that leverage that API to scrape all your data right that is publicly available to take advantage of maybe price that you're giving to your um your your and try to see if they can sell it for cheaper course in real time almost real um API documentation which is another one as well I think it's missing into the the top 10 one from our webs um so there's two type of documentation for um I would say for for API the one that are

public and the one that are private um so most of the API that are public do have that are publicly available and the reason is pretty simple like if I'm customer of AWS, I want to be able to leverage their API. Of course, same thing for Microsoft, any other Salesforce, whatever other SAS provider giving the service. Um, so the documentation needs to be publicly available for sure. But in this case, I doubt that there's a lot of problem within those AP those documentation. There's probably a bunch of people that went through and find all the different uh um issue with it. But on the other hand, if you're building an in-house application that is um

leveraging API and think about it, should you publicly um uh expose your API documentation, right? I don't know, maybe it could be part of your uh business, maybe not, right? if this API is just leveraged internally that it maybe doesn't make sense to publishly um to p publish that API documentation make sense. So the other part as well is swagger. So for those of you are not familiar. Wow I'm trying this. Someone was asking one over there. Oops. Oops. So the swagger is another one that is pretty interesting. So for those of you are not familiar with swagger, it's typically the a diagram of all your API tree, right? Um it's help a lot for

developer to look at all that. It's kind of a documentation as well that can be leveraged by many different people to do good things or bad things as well, right? Um so again if there's no requirement for you to publish this to the outside world keep it for you. So it's a so now it's time to learn a little bit. Um so if you're not familiar with API here's your chance. Okay the easiest way to uh start to start with API is to use your regular browser and that's it. Right. um instead of having an HTML content showing in your browser then you will have the JSON result from that HTTP request which is an HTTP request to get detail on a

specific IP over here which is Google. Okay, of course um you're not going to be able to do all kind of fancy fancy API requests with your browser. um a start. If you work a little bit further than that and start to play with free API, there's a ton ton of free API available on on on the internet, okay? That are that are always on things that are from weather to price on stuff to jokes, cats, uh picture and all that. There's tons of the those API that are publicly available. Like if you look at rapid uh I think it's rapid API um they have um they have a way to search through those one um so you can

subscribe to some of those API and leverage it into your own project if you want to if you want to start playing with your own API for example test your own API as well or even those those API I strongly suggest to use Postman um so Postman kind of the tool to be used Right? If you want to go a little bit away from a CLI and the Linux shell or whatever other shell that you're using with Python, then you can leverage uh Postman for that. Okay. Um the great thing about postman there's a lot of um uh organizations that are are creating their own API creating as well right um that can be download and

all this package include endpoint um so which is URL um for for all their API any questions so far who wants a pig So the next thing here is to uh those top 10 um OOPS uh vulnerability. Um so unfortunately I have not been able to test it myself. Um but the um that tool seems to be updated. Um so a couple of months ago so I guess it's not too old. Um, so essentially it's a docker that has his own API that has a ton of vulnerability typically associated to the top 10 of OAPS. So if you want to test that, that's a cool way to do it, right? Start with it. Um, and of course the question, do I

test this in a production environment? The answer is always it's up to you right? Yeah, it's some some people will say no, some people will say I don't have the luxury or I have no choice, right, to do it in production because I don't have that API elsewhere. Um, so totally it's up to you. Uh, I will say it's a it's depend if the API itself is critical to your organization. If it's critical then it may be a good things to wait until midnight or whatever other time of the the day that the API is not as used by uh your customer or your user or whatever u server or application that is leveraging the API itself.

Okay. Um so a couple of tools over here as well. These are most they're all open source tool um that are available through GitHub or any other type of repository as well. I have not test those one and some of those are pretty old as well. Um but the key here is these are all tools that will help you to test your own API or API from your SAS provider or from your iOS application as well that you have in ABS. Um there's a reference over there as well um for the list. Um mostly most of those application will require you it's unfortunately it's not a one button test. Okay. So most of these uh um uh

tool will require you to add some content to be detected. All right. Um please look for this, please look for that and stuff like that. Okay. But at least it's a good um uh script or tool that will allow you to go through all your application or API and figure out if there is any type of vulnerability through it. There is also other tools that are not show here that are commercial tools that will do similar things. Of course, some of them sometimes are part of a vulnerability scanner um product and so on so forth. One tool that I have test myself and this one is pretty nice. It's how to find API key that could be lost in the

wild. Right? Essentially, so do I have any of my developer that has left any API key on a script and uh uh and save that script on GitHub repository for example. Okay. So this tool um it's based on pattern. So you have there's a list of already populated pattern but you can also add your own pattern as well that would look for pattern of API key um and essentially will go through all a list of URL where you have your repository of of script for organization or for whatever other reason as well and it will go through all these script and try to figure out if there's any API key that are left within those those script

itself make sense Um so almost at the end take away. Um so please please please make yourself familiar with API before it hit you of course um be better at visibility. Increase the visibility that you have on on on your API that you're leveraging um at your organization. document all these application as well that may use API without your knowledge and use some open source or commercial or whatever tools to test those API for vulnerability. Okay, any comments any question?

There's a lot

of also another portion that comes from bots. Bots can also attack your so you can also look at bot management solutions. Make sure they have API protection that will look at the trends how your APIs are used normally. Yeah, I do agree. So there there's a lot of API gateway now these days. So typically an organization that has a lot of API will try to forward or for forward all these API or proxy all these API through a API proxy. Uh in this case you can have multiple different look and inspection inspection as well at that at that enforcement point. Hopefully it was useful for you guys and see you next year. [Applause]