Welcome to the Jungle: Pen Testing AWS

thank you

Mike here [Music] that's connected to the audio on here so we'll have to presenter notes Here oh

I'm over here it's like like it's a Mac I'm over here all right uh let's see you're not gonna get that so let me see if I can give you the different views though yeah that's right so that works

so what I'm going to do is then let me do this

share the individual and then you'll have your first interview um [Applause]

is it this one so that should still be recording so like if we go back to questions

um

thank you very much

[Music] um weird sludge at the beginning yes we can move all that there's a water under there if you need it um yeah okay perfect

um

thank you this is static that's good

yeah sorry about that man yeah

um

thank you Florida and Tampa specifically

so far

just like I'm so tired of going there I think there's so many times without going to like this whole separately because it's like okay another highlights

thank you

again

um

together

for a long time I think I've been following you guys so I I think in my early days

yeah

oh really oh man yeah um

um

AWS it's the correct way to scale so they like your data increases like going up your cost is going down

oh yeah

all right getting ready to start our next talk here how's the sessions going so far is everyone having a good time get some energy let's go all right so here we have Mike Felch Mike Felch is a red teamer and penetration tester with black hills information security and he is here to talk about pen testing AWS I'm excited without further Ado Mike here you go thank you so just to show a hands real quick who works with AWS resources in their environment okay if your hand is up and you're not a pen tester uh how many do pen tests in their AWS environment already just a handful oh okay sweet how many are pen testers

okay so the same hands all right cool so we're gonna just walk through some of the pen testing with AWS now this is like you know a Hot Topic we've had some talks earlier today like Bo did an awesome job covering some of this so there's going to be a slight overlap there but the idea behind this is we're going to look at targeting AWS from a pen testing perspective so the reason why I asked that initial question is if you're responsible for AWS infrastructure or managing projects that use AWS in that environment one thing that I want you to take away from this is what to expect from an AWS pen test as you're walking into it if you're a

pen tester and you're walking into this talk then I want you to kind of consider it if you haven't already started pen testing Cloud use this as a catapult because I think I cover a lot of different content here I'm going to try to go through it pretty quick I'm going to make the slide decks available as well so you have the reference there's just a lot of content here to cover and so um without further Ado just kind of Step through this so as you said my name is Mike Felch I've been in the offensive security world since around like 1997 my first exposure was a CGI bin phf vulnerability which was super cool back

in the day and I've also been writing software for a really long time back from like the vb3 days and so um and I got my start in the BBS world my dad was a engineer and so I kind of got started with bbs's and back doors within bbs's and so it kind of just piqued my interest and since then I've just kind of stayed in this realm for some reason but that's kind of me and so about this talk this is not a reflection of Amazon specifically uh you know they are a phenomenal company they provide a lot of different security controls to implement but a lot of times we're putting these these environments together and it leads

to a lot of insecurities so this talk is going to kind of cover a lot of that and then looking at it from like using like the CLI and some other tools and so we're going to dig into some of the services and then we're going to try to scale this because if if you're if you're like some of the customers that I've had to pen test before it's usually not just one AWS account or three AWS accounts it's usually like 20 AWS accounts they split them up into different silos within the business structure or in the sdlc so they have a Dev and then they have a prod and a test and a stage a uht and they just set it

all up where they're separate accounts and they're wanting us to come in and kind of do that and then on the other side that we're going to cover a little bit is just reporting which is the super boring stuff but I want to kind of make sure that I give you what you need in order to know uh just kind of how to present this stuff and so with that um the agenda we're going to look at just from a high level testing overview and then we're going to look at how to provision our access so whenever we're going to do a pen test so we're going to pen test an environment it's going to be specifically on AWS how

do we set up for our initial access and then we're going to walk through your traditional pen test phases that's going to kind of break it all down and then I have a tool that I just released that'll help you a little bit on on some of this it's nothing super sexy but it's still fun and then we'll have some closing thoughts and so from a high testing or from a high level testing overview what we're looking at is we're looking at like an organizational structure where they roll AWS accounts up underneath that organization so when we talk about organizations that's what we're talking about the AWS account not to be confused with an IM account but an AWS account is

going to have you know we're going to have one or more AWS accounts that we're testing and sometimes they have resources that are in different regions of AWS and so we're going to try to leverage this for scoping our pen test so as you're going and you're on the scoping calls or you're trying to figure out how much level of effort it's going to take and actually to pen test the environment some of the things to consider is how many different AWS accounts and then we would like to know how many resources are in there but that can get really tricky right because we have the whole ideal idea behind cloud is scaling so we might have one resource

