FireTail at Infosecurity Europe

‍Jeremy:‍

Hello! Welcome to this rerecording of FireTail’s session from Info Security Europe in June of 2023. My name is Jeremy Snyder. I'm the founder and CEO of FireTail, and I'll be presenting today on the topic of APIs, the attack vector that connects us all and where traditional security fails. So in today's presentation, we're going to go through a few examples of API security breaches and we're going to dissect what happened, what was the root cause in each of those breaches. We're also going to examine why traditional security falls flat in the face of APIs. 

‍

So just a few words about me to kind of start today's session. I am the CEO and co-founder here at Fire Tale. I've been in the cybersecurity industry, roughly speaking, for a little over 20 years. For the first half of my career, I was a hands on keyboard practitioner, and I transitioned into more customer facing roles in terms of sales, product strategy and consultative implementation approaches. And I've been working in this space for a long time. The last kind of seven years, I spent heavily focused on cloud security, working with innovative organizations around the world, a lot of digital native working at high scale, and we found APIs to be one of the most interesting attack surfaces to look at. And we know that APIs are going to be one of the most frequently targeted attack surfaces going forward. That is actually the vision behind Fire Tail how and why we started the company. So let's dive in if you have any questions on today's presentation, my contact info is on the screen. Please don't tweet at me, just email me instead. I'm super inactive on Twitter, so if you do tweet at me, I'm very unlikely to see that in any questions. Feel free to reach out any time. No worries at all, but please do so by email. 

‍

So the first question is how do APIs connect us all? You know, the name of today's session is APIs are the attack surface that connects us all and where traditional security fails. But let's talk for a second about how APIs do connect us all. So first thing I want to point out, and this is a statistic from a few years back that's been widely cited and verified, and that is that more than 83% of internet requests are API calls. Now, that's not to say the volume of bandwidth being utilized or the volume of data being transferred, but the number of requests. So it's not, you know, your Google search, my Google search, your email, me reading a post on Reddit, things like that. It's actually all of these third party composable services. And one of the things that this speaks to is that this is the way the modern internet is built, and you can actually view this for yourself the next time you're loading up a web page, particularly a content type of page, pay attention to the status bar down at the bottom of your browser and watch what gets loaded along with that page, and you'll see that you've got, you know, Google Analytics, you've got third party services, maybe you've got, external referral links, maybe you've got syndicated content and a bunch of other things that kind of stitched together to kind of build that page. And that really is how the internet is built nowadays. And when I say the internet, I mean content, I mean applications, I mean services. 

‍

Second thing is we are on track to have a trillion APIs. So I think the time frame or the target date for that is 2030. We're in the billions right now. I think we're in the tens of billions technically, but we do see with the rate of increase, it very much is pointing in that direction of having a trillion APIs over the next seven years or so. 

‍

One example that I really like to give, that I think can make this point quite relatable to everybody involved, is the example of a mobile food delivery app. So very little actually happens on your device when you're ordering food through one of these services. So the first thing that happens is, you know, your phone does fetch your location. Typically that's GPS coordinates. And that is then sent to a backend cloud service over an API based on the coordinates. Your phone is then going to get back a list of restaurants that are available for you to order from, maybe also things like menus and so on. When you create an order, all that you're really doing is kind of patching packaging up a transaction, which is to say you've selected the dishes or the items that you want, and then you click submit. And together with that submission, you send your payment details, you send your address and things like that. So that's again one or more API calls sent to this backend cloud service. Now from that point forward, the payment credentials are sent to a third party payment provider of responses received both API calls. The order is sent to a restaurant, response is received, confirmation is received, and then also updated information about preparation time, estimated time for availability for pickup, etc. again, a set of API calls and then a delivery is coordinated with the delivery driver. But again a set of API calls. 

‍

And so you know, one of the things that I did live with the audience at Info Security Europe and you know, it's kind of hard to do over this recording. But I asked the audience, you know, how many API calls went into this was this 0 to 5, 5 to 10, 10 to 15 or more than 15? And the answer is, of course, more than 15. And I actually take that from a conversation I had with a security practitioner at one of the leaders in the mobile food delivery space. We started together on counting the API calls in a transaction. We got above 25 and we said, okay, that's enough. We know it. It's an awful lot to just make. This one transaction is just a whole lot of API calls between both internal and external services. 

