Abusing AWS Permissions: Teaching an Old Dog New Tricks

ready Cool first I just want to say thanks to everyone who came uh because my friends and family who made the long trips to get you out and watch me speak uh thank you so I'll be speaking on abusing AWS permissions and ultimately teaching an old dog new tricks let's get on something new next slide and New Zealand so firstly who am I or if you're an AWS Nerd Like Me AWS STS get quarter identity my name is Jason I work at gmail as a cyber security engineer and I've been in the industry for half a decade which is roughly five years which are basically dog years in the cyber security industry things move at such a fast pace

and I left my email address there in case you want to contact me um I just put that there because emails for companies are really easy to enumerate and you guys are going to figure it out anyways so if you need to get hold of me it's over there foreign quick agenda what we're going to do is we're going to cover some basic access principles within AWS I want everyone to be up to speed with what everything means before we jump into something a little bit more fun if you've ever seen any talk that I've ever done before you know that there's going to be a live demo component and I really hope that the demo gods are with me for this one

so we're going to cover two main policy types resource-based policies and identity based policies cool cool so first things first this is the flow diagram that displays whether an action can be executed on a resource or not this is displayed by this is given by AWS the source is at the bottom and we're just going to cover this very highly so first we look at what AWS does is they look at all of your policies for any explicit deny policies or statements and if there is then it'll deny an action other than that we started ecps service control policies which are organization-wide basically you can have multiple AWS accounts in one organization and apply policies at an

account level the next part I think everyone is a little bit familiar with are resource-based policies and identity-based policies these are things that we're gonna focus on I just want to mention that the difference between an explicit deny and an implicit deny an explicit deny means that you state that this resource cannot perform this action where an implicit deny means that there's no allowed permissions so it's denied by default as I said these are the two we're going to focus on because I think most companies focus on these two so at a high level what is a policy right a policy is a document that contains a number of statements that determine whether or not an action can

be performed on a resource a statement generally has an effect action and a resource as well as sometimes a condition so the effect can be either allowed deny the action could be what's going to be performed and the resources whatever resource what you can also add wild cards to this which is a stop so we're looking at resource-based policies essentially if we go back to this document you can see that resource-based policies the logic is looked at first before identity-based policies so what I mean by this data yeah we'll get to that firstly resource-based policies can allow principles outside of the current account to interact with that resource and a lot of companies Focus their

efforts on ensuring that their identity based policies are as strict as possible but if your resale space policy if someone creates a resource Place policy that allows an action and there is no identity based policy that explicitly denies the action so there's implicit denies well then all the safeguards you've put in place around identity based policies or Essence essentially as good as this gets really short and someone can easily just jump over it and there's also some permission permissive options available directly from the console so if you're in the AWS console um there might be some very permissive actions that can take place what I mean by this is we've seen buckets go through many iterations of

improvements so we're not really going to focus on buckets I decided that we would look at a different reasons the simple notifications yes it is I'm definitely going to undersell the service it's a really cool service but essentially what it allows you to do is send people send emails and sms's and other notification types to different Services as well as users and when you're creating an SMS topic from the console this is the access policy options that you are given from the console and what I find quite interesting is that you given with the basic options you're given some very limited options to choose from only the topic owner everyone and only the specified AWS accounts

so if we look at the first one right only the topic owner what exactly does that mean right and the only way to really see what that means is to look at the policy on the right as you can see from the policy it has a whole bunch of permissions publish remove permissions set topic attributes and so on and on the resource and then it has a condition so any resource within this account can perform those actions by default and this is the default one that's checked so essentially this policy is permissive by default if you created this resource-based policy regardless of what permissions you have given other use other IEM entities such as users or roles

and if there are no explicit denies then they would be able to perform those actions by default now what I found more interesting is the one that says everyone and the little description says anybody can publish so what does that actually mean what is anybody in AWS so if we look at the policy on the writer it says principal AWS star that means that's a wild card for anything that means any AWS account anyone who has any object within an AWS account that they control or IM entity could perform that publish attribute if you click the anybody so essentially what you're doing by clicking that everyone is allowing anyone in the world to publish to your

topic and if you click the everyone for the Subscribe action then you can subscribe anything you want to that top anyone in the world could do that let's have a quick look at identity based policies these are policies that are attached to users groups and roles users are intended to be real live users so human people groups are just a grouping of users and roles and roles are essentially the services or users that can inherit those permissions you can attach multiple documents to any of these and some actions that are given to an entity can allow that entity to gain more permissions or give someone else more permissions either in conjunction with other actions or just

