This automatically-generated transcript is taken from the IT Pro Podcast episode ‘The problem APIs'. We apologise for any errors.
Rory Bathgate
Hi, I'm Rory Bathgate.
Jane McCallion
And I'm Jane McCallion.
Rory
And you're listening to the IT Pro Podcast, where today we're discussing API vulnerabilities.
Jane
Application programming interfaces, or APIs, have become an integral part of maintaining an online business, and can be incredibly useful in facilitating cross-functionality and improving user experience.
Rory
However, the increased use of APIs has led to a rise in attacks against them, which can lead to breaches of company data or even full account takeovers.
Jane
Today, we're speaking to Yaniv Balmas, VP of Security Research at Salt Security, to discuss the threats facing businesses that use APIs and how to mitigate them.
Yaniv, thanks so much for joining us.
Yaniv Balmas
Hi, it's a pleasure being here. Thanks for inviting me.
Rory
So to start off with Yaniv, if you wouldn't mind, could you start by unpacking the concept of APIs and where they're commonly used?
Yaniv
Well yeah, it's actually pretty easy to understand. APIs are sort of a language. And that's a language that modern services, online services talk. So you know that everyone, in every company, every business today that wishes to go online has some kind of services published over the internet. And the way or the language that allows users or machines to interact with the service is called APIs. That's basically what it is.
Jane
And so obviously, we're here to talk about security problems with APIs, what kind of attacks are levelled against them? And are they more vulnerable than any other kind of potential attack surface?
Yaniv
Well as I said, APIs are a language and language is a complex thing. Basically, there isn't only one language, there are several languages in which this service talks and people can basically invent their own languages as well. Now, inventing languages or using languages, or languages in general as I said, are a complex thing. And it's very easy to make mistakes, or to have flaws in this language, or words that don't come into place and stuff like that. When you do it in normal language, your sentence will be misunderstood maybe. When this happens with services, the consequences can be much more severe. When you're speaking a different language than the service is expecting to hear, there could be one of many, many, many issues that will follow starting from very simple things like, you know, simple error page or server crash or something like that. And ranging up into, you know, information disclosure, full account takeovers, and stuff like that. That's the consequences of languages or API errors in our day and age.
Rory
So a lot of businesses use APIs to communicate between different servers or different front end and back end websites. Do you think that there's a tendency for businesses to maybe spread themselves too thin with their APIs? Or are businesses adopting them on too broad a scale?
Yaniv
So if you look at, you know, the growth of APIs over the past, I don't know not a lot, five, six years. I mean, if we would draw it on a graph, it would be an exponentially growing graph really, really high. So everybody, basically everybody wants to have online services today. And if you don't, if you're a business, and you don't have an online service, probably you're gonna move to doing that or you will be basically out of business. So everybody's rushing to put services and to define new APIs, and to put them out there. And you know, basically, human nature to favour functionality over securities, it will always be functionality first, these this is what my customers expect to have. So I will first give them that and then I will go and dive deep and check if everything is secure, or no and that is not a specific problem with APIs. It's with every new technology anywhere, right? But this dramatic increase in usage of APIs is what makes this really, really, really important today and the amount of issues flows vulnerabilities that we have seen in APIs is absolutely breathtaking. I mean, it's there's just so many issues out there that still needs to be addressed.
Jane
So Yaniv, when we're talking about this talk from sort of a fairly technical-type view, a slightly abstract type view. To put this into concrete terms for our listeners, what does an API attack look like? What is an example of an API attack?
Yaniv
Okay, let me give you a pretty naive example. It's very understandable, you don't need to be really technical to understand it. And I think it showcases also the potential impacts. So let's assume that you're using some kind of, let's say, online document service. Okay? So using this service, you can basically edit documents, you can view them, you can delete them, you can share them and everything, everything else. Now, think about it for a second, what happens when you try to delete a document? Basically, your computer following your click on delete the document, will send the request to the server and this request will go to the API of the of the service, right? And it will say, "okay, operation, delete", and document ID, "this is the document ID that I want you to delete". The document should be deleted right? Now, there's a really important thing here. Because the server must make sure that the document that you are requesting to be deleted, is actually owned by you, it's your document, you actually have permissions to delete it. And when the server fails to do that, that's where vulnerability has happened. So and you know, it sounds, it might sound like a pretty naive example. But you'd be surprised of how many of these exact examples do we find each and every day. So basically, if I were an attacker, that would allow me to pretty easily delete every document in the system or a specific users' document, all I need to know is the document ID. Sometimes it's easier to know that, sometimes it's harder to know that. But in both cases, it is possible. That specific vulnerability, by the way, is called 'BOLA' - broken object level authorization. So that's the technical term for that.
Jane
So it sounds almost like it's a configuration problem, rather than a problem with APIs. in and of themselves.
Yaniv
I wouldn't call that a configuration problem. I would call that a software engineering problem, a bug somebody... that definition, basically, we just described every vulnerability out there, whether it's APIs or not APIs, or software engineering bugs, and that's no different.
Rory
So to get specific, Salt's Q3 2022 report found that your customers experienced a 117% increase in API attack traffic, while their overall API traffic grew by 168%. What's leading to these attacks? And are these numbers likely to remain high?
Yaniv
What's leading to these attacks? Well look, the vulnerabilities are out there. It's a relatively new field, as we said, which is why the vulnerabilities are there in the first place. But you know, from the other side of that, attackers whether they are cyber criminals or just kids playing with APIs, nations trying to do things, they are new to that field as well. So they are learning how to attack as well as we are learning how to defend. And as time passes, yeah, more attackers join this API attacking club, and that's why we see this increase. And if you're asking my predictions on the future, I don't see that stopping or, you know, start being in lower volumes. Quite the opposite. I see that keep increasing, and even increasing more than what we've just seen. So there's, there could be a pretty direct relation between the growth of APIs and the growth in the number of attacks.
Jane
Kind of from my point of view, it's a bit easy to be, I want a better word than 'cynical' because I don't want myself to show myself in a terrible light, however, about these kinds of numbers here, 117 and 168 look massive, but it depends on your starting point. Obviously, if your overall API traffic is growing by 168, and your starting point was several thousand, then that's kind of a big number. But if your API attack numbers are 117% sure, but if that's your starting point was two, then that's it's a big increase but the actual numbers are smaller than it appears. So do you know what we're looking at in terms of those? The actual comparison between API traffic and API attack traffic?
Yaniv
Yes, of course. And I think it all boils down to the question of how do we actually get those statistics? There could be many ways to do that. So we can, for example, count each and every request and count each request has an attack. We don't do that. Because if you do that, numbers will be dramatically higher. We try to aggregate attacks and kind of, you know say "okay, all of these requests, it may be ten requests, a thousand requests, a hundred thousand requests. All of these relates to the same attacker in the same attack", and that's counted is one. So when you say the number, if you want, if somebody else would have counted it, it might be a million. It all depends on how you count. And let me tell you, report or no report, statistics, or no statistics me and my group and other people deal with these cases each and every day. And let me tell you, this is an issue. It's a real issue. It's everywhere. We see vulnerabilities everywhere, and we also see attacks everywhere. You don't you don't necessarily need to believe us when we say that, but you know, just go and read the news. I think that almost every week or so, there's another catastrophe being published with another huge vendors’ APIs. So it's really apparent that this issue is out there, and the numbers are really high.
Jane
I'm sorry, I know a bit of a follow up question. Rory's not getting any questions today. Talking around all this, do you have any insight on who these attackers actually are? You kind of mentioned nation states and professional hackers, and what we would have called script kiddies back in the day. Yeah with API attacks, is it more appealing to any one of them than others, to somebody doing more sophisticated stuff? Or is it across the board, everybody's going down this route?
Yaniv
That's a pretty good question. And you know, in fact, one of the hardest thing to do when you're analysing attack is to understand who exactly is the attacker and what is the motivation? It's not always possible, it is possible sometimes. I can tell you that look, let's take our attackers' spectrum and divide it into, let's say, three major parts. As we said, there is the very, very high end, which is nation state sponsored attacks, right? They are cutting edge, they have unlimited budget and unlimited resources. Whether or not you look at attacks, or you identified if they are attacking, I can assure you that in a very high probability they are already playing this game, right? But that's very specific. And probably if it's nation state, then the targets are also pretty specific. Depends on the nation, probably. But that's one part of them. That's not a surprise, because they do everything from everything, right? The middle part of that, the more let's say technological researchers, hackers, whatever you want to call them. Yeah, they are slowly starting to move to this area. And you see a lot of more research being published on APIs. So they are basically motivated, usually, by financial. So they are cyber criminals. They want to attack you, because at the end of the day they want to steal your money in that way or the other. And they do it really well today with other attack vectors, other than APIs. And slowly we see them, you know, starting to realise that, "okay, that's also an attack vector. And it's out there, might be easier to do than, you know, the other attacks that I'm doing". So we see a gradual shift of cybercrime going into API attacks. But then there's the, that's the really interesting part of that, there is the low end of that, as you said, the 'script kiddies'. Just you know, some people playing with computers, not necessarily very technologically advanced. They don't know anything. The nature of API attacks, you know, maybe finding a vulnerability in APIs might not be that easy. But once you found this vulnerability, it's so easy to replicate that. Any kid basically can just, you know, pick up his computer and do that. It's really that easy. And in, you know, in this day and age where information sharing is just everywhere, you just need, it's like, it's like fire, spreading fire. If just someone would identify that, post that in the wrong forum, you will immediately see just a few hours later, a bunch of attacks happening on that specific vector. And that's, I would say that that's not very common for all attack vectors. I'm not talking about APIs for others, sometimes the technological bar is pretty high. So even if you know the vulnerability, it's not really trivial to use that in APIs. That's not the case. If you know the vulnerability, it's completely effortless to do that, which is basically what makes them even more dangerous in my mind. Yeah.
Rory
So it's, in some ways, it's a path of least resistance thing where it's just APIs are, in some ways, the go-to for an easy attack on an organisation?
Yaniv
If you're a good researcher, or a good hacker, a path of least resistance is always the way that you go. You will never want to waste too much time or effort on doing something if you have an easier option to do that.
Rory
Right, yeah. On a specific example of API attacks, security researchers recently discovered API flaws that allowed them to remotely unlock luxury cars, and access functions such as parking cameras. You, in fact, commented on that for us in the article we published on it a short time ago. Cars are kind of a flashy example, but is business hardware similarly vulnerable to attacks such as these.
Yaniv
The problem is not with the hardware. It's, yeah, the hardware is there. And APIs can communicate with hardware just as well as they communicate with software. Basically, APIs is, as I said, it's the language, it's what wraps your technology, whatever it will be. An embedded device, a web service or anything else, right? So cars in that respect, are no different than any other online services. The only question is, what functionality is exposed over these APIs? And as you saw from the published research, and as we see from other very similar research that we internally did, yes car manufacturers as all other businesses, they tend to publish a lot of services out there. And to expose them over APIs, as I said, in favour of the customers to make their life easier to make the cars more accessible. It's all about functionality. And, again, as I said, security always comes second. And that's a wonderful example for that.
Jane
Yeah, I suppose if you can remotely turn off my heated seat, then you know I'll have a cold bum, but it's not going to be the worst thing in the world. Whereas if you can remotely disable or mess with my cruise control or rev limiter or anything like that, then that's going to be a bit more of an issue.
Yaniv
Exactly. Just, you know, initiate your ABS when you're not expecting it. Think about the consequences.
Jane
Yeah.
Rory
So with all of that in mind, with that kind of terrifying example, what measures can an IT decision maker implement to protect APIs against attacks?
Yaniv
Well, the first thing you need to do when you want to protect something is to understand that there is something that needs to be protected. Unfortunately, in many cases, that's not how it happens. I think many organisations, many businesses today, especially if they are not coming from the technology market, they are not really aware of the risks in APIs. I mean, they understand that they expose more functionality there, and they don't understand that it comes with a risk. And I think that understanding the risk is the first step, it's almost 50%, of finding the solution to that. And really, by the way, in Salt Labs, that's our main goal is to educate people to shout out that, "hey, guys, these wonderful new APIs that you have out there, they're wonderful. That's right. But they're also an issue and you need to understand that". But once you understand that there is an issue there, then really there are a lot of things that can be done. And it's really not very different from dealing with any other type of vulnerability that you have. So if this is a product that you are developing, if it's code that you wrote, then you need to practise secure development and to understand the common API issues and address them in the development stage. If it's a third party tool that you're using, then you need to test it to make sure that, you know, it complies with everything and that it stops everything, all the relevant API attacks. And then finally, once you've deployed your solution, that's not enough because this world is constant, it's dynamic. It's constantly changing. There are always new attacks, every day you hear about new techniques and a new attack. So a good idea would also be to monitor in real time your API traffic, try to understand what it means and look for any anomalies. So there are things that you might know, I mean, you know what to look for and other things, you know, that they could be there, but you don't exactly know what to look for. So monitoring for anomalies could really help you out in, you know, pinpointing those places where something bad could happen. And then finally, there's not maybe not related to the vulnerabilities themselves, but you need a good incident response. So if something does happen, you need to make sure you know how to deal with that. And to kind of confine the impact, so it won't be too dramatic. So that's my two cents of protecting APIs.
Jane
I mean, this is all well and good for larger companies who have their own IT departments, who are doing their own development. The UK or Great Britain was famously demeaned by Napoleon, actually, as "a nation of shopkeepers". And we still, maybe not shopkeepers, but we are most of our companies operating here, most of our businesses are small businesses, micro businesses, maybe medium at the top end something like 99%. How can these organisations that almost certainly rely on external IT companies, whether that's sort of a some kind of channel partner, or they've just outsourced the whole thing because they're a three person band, and their speciality is audio mastery, or whatever. What should they be doing? Is there anything that they can actively do to protect themselves? Or is this something they should be looking for, and discussing with whoever they are working with?
Yaniv
Yeah, so I think the, if you ask me personally, I think the second option is the more realistic one, right? Because if you're a small or medium business you don't do any development, you only trust third-party vendors to provide everything that you need, then you need to trust this vendor to be able to handle API security as well. And it's no different than you go and buy your own, I don't know, Windows operating system right? Now you trust Microsoft to make sure that this operating system will not have any vulnerabilities, and they are doing a pretty good job of that. Not, it's not dramatic of course, there are vulnerabilities, but they've been doing an increasingly good job at that over the past years. And the same expectations should stand for APIs as well. If you're uneducated in that, if you're not technological, it will be very hard for you to try and test how good this product handles API issues. But it's really the same thing with any other type of vulnerabilities. So yeah, again, API in these regards is not very different, you're just taking it one level higher. So if you don't, if you can't protect or make sure your APIs are protected, then your vendor should do that for you. So it takes the problem to the vendors' front door, and now they need to address that. Some, by the way, address that pretty well. Others, not yet.
Rory
So having discussed all of this, given the fact that API's are apparently such a popular attack vector, does the benefit of using them really outweigh the risk?
Yaniv
Can you imagine your life without APIs? Well, maybe you know, maybe you don't know what APIs are. Let's assume that. But let me tell you that today, according to statistics that we didn't do, we looked at other who did these specific statistics, around 80% of all your web traffic is routed through APIs in that way or another think about it. When you're shopping online you're using APIs. When you want to check your COVID certificate, you're using APIs. When you want to do a voice recording and store it in the cloud, you're using APIs. Almost everything, every function that you are using today, over the web is using APIs. So I would say that, you know, taking APIs down because they are risky. In my personal opinion, wouldn't not be the smart thing to do. Yeah, we need to grow forward with technology makes our lives easier. It moves us forward. But yes, we must always understand that new technology comes with new risks, and we need to address them. The real problem comes when we don't understand that there is a risk, or if we don't address it. If we will do both of them, we'll be in a much better situation than we are today. And I think that slowly, gradually, we are getting there. We're still not there, it will take some time. But this podcast might also help a bit in doing that, I hope.
Jane
Well, unfortunately, that's all we've got time for this week. But thank you very much to Yaniv Balmas of Salt Security for joining us.
Yaniv
Thank you very much. It was my pleasure.
Jane
Thank you. As always, you can find links to all of the topics we've spoken about today in the show notes, and even more on our website at itpro.co.uk.
Rory
You can also follow us on social media, as well as subscribe to our daily newsletter. Don't forget to subscribe to the IT Pro podcast wherever you find podcasts. And if you're enjoying the show, why not tell a friend or colleague about us.
Jane
We'll be back next week with more from the world of it. But until then, goodbye goodbye