that looks like you know 20 resources so do we have 20 resources or do we have one resource is it up and down and so it's kind of tricky to scope a pen test based on the number of resources and it also depends on the client or your environment sometimes they want something completely different they say hey we just want to know what's the impact if our developer gets compromised so we're going to simulate starting from a developer role and then trying to pen test the resources from that compromised position and so that's kind of what we're looking at when we talk about what we're actually testing when we talk about resources if you're not familiar just to kind of go over it

really quickly resources are really going to be the infrastructure that we're using so in this case ec2 for virtual machines or for object storage we're going to look at S3 if we're looking at relational databases and they have applications and all that that might be RDS sometimes it's even serverless compute where they're not wanting to roll out any infrastructure they're just wanting to take the code throw it into some serverless microservice and run the code and then give us the result and there's lots of resources within AWS and there's lots of different service types and so they're pieced together like Legos now the the thing like that the thing about that is when it's put together properly it can

be hard to break apart but when it's done wrong it could have major consequences and so we're going to kind of look through some of these and then the idea behind it is we're going to try to exploit a resource and then interact with other resources using that initial compromised resource and so when we're talking about scoping what are we what are we how many accounts are we talking about five to ten are we talking about plus a hundred the best way that we've found to scope the pen tests is if it's only five to ten we could probably get that through you know within a week or so for a pretty decent in-depth test of the

resources and the ones the services that you're using if it's a lot of accounts I mean I've had some where it was like 186 accounts uh we usually time box that and then we're trying to cast a wide net and then focus on the priority issues that we've arosed rather than go deep dive into every single policy of every single service the other thing to really know that's that might be really useful for scoping is what regions are they using and so a lot of times they might only use Us East one well that's really good to know because if you have to go through your reconnaissance you're going to have to enumerate those regions for

each account that could exponentially increase the the amount of scope that you're actually doing the test I think the other thing that's really really important is understand that these are the expectations that we really want to set during this open call because the last thing you do as a pen tester as you're walking in and you're starting it you have your Rules of Engagement call you're kicking off the test on Monday they say you know that you get in there and next thing you know you're testing 50 accounts and you only have like five days like that's just crazy and so setting that expectations up during the call and really understanding what the client needs are is super important in

order to do an effective pen test and so one of the components of this is I am and so this is the identity and access management this is how we're going to get our initial access in order to start the testing there's a number of different ways to do this uh one of the one of the the solutions is they could just create you know your your IM account or I am user um but what we're going to want is we're going to want read-only access to the environment and so we can provide a policy that has all of the read-only access to the resources this is not going to give us any ability to interact

with the the resources outside of reading those policies that are associated with it so I am is going to control the access to the resources for users for groups for all the permission models that are that are based behind it and it's going to use these policies in order to kind of differentiate between what users have access to what resources and so these policies are going to be applied or the permissions of the policies are going to be applied for resources to the specific users and so there's also password policies that you can create and that's going to manage all of the MFA and anything that you would want so I am that's pretty much

what I am is anything that anybody is familiar with your identity and access management it's the same thing I'm just I'm I throw this slide on here for more of the terminology because it's kind of different between some of the cloud providers and then a principle in this case is any AWS user any role any AWS account that's the word principle so you'll see that in a little bit later um and why is all of this super important it is because vulnerable policies are what we're going to use as the entryway into exploiting the resources and so we're going to start with that read-only access and we're going to try to exploit from there and

so let's just look at what that is real quick this is just a sample policy these policies I know it's hard to read sorry about the colors but the idea behind the policy is you're able to specify what type of action and what that action is applied to and what resources are governed by that policy and so this is just an example policy and and they could be misconfigured in a number of different ways there's and they can be configured to allow for specific principles or you could do asterisks and so in this case this was just an SNS so the notification system service uh within AWS and it's the security notifications this was actually a real

policy that I had found on an engagement obviously it's redacted actually there is no redaction because it allows everybody um but you'll notice the principal uh Arn down here it's the IM and it's it's asterisk and so what we he what we see here is we have an allowed to publish to an SNS topic called security notifications you can only guess where that went uh it is for any AWS account based on the asterisk within the principal arm now this is just a misconfigured one there's a lot of them that look like this but this is some of the issues that we're looking for it can get really really confusing really quick uh so we'll cover that in a

little bit a little bit later in the presentation so for provisioning initial access I mentioned that there's you could do the IM account so I am users of your access keys key A lot of times if there's only a couple accounts to the client's gonna say hey we'll just give you a set of AWS access Keys other times they say hey we don't even use IAM users so we can't provide that for you and we'll talk about how to do that in that on the next slide but in this case what we're going to need if they're giving us access to the web console would be the account ID or the Alias that they're using plus an