by themselves and we'll have a look into this here's just a quick video it's a demo on what we've just spoken about I'm going to show you that I've created a user named Jason which is me the user has no group so no inherited permissions if we open this user we see that they actually have no permissions they've been given absolutely no permissions so because they've been given no permissions it's implicit deny for everything so let's look at the SNS topic if we look at the topic I created this topic using the default basically just giving it a name and clicking next next um if we look at the policy document for the access policy

we can see that it's as we stated any AWS account can interact with this perform any of these actions as long as that I am entity comes from that account it does right so it just doesn't have any permissions given to it so now we can just see here that we have two pending subscriptions and I'm logged in as that user and I'm going to create an additional we saw that there was only one user I'm going to create an additional subscription and we run it because let's give a second if we go back see testing three which is the one we just created if we go back and just refresh we could see that testing 3 was created

and that's because if we look at this doc this flowchart here we can see that resource-based policies are evaluated before identity based monsters essentially meaning that the permissions given to that user unless they've unless they fall in this category explicit deny don't actually matter and that's what I meant by this gate if you focus all your effort on identity based policies it's not very effective against resources that have resource-based policies

so now how can we apply all techniques or old mindsets to these new Cloud problems so we've all heard of Bloodhound I think there's no one in the Stream it hasn't heard of bloodhound which allows you to see different how things can interact with each other different resources is a similar tool for AWS that was written by Craig which is very cool and it allows very similar things but because of how many permissions and how many different resources there are and resources are added literally all the time we need to apply our hacking mindsets when looking at stuff like this so I'm going to show you the demo that I'm going to show you is a path that these tools actually did

not pick up and now we're going to jump into the fun stuff so what I've done is I thought I'll take the Capital One hack as an entry point to everyone I think is familiar with that we've been testing a web app and we see that the web app makes a call to this web service and it sends in that parameter so what we do is we change that URL parameter to google.com or any other website and we realize that it returns that data to us so if you're familiar with web application security you'll know that this is server side request forgery ssrf and we can essentially have the networking capability of the server we

can make the server perform HTTP requests on our behalf cool so the first thing I would do is first understand is that an ec2 instance performing NS lookup to see if there's a DNS name attached to it and we see that it is an ec2 instance so if you're in the AWS environment or you're very familiar with AWS topics your spidey sensors will be absolutely tingling at this point thinking is there a role attached to this instance because you have ssrf you have the ability to query the metadata service and you might be able to give credentials so let's jump into a little bit of a demo first things first I'm just going to run

my ssrf vulnerable web app and to save time however n ah come on and essentially the metadata service allows us to query information about the ec2 instance and at a fundamental level we are allowed to actually obtain the AWS credentials for that role so it works the same as a user account right it has an access key and a secret key so if we run this basically what I'm doing here is I'm querying the meta service to find out if there is a role attached and it came back with yes there's a role attention okay sorry about that

so I query the metadata service to find out if there's any IM security credentials attached to this or a role and there is a role it's called ec2 Lambda rule so now what we can do is actually obtain the credentials for that role by just using the same endpoint the AWS metadata service endpoints and now we see that we have the access key and the secret and the secret key as well as the token so if we do an AWS so what I'm doing is configuring my local AWS instance by local AWS CLI

as with live demos looks like it's already broken

okay cool well let's just start again just looks like it's taking a bit of time internet slow cool no idea why a copy done

I see it didn't copy the session token which is fine we'll just do it manually

to bash my use of Nene so this is the file where your credentials are stored when you configure the AWS service station token is definitely not correct I'll kill the whole line but I can't remember what the variable name is but essentially what I want to show you is that it's not you're not required let's do it this way

okay but anyways what I'm trying to get to with this is we can see that where the yeah dc2 Lambda roll on this instance ID what I'm trying to get with this is those credentials don't have to be used on the specific ec2 instance that the role is attached to you can actually use those credentials wherever you want they work just like normal access tokens

cool now you have compromised AWS credentials now what what are you going to do with it right if you're doing a pen test your goal is to find all avenues of attack right but if you're doing something nefarious or a red team what what is your goal and generally the da equivalent is all actions over all resources which essentially allows you to perform whatever you want on whatever you want assuming that there are no scps in place or resource-based policies stopping you from doing what you want to do

so the first thing we're going to run here is we're going to use our newly found credentials

to find out if we have what what policies we have attached to them first we're just going to use the CLI

