Why APIs are a Powerful Ally and Your Achilles Heel, All in One

Episode Resources:

• Resilience Cybersecurity & Data Privacy
• Best Small Business VPN Services – Resilience Cybersecurity & Data Privacy
• The Best Cloud Backup Services for Personal Data and Devices – Resilience Cybersecurity & Data Privacy
• The Best Password Managers for Individual and Family Use – Resilience Cybersecurity & Data Privacy
• 10 Easy Ways to Immediately Boost Your Online Security – Resilience Cybersecurity & Data Privacy
• 8 Useful Small Business Cybersecurity Tips You Need to Know – Resilience Cybersecurity & Data Privacy
• What are different types of APIs? – IT Security Guru
• API Security Fundamentals: API Security 101 – Salt Security Blog
• APIs Have Taken Over Software Development – Nordic APIs
• 5 Ways to Determine if you do Cybersecurity or Cybersecurity Theater – Imperva
• Why Lawyers Should Use Managed Services Providers for API Integrations – Attorney at Work

Episode Transcript

Brian: Hey there, welcome to Fearless Paranoia. We want to thank you for joining us. I’m Brian, the cybersecurity attorney.

Ryan: I’m Ryan, I’m a cyber security architect.

Brian: And we’re here to help demystify the complex world of cybersecurity. An interesting thing happened recently. Well, interesting in that it happened. Recently, we heard from a major telecommunications company T Mobile, that the personal data of 37 million customers potentially including at least part of present company was or may have been taken in a month-long breach that was discovered and shut down on January 5, 2023. According to T Mobile, the breach fortunately does not involve financial information. But they did get plenty of personal information. And if you’ve listened to any of our podcast episodes in the past, you know how dangerous that personal information can be in the hands of a hacker. It puts the person whose information was taken in a particularly vulnerable position, you are now a potential target of incredibly well-crafted and well assembled phishing attempts. Obviously, that’s a bad thing. But what we’re actually going to focus on today is how the breach happened. According to T Mobile, they were reached through a system by which their software T Mobile software communicates with the software of another company. We’re talking about APIs, what they are, what they do, and why they are so popular both as legitimate software tools, and by hackers as avenues for cyberattacks. Ultimately, we’re also going to talk about what can be done to protect your systems from attack that relies on an API. So let’s get the basics out of the way. Ryan, walk us through what we’re talking about here. What is an API?

Ryan: Alright, API is an application programming interface. It’s a really powerful tool that was developed to actually provide numerous different pieces of functionality. It’s typically used as a way for developers or applications to make a connection to another application for sharing or delivering commands or doing administrative tasks or passing and exchanging data and a variety of different integration tasks along those lines. And so then, obviously, that makes it an extremely powerful tool and gives it quite a bit of access to whatever it’s connected to. It’s usually meant to be powerful for that exact reason, which also means that security becomes a paramount concern around things like API for exactly the reason that T Mobile found out quite a few others have found out in the past. APIs are wonderful tools. They allow administrators, they allow vendors and partners and different systems to really automate and make more efficient, a lot of day-to-day practices, a lot of APIs are really, really kind of misunderstood, I guess, by the people that are utilizing them. And we don’t mean that with any offense or anything to anybody. But there’s a lot of them that are usually configured with too heavy privilege with too light of security, too light of a security posture and not nearly enough auditing and logging and monitoring as there could be for a tool that’s got this level of access and this level of privilege in an environment.