email or password and so this is really easy for a few accounts to the provision I actually don't recommend doing this way at all um it's actually also harder to generate when you're testing 100 accounts right because you have to go in there unless you have some sort of super automation it makes it a little bit difficult what I what I recommend doing is the assume role now an assume role is this feature that allows the assuming of a role with permissions for resources to be designated to another account um but the idea is you can actually use it for cross accounts so I could bring my own external account on the free tier AWS account and uh we could basically

give permissions to my external account into the role that's applied to that read-only policy and so they can apply that read-only policy give an assumed role to my user and that's great because then I could use that to assume permissions in their environment for their resources and generate temporary credentials this is the ideal way to test I love the CLI I have a lot of tools I try to automate as much as I can for the reconnaissance because Gathering all that data can be really difficult to scale especially when we're dealing with a lot of accounts and so this is also really really useful for the client that's provisioning these because they can just assign that assumed role across all of

their accounts create the same name we'll just say pen test role and and then provide that role name to me and I could configure my environment and I can just Loop through each of the accounts and kind of do that so it's super useful for doing that next thing we want to do is we want to set up our environment so one of the easiest ways to do that is just install the AWS CLI configure it and then you can actually configure it with a profile name I'm specifying this here for a second with the testing but normally what I would do is take the account number of the accounts that I'm testing and I

could provision my environment with that account number because in my tools I'm going to enumerate some files I want to pull the account number and kind of do some enumeration it's really useful but what I would do in this case though is provision my own keys right so I created my free tier account I used my keys I provision it with the configuration command it stores it in the the credentials file on my computer so that way when I call AWS commands it's going to pull from my profile and I'm good to go I'm just going to put that in the credentials file that's listed there on most operating systems and so now we're going to need to assume we need that

assume role from from the client so they let's just say they set up the environment they have tied that that read-only policy to an assume role they've granted my account permissions well the other really cool thing that AWS CLI does is they give you this config uh in the in the config folder or the file is where you would set the profile name the role arm so remember they created this assume role and they have a role name in this case it's just called the pen test role and so I'm specifying this in the config file the profile is going to be the name of the account that you're testing I do this because like I said I'm going to be

calling it from some enumeration tools and so I want to reference that account number so I know which account I'm testing of that client's environment the role Arn is going to be the Arn the the resource name for that specific role in the the customer's environment so that's going to be one of the accounts that I'm testing it's matching the profile and I'm setting the source profile to my profile this is because when I invoke AWS with the profile flag I'm going to be calling the testing that testing is going to use the assume role to generate temporary credentials to interact with the AWS API this is how we're able to environment cross between mine and the

testing environment in a way that gives us the ability to read the resources and so once we have that set up and configured you're going to want to do this ahead of time before the engagement starts you're going to want to test the access to make sure that that assumed role is generating the right roles and responsibilities that you have so that you can actually do the testing and so if you just called the STS get caller identity you should see the results with the Arn the account number and the user ID and you can match that with what the customer provided you if you get an error here your your configuration is messed up something's not right nine

times out of ten they didn't apply that role to your account properly and they can go back and kind of tweak it and this is super important to do because if you're doing it with 100 accounts the last thing you want to do is find out that 20 of the accounts aren't working for some reason and now you have to go back to the customer you lose a day and so you want to kind of avoid all of those types of those headaches beforehand and so let's talk about reconnaissance this is the first step in our pen testing phases so what we're wanting to do is we're wanting to do for every AWS account we're going to pull

every region in that account and we're going to retrieve each of the resources you can imagine how bad this scales uh when you're trying to do this you know kind of across a lot of different accounts and so while we're at it we're going to want to pull the policies because we need a quick way in order to determine whether or not that policy is vulnerable now you could dig in and and I I highly encourage you to do that why don't you identify what resources are there but before you get to that point we just want to pull those policies there's some tools that we'll talk about in a second to do that the first tool is

going to be Scout Suite now this is a tool that I thought was no longer around I thought was dead because they haven't had any pushes in a while but I found a new branch on the GitHub and so they're going to be I guess doing some releases soon hopefully because I see a lot of activity on the dev Branch it doesn't find everything but it is really great at finding just the initial snapshot of the resources and some of the common misconfigurations it's pretty good at identifying profile or policies that have misconfigurations and so it'll give you that low hanging fruit right up front and say hey there's something going on here you want to dig in here

