Eric Brown: 0:05

You're listening to the Audit presented by IT Audit Labs.

Kyle Rosendahl: 0:15

Welcome back to the Audit. We are here today with Matt Starland and Nick Mellom and myself. How are you guys doing today?

Matt Starland: 0:25

Doing awesome, excellent, happy to be here.

Kyle Rosendahl: 0:30

Yeah, today is really a continuation of our last episode that we had with Matt Starland, where we talked about the T-Mobile breach and some other security news stories. And I know towards the end of the episode last time we really got cut off, or cut ourselves off, because we started to dive really deep into kind of the policy implications and all of the pieces that go into that and could, you know, even lead to prevention of these breaches or why they might not be in place. And so we invited Matt back in to come in here, chat with us a little bit more and really take an even deeper dive than we did last time to really just go over potential ways that it could have happened, what you need to do to prevent these types of breaches and common security measures, and talk more of those administrative controls and policies that you can use to protect environments like this. So, matt, I know at the end of the last episode I think we cut you off specifically about API security right and the T-Mobile breach. For those that either didn't listen to the last episode, you know I would recommend going back listening to it.

Kyle Rosendahl: 1:43

But the long and short of the story is that T-Mobile experienced a pretty big breach where the threat actors or the attackers had access to their public API and were able to pull down personally identifiable information of over 3 million yeah, 37. 37 million T-Mobile customers Not social security numbers are necessarily really protected information, but enough, that's phone numbers, number of lines on the account, address, things like that and they were able to conduct this breach by using the API over the course of like a month and a half and we're able to, you know, exfiltrate all of this data out of T-Mobile servers. So we were getting into when we cut ourselves off, just talking about, you know, some of those API, public connections and that new kind of cloud infrastructure and how that changing landscape from this on-premises environment to these, you know, more cloud-connected, interconnected environments, and how the security and the policies and the administrative changes need to be different in order to, you know, better secure this type of data. So any thoughts on that?

Matt Starland: 3:00

Yeah. So, yeah, going back to like what you're saying. When we talked last time, you time we really talked at the high level of administrative controls, just company policy procedures, and even the one thing I like to pitch a lot to some of my fellow IS colleagues is least privilege access. And so what does that now look like from the technical perspective of this API? So when I start to look through or think through this process of, well, how would somebody connect to T-Mobile's API? Well, are they sitting there sniffing the connection, trying to decrypt it? Well, highly unlikely. A lot of those types of connections are using pretty high-end TLS encryption ciphers. You're using TLS 1.2, 1.3, something like that, and I mean the likelihood of them intercepting that and then cracking it is pretty unlikely. So then I would also then look at the next risk how did they then gain access? Was it some vulnerability in the API itself Maybe, being that this is a T-Mobile and it's a high-profile company and you got a little bit more sophisticated attackers trying to attack that or is it going back to what I was saying before? Is it a least privilege issue, for an example here of where you can easily overlook permissions here and somebody could gain access, not when an organization, maybe like T-Mobile, might have not have followed these privilege. So if you're connecting to, let's say, you're using Azure AD as your identity provider and it's also you're using Microsoft 365 resources, sharepoint Online, teams, exchange, etc. And so now let's just say that some of that data, this customer data, was residing in let's say, it was email, for example. So you had a third party of some sort of host and provider that has an application that they need to integrate into your email system, so they can, you know, schedule meetings, invites or read emails and show you certain bits of data within your emails to integrate with their application. And so when vendors like that, you know, provide a system administrator or security engineer, admin details on how to create that integration, the vendor, that third party, is just looking at how quickly can we make this an easy, you know, for the organization integrating our app into their system? How do we make it as easy as possible?

Matt Starland: 5:58

Some of them do look into maybe that least privilege, but it's not always necessarily there, and so they'll give you the easiest permissions that you can get this integration up and running. So, for example, then you're starting to create this app registrations into Azure AD. Then you're starting to create this app registrations into Azure AD. You create either a certificate for it and you provide that third party that certificate, or you create the secret key and give to them and then you assign all those permissions within that Azure AD app registration. Well, when you're creating those permissions, microsoft really gives you blanket permissions.

Matt Starland: 6:37