Brian: I think it’s useful to kind of understand what we’re talking about when we talk about an API that has access that is too high or too broad to accomplish its specific purpose. One interesting use case that’s in the news right now about APIs involves Twitter recently, Twitter has effectively cut off their API, or at least they’ve cut off the free version of their API that allowed programmers to connect to Twitter’s platform. Interestingly, for familiar with the history of Twitter, the products and innovations created by programmers using their free API have served as the basis for almost every single major feature that Twitter is used things like hashtags at mentions retweets, tweeting photos, and video clips, all created by people not affiliated with Twitter, but who created things that interacted with Twitter through an API. The result was platforms like Tweet Bot, which allowed users to use Twitter and see their Twitter contacts and their Twitter feed. But to see it in a different way, and to interact with it in a different way that works by tweet bot interacting with Twitter through Twitter’s API Tweet Bot takes the data from Twitter through the API communicates with Twitter through that API, and then using that data, reformats it and displays it a different way. So that when you see it, it’s technically a different system. But it’s Twitter’s data, you’re also able to add to Twitter through tweet bot without the user actually being on Twitter’s platform itself. Well, Twitter has decided that at least for their free version, the API will no longer be available. Or let’s say we think that’s what they’ve decided, since they no longer tell anyone anything, or even have a PR or press department, in their company, among other things that are being affected things like well, for lack of better way of putting it, bot accounts, like at Elon jet, that account was a bot that automatically posted information to Twitter, not by using Twitter directly, but by using information from a different application. And then through Twitter’s API, creating an automated tweet that shared that information. Without the free API, you’d have to get the information on Elon jet where it’s located, then log into your Twitter account manually enter the information into a tweet tweeted out every single time well, APIs are everywhere because they’re incredibly useful. In fact, one thing I read recently kind of interesting said that 50% of the communication in business-to-business software, so communication these days, you could almost say it’s communications between businesses. 50% of it is expected to be done through APIs in 2023. That means, as opposed to any other mechanism, including directly using a company’s own software companies are going to have their own version contact with the other company software. So we’re talking about APIs, we’re talking about a lot of stuff, things that do incredibly powerful and incredibly important things and things that every single listener of this podcast well all four of you use every day, it’s a big deal. When we start talking about how these APIs have an excessive amount of authority and excessive amount of access. That’s a big deal, too, it can be really difficult for the average user to get a grasp of how that works, because you don’t see the steps that your programs are going through to do what it takes to interact with the target application. If what your program does is able to work to do what you expect and needed to do that means that the API that your program is using to connect has all the right authority that needs to do what it’s doing with that target application. But the reality is, it probably has far more authority than just what it needs. So what kind of risks are we creating when we create these APIs with authority like that?

Ryan: Well, it’s not so much the creating of the API with authority, right? Because that could be similar to creating any administrator level account, the problem would be is just not understanding the power of the API or the security recommendations around using it. But an API is effectively no different than setting up privileged accounts. To access different pieces of the system, you can set restrictions on what an API can and cannot touch in numerous places that I’ve consulted or worked at in the past, we’ve used APIs to connect different systems together. But each of those different APIs has their own set of credentials, their own set of privileges, that restricted down to what the application needs that it’s connecting to, to avoid any sort of cross privilege or extra privilege from getting in place. And they’ve all got, again, separate credential sets, separate IDs and secrets to keep their access individual so that it can be individually logged individually monitored. And in the case that it needs to be if anything gets compromised, that can be individually cut off without having to you know disrupt the entire service as a whole. Most APIs will start at its core from having access to everything so that those capabilities are there. But it comes down to the delegation of the access that you’re giving the users of the API, that’s really where the security measures need to be put in place. And then in the case of something like T Mobile, where this is obviously a publicly accessible API, and in some cases, you have too many vendors to vet them out and vet out their IP ranges, or you’re allowing the general public, or you’ve got too many partners where that’s just not feasible. And in that case, you have to be very diligent on the provisioning side and the monitoring side and just make sure that you really balance your security to the other end of that spectrum and watch and understand the activity that is coming through.

Brian:   You’re listening to the Fearless Paranoia podcast. For more information on keeping yourself your family and your company protected against cyber threats, check out the Resilience Cybersecurity and Data Privacy blog. If you’re enjoying this podcast, please like and subscribe using any of your favorite podcast platforms. Also, please share this podcast with anyone you think would find it helpful or useful. We rely on listeners like you to help get the word out about this show, and we appreciate the support. Now, time for some more cybersecurity…

Brian: All right, you said something there that I want to at least run through you talked about a public API. Now there are multiple types or kinds of API. And I want to make sure that we understand the difference between these major types. So there’s obviously the public or the open API. There’s the converse, which is a private API, there are things like partner APIs, which my understanding is basically it’s an API between specific businesses but not open to anyone else. Then there are also things like composite APIs, which are I guess, which aren’t really a type of API like public or private, but rather refers to how the API works. Ryan talks about the differences between these different types of APIs.