and we have three policies and already I can see one that is awesome if we look at these policies over here it would have the AWS account ID if it was created within that account if it says AWS there's a managed policy which essentially means AWS manage that policy and it's available to any account so you can use your own account to see what permissions you have without doing anything weird um and if we look at one of the interesting policies AWS Lambda four axis this is also an AWS managed policy

just gonna have a quick look at it and look at the permissions so the Assumption there is really that you'll have all permissions over Lambda but we're not 100 sure it's a role

swear so what's interesting here is if you look at the description it says grants full access to AWS Lambda service AWS Lambda console features and other related services we're not going to look at all of the statements we can already see that we can do anything on Lambda which essentially means we can create a Lambda that we want execute whatever code we we want if you're not familiar with Lambda essentially it's something that allows you to run code without thinking of the underlying infrastructure and this is the statement that's also quite interesting so what we can do is we're allowed to pass a role essentially attach a role to an AWS instance sorry an AWS Lambda function what's quite cool

about that is if there is an existing role with different permissions to what we already have we automatically gain those permissions because we can execute code with that and that's exactly what we're going to do show you that we're still that user even in this console in this terminal

cool we are and I'm going to create the Lambda function and I'm going to pass a role that we previously found actually go through that that one is not too obvious I'm going to skip to that if we look at the roles

if we list all the roles in the account essentially what we're looking for is one that allows the principle so the service to be lambda.amazon.aws which corresponds with the policy that we had so we can only pass policies for that service um I'm just going to go pretty fast because it knows towards the end but essentially you would look at these pretty closely we see this Vault role what I see that is quite interesting is SSM Lambda manager SSM stands out to me because that's the service manager within AWS which is essentially something that allows you to control whole ec2 instances that are in the SSM Fleet so you can run code push software control those ec2 instances

so that's quite an interesting one to me and if we look at the permissions attached to that policy to sorry to that role

we can see another AWS managed policy and I know this policy pretty well essentially what it is is it allows all permissions to be performed um all SSM actions which it will allow us to push code to instances in the fleet allow us to view the fleet the last few instances within that Fleet so let's have a look at that just so I can give you an idea of what SSM is thank you

so we have two instances within this Fleet we have the web server that's the if we looked at the account ID versus the if we went back up we would see versus the the role that is assumed that has that at the end um we would see that we compromise the web server we also see this admin host which is quite interesting so what I would do is I'd go look at ec2 and see exactly what this admin host is because essentially we have full control over that admin host

all right this way look at it if we see the admin host actually has a role attached to it and this role is an ec2 admin so now what we want to do is we want to create a Lambda function that allows us to compromise this ec2 admin account

because that ec2 admin account has all actions overhaul over everything so our initial entry point through ssrf allowed us to compromise a web server which had a role attached to it that could create an AWS Lambda function which would have the ability to pass a role to any function that we created and that role allows for full control over the systems manager which allows us to run a command on an ec2 instance that has a role with all actions overall resources it's a little bit of a mouthful but you guys have the general picture so now what we're going to do is actually create this Lambda function and I'm going to focus on the console

because I think it's a much better visual representation in kind of just looking at live code on the screen

so we looked at how ec2 instances obtain their credentials using the metadata service let's have a look at how Lambda function stood so Lambda function is done in a bit of a different way they do it by using environment variables so the first line of code we have there is just to print out the environment variables let's give a refresh

so if we look at the environment variables just like with the metadata service we can see that there's the session token and if you look through the rest you'll find all the rest of the credentials so that's how it works it's not exclusive to the Lambda function it can be used pretty much anyway just like ec2 now what we're going to do is actually add to this Lambda function the ability to run a command on the ec2 instance

this command will query the metadata service on that instance and return the credentials for the role attached to it so essentially we have the ability to also View SSM commands that have been around the history and find the output for that likeable demos it broke

cool

let's go look at this I hope no one's taking notes of the credentials

so let's look at the history did not succeed cool

again to not succeed okay

cool we'll see that it did succeed look at the outputs we have the access key and the secret key which essentially means we can use these credentials outside of AWS in our own in our own local CLI and perform any action over any resource we are the da of the AWS environment so I just want to go through something quickly when I was performing this presentation to a couple of my mains they asked me this question and I actually kind of forgot they said yes you can this policy is here by default but someone needs to be able to guess they are in to do that right which is essentially your account number and the