but the other thing that it doesn't do is it doesn't retrieve all of the resources so that's the other problem with with Scout uh awesome tool does great job without doing what it does but it doesn't do everything so you're going to want to continue and so this is the nice report that it generates so as you can see it breaks down some of the services it shows the number of resources that identified the number of security rules that it's scanned against so this is built in the Scout Suite it's kind of how it identifies the vulnerabilities the number of findings that are there and you can dig into these at a little bit more of a granular level now it does

AWS but it also does Azure gcp it does some of the the other more less popular Cloud providers but I haven't used it for any of those things I use a pressure as well though there's another tool though called AWS list all now this tool is not really a pen testing tool but it's really valuable for quickly enumerating all of the the resources and across the entire account in all the regions uh it does take a little bit of time and it may exhaust some of the rate limits that you have within AWS but it's super powerful at giving you a quick snapshot of where potentially the attack surface could lead to so that you could dig in a

little bit more and so now that you've kind of cast that net you've enumerated a lot of the resources you've pulled some of the resources down you've looked at some of the policies let's look for some of the vulnerabilities and how we can actually leverage these for exploitation and so when you're analyzing the Scott Suite result results um I want to warn that it does give you some false positives from time to time because you can imagine these policies get very complex and very difficult uh for your traditional um analysis by a tool so you're writing these rules and it's hard coded and I showed you the policy earlier that's really difficult to kind of identify

within uh within a scanning tool at least ones that we're coding with rules and so you're going to want to really validate some of this stuff the other thing that I wanted to point out this is not like super well known I don't know why but um Scout Suite stores a huge Json blob of all of the data that it gets back from the AWS scan in a Javascript file and so you could carve out that Json file I have some one-liners I think in here which will help you retrieve some of the data where you could just query it using JQ on that Json blob in order to kind of drill into some of the resources but as you're

looking at the scout Suite results in the the report you'll notice that it gives you a brief description and and if you click on the title where it says receive authorized to all principles it'll show you where it's vulnerable what you know what where in the policy it was vulnerable what if resources are affected by so it's super handy for really trying to identify some of this information early on because it's going to kind of point you and calibrate you towards where you should dig in the other thing you could do is just Brute Force the actual resources so this is this is fun so sometimes I don't even worry about it I just I kind

of just go this way anyway so SNS topics you could query for all of them so hit AWS get all of the regions back get all of the list topics back for each of those regions query that topic Arn and just brute force it with a one-liner and just try to send a message to each of the SNS topics if it's going to allow you to publish it's just going to come back with some an ID of that published message if it doesn't it's going to say that it's not you don't have authorization but it's a quick way to just kind of Brute Force some of this now be careful on what you're brute forcing just because that can get

dangerous but for for generating these crazy one-liners obviously Chad gbt so this is awesome um you could so AWS documentation sdk's code repositories stack Overflow the apis the python libraries chat GPT has mined all of this it's pulled all of that Corpus into chat GPT and it knows it really well and so you could generate amazing one-liners to query AWS CLI directly or you could sanitize the policy so you could query the actual AWS infrastructure retrieved the policy take that policy send it to chat GPT after you sanitize it because you want to pull out the account numbers you want to send all that stuff to chatgpt and just say hey is this vulnerable it's amazing it'll come back

and say yes this policy is vulnerable to you know any accounts being able to interact with Lambda functions over here you could demonstrate this by and gives you the command and it's just amazing it's a really good useful tool but just once again you want to be careful not to leak customer information um and so with that I'm releasing a brand new tool I'm selling it for a lot of money not really um so chat GPT plus Bodo 3 gives you the ability to automate this so I have a full tool I haven't released it yet I'm actually releasing it in two weeks at hackspacecon at Kennedy Space Center it's actually pretty cool it will and I got a proof of

concept down here so if you grab that link it's just a little it's where I started you know the proof of concept before you write a tool but it's there and it does it it doesn't redact anything it doesn't sanitize anything so just be really careful if you're actually using it but it'll retrieve all the policies send them all to chat gbt and then get a response and then tell you whether it's vulnerable or not awesome stuff it works really well so the other thing you want to try to do is we want to try to treat this from the addition like the the standard attack surface perspective of the infrastructure right so a lot of the

stuff is exposing either web applications or some sort of uh infrastructure for interaction with the internet and so we want to take all of the IP addresses and host names for all of the external infrastructure whether that's elastic IPS ecs2 instances RDS endpoints and we're going to try and um we're going to try to look at those because we want to treat this as your traditional scan this is where your external scan would kind of come in but you could do your traditional Port scanning screenshot with go witness do your dirtbusters or your your fuzzing and then treat even the web app pen test because one we're going to be looking for if you didn't go to Bose talk

