Okay everyone, as we're tied on time, I'll just say, I'll skip all the introductions. I'm the identity beer guy if you haven't seen that. Hashtag identity beer, that's sort of me. We're jumping right into the action I have with me online. The main presenter, Manuel Benz, he's sort of the one doing the most work today. So we just go from Azure to that other cloud named AWS. And I do believe that some of you will know that the IAM policies that you are using inside the AWS infrastructure may lead you to allowing other people privilege escalations.
So there may be things like functionalities, assigning permissions to another user, like create an access key, create an update, a login, a profile, add user to a group or something like that. You could also tweak permissions on policies by creating new policy versions, attaching policies to users, groups and roles or put policies to new users groups and roles.
But you could also do that by updating an assume role policy or an IAM pass role, such as pass existing role to resources, such new lambda, new glue dev environment or the cloud formation.
I'll just do that as a very, very quick introduction because you could go and have fun with all of those. But beware, this is definitely not meant to be an because it could be interpreted as something like that. If you read all those papers that I've linked you here, they will explain to you why those different positions highlighted here in different colors may actually be the reason why your AWS infrastructure is highly insecure and you'd be prone to privilege escalation. So how did we end up there?
Well, climbing a mountain, you know, a few years ago, your baard, oh well yes, I want us to use AWS, right? Go there, go to the peak and take us to where the clouds are and make us all happy and save us some money.
And of course our boss said, oh well we we're the experts, we know what to do. He thought we'd be somewhere at the mid-level camp and we are prepared to just, you know, lift and shit, right? The problem is most of us were probably down there in that cozy little village and we did know nothing about how to grant access, minimum access to all the different resources that we had.
And our main goal would be not to be falling off that cliff and you know, ending up with some sort of headline in the newspaper. You've been hacked. And in order to do so well we would need to know which resources are there in my vast AWS environment, which I identities subjects are there, which are having been granted access, and to which privileges for those objects. Well unfortunately that led us to a situation where we were lost in far too many ways somebody else could harm us.
And for me, that sounds awfully like standing in front of a really dark, dense jungle and all those threat actors out there are trying to get to us and our business people are standing there. Oh, well that's nice, but how do we get outta there? And this is the reason why I think hopefully Manuel and Yana Jones Benz can help us out. And I'll just step back and have you watch the show. Manuel is yours.
Thanks a lot, pastor. Can everyone hear me? I hope so.
So before I go into detail regarding the solution, let me first showcase what Sebastian just explained by giving you a quick example of trying to answer the question. Which S3 buckets are actually reachable by an EC2 instance only by looking at the AWS console. So if we look at the AWS console, this is basically the EC2 console. We can see we have like one virtual machine running here. We see all sorts of details. Most importantly for us, the EC2 instance has like a role attach. This role defines the permissions of the instance.
So if you want to find out what is accessible by this EC2 instance, we have to have a look at the role. So let's do this quickly. So what we see here is this role has a policy attached the policy.
It says we should be allowed to do all sorts of S3 actions on all S3 buckets ending with EIC, right? So let's have a look at the S3 buckets in the account. So we see there are like four buckets in this account. Three of those end with EIC. So these should be reachable, right? So it should be accessible by the EC2 instance.
Well, it's not so easy in AWS you can define permissions from the perspective of the identity. So from that role, but also from the perspective of the resource that should be accessed for this, you can define a so-called resource-based policy that defines the permissions from the resource.
And as we, as we look at this, we can see this says basically deny all S3 actions to all principles except the admin user. So while we first thought we should be able to access everything ending with EIC, we actually cannot access the sensitive data bucket at all.
But let's have a look at the other, other bucket doesn't have like a resource based policy.
Okay, that's fine. Customer data. EIC doesn't have a resource based policy.
Fine, right? Well unfortunately not because you can also add different things in AWS like so-called permission boundary. This really caps the permissions that this role can have. And if we look at this permission boundary, we now see okay, we should be able to do all at three actions, but we are actually denied to do all sorts of right actions on the customer data EIC bucket. So after thinking about this, we actually know, okay, we can just read from the packet. We cannot write to it, right? We cannot access this one at all. We can access this one. What about this?
It doesn't end with EIC, but again it has resource-based policy that allows the access, right?
And it even gets worse because we also have things like service control policies. These work like permission boundaries and kept the maximum resource that you can have, but they are applying to the whole account. And by default you don't even have like read permissions to this. So in the worst case, we don't know at all what our EC2 instance could do because it could be denied in service control policy. So I'm showing this because this is a very small account, right?
It has one EC2 instances, four buckets, and still it was very, very hard to find what can actually be accessed by the EC2 instance. And the problem really points down to this. So this is like an AWS, so-called policy evaluation pipeline. So for each to decide for each action, if one resource can access another resource, you have to want run through this policy pipeline, right?
And it contains things like we already source, it evaluates like the resource based policies. It evaluates the identity based policies, it evaluates the sales control policies and the permission boundaries.
And there are a lot of special cases here. And so while the permission system of AWS is is great and you can really do fine, create access with it is also very, very complex. And it gets even worse because all these concepts are defined like in a decentralized fashion. So as you saw in the console, there's not a single place where you can find all the permissions you really have to look at in different locations of the account. And if you would now try to visualize what, what we just discussed, we would get like a network looking something like that.
So you would have like all the resources of all the 200 AWS services and you would see that like this resource can access this resource and this can read from this and so on.
And, and it really gets like very, very overwhelming. I think it, it, it goes without notice that's impossible for a human being to really build a mental model of this and really understand like what can be accessed by, by what in an account, right? And fortunately, this visualization also presents the solution for the problem in my opinion.
So you can actually model the whole thing as the mathematic mathematical graph model, where you take like each resource as a node and the edges define the effective actions that are possible between two resources. So after going through the whole policy evaluation pipeline and model like that, and you can use this to answer different questions. So for example, you could ask like what can be accessible by a lambda function or who can access this dynamo DB table and with which exact actions and why? Because we do the whole policy evaluation pipeline.
We can at all the times say why isn't access possible or why it isn't possible. That's very important to really understand how you can fix it. But you can also run like different security checks using these queries. So for example, you could ask like if over permission. So if this lumpar function has like access to 50 buckets, it's it's pretty likely over permissioned, right? Because why should have microservice have like 50 buckets to be accessible? Same for database, like if any, a lot of identities can access this.
It might be over permission, but you can also ask other questions like I have like a database which contains sensible data. Is it at risk? Right? And you can do it by using craft visibility and see, okay, here's like an API gateway that's reachable through the internet and it connects to lambda function, which has a role and accesses the data with database with the sensible data.
So now you know, basically your sensible data might be at risk if someone finds a vulnerability in a lumpar function and exploits it.
So that helps a lot to, to really strengthen your security posture regarding the, your critical assets. But most importantly, we use this craft model to do like privilege escalation analysis on it. And this is not like a simple craft more complex. We really simulate the attacks on our model of the cloud. But what you get in the end is really like the step by step description of the attack. And here we can see basically here I have a very simple attack that starts from a variable EC2 instance. This is like publicly reachable through the internet.
It has like a role attached, which has a positive policy attached, which allows to create access keys. So now we can see in our model, since we evaluate all the actions, we know exactly which users this action applies to.
So our, our engine basically finds a user which looks very fruitful. The so-called GitLab CI user because it already has the admin access policy. So the attacker can basically use this to create an access key for this user log in as that user and bam, he got admin rights, right? And to be able to really do such like a, a, a, a step by step description, which is very precise, you need a model like the craft model we built because you need to know is this action really conductive or might it be denied? And to which resource does it apply?
And then then we can really compute as well what is the actual impact of the attack? So what exact resources which with which exact actions can be like accessed after the attack was conducted. So this gives you like very valuable information to understand the, again, the risk of this and how important and how it is to be quickly fixed basically. But also this allows us to do things like finding, like assume role change in between. Like if this role needs to assume another role and collect some actions to do the attack, right? In any case, thanks a lot for your attention.
Sebastian is on site so feel free to ask him questions. But you can also just give me a call, drop me an email or connect me on LinkedIn if you have any questions. Thanks a lot.