‍

The second thing I want to point out about this transaction is there's a lot of high value data, and there are a lot of critical business transactions happening as a result of API calls. So when we think about the call itself, we're sharing or sorry, the order itself, we're sharing our delivery address. That is PII. Now that is PII, both in the sense that it does personally identify you, but it's also PII in the sense of regulatory compliance and things like GDPR. That is data that would qualify for protection under many of those systems. Second thing to point out is we have critical business transactions that are processed as a result of an API call. So we're sending our payment credentials to a third party. That third party is processing the payment over an API call and sending back a response. So that is all enabling this transaction over APIs. And this is again common for the modern internet with these composable third party services. 1.2s So let's talk about traditional cybersecurity for a second. You know, and I've been in this space for a long time. And when I talk to most cyber practitioners, especially those for more traditional backgrounds or more traditional IT environments, what are the main strategies or the main tactics that get employed? And we hear a couple of things. Number one is we are here, let's define our perimeter and let's keep bad actors out of our perimeter. You know, I am old enough to say that I've spent enough time connected to things like Cisco firewalls over serial cables to know that this is, you know, one of the most common first lines of defense that many organizations will employ. 

‍

One of the challenges around perimeter security is that when we take something like that previous example, you could be using your phone from really anywhere in the world to initiate one of those sessions. What that means is your IP address is completely unknowable to the back end service. So what does that mean? That means that the API for the cloud service that receives the order has to be open to the broad internet. So there's limited capabilities that perimeter security can actually apply to something like a mobile app or to many public facing APIs. They kind of, by definition, need to be open to the entire internet. So that's one challenge around perimeter security. What about the second function, which is something like agents and agents can be things like, you know, antivirus, anti-malware. They could be things like runtime protection etc.

‍

One of the challenges we've heard time and again from some of these more digital native organizations is that they are moving their APIs away from traditional server infrastructure to containerized and serverless environments. What that implies is that you don't really have an environment where you can install an agent. So there's limited functionality offered by an agent relative to API security. The second thing is, and we're going to go through a few examples of the API data breaches, the breach is very often happen at a level that an agent wouldn't have visibility into anyway. So there's some challenges around that. 

‍

And the third is monitoring. So when we think about monitoring, what we often think about is kind of the collection of logs or the collection of system events into one central location that can be analyzed in order to detect breaches or detect malicious behavior. And we see kind of two challenges around that. One, which is the most obvious, is that it is post-event meaning that a breach will already have happened now. If the argument is that monitoring is better than nothing and can help you respond quickly to an event, that's a fair assessment, and I think that's a fair approach to bring. Second challenge that we've heard around monitoring, though, is again, back to the digital native and kind of cloud native side of these things. APIs can run across any number of compute platforms, all of which by default will send their logs to a different location. So this poses a real challenge around API monitoring in the sense that where do you go to look for the right API logs? Do you look on an operating system? Do you look inside network traffic? Do you look inside container traffic, or do you look in yet another location, which is serverless logging? So this is a real challenge around figuring out the right place to look or around centralizing all your logs for your APIs. 

‍

So these are some of the challenges around the traditional environment. And when we think about API breaches, let's go into a couple of examples and see whether those will really work for us. So I've got three examples highlighted here. 

‍

One, the first one here was a good example in the sense that it was a responsible disclosure from a security researcher. The organization took the disclosure very seriously. They did take remedial action in a good timeline and communicated back to the researcher that the kind of attack vector had been closed off. So again, going back to the point around API's having to be open to the entire world. This was the back end for the Starbucks mobile app. It was discovered by a security researcher. Now we had kind of a couple problems here. Number one was that the server actually gave very verbose error reporting. So the researcher started by kind of issuing API calls to API endpoints that didn't exist. And what happened, instead of just dropping those with the standard 404 error, was that the server started to give back more and more details around the application path structure, which led to the discovery of a GraphQL endpoint that may or may not have been intended to be open in production. But the long and short of it, it was available and discoverable. And there was the second challenge, which was that this GraphQL endpoint did not have restrictions around the queries that could be issued to it, and so effectively allowed the equivalent of a select star query via API that extracted 100 million records. 