For example, one of the applications I've seen that wants access to email when you're using those API permissions it just says all mailboxes. So you might be integrating an application that only needs to have access really maybe to 10, 15 users, but the API just gives a blanket access to all mailboxes. And so when you're looking at that configuration page within Microsoft, they don't give you any configurations right there and then to easily limit that to just what's needed to have access. So now let's just say you give that information back to the vendor host that you know that certificates or that secret key and somebody on that side disgruntled employee or something gets breached on their system to where, wherever that key was stored is now available within either their network or maybe that person download or the malicious actor downloads it to their infrastructure and then tries to make a connection back to that app registration within Azure. Well, they have access now to all mailboxes, even though that app might have been only designed to be really needed, used by 10 mailboxes. So that's an example right there, so, of how that would be overprivileged and where Microsoft, out the gates, does not give you something right at that configuration console, an easy way to just limit that permission.

Matt Starland: 8:08

So this is where, as being a security architect, engineer, when you're looking at some of these requests coming in assuming it's even coming to you and or maybe it's another way of educating the other team that is integrating these is what they need to. You know, look out for, ask the questions like well, who's this all being used by? And that seems a little bit overkill that we're adding this to the entire organization's mailboxes versus just 10. And then doing some more research to see is there other things out there that Microsoft provides to limit this? Because, in my experience working with some of their exchange online platforms, if you're just going based off of the GUI, really the GUI only gives you about 50% of what you can actually configure and control. The rest is all being done behind the scenes using PowerShell.

Matt Starland: 8:57

So in this instance, here, this example, we're talking about using this Azure App Registration. That's what you actually need to do. You got to do a little digging and you'll find a TechNet article out there that talks about how to create a policy and then tie that policy to a group of users and that policy then can connect to this as your app registration. So when that vendor is making a connection and they are scanning or trying to connect to mailboxes that are maybe relevant to that the identities that you've added to the security group that they're supposed to have access to they'll work just fine. But if they were trying to access another identity that's not in that security group that you created via PowerShell and that policy and tied it to the app registration, it gets denied. So that's one way to look at you know, limiting that.

Matt Starland: 9:47

But the other one is to is a conditional access policy. So so for the example I gave is that you know, let's just say that that vendor, third party was breached and those credentials were then offloaded to wherever that threat actor is coming from, and then that threat actor is trying to make a connection back to that customer. You know T-Mobile's environment that got breached customer. You know T-Mobile's environment that got breached. If T-Mobile, for example, had that conditional access policy, not saying that they use Azure AD or using conditional access policies, but just let's just say they used that in that instance and they said all right, we are going to only allow connections to this app registration from the IP address that is associated with this vendor third party. So that way if that threat actor is trying to now come from another connection, boom, it's getting denied.

Matt Starland: 10:42

But also maybe their SOC team or their security engineers could be putting in you know, monitoring too that says, hey, anything that's coming not from this location.

Matt Starland: 10:54

Also, you know, create an alert, anything that's coming not from this location. Also, you know, create an alert, because then that's going to also give us an idea that these credentials have been compromised and are being used somewhere else or I mean it could be an app dev person too, testing some things and or they forgot to give an IP address, but at least somebody on the T-Mobile side would be getting an alert to question and whether or not, why, why this connection is coming from something that we were saying it's only allowed from. So you know, from the technical aspects, I think that's kind of to me that's easier. Breaching these is just finding that least privilege and just use using passwords. I know, kyle, you've got a little bit more red teaming experience and specialty than I do. I sit more on that blue team architecture side of the world. Have you dealt with trying to compromise APIs or you know, kind of like AWS S3 buckets or Azure blob storage before?

Kyle Rosendahl: 11:59

Yeah, apis are an interesting one that I haven't touched a whole lot, right, and yeah, I guess for anyone listening that doesn't necessarily know what an API is is it's essentially a program that's running on a server somewhere that's waiting for a specially crafted internet packet to be sent to it. That packet usually is protected by sometimes a username and a secret right. So a lot of times if you want access to the API, you have to sign up for the website or pay for the service and then when you sign into your account, they'll give you a secret key that you include as part of that request to that web server and then it returns you the information. So you have to tell it what you're looking for and then say, hey, this is also my secret key, I'm authorized to get this information. So I do have maybe some questions for you on that. But yeah, as far as like attacking cloud infrastructure right from a red team side of things, it's kind of the new frontier in penetration testing. As more stuff gets put out there, as more expensive stuff gets put out there and is secured there and is held there, it just becomes a bigger and bigger target and people find more vulnerabilities.