Ryan: Yeah, really, at the core underneath the hood, there’s not a ton of difference, it really comes down to kind of use case and how you utilize how you administer and how you secure those different types of connections. Again, with anything public, the security on the network side is easy, you open it to the world, you really don’t have much of a choice at that point. So that’s where it’s important to make sure that you have certain types of technologies in front of it to help you monitor that inbound traffic and look for repeated patterns or known bad traffic to where you can where you’re capable of any sort of web application firewall, or any sort of monitoring like that to at least see the traffic. But for a lot of those, the more important part is to really be watching for trends on the inside. So make sure that you’re doing your general threat modeling around what’s been seen on API traffic and is known being like general threats for APIs, you start to build your monitoring and your visibility around those types of trends to start with, and then just to look for other potential trends that can identify any anomalies, but really, with the open ones, it comes down to the fact that most of that data is really not planning on being secured in any sort of major fashion and that makes it a little bit safe. Were to kind of allow that open API to kind of run-in-place. But that’s again, where you start to see things like Twitter, where again, they’re not really trying to secure a ton of information other than the basic controls that Twitter would have. So, for the most part that’s open to the public, it’s open to third parties to use, there’s just general best practice and general accepted rules around its use. Same with any kind of terms and conditions that would be in place.

Brian: Twitter, I think, is a pretty good example of that just because of the simple fact that a tweet by its very nature is public. It’s something that doesn’t need to be secured, at least beyond what it normally takes to access the tweets, because it’s already public. Now you do have your terms of service that govern what APIs are allowed to do, including sometimes what an API is allowed to use the information, for example, you can’t use the information or the system in an inappropriate way…

Ryan: If you’re being abusive, you’ll get blocked.

Brian: Really, things like that will be a violation of the terms of service and your access to the API will be cut off. But otherwise, it’s information that doesn’t need to be secured.

Ryan: And in a lot of cases, there are some APIs. Some of those open public APIs like that, that are just they don’t have authentication on the front, because they don’t need it, the data behind there is meant to be openly freely accessible. So, if you add an API into like Wikipedia, they’re not hiding any of their information, there’s really nothing private or anything back there. And if they want you to be able to access it, you know, that’s something they can certainly offer up and then you just have access to their whole set of data. But there’s no reason to put an authentication lock in front of it, there’s not one on their website, you can access the same data the same way.

Brian: One notable thing about Twitter though, is they do have a higher paid tier probably involving something about the volume of the data that you use being the reason that you need to pay. Obviously, if your API is going to cause a significant workload to be placed on their servers and their hardware or cause extensive burden to their systems, they are probably going to want you to pay for that access. For something like Twitter, it may seem trivial, but they still have to pay their power bills just like everyone else does. Beyond that, it’s your access to the existing data that’s not secured.

Ryan: Exactly. So, you start to get to like the private in the business-to-business type ones, those tend to fall a lot more in similar categories. Again, it tends to kind of fall into how private or how direct is the connection read to be, you can really have kind of a private API that is more of just like a registered API, where it’s still really open to the public. But you have to have proper authentication to get into it. And the data behind it think like

an API that uses a connection to an email account to Microsoft Outlook, for example, technically, it’s open, but you have to have the authentication for that user for the API to work

exactly. So, I’ve worked as a software development partner in the past, and they wanted to be able to send mail through Office 365 from their applications securely. So rather than go through legacy authentication, like back in the day, we use username, password instead of putting hard coded credentials, and you can delegate API permissions to it. So you create effectively your mail account, you delegate a client secret and a client ID that you hand to the application to use as basically username password to validate itself to this enterprise application. So, you never actually give the sending application direct access to the mail server in any way. There’s an intermediary in the center that has the API access. So really, they take the API call and hand it off to this application, which then either provides its output or sends the traffic on and does whatever the process is that’s being requested. That’s a real kind of basic private API setup.

Brian:   You’re listening to the Fearless Paranoia podcast, we’re here to help make the complex language of cybersecurity understandable. So if there are topics or issues that you’d like Ryan and I to break down in an episode, send us an email at info@fearlessparanoia.com or reach out to us on Facebook or LinkedIn. For more information about today’s episode, be sure to check out Fearless Paranoia.com where you’ll find a full transcript as well as links to helpful resources and any research and reports discussed during this episode. While you’re there, check out our other posts and podcasts as well as additional helpful resources for learning about cybersecurity. Now, back to the show.

Brian: The funny thing is that Twitter can actually provide the example for that as well, with the ability to authenticate your access to other company’s services by using your Twitter account, authenticate through Twitter, it’s when you use your Twitter account, essentially, to serve as your login credentials for some other service. Just like you can use Gmail, authenticate through Gmail, authenticate through Facebook, authenticate through Instagram, those platforms that allow you to use your account with them to log in to other services. And they want you to do it because usually it means they get access to the information that you share with the other service. But it’s still your Twitter account to authenticate you to a third party. It’s not public, and the information that you’re accessing is not publicly accessible, and you need credentials to log in. But it’s also not entirely private. It’s not solely within one organization, you are using Twitter to log in to that other service. So yeah, these are things that I think people use every day.