earlier he talked about ssrfs we want to find those if we can find those in web apps there's some opportunities there that we might be able to laterally move and escalate into the environment and so the other thing that I like to do is when I'm in there I'll I will pull the IM users to retrieve the IM usernames and the credential reports from the AWS IM the reason is because these credit reports show whether or not MFA is enabled for the users it tells you their password last change date when that account was created and the reason why that's important is prior to November 18th of 2020 there was no default password policy for AWS

what that means is you can have a password with one character um and so the other problem is AWS IM does not have a lockout policy and so if you're familiar with password spring about 20 years ago there was this idea that brute forcing passwords was a thing well we're there again um I am allows you to Brute Force without being locked out and so it gets really interesting is if you could pull the IM users from the credential report and see that that account was created prior to November of 2020 and there was no last password reset date prior to November 2020. there's a chance that you could just brute force that password um very easily especially with you know

Single Character passwords and so the way that I typically do this I just point um I use burp just burp Intruder I'll point it at the the sign in url and then I'll post my uh my account my username and my password that I'm brute forcing I'll load up a you know Common password list and just Brute Force the Daylights out of it um sometimes you get lucky and you'll find stuff there was some other issues with that login process where there was a timing attack where if you could send a number of requests to test to see whether or not that user existed it would tell you based on the discrepancy between the results from the

web server you can look at the timing and the time it came back to determine whether or not that was a valid user so you could kind of enumerate users externally without having your your AWS IM query for that user credential report prior to the testing so just kind of useful if you're wanting to do it from an external perspective and so for lateral movement and privilege escalation we're going to kind of talk about a couple different things but one of one of the the highlights of this I would say is we're going to look for we prefer permission snowballing if you're from like the active directory environment and you know like cred snowballing where you know you get some

creds you pivot to a machine you escalate you dump credits from memory you find new credentials you find where they're logged in you pivot over there you find domain admin and you're good it's the same kind of concept but we're doing it with permission so we're wanting to find assumable roles or credentials that we could use to leverage other resources that gives us a further foothold into the environment with more elevated permissions and so we're going to take those Services we're going to Pivot around we're going to try to unravel those roles and those policies and make sense of them because then what you're going to learn is you're going to learn that you might

have the ability to take a Lambda function for instance and interact with the ec2 environment or an ec2 instance but you can't do that directly so if we could find a way to do something with Lambda to kind of do that we'll talk about that in a minute then you might be able to Pivot around and laterally move between Services which gets you to the destination and the same way the other thing that you might be able to do is if you're looking at these permissions and these policies you might find like the one we saw earlier where you don't even have to have an AWS account within that customer's environment you can bring your own AWS account which means you

just go sign up with a free tier with a just you know burner credit card and put that card in and get those credentials and then use those credentials to kind of laterally move sometimes you do need internal creds so we're going to kind of look at how to focus on those the other times you might be able to even pass in a no sign request and not even log in and just interact with them directly depending on the permissions and so one of the components that we're going to really want to focus on on these tests is third-party services and the reason why I focus so heavily on this is because a lot of places within

Amazon resources you could put plain text credentials and it's a lot it's everywhere so ec2 user data is like a script that you could kind of provision within the ec2 instance to to trigger some code execution whenever that that ec2 launches that user data is base64 encoded and a lot of times they'll set environment variables or they'll put like command line arguments that contain credentials or tokens and they'll try to provision that environment with these so if we look and we pull the ec2 data the metadata for that we'll see the user data blob in there if we base64 decode that we'll be able to see whether or not there's plain text passwords in there

now if you do that across the entire environment you'll be you'll be blown away how many credentials you'll find I've leveraged ec2 data in order to compromise Microsoft SharePoint because for some reason the ec2 data was provisioning something within there with some credential tokens that interacted with SharePoint so I was able to laterally move between clouds other times we were able to just completely disseminate the whole entire environment just because of credentials that were in there Lambda function code is another really big one so Lambda is that serverless compute you push your code up there and it runs it but you could provision it with environment variables those environment variables are the same thing that you can imagine within

infrastructure their environment variables for the context of that code to be ran so access keys are provisioned in there all the time another thing too is if they're they're deploying cloud formation Stacks there's a lot of parameters that they could provision within those Stacks plain text passwords in there all the time now there's ways to mitigate this that they don't have to have them in there as plain text but a lot of times we find them in there if they're pushing code the code build environment variable is another one the SSM parameter store there's actually a secure string within the SSM parameter store where you're supposed to store sensitive data but a lot of times if you look there'll be

