May 1, 2023 • 18 mins
Continue the conversation with guest, Matt Starland, as we dive further into security in the news. How do these breaches happen and how can they be prevented? Find out today on The Audit.
#Breaches #ThreatActors #CyberSecurity #TheAudit
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Eric Brown (00:05):
You're listening to the Audit presented by IT Audit
Labs.
Kyle Rosendahl (00:15):
Welcome back to the Audit.
We are here today with MattStarland and Nick Mellom and
myself.
How are you guys doing today?
Matt Starland (00:25):
Doing awesome, excellent, happy to be here.
Kyle Rosendahl (00:30):
Yeah, today is really a continuation of our
last episode that we had withMatt Starland, where we talked
about the T-Mobile breach andsome other security news stories
.
And I know towards the end ofthe episode last time we really
got cut off, or cut ourselvesoff, because we started to dive
really deep into kind of thepolicy implications and all of
(00:52):
the pieces that go into that andcould, you know, even lead to
prevention of these breaches orwhy they might not be in place.
And so we invited Matt back into come in here, chat with us a
little bit more and really takean even deeper dive than we did
last time to really just go overpotential ways that it could
have happened, what you need todo to prevent these types of
(01:13):
breaches and common securitymeasures, and talk more of those
administrative controls andpolicies that you can use to
protect environments like this.
So, matt, I know at the end ofthe last episode I think we cut
you off specifically about APIsecurity right and the T-Mobile
(01:37):
breach.
For those that either didn'tlisten to the last episode, you
know I would recommend goingback listening to it.
But the long and short of thestory is that T-Mobile
experienced a pretty big breachwhere the threat actors or the
attackers had access to theirpublic API and were able to pull
down personally identifiableinformation of over 3 million
(02:01):
yeah, 37.
37 million T-Mobile customersNot social security numbers are
necessarily really protectedinformation, but enough, that's
phone numbers, number of lineson the account, address, things
like that and they were able toconduct this breach by using the
API over the course of like amonth and a half and we're able
(02:25):
to, you know, exfiltrate all ofthis data out of T-Mobile
servers.
So we were getting into when wecut ourselves off, just talking
about, you know, some of thoseAPI, public connections and that
new kind of cloudinfrastructure and how that
changing landscape from thison-premises environment to these
, you know, more cloud-connected, interconnected environments,
(02:49):
and how the security and thepolicies and the administrative
changes need to be different inorder to, you know, better
secure this type of data.
So any thoughts on that?
Matt Starland (03:00):
Yeah.
So, yeah, going back to likewhat you're saying.
When we talked last time, youtime we really talked at the
high level of administrativecontrols, just company policy
procedures, and even the onething I like to pitch a lot to
some of my fellow IS colleaguesis least privilege access.
And so what does that now looklike from the technical
(03:22):
perspective of this API?
So when I start to look throughor think through this process
of, well, how would somebodyconnect to T-Mobile's API?
Well, are they sitting theresniffing the connection, trying
to decrypt it?
Well, highly unlikely.
A lot of those types ofconnections are using pretty
(03:44):
high-end TLS encryption ciphers.
You're using TLS 1.2, 1.3,something like that, and I mean
the likelihood of themintercepting that and then
cracking it is pretty unlikely.
So then I would also then lookat the next risk how did they
then gain access?
(04:04):
Was it some vulnerability inthe API itself Maybe, being that
this is a T-Mobile and it's ahigh-profile company and you got
a little bit more sophisticatedattackers trying to attack that
or is it going back to what Iwas saying before?
(04:27):
Is it a least privilege issue,for an example here of where you
can easily overlook permissionshere and somebody could gain
access, not when an organization, maybe like T-Mobile, might
have not have followed theseprivilege.
So if you're connecting to,let's say, you're using Azure AD
(04:50):
as your identity provider andit's also you're using Microsoft
365 resources, sharepointOnline, teams, exchange, etc.
And so now let's just say thatsome of that data, this customer
data, was residing in let's say, it was email, for example.
(05:13):
So you had a third party ofsome sort of host and provider
that has an application thatthey need to integrate into your
email system, so they can, youknow, schedule meetings, invites
or read emails and show youcertain bits of data within your
(05:33):
emails to integrate with theirapplication.
And so when vendors like that,you know, provide a system
administrator or securityengineer, admin details on how
to create that integration, thevendor, that third party, is
just looking at how quickly canwe make this an easy, you know,
for the organization integratingour app into their system?
(05:55):
How do we make it as easy aspossible?
Some of them do look into maybethat least privilege, but it's
not always necessarily there,and so they'll give you the
easiest permissions that you canget this integration up and
running.
So, for example, then you'restarting to create this app
registrations into Azure AD.
Then you're starting to createthis app registrations into
(06:15):
Azure AD.
You create either a certificatefor it and you provide that
third party that certificate, oryou create the secret key and
give to them and then you assignall those permissions within
that Azure AD app registration.
Well, when you're creatingthose permissions, microsoft
really gives you blanketpermissions.
(06:37):
For example, one of theapplications I've seen that
wants access to email whenyou're using those API
permissions it just says allmailboxes.
So you might be integrating anapplication that only needs to
have access really maybe to 10,15 users, but the API just gives
a blanket access to allmailboxes.
(06:58):
And so when you're looking atthat configuration page within
Microsoft, they don't give youany configurations right there
and then to easily limit that tojust what's needed to have
access.
So now let's just say you givethat information back to the
vendor host that you know thatcertificates or that secret key
(07:22):
and somebody on that sidedisgruntled employee or
something gets breached on theirsystem to where, wherever that
key was stored is now availablewithin either their network or
maybe that person download orthe malicious actor downloads it
to their infrastructure andthen tries to make a connection
back to that app registrationwithin Azure.
(07:42):
Well, they have access now toall mailboxes, even though that
app might have been onlydesigned to be really needed,
used by 10 mailboxes.
So that's an example rightthere, so, of how that would be
overprivileged and whereMicrosoft, out the gates, does
not give you something right atthat configuration console, an
(08:04):
easy way to just limit thatpermission.
So this is where, as being asecurity architect, engineer,
when you're looking at some ofthese requests coming in
assuming it's even coming to youand or maybe it's another way
of educating the other team thatis integrating these is what
they need to.
You know, look out for, ask thequestions like well, who's this
(08:26):
all being used by?
And that seems a little bitoverkill that we're adding this
to the entire organization'smailboxes versus just 10.
And then doing some moreresearch to see is there other
things out there that Microsoftprovides to limit this?
Because, in my experienceworking with some of their
exchange online platforms, ifyou're just going based off of
the GUI, really the GUI onlygives you about 50% of what you
(08:50):
can actually configure andcontrol.
The rest is all being donebehind the scenes using
PowerShell.
So in this instance, here, thisexample, we're talking about
using this Azure AppRegistration.
That's what you actually needto do.
You got to do a little diggingand you'll find a TechNet
article out there that talksabout how to create a policy and
(09:13):
then tie that policy to a groupof users and that policy then
can connect to this as your appregistration.
So when that vendor is making aconnection and they are
scanning or trying to connect tomailboxes that are maybe
relevant to that the identitiesthat you've added to the
security group that they'resupposed to have access to
they'll work just fine.
(09:34):
But if they were trying toaccess another identity that's
not in that security group thatyou created via PowerShell and
that policy and tied it to theapp registration, it gets denied
.
So that's one way to look atyou know, limiting that.
But the other one is to is aconditional access policy.
So so for the example I gave isthat you know, let's just say
(09:55):
that that vendor, third partywas breached and those
credentials were then offloadedto wherever that threat actor is
coming from, and then thatthreat actor is trying to make a
connection back to thatcustomer.
You know T-Mobile's environmentthat got breached customer.
You know T-Mobile's environmentthat got breached.
If T-Mobile, for example, hadthat conditional access policy,
(10:22):
not saying that they use AzureAD or using conditional access
policies, but just let's justsay they used that in that
instance and they said all right, we are going to only allow
connections to this appregistration from the IP address
that is associated with thisvendor third party.
So that way if that threatactor is trying to now come from
another connection, boom, it'sgetting denied.
(10:42):
But also maybe their SOC team ortheir security engineers could
be putting in you know,monitoring too that says, hey,
anything that's coming not fromthis location.
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 thesecredentials have been
compromised and are being usedsomewhere else or I mean it
(11:04):
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 gettingan alert to question and whether
or not, why, why thisconnection is coming from
something that we were sayingit's only allowed from.
So you know, from the technicalaspects, I think that's kind of
(11:24):
to me that's easier.
Breaching these is just findingthat least privilege and just
use using passwords.
I know, kyle, you've got alittle bit more red teaming
experience and specialty than Ido.
I sit more on that blue teamarchitecture side of the world.
Have you dealt with trying tocompromise APIs or you know,
(11:52):
kind of like AWS S3 buckets orAzure 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'tnecessarily know what an API is
is it's essentially a programthat's running on a server
somewhere that's waiting for aspecially crafted internet
(12:19):
packet to be sent to it.
That packet usually isprotected by sometimes a
username and a secret right.
So a lot of times if you wantaccess to the API, you have to
sign up for the website or payfor the service and then when
you sign into your account,they'll give you a secret key
(12:40):
that you include as part of thatrequest to that web server and
then it returns you theinformation.
So you have to tell it whatyou'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 somequestions for you on that.
(13:02):
But yeah, as far as likeattacking cloud infrastructure
right from a red team side ofthings, it's kind of the new
frontier in penetration testing.
As more stuff gets put outthere, as more expensive stuff
gets put out there and issecured there and is held there,
it just becomes a bigger andbigger target and people find
more vulnerabilities.
You know Amazon specifically,there's a lot of nice attacks
(13:24):
because they have this whole CLIenvironment where you can play
around with, you know, theAmazon AWS command line
interface and interact with yourS3 subscription or interact
with the buckets and thestorages, and a lot of ways that
those buckets are accessed isthrough a subscription ID
(13:45):
essentially, and so a lot oftimes what the red teamers and
attackers are finding is thatyou know there's an image that's
stored in an Amazon S3 bucketthat'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 anAmazon S3 bucket.
You go back to your Amazon CLIand you start digging into well,
(14:09):
whose subscription is this?
What subscription does thisbelong to?
Right?
And then start enumerating andfiguring out well, is this the
only file in this bucket?
Do they follow a standardnaming convention?
Can I get to a higher levelbucket from where this one is?
Permission levels on these cloudbuckets that that are there so
(14:32):
you may have.
You know the general cloudbucket that says yep, anyone can
access these, and then specificusers can access this bucket.
Well, in a normal windowsenvironment there's those kind
of parent, child inheritanceproperties of files and folders.
If you give someone access tolike a deeper folder structure,
(14:55):
usually they also get thepermission that they need.
That kind of trickles up to thetop of the domain where they
last had access.
S3 buckets aren't the same inthat you could have a totally
locked down you know bucketholder, but then a specific
bucket in there could be openand that doesn't allow access to
the wider range of buckets,right.
(15:15):
And it also works kind of viceversa, where you could leave the
entire structure open and lockdown another bucket and you know
none of it's inherited betweenthe two.
So it's a totally differentconcept and I think that's a big
problem with a lot of thesecloud infrastructures is that I
think we mentioned it on thelast episode where it's not just
I physically plug this serverinto this network port and I
(15:38):
know the data is flowing there,right.
These cloud infrastructures dothings in a different way that
most computer people aren't usedto thinking about.
Sure, because it kind of breaksthe standards on how things
have functioned in likeoperating systems for years and
they do things a little bitdifferently and they do it well.
(15:58):
It's just people aren't alwaysthinking you know, they think
it's a one to one comparison.
The security doesn't alwaysmatch 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.
For example, like this, the APIyou know that, let's just say it
is kind of similar to what Iwas talking about like that
Azure AD integration or whateverapp registration from like that
red team perspective.
That doesn't seem likesomething that you can just sit
here and just crack away at itto try and figure out, like some
(16:28):
buffer overflow, cross-sitescripting type stuff, sequel
injection, this is, you know alot of these are, they've got
quite the security on them fromthose types of I I.
I realize I'm using thoseexamples and they might, they
might not work in that aparticular situation, but the
(16:49):
point I'm kind of trying to getat it doesn't seem like it's
something you can trick theinterface into giving you access
.
At least that's what I wouldkind of garner from you know,
kind of my experience and seeingthis, is that what you've seen
too.
You know, like the I, the I meanthey, they if this is again a
(17:10):
Microsoft infrastructure, we'lljust say again, using them as an
example, you know they put alot of security at that front
end um, to just gain access toit from just you know, tricking
that system into giving youcredentials.
Do you think it could have beensomething like that, or do you
think it's no?
They they somehow got thosecredentials some form or another
(17:31):
.
They were the access and thenjust logged in.
Kyle Rosendahl (17:36):
Well, nick and Matt.
Matt thanks again for joiningus 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 atitauditlabscom.
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 thingthere.
(18:03):
And if you want to pull downthe podcast, you know wherever
you can listen to them, but youcan go to Spotify, Apple
Podcasts and pretty much anyother app that you could find
out there on Android.
Homing pigeons, smoke signalsyou 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 canbe incredibly challenging.
Managing risk among otheroperations can be incredibly
challenging.
Let IT Audit Labs expertsprovide a detailed, thorough
examination in preparation foryour upcoming audit.
Contact us to learn more.
You're listening to the Audit presented by IT Audit
Labs.
Kyle Rosendahl (00:15):
Welcome back to the Audit.
We are here today with MattStarland and Nick Mellom and
myself.
How are you guys doing today?
Matt Starland (00:25):
Doing awesome, excellent, happy to be here.
Kyle Rosendahl (00:30):
Yeah, today is really a continuation of our
last episode that we had withMatt Starland, where we talked
about the T-Mobile breach andsome other security news stories
.
And I know towards the end ofthe episode last time we really
got cut off, or cut ourselvesoff, because we started to dive
really deep into kind of thepolicy implications and all of
(00:52):
the pieces that go into that andcould, you know, even lead to
prevention of these breaches orwhy they might not be in place.
And so we invited Matt back into come in here, chat with us a
little bit more and really takean even deeper dive than we did
last time to really just go overpotential ways that it could
have happened, what you need todo to prevent these types of
(01:13):
breaches and common securitymeasures, and talk more of those
administrative controls andpolicies that you can use to
protect environments like this.
So, matt, I know at the end ofthe last episode I think we cut
you off specifically about APIsecurity right and the T-Mobile
(01:37):
breach.
For those that either didn'tlisten to the last episode, you
know I would recommend goingback listening to it.
But the long and short of thestory is that T-Mobile
experienced a pretty big breachwhere the threat actors or the
attackers had access to theirpublic API and were able to pull
down personally identifiableinformation of over 3 million
(02:01):
yeah, 37.
37 million T-Mobile customersNot social security numbers are
necessarily really protectedinformation, but enough, that's
phone numbers, number of lineson the account, address, things
like that and they were able toconduct this breach by using the
API over the course of like amonth and a half and we're able
(02:25):
to, you know, exfiltrate all ofthis data out of T-Mobile
servers.
So we were getting into when wecut ourselves off, just talking
about, you know, some of thoseAPI, public connections and that
new kind of cloudinfrastructure and how that
changing landscape from thison-premises environment to these
, you know, more cloud-connected, interconnected environments,
(02:49):
and how the security and thepolicies and the administrative
changes need to be different inorder to, you know, better
secure this type of data.
So any thoughts on that?
Matt Starland (03:00):
Yeah.
So, yeah, going back to likewhat you're saying.
When we talked last time, youtime we really talked at the
high level of administrativecontrols, just company policy
procedures, and even the onething I like to pitch a lot to
some of my fellow IS colleaguesis least privilege access.
And so what does that now looklike from the technical
(03:22):
perspective of this API?
So when I start to look throughor think through this process
of, well, how would somebodyconnect to T-Mobile's API?
Well, are they sitting theresniffing the connection, trying
to decrypt it?
Well, highly unlikely.
A lot of those types ofconnections are using pretty
(03:44):
high-end TLS encryption ciphers.
You're using TLS 1.2, 1.3,something like that, and I mean
the likelihood of themintercepting that and then
cracking it is pretty unlikely.
So then I would also then lookat the next risk how did they
then gain access?
(04:04):
Was it some vulnerability inthe API itself Maybe, being that
this is a T-Mobile and it's ahigh-profile company and you got
a little bit more sophisticatedattackers trying to attack that
or is it going back to what Iwas saying before?
(04:27):
Is it a least privilege issue,for an example here of where you
can easily overlook permissionshere and somebody could gain
access, not when an organization, maybe like T-Mobile, might
have not have followed theseprivilege.
So if you're connecting to,let's say, you're using Azure AD
(04:50):
as your identity provider andit's also you're using Microsoft
365 resources, sharepointOnline, teams, exchange, etc.
And so now let's just say thatsome of that data, this customer
data, was residing in let's say, it was email, for example.
(05:13):
So you had a third party ofsome sort of host and provider
that has an application thatthey need to integrate into your
email system, so they can, youknow, schedule meetings, invites
or read emails and show youcertain bits of data within your
(05:33):
emails to integrate with theirapplication.
And so when vendors like that,you know, provide a system
administrator or securityengineer, admin details on how
to create that integration, thevendor, that third party, is
just looking at how quickly canwe make this an easy, you know,
for the organization integratingour app into their system?
(05:55):
How do we make it as easy aspossible?
Some of them do look into maybethat least privilege, but it's
not always necessarily there,and so they'll give you the
easiest permissions that you canget this integration up and
running.
So, for example, then you'restarting to create this app
registrations into Azure AD.
Then you're starting to createthis app registrations into
(06:15):
Azure AD.
You create either a certificatefor it and you provide that
third party that certificate, oryou create the secret key and
give to them and then you assignall those permissions within
that Azure AD app registration.
Well, when you're creatingthose permissions, microsoft
really gives you blanketpermissions.
(06:37):
For example, one of theapplications I've seen that
wants access to email whenyou're using those API
permissions it just says allmailboxes.
So you might be integrating anapplication that only needs to
have access really maybe to 10,15 users, but the API just gives
a blanket access to allmailboxes.
(06:58):
And so when you're looking atthat configuration page within
Microsoft, they don't give youany configurations right there
and then to easily limit that tojust what's needed to have
access.
So now let's just say you givethat information back to the
vendor host that you know thatcertificates or that secret key
(07:22):
and somebody on that sidedisgruntled employee or
something gets breached on theirsystem to where, wherever that
key was stored is now availablewithin either their network or
maybe that person download orthe malicious actor downloads it
to their infrastructure andthen tries to make a connection
back to that app registrationwithin Azure.
(07:42):
Well, they have access now toall mailboxes, even though that
app might have been onlydesigned to be really needed,
used by 10 mailboxes.
So that's an example rightthere, so, of how that would be
overprivileged and whereMicrosoft, out the gates, does
not give you something right atthat configuration console, an
(08:04):
easy way to just limit thatpermission.
So this is where, as being asecurity architect, engineer,
when you're looking at some ofthese requests coming in
assuming it's even coming to youand or maybe it's another way
of educating the other team thatis integrating these is what
they need to.
You know, look out for, ask thequestions like well, who's this
(08:26):
all being used by?
And that seems a little bitoverkill that we're adding this
to the entire organization'smailboxes versus just 10.
And then doing some moreresearch to see is there other
things out there that Microsoftprovides to limit this?
Because, in my experienceworking with some of their
exchange online platforms, ifyou're just going based off of
the GUI, really the GUI onlygives you about 50% of what you
(08:50):
can actually configure andcontrol.
The rest is all being donebehind the scenes using
PowerShell.
So in this instance, here, thisexample, we're talking about
using this Azure AppRegistration.
That's what you actually needto do.
You got to do a little diggingand you'll find a TechNet
article out there that talksabout how to create a policy and
(09:13):
then tie that policy to a groupof users and that policy then
can connect to this as your appregistration.
So when that vendor is making aconnection and they are
scanning or trying to connect tomailboxes that are maybe
relevant to that the identitiesthat you've added to the
security group that they'resupposed to have access to
they'll work just fine.
(09:34):
But if they were trying toaccess another identity that's
not in that security group thatyou created via PowerShell and
that policy and tied it to theapp registration, it gets denied
.
So that's one way to look atyou know, limiting that.
But the other one is to is aconditional access policy.
So so for the example I gave isthat you know, let's just say
(09:55):
that that vendor, third partywas breached and those
credentials were then offloadedto wherever that threat actor is
coming from, and then thatthreat actor is trying to make a
connection back to thatcustomer.
You know T-Mobile's environmentthat got breached customer.
You know T-Mobile's environmentthat got breached.
If T-Mobile, for example, hadthat conditional access policy,
(10:22):
not saying that they use AzureAD or using conditional access
policies, but just let's justsay they used that in that
instance and they said all right, we are going to only allow
connections to this appregistration from the IP address
that is associated with thisvendor third party.
So that way if that threatactor is trying to now come from
another connection, boom, it'sgetting denied.
(10:42):
But also maybe their SOC team ortheir security engineers could
be putting in you know,monitoring too that says, hey,
anything that's coming not fromthis location.
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 thesecredentials have been
compromised and are being usedsomewhere else or I mean it
(11:04):
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 gettingan alert to question and whether
or not, why, why thisconnection is coming from
something that we were sayingit's only allowed from.
So you know, from the technicalaspects, I think that's kind of
(11:24):
to me that's easier.
Breaching these is just findingthat least privilege and just
use using passwords.
I know, kyle, you've got alittle bit more red teaming
experience and specialty than Ido.
I sit more on that blue teamarchitecture side of the world.
Have you dealt with trying tocompromise APIs or you know,
(11:52):
kind of like AWS S3 buckets orAzure 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'tnecessarily know what an API is
is it's essentially a programthat's running on a server
somewhere that's waiting for aspecially crafted internet
(12:19):
packet to be sent to it.
That packet usually isprotected by sometimes a
username and a secret right.
So a lot of times if you wantaccess to the API, you have to
sign up for the website or payfor the service and then when
you sign into your account,they'll give you a secret key
(12:40):
that you include as part of thatrequest to that web server and
then it returns you theinformation.
So you have to tell it whatyou'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 somequestions for you on that.
(13:02):
But yeah, as far as likeattacking cloud infrastructure
right from a red team side ofthings, it's kind of the new
frontier in penetration testing.
As more stuff gets put outthere, as more expensive stuff
gets put out there and issecured there and is held there,
it just becomes a bigger andbigger target and people find
more vulnerabilities.
You know Amazon specifically,there's a lot of nice attacks
(13:24):
because they have this whole CLIenvironment where you can play
around with, you know, theAmazon AWS command line
interface and interact with yourS3 subscription or interact
with the buckets and thestorages, and a lot of ways that
those buckets are accessed isthrough a subscription ID
(13:45):
essentially, and so a lot oftimes what the red teamers and
attackers are finding is thatyou know there's an image that's
stored in an Amazon S3 bucketthat'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 anAmazon S3 bucket.
You go back to your Amazon CLIand you start digging into well,
(14:09):
whose subscription is this?
What subscription does thisbelong to?
Right?
And then start enumerating andfiguring out well, is this the
only file in this bucket?
Do they follow a standardnaming convention?
Can I get to a higher levelbucket from where this one is?
Permission levels on these cloudbuckets that that are there so
(14:32):
you may have.
You know the general cloudbucket that says yep, anyone can
access these, and then specificusers can access this bucket.
Well, in a normal windowsenvironment there's those kind
of parent, child inheritanceproperties of files and folders.
If you give someone access tolike a deeper folder structure,
(14:55):
usually they also get thepermission that they need.
That kind of trickles up to thetop of the domain where they
last had access.
S3 buckets aren't the same inthat you could have a totally
locked down you know bucketholder, but then a specific
bucket in there could be openand that doesn't allow access to
the wider range of buckets,right.
(15:15):
And it also works kind of viceversa, where you could leave the
entire structure open and lockdown another bucket and you know
none of it's inherited betweenthe two.
So it's a totally differentconcept and I think that's a big
problem with a lot of thesecloud infrastructures is that I
think we mentioned it on thelast episode where it's not just
I physically plug this serverinto this network port and I
(15:38):
know the data is flowing there,right.
These cloud infrastructures dothings in a different way that
most computer people aren't usedto thinking about.
Sure, because it kind of breaksthe standards on how things
have functioned in likeoperating systems for years and
they do things a little bitdifferently and they do it well.
(15:58):
It's just people aren't alwaysthinking you know, they think
it's a one to one comparison.
The security doesn't alwaysmatch 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.
For example, like this, the APIyou know that, let's just say it
is kind of similar to what Iwas talking about like that
Azure AD integration or whateverapp registration from like that
red team perspective.
That doesn't seem likesomething that you can just sit
here and just crack away at itto try and figure out, like some
(16:28):
buffer overflow, cross-sitescripting type stuff, sequel
injection, this is, you know alot of these are, they've got
quite the security on them fromthose types of I I.
I realize I'm using thoseexamples and they might, they
might not work in that aparticular situation, but the
(16:49):
point I'm kind of trying to getat it doesn't seem like it's
something you can trick theinterface into giving you access
.
At least that's what I wouldkind of garner from you know,
kind of my experience and seeingthis, is that what you've seen
too.
You know, like the I, the I meanthey, they if this is again a
(17:10):
Microsoft infrastructure, we'lljust say again, using them as an
example, you know they put alot of security at that front
end um, to just gain access toit from just you know, tricking
that system into giving youcredentials.
Do you think it could have beensomething like that, or do you
think it's no?
They they somehow got thosecredentials some form or another
(17:31):
.
They were the access and thenjust logged in.
Kyle Rosendahl (17:36):
Well, nick and Matt.
Matt thanks again for joiningus 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 atitauditlabscom.
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 thingthere.
(18:03):
And if you want to pull downthe podcast, you know wherever
you can listen to them, but youcan go to Spotify, Apple
Podcasts and pretty much anyother app that you could find
out there on Android.
Homing pigeons, smoke signalsyou 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 canbe incredibly challenging.
Managing risk among otheroperations can be incredibly
challenging.
Let IT Audit Labs expertsprovide a detailed, thorough
examination in preparation foryour upcoming audit.
Contact us to learn more.
Popular Podcasts
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
24/7 News: The Latest
The latest news in 4 minutes updated every hour, every day.
Therapy Gecko
An unlicensed lizard psychologist travels the universe talking to strangers about absolutely nothing. TO CALL THE GECKO: follow me on https://www.twitch.tv/lyleforever to get a notification for when I am taking calls. I am usually live Mondays, Wednesdays, and Fridays but lately a lot of other times too. I am a gecko.