Kyle Rosendahl: 13:21

You know Amazon specifically, there's a lot of nice attacks because they have this whole CLI environment where you can play around with, you know, the Amazon AWS command line interface and interact with your S3 subscription or interact with the buckets and the storages, and a lot of ways that those buckets are accessed is through a subscription ID essentially, and so a lot of times what the red teamers and attackers are finding is that you know there's an image that's stored in an Amazon S3 bucket that's visible on a web page. You, you know. You right click on that. You say view the source. It leads you to a URL for an Amazon S3 bucket. You go back to your Amazon CLI and you start digging into well, whose subscription is this? What subscription does this belong to? Right? And then start enumerating and figuring out well, is this the only file in this bucket? Do they follow a standard naming convention? Can I get to a higher level bucket from where this one is?

Kyle Rosendahl: 14:27

Permission levels on these cloud buckets that that are there so you may have. You know the general cloud bucket that says yep, anyone can access these, and then specific users can access this bucket. Well, in a normal windows environment there's those kind of parent, child inheritance properties of files and folders. If you give someone access to like a deeper folder structure, usually they also get the permission that they need. That kind of trickles up to the top of the domain where they last had access.

Kyle Rosendahl: 15:01

S3 buckets aren't the same in that you could have a totally locked down you know bucket holder, but then a specific bucket in there could be open and that doesn't allow access to the wider range of buckets, right. And it also works kind of vice versa, where you could leave the entire structure open and lock down another bucket and you know none of it's inherited between the two. So it's a totally different concept and I think that's a big problem with a lot of these cloud infrastructures is that I think we mentioned it on the last episode where it's not just I physically plug this server into this network port and I know the data is flowing there, right. These cloud infrastructures do things in a different way that most computer people aren't used to thinking about. Sure, because it kind of breaks the standards on how things have functioned in like operating systems for years and they do things a little bit differently and they do it well. It's just people aren't always thinking you know, they think it's a one to one comparison. The security doesn't always match up on that.

Matt Starland: 16:05

Right.

Kyle Rosendahl: 16:05

But you know like.

Matt Starland: 16:06

So I just want to interrupt yourself.

Matt Starland: 16:08

For example, like this, the API you know that, let's just say it is kind of similar to what I was talking about like that Azure AD integration or whatever app registration from like that red team perspective. That doesn't seem like something that you can just sit here and just crack away at it to try and figure out, like some buffer overflow, cross-site scripting type stuff, sequel injection, this is, you know a lot of these are, they've got quite the security on them from those types of I I. I realize I'm using those examples and they might, they might not work in that a particular situation, but the point I'm kind of trying to get at it doesn't seem like it's something you can trick the interface into giving you access. At least that's what I would kind of garner from you know, kind of my experience and seeing this, is that what you've seen too.

Matt Starland: 17:08

You know, like the I, the I mean they, they if this is again a Microsoft infrastructure, we'll just say again, using them as an example, you know they put a lot of security at that front end um, to just gain access to it from just you know, tricking that system into giving you credentials. Do you think it could have been something like that, or do you think it's no? They they somehow got those credentials some form or another. They were the access and then just logged in.

Kyle Rosendahl: 17:36

Well, nick and Matt. Matt thanks again for joining us here on the audit.

Matt Starland: 17:41

Yeah, definitely a pleasure.

Kyle Rosendahl: 17:42

Yeah, yeah, it's always a good thing to have you on here For those listening. Feel free to check us out at itauditlabscom. If you want to find more of us, you can always find our social links there. We're on YouTube, instagram, facebook, you know, you name it, we'll probably have a thing there. And if you want to pull down the podcast, you know wherever you can listen to them, but you can go to Spotify, Apple Podcasts and pretty much any other app that you could find out there on Android.

Kyle Rosendahl: 18:12

Homing pigeons, smoke signals you got it Smoke signal Going off the grid. Yep, all right, thanks guys, bye.

Eric Brown: 18:24

In the current technology landscape, managing risk among other operations can be incredibly challenging. Managing risk among other operations can be incredibly challenging. Let IT Audit Labs experts provide a detailed, thorough examination in preparation for your upcoming audit. Contact us to learn more.