‍

Now, in this example, we know that perimeter security would fail because the mobile app needs to be open to the world. We know that the agent might have been able to see certain things on the operating system level regarding, let's say, path structure and so on. And we may have gotten some limited capability around the monitoring, but the monitoring would again, at best, tell us that somebody was probing the endpoint. So there's let's say a partial fit here, but not a complete fit and nothing preventative. When we move to our second example we look at Peloton. So this was a breach that was initially disclosed to the company. The company did not take remedial action in any reasonable time frame. And in fact, after the responsible disclosure time period had expired, the vulnerability still existed, and as a proof of concept, 3 million records were extracted from the IoT back end of the peloton device, which again was an API open to the world. There were a couple problems in the peloton example that would be completely invisible to a, uh, to an agent or to a monitoring system. Number one was that the system had easy to guess user IDs, so if my ID was one, I could guess that ID number two would be valid, ID number three would be valid, and so on and so on. So easy to guess and sequential. And the second thing was that even though there was good authentication in place and there was some authorization going on, once any user was authenticated, they were allowed to request any data now to a monitoring agent or to a system agent. This will all look like normal API traffic. And that's one of the big problems. With API breaches. Time and again we've come to publish some research around. This will come to in just a second. Next when we look at Optus. So this is a telecoms provider in Australia that had a recent breach in September of 2022. 11 million records extracted. We see a couple of things. Number one is that challenge around cloud environments. And the challenge here was that one simple network configuration change made something that was private public. So relative to that, our perimeter defense wasn't really well configured or monitored. This is true in many cloud environment. And I think there's a often a disconnect between what infrastructure teams know about network configurations and the blindness that a lot of security teams have relative to the number of APIs or which APIs are running and which environments. Regardless, the change here made an unauthenticated API open to the public, which allowed for kind of investigation of data, updating of records, extraction of data, etc.. So when we look at our kind of three core elements, we'll see. Again, this wouldn't really have been blocked and could have been very difficultly only picked up by any of those monitoring agents. So we've done some work analyzing kind of API data breaches from the last ten years. We've seen a number of really staggering statistics. I think one of the things that's really interesting to observe is that in the vast majority of situations, two or more things went wrong. So just like in those examples we went through, and you'll see that authentication and authorization at the application layer are really the two big challenges that we see. Feel free to download that report. The link was there. We'll have that again. The good news is when we think about API security, a lot of it really comes back to what you might think of as cybersecurity first principles. So the first challenge for a lot of organizations is just establishing and maintaining visibility of all their APIs. The good news is that there are any number of methods nowadays, including, you know, technology solutions that can bring you that visibility. 

‍

The second thing is around assessment. So understanding what vulnerabilities your API has from an application logic perspective is really a key learning. And if you're going to focus on one aspect of this API security, I would recommend identity knowing that authentication and authorization are the top two vectors. And then fourth, think about an audit solution where your APIs can send all your traffic to one single location for monitoring purposes. If you rely on a kind of default operating system or provider offered monitoring solutions, you may face challenges. So you may need to think about sending you the logs on your own from the application layer. And once you get past that, uh, the key areas for improvement are on the runtime. And then connecting into SoC tools and integrating with cloud provider platforms or third party tools that you might use for security operations or cloud security. 

‍

So a couple things we'd like to offer. Obviously, this recording is being done post event, so it's no longer practical to come meet the team at our stand at Info Security Europe. But please do feel free to download the report The State of API security for 2023. We'll have that linked in the video notes, as well as on the blog post where we embed this recording and the slides will be available as well. Again, if you have any questions, my name is Jeremy Snyder. You can find me Jeremy@FireTail.io. Thank you very much.

‍