topic name that's something we call security through obscurity and to put to give you a physical example it's essentially if you had a house on a relatively busy Street and you kept your keys in the pot outside you told all your friends and family but you relied on no one being able to figure it out if that's good enough for you sure good luck but that's definitely not good enough for for most people who love security cool so now we're we've got all of the Power well not quite there's only two gems there it's only within this account we have full admin over of everything essentially so what could we do to actually stop this from happening

three main things I could think of really is prevent detect and remediate and we hear stuff like this a lot these very high level prevent this detect this fix this but actually how do we do that and it really does depend on the organization whether you're going to put acps in place to stop certain certain creation of resources or only allow like a white list of if your company only creates ec2 instances instances only allow that don't allow attaching of roles don't allow the creative roles whatever the case may be but the example I work at a Dev house so if you do too you'll be somewhat familiar with this if you use Jenkins and what we do is we have two things

really one we have custom modules so we try and Abstract the security away from the Developers the module for instance would be like for um S3 buckets if all S3 buckets are not allowed to be public in the module it won't even give you the option right you just create a bucket and in the background it'll ensure that it's not public it's encrypted whatever other compliance policies you have so we have a compliance step that also checks to ensure that that's in place in the pipeline we want these things to fail at the pr stage because it fails that they apply we can have an account with half created resources ticked and remediates so we don't know

what we don't know right and we have a community that we can rely AWS has something called security Hub which tries to detect misconfigurations not specific to what we spoke about today but definitely other misconfigurations that's a great tool to use there are other open open source tools out there such as Prowler and Scott Suite those are things you should definitely be making use of on a regular basis and then remediate do you have a process to remediate these things what what is it and what are the timelines are you sticking to those timelines do you have a security posture where you review these things these are things that definitely need to be put in

place

and yeah just in conclusion what I wanted to add to this is the tools are very good but also we need to apply our hacking mindsets to some of these things like this path we found here was not a path that a tool found but it's something that we could we could see because we understand the Technologies right we understand that in ec2 instance with an ssrf vulnerability would allow you to grab the the role we understand that being able to create a Lambda function and attach any policy that is or any role that already exists would allow you to essentially abuse that role's permissions so these are things that we need to think about when

when doing assessments or creating these things cool and that's it

uh skates on I'm scared to ask this but are there any questions

yes sir

that that for SNS specifically or for other resources yeah so essentially anyone with permissions to view they are in will be able to find it um so just to to uh jump onto what the question was the question was those Arns in the SNS topic is that something that people would be able to find right and just like the example of the physical security where all your friends and family know where the key is everyone who has view of only access or read-only access or any permissions to view that within your account which will probably be your entire Dev team would know what they are in is and if you're using that Arn in other systems that are

not AWS related they would be there too so yeah it's pretty dangerous to to rely just on that also the Arn is your account number and the topic name so it's not something that's people may not be able to guess it's something people probably will be able to guess any other questions yes sir

sure so the question there is how do we maintain the compliance policies within our Pipelines sure so we have a security team that does that we're constantly looking at new things we also utilize other open source Frameworks or research that's being published so like security Hub is a major driver for us um yeah so that's how we find that compliance and again those compliance steps fail at the pr stage right so that PR can't be merged um so the developer will see that it's broken and why as soon as they try and push their code any other questions yes sir

correct yes okay more of a statement than a question so the metadata service there's two versions version two actually stops this from happening version one is still the default so if you create an ec2 instance through the console AWS console it'll look created with version one and it'll be vulnerable to if you have an ssra vulnerability you'll be able to call that Justin

that's a very good question I like it when you when you say permission boundaries are you talking about so we're going to go back quite a few slides I am permission boundaries over here so look how far along the line that is right that's after resource-based policies and it's after identity based policies

sure and what about resource-based policies and SCP so I think we try and focus as far to the left as possible but but yeah that's not something that we've actually explored

uh really does depend on the organization I'd say before I think scps is a very good one if you have a lot of accounts and you want to enforce certain things on all of your accounts but it really does depend on the organization the question there was just the first one was have we considered permission boundaries and the second one was are there any other guard rails that you've thought of putting in place

any other questions

oh yeah the question is is the tools within AWS the the permissions within AWS not good enough or not not good enough was that or that we need to use other tools I don't think so I think that AWS allows you to do whatever you want with whatever you want within the account how you you misconfiguring it is is really on you um but yeah there are tools out there that help you identify these things and guard rails in place just to help you stay within those um yeah there are some really good Cool Tools out there any other questions cool well you have my email address so you can always uh email me uh thanks everyone for coming