plain text strings in there because they're not using that type uh and so you'll all the time find more AWS Keys now you find AWS keys in a Lambda environment you load those back into your environment in your uh you just do your AWS configure with those new credentials and you start the process over because now you have access potentially to more resources or more more permissions to the resources that you already know about the other thing that you'll find in here is a lot of third-party services like datadog and Docker we found Docker keys we're able to pull private stuff um slack hooks so they send messages to slack or to teams you'll find those

hooks in there all the time I compromised an entire mobile device Fleet because they're third-party service was the token was in there to be able to interact with it so you just really want to slow down as you're finding these credentials a lot of times you're not going to know what they are you're just going to see these weird variable names spend some time trying to decipher what those are because once you do that you'll find that it's a it's a really useful attack path in another Direction so let's look at some of the issues where policies have higher permissions than they should so if you have the ability to create a policy version this

is interesting because if you have the ability to create a policy version why don't you just create your new policy and then attach that policy version to an existing policy and then set it as the default policy right because if you have if you're a part of that policy you just escalated your own permission model to to that or you could just attach a new policy so attaching User Group user policies group policies or even role policies and there's also these in-line policies where it's it's very similar but it's a one-to-one relationship where you're attaching it to a specific user so that policy goes to that user if you have these types of permissions in these

policies there's there's a potential for attack um you know privilege escalation opportunities or if you can update assume role policies this is just where if an attacker has the ability to update that assumed role policy if you just update that policy and I don't know give yourself more permissions then it's good I did want to Spencer here this a lot of This research is from Spencer Spencer passed away a little while ago he was phenomenal at a lot of the AWS lot work a lot of the work that I've researched was building off his work already so but I put a link there um so he covers more in depth some of these privilege escalation methods so

just kind of threw that on there for the slide so you can kind of follow it up if you want to dig into it more some of the more odd permissions that we see is pass roll so if you could pass an existing role to a resource or service and then use it you could pretty much pass whatever role you want to pass to it so if you wanted to launch an ec2 instance um there's some stuff that we could actually pass that role and it'll call it on behalf of uh whatever role you're passing in so it's kind of like if you're familiar with like sudo for like Linux or Mac like pseudoers being able

to call it from a higher level permission that's kind of what pastoral is so you could pass in the permission and then kind of call it it gets a little bit more complex but the other thing to look for is not actions so not actions are weird because if you don't specify all of the not actions then everything that you don't specify is an action so if you see not actions with plus effect then it's creating a prevent list which is not really good right because that means everything else is you have to have a really large prevent list on lambdas if you could create an Event Source mapping you could tie lambdas to other stuff so if you can't access ec2

or you can't access RDS but you could do something with Lambda let's say you could create a function and you also have the ability to create like an Event Source mapping you could tie that Lambda to another service to interact with on your behalf and then um and then the last one like cloud formation if you could create Stacks you could it's really bad with pastoral but you could launch new resources to like create administrator accounts and whatnot and so I am roll also has this ec2 metadata so Cloud providers provision this in order to have the cloud compute resources be able to assume the permissions that they need in order to interact in the environment where

they're at and so ec2 has this metadata called imds and there's two different versions the first version allows that ec2 instance with an IM role that's attached to it to generate temporary access keys so back to the problem with the ssrf if you're able to trick a web application into hitting that metadata URL you could potentially if it has an IM role attached to it you could grab those credentials from that metadata URL and actually use those back to the reconnaissance process to reconfigure your environment use those new credentials and you go the other thing too though is on the version one it did not require authentication any type of authentication so any type of

vulnerability uh where you were able to trick an application into interacting with it or if you were able to SSH into an ec2 environment you could just curl that metadata URL and retrieve those credentials to fix that and remediate that they created a version two which does require authentication but the security fix was basically to re retrieve a token from the token URL using a put and then use that token in a request header that specified the X AWS ec2 metadata token header and then call that to the metadata URL and so it requires that extra token in order to be able to interact with it but you can still do it so if you're on a machine or you're in a

Lambda function that has some functionality like that where you could call into ec2 it's still available it just makes it a little bit more tricky and it kind of mitigates the external ssrf type of attacks unless you have multiple ways to do that which would be really weird and to have bigger problems anyway and so the other thing that we can look at is within Lambda so Lambda with an assumed role is really valuable so you're going to want to look at the inline and the managed policies and all of the policy versions so you're going to look for that assume role with either your principal ID your account ID or for anything with an asterisk or an account

that you have access to and then if you call the AWS SCS assumed role with that Arn once again you're back in there now this is the same way we provisioned our environment so if we could leverage that assumed role we could do the same exact thing but what we're going to want to try to do is use these creds to see if we can create functions or update function code or you can even add new layers to the Lambda function which is basically just another way to have code in there without having code in there and if we can update those function configurations we have the ability to leverage Lambda with these assumed role