Ryan: Yeah, API becomes part of a much bigger picture that we could spend a whole lot of time talking about. Because API is really a connective tissue between numerous different technologies. And that’s really what it is. It’s not even a great technology just on its own because it to me, it’s similar to like scripting technologies, other core, you can produce small tasks, one off with an API, and that’s great. But really the true power of API comes when you start to integrate that into other workflows and other applications and start building this bigger picture of day. To exchange that secure and that seamless, and it’s quick and accessible from all over and gives you the ability to interact between applications without having to have a person sitting in the middle providing the privilege or providing the access between those. That’s where you start to really kind of see that power because it opens up a lot of capabilities for collaboration between business units between different businesses between different marketing and collaborative partners, creative partners, the opportunities are just endless. But really at the core, what we’ve done is we built a language. This is a language that computers and technology uses to communicate with one another. And that really is the true power and the magic behind the API. It just means that with that power comes a lot of responsibility of making sure that if we are going to enable it, that we understand it, that we use it properly, and we secure it notably and understand what the responsibility is if we fail to check those boxes before enabling that tool.

Brian: You kind of touched on exactly the thing I want to talk about next. While APIs are phenomenal tools that can be really helpful and create better ways to use existing applications as we discussed earlier regarding the history of Twitter API has also become a way for software developers to cut costs and shorten development time for software and applications. So instead of fine tuning a UI taking the time trouble to make sure an application is designed properly and is usable for multiple different types of users. Software developers can make a basic interface with limited practical applications or with a focus on very limited customer base, and then provide access to raw information through an API instead of spending the time and money on further developing their product. They say here, here’s the API, you don’t like what we put together, you can program your own version at your own expense, but you’re still going to pay for our underlying software. Well, in the best cases, APIs can potentially make core software and data a bit cheaper, while allowing us to craft a user interface that best suits our purposes. But it also seems like it can contribute to the culture of cost cutting and the releasing of incomplete software. Unfortunately, that means that security’s gonna get reduced amount of attention as well. And we can’t forget that the API is still part of the software. So how much attention is the API getting when it’s installed, it starts to get really easy to see why it’s become such a popular route for cyberattacks.

Ryan: Yeah, the two main points again, that we keep reiterating, they’re popular with hackers, because they’re very often overprivileged, they’re very often mismanaged, or under managed. And they are a very easy and usually publicly accessible entry point, a lot of times, it’s something that you can sit and just poke at repeatedly. And now again, all it takes is one successful use, or one successful attempt to authenticate to that and all of a sudden got significant amount of power and access. And that’s a very valuable thing. It doesn’t require a whole ton of extra skill set once you get beyond that point. So finding something like somebody’s API key or certificate or that type of information could really just open up a very large and gaping hole on the side of a business’s perimeter that until they start to see the actual impacts, or exfiltration, or something happening at that point, they may not even notice the malicious activity at the point of login initially, and there might be a lot of discovery being done that just looks very benign until something happens. And a lot of times that that case, it’s far too late to do anything about it.

Brian: You can see that was apparently the case with T Mobile, they were able to shut it down, but it did take 24 hours. Well, that’s all the time we have for today on Fearless Paranoia. We hope you enjoyed hearing about APIs and how amazingly great and horrible they are all at the same time. You do use them all the time, you probably use several just to get to the podcast today. They are incredibly useful and powerful tools we wanted to stay secure along those lines, please tune in to our new episode next week, which is going to be part two of our API discussion where we go through some best practices to make sure that you can keep APIs safe, we want to thank you for tuning in today. For more information on APIs including our sources and some useful links check out this episode is posted on Fearless Paranoia.com. You can also find information on how to improve your own personal cybersecurity including various tools and applications at Resilience Cybersecurity. If you have any suggestions for topics or things you’d like us to talk about, you can send us an email at info at Fearless Paranoia.com. Or you can reach out to us on any of the social media accounts that have not been blocked yet. For the record. I think they actually reopened our Twitter account. I still haven’t done anything with it, but I’ll try to get to that. Also, don’t forget to like and share our podcasts on social media. We rely on your support to help us get the word out about our episodes. Once again. Thank you for joining us for Fearless Paranoia. I’m Brian.

Ryan: And I’m Ryan.

Brian: And we’ll see you next time