with the assumed role so that we could take our code put whatever code we want in there we could just say you know query RDS and give me back all the data and we create a function in Lambda we push that create function code up to Lambda we use that Lambda to Pivot over and then we get the data back and kind of go from there so just gives us a quick way to kind of do that um or we could launch ec2s with instance profiles so we could check inline and manage policy versions again if we have the ability to do run instances great we'll just launch an ec2 instance if we don't we might be able to create or add

or remove instant profiles which is going to provision a new ec2 instance we do that with our own keys and we could use that to ssh in the beauty behind being able to SSH into your own instance that you just launched is it's usually launched within the VPC that virtual environment and we might be able to interact with the other resources directly because a lot of the security groups are going to restrict outside access but they might provision it where inside that VC that VPC we could actually see the resources and the firewall has holes there so we could use that for lateral movement and interacting with it the other thing is if the SSM nodes have that send command

availability we could just call run shell script and just literally remote code execution and send it across the board so it's super useful if we see these types of commands to really dig into them a little bit more just kind of see what we have Cognito if anybody familiar with Cognito it's kind of a weird one I don't see a lot of people that know about it but it's really really useful in Hardware devices that are interacting with cloud or mobile apps so it's basically a Federated way of managing access to an application using like third-party authentication providers so using your Google account to log into a hardware device that's communicating with AWS for instance like you're

provisioning your your new router and it's super cool when you're doing all this stuff and it lets you log in with what your whatever credentials you want user pools manage the identity access for creating new accounts for signing up so you're creating a new account what ends up happening is once that user pool assists us with creating that account it goes to the identity pool to see what permissions we have available to so we can see what access we have sometimes those identity pools are hard coded in a mobile app or a hardware device if we could get those identity pools and interact directly with it we might be able to generate temporary credentials because that's what the identity pool

does so your user logs into a user poll of an application that user pool gets access to the identity pool that it needs you use the identity pool to retrieve temporary access Keys credentials to log into whatever environment you want or whatever they give you access to so a lot of times these are super loose right so they're just giving you access to a lot of stuff so you use those credentials that you just generated log back in do your configure and redo your reconnaissance and you can find these everywhere sometimes you're in JavaScript sometimes they're in response headers when you're making web requests sometimes they retrieve like a JWT that interacts that use that JWT to interact

with AWS so it just depends on what you find but these identity pools can be pretty easy to do so at the bottom here I have the Cognito identity to get the identity pool and then you could use the get credentials for identity and just pass in that identity ID and it just gives you your temporary credentials and it's pretty cool so data X fill so Amis these are super useful for uh when you're creating an image that you want to launch in a repetitive way with ec2 so the thing is a lot of people don't realize that they have public exposed Amis on the web already so you could do this either using describe images or you

can go to your you know your web console you could drop over to your Amis and there's a drop down it defaults to owned by me and usually you have nothing in there unless you have created one if you drop it down to public images these are Amis where I can literally take this Ami and launch my own ec2 instance with those images now some of them are for like the marketplace some of them are just default some of them are just accidentally exposed like I found one on an engagement where the Ami was actually public it was on an on accident I thought it was just like a public one that you know they were just reusing but

it ended up being one that they accidentally set and then you just Mount that into your or use that for your ec2 instance and then you're back to 1999. you're you're enumerating the file system looking for credentials and doing the whole thing so it's just a big problem same thing with EBS this is the the block storage so you're wanting to provision like a a block of storage for files or whatever saving exact problems snapshots you go to the public snapshot filter it shows you all the snapshots so you can create um you could you could assign these snapshots to another AWS account or you can make them public and then once again you're right back into it or if you're

on an engagement and you have the ability to modify the attributes of a snapshot in your customer account you could just take your external account and then modify the the snapshot attribute with the snapshot ID of the one that you're trying to X fill and you can create volume permissions and just add your own user account to the permission model and then you can go to your account and then just create a new volume with that snapshot because they've shared it with you I would never make an Ami public all the way public I would always share it with my external account if I did it you may also want to verify with the customer that they want you to test this

before you do so sometimes just telling them that hey this is this is vulnerable to this is good enough and they'll look into it themselves but just be careful and then hacking S3 buckets I want to kind of slim through this because a lot of people know about the S3 buckets so inspect the HTML and JavaScript a lot of times you can find the the URLs for these S3 buckets and then just kind of Brute Force to see if you have access to it there's a lot of tools out there that kind of do this already you can look at SSL subject alternative names to see whether or not there's any sort of um uh

hosts that are in there and then just do an NS lookup or try to just browse to it directly to see if you have it and then just take it to AWS and just run your AWS S3 LS on that bucket name to see what you get a lot of times you'll find data it's crazy what you find in there and so for scaling so this is just a quick way to scale these pen tests so I told you I kind of gave you the rundown of what we're doing here so by them giving us an account number list the client giving us an account number list I put it into a text file you could just cat that thing

do a while read on it and then run your scout against all of it and it'll create new folders and it'll give you all the reports and it'll give you all the fun stuff and so you could do this across a lot of accounts I would just I would I would be careful and make sure you consider using your max rate or your max workers so you don't burn yourself out and then also back to the the regions thing if you know that they're only in Us East one I mean you could ask them if they want you to test the other regions just in case like a rogue developer created like resources in some region

that they're not using but nine times out of ten if it's a lot of accounts you're going to want to specif specify the region that you're doing it's going to generate the report it's going to give you a lot of cool stuff and so for a quick analysis this is some of the stuff that I do with uh with the data after I get back from Scout Suite as I mentioned earlier the Scout Suite results are in a Javascript file so if you just do a fine Loop you do your find you execute tail minus n plus two you can actually carve out that Json object and then just pass it directly into jQuery or not jQuery JQ and then query

the the instance metadata for instance in order to see what that results with or the Lambda environments you could kind of do it from that perspective it's super easy it scales really well you'll be surprised at how quick you'll find attack paths in an environment and so the tool that I want that I kind of just released is called Outpost it's not super crazy awesome but it will generate your config file for you with your assumed role so they give you 200 accounts and you don't want to have to go you know hand Jam all that stuff in your config file pass it to Outpost it'll do that it's also really useful for testing all of your access so you

could pass in like your your accounts.txt file and it'll test all of your access for you the other thing that it'll do is it'll um it'll generate all the findings from your scout Suite results in a nice hand crafted observation description recommendations it'll put all that so you can you know a lot of times you're looking at you're having to generate findings for these in reports so it kind of gives you the boilerplate you're obviously going to want to go back in there and context it to the customer's environment as you find out what attack paths are there it just kind of gives you the boilerplate and it'll generate a list of findings and all kinds of artifacts so if you say

okay well you know what 200 accounts were vulnerable with this SNS topic uh to publish it'll give you a nice itemized list that you can hand over to the developers or devops team in order to kind of remediate whatever the issues are and so you can find quick wins this is the command line if you're wanting to access it there's a URL down there I found this really useful I use this regularly I use it at the beginning of the engagement and usually at the end of the engagement just because it's super helpful and so closing thoughts I'm kind of shot for time and so client recommendations always use cloudtrail you won't believe how many times we find that there's no

logging or any type of monitoring in these AWS environments or they're only doing it in prod but they're not doing it in tests and for some reason you know the problem is persistent across both um I would also Implement a routine AWS pen test on all of your accounts don't leave one off just because it's just a one that you gave a developer so he could or she could test some sort of development efforts before they roll it into another environment you want to test it because sometimes there's cross account pollination where that Dev account has access into the production account and those resources are able to connect so if I could pivot over there I

might be able to Pivot into the the production environment as well you're also going to want to implement a least privileged model so if you're you're Lambda just needs to invoke Lambda don't give your Lambda the ability to create something if it's just invoking a function just limit that permission to invoking just that that um that Lambda function if you have web applications that are in ec2 Block access to 169 254 169254 that's the metadata host your web application should not be interacting with that there's there's other ways to get access to the access credentials then externally within the web app um and then avoid not actions plus allow um and so if you're a pen tester follow

your traditional pen testing phases the more attack surface that you know about the better the test is going to be and then create cheat genes for these one-liners it's it's super useful to be able to go back in your documentation grab it copy it over it really helps with the repetitive tasks as you're trying to do your reconnaissance or look for specific low-hanging fruit you also want to get familiar with the AWS offerings I only covered a handful here there's so many of them every time I open the door to a new one there's like oh wow where can I store plain text Data oh there oh wow there's credentials there I didn't even look there before so

it's really useful get familiar with the service offerings that are there and it's really a great time to start cloud pen testing there's so much there's pen testers have been around for a while cloud is still so new there's still you won't believe how many people are looking for cloud pen testers or looking for cloud pen tests and so and if you want to pen test or you want to learn how to pen test or if you need help trying to get set up for a pen testing reach out to me I'm more than happy to help in any capacity and yeah that's pretty much it so if you follow me on Twitter it's you stay ready and I'll be

around for questions thank you

I had to get a break so I missed like 20 minutes

[Applause]

um