In this lesson,
we're going to spend some time looking at a
couple of reports when you're conducting cloud auditing.
Now for the exam,
you don't need to be able to go through all these reports
and understand them step by step by step,
but I just want to give you a good overview
so you can then explore more on your own.
We're going to take a look at a couple of auditing reports
based upon a misconfigured cloud environment.
To do this, we're going to use a tool known as Sadcloud.
Now, Sadcloud is an intentionally vulnerable distribution
of a cloud infrastructure
and it's for use inside of the Amazon Web Services Cloud.
If you'd like to be able to spin this up yourself, you can.
All the instructions are on their GitHub
at GitHub/nccgroup/sadcloud.
Now, the makers of Sadcloud are the same people
who make ScoutSuite,
and so they provided this as a way for us to learn
how to use that tool, look at the different auditing reports
that are generated from it,
and then use other tools against it as well.
Think about Sadcloud like you would Metasploitable 2.
Metasploitable 2 is a vulnerable virtual machine
that you can then attack using Kali Linux.
Well, Sadcloud is a vulnerable cloud infrastructure
with servers and other misconfigurations
that you can then look at using the different tools
in the cloud area to be able to get better
at using those tools and using them for the real world.
If you go over to github.com/nccgroup/sadcloud,
you could scroll down through their readme.
In the readme, they explain a little bit
about what this particular system is.
As you can see here, there are 22 AWS services
with 84 different misconfigurations
that they put inside of Sadcloud.
They do this so they can then look at it using tools
like ScoutSuite, Prowler, and many others.
Now, Sadcloud was, as I said,
a way for security researchers
to be able to learn more about cloud vulnerabilities
inside of AWS and it's a great tool for us
as future penetration testers.
Now, if you're going to do this,
you need to know that you will incur some cost
by running Sadcloud.
It costs about $10 per day for the cloud compute time,
so if you are going to use Sadcloud,
you don't want to leave this running 24 hours a day,
seven days a week, because it'll start eating up
a lot of money inside of your budget for cloud computing.
Instead though, you can go ahead and turn it on,
you can run your scans or run your hacks against it
and then you can shut it back down again.
There are instructions of how to do all of that
here in the GitHub for Sadcloud.
Now, in this particular lesson,
we are going to focus on the actual outputs
of those scans that you would get
by using something like ScoutSuite or Prowler
as opposed to running those scans yourself.
Now, if you want to run those scans yourself,
it's not really difficult to do.
If you go over to the GitHub for nccgroup,
you'll also find one called nccgroup/scoutsuite
and this is the actual tool for ScoutSuite.
If you scroll down, in the readme,
there are instructions of how to run this tool
and it really is simple.
To run it, you're simply going to type in scout aws
if you're doing it against Sadcloud in AWS, --profile,
and then basc -f, and this will go through
and run a scan against that Sadcloud infrastructure
that you have then deployed.
But what we're going to do is instead of running it,
we are going to look at the report that comes from it,
and if you go over to the Sadcloud GitHub,
there are links to this audit report as well
that you can go through on your own
and explore it a little bit more in depth.
When you run ScoutSuite,
you are going to get a report like this
generated based on this cloud that you have just scanned.
You could see here all of the services listed
on the main dashboard, the resources,
the rules, the findings, and the checks.
Each of these is for a different service
inside of Amazon Web Services.
You'll notice if we scroll down that EC2
is one of the largest that we have
with the most vulnerabilities.
Now, why is that?
Well, because EC2 is Elastic Computing
and that means virtual servers.
These are virtual machines
and there's lots of different vulnerabilities
that are associated with that.
The other one that is really high that you could see
with the red exclamation is IAM,
which are Identity and Access Management.
So as we go through, you can click on any of these.
For instance, let's go ahead and click on EC2.
By clicking on EC2,
we can now see all the vulnerabilities we have.
Now, as you can see going across the top,
we do have four filters.
We have show all, good, warning, and danger.
If I click on good, I'm only going to see the things
that passed the vulnerability scan.
In this case, the public EBS snapshot was good.
If I want to see the details,
I can click on the plus and here I'll get a description
that the snapshots should never be public
because that could risk exposing sensitive data.
And in this case, there was one snapshot
and it was not public, so this was considered a good check.
Now these snapshots are considered backups
and they contain all the state information
from a particular virtual machine.
Now, if I want to see all of the things that were warnings,
I could click on warning,
and you can see there are several warning areas here,
including all ports being open,
the default security groups in use,
non-empty rulesets for default security groups and others.
Again, if you want to get more details about what it found,
just go ahead and click here,
and in this case it checks 73 rules
and there was 26 open ports,
so we'd have to go in further to be able to figure that out
as we look through some of the tabs of ScoutSuite.
Next, if we go to danger,
we will see everything that is a big danger area
that we really need to take care of.
In this case, again, we have all ports being open,
and we had two rules that were flagged here
out of 69 that were checked.
If I look at DNS port, that's open to all.
We could see again, one rule was flagged.
With EBS not being encrypted, there was one snapshot check
and one was flagged,
so there was no encryption on that snapshot.
Again, the EBS volume itself was not encrypted.
That was, again, we had three volumes checked
and three of them were flagged.
So these are things that we'd want to go and fix
as somebody who is a network defender.
Next, we can go click back onto ScoutSuite
to see our main dashboard again
and we can pick another area.
Let's go ahead and choose IAM.
IAM is our Identity and Access Management,
and this is all about rules, roles, and permissions,
and so as we go through,
we can see some things that are lacking.
For instance, we have a cross-account AssumeRole policy
lacks external ID and multi-factor authentication.
This says that when you're authorizing
cross-account role assumption,
you should require multi-factor authentication.
In this case, we checked it against 13 accounts or 13 roles,
and one of those was flagged,
and so we'd want to figure that one out
and then go dive into that to get that fixed.
Now, in addition to looking at each individual thing
that comes up on the dashboard,
we can actually dive down a little bit deeper as well.
To do that, just go up here to security,
click on that, and then go to IAM,
and instead of going to dashboard,
we can actually look at the password policy,
the permissions, or the IAM configuration itself.
Let's go ahead and take a look at the roles
underneath IAM config.
Underneath the roles you'll see lots of good information.
Here we have awsconfig-example-role,
and in this case we see the ID,
we see the Amazon resource number, the description,
the creation date, the path,
and the maximum session duration.
Underneath Role Trust Policy, we can click that
to see details, and in this case,
we see that this is an AssumeRole.
The effect is allow, the service is config.amazonaws.com,
and it was created with version 2012-10-17.
We can see this applies to zero instances,
zero inline policies, and zero managed policies.
Then we have the next rule, and we can keep going
through all of these rules as we're looking at them.
Additionally, we can go back up here
and we can go to our IAM
and we can go to our credential report.
Under our credential report,
we can learn information about the particular passwords
and authentications that are currently in use.
So based on this credential report,
we can see the user rami never used their password.
There is no date available,
and there is no MFA or Multi-Factor Authentication active.
They do have access keys one and two that are active,
and we could see that those were last used back in 2019
and 2020, which was over two and three years ago.
If we go to the next user, we see sadcloudInlineUser,
and again, we have the password that was never used,
MFA being false, and in this case,
we do not have any active keys.
We scroll to the next person, we have the root_account.
The root account has the password last used in 2020,
MFA is true, so they are using Multi-Factor Authentication,
but they do not have access keys one and two active.
We go to jdow, we can see this person
also has MFA turned off.
They have access key one is true.
Access key two is false,
and we can see the password was last used in 2019.
All right, as we continue to go through,
you can find more and more information
as you go through the different services.
In this case, I'm looking at S3,
which is our buckets that contain our objects,
which is another way of saying our folders and our files.
And here you can see there are two dangers listed.
All actions authorized to all principles
and get actions authorized to all principles.
If I look at that, I can see that the buckets were checked,
there was seven, and one of them was flagged.
So only one of them has an issue,
and again, we are looking at the summary level
when we're on the dashboard to dig in deeper
and find out which ones it would be,
we would click down here onto buckets,
and this would give us more information
about those particular buckets,
and that's where we'd be able to find the information
and the ACLs for each of these different buckets,
whether they have list, upload, delete, view permissions,
or edit permissions, as well as the groups with access,
the roles with access, and the users with access
based on these particular buckets
as you go through all of them.
As you could see, ScoutSuite does a really good job
of collecting all the information
and putting it into a graphical way
for you to start digging through it.
Alright, let's go over and take a look at Prowler.
Here's a report that we generated using Prowler
against Sadcloud.
Now, in this case, Prowler is being used
to look at all the different vulnerabilities
that may exist against that particular cloud inside of AWS.
As you can see, this HTML file is not nearly as pretty
or well laid out as the ScoutSuite report,
but it is something
that we can get a lot of information from in one place,
and it's all kind of listed in one area.
As you see, anything in brown,
that's going to be considered informational.
Anything that's green means it was passed,
it was the recommended security value.
Anything that's red is something that has failed
and needs to have a fix applied.
So let's go down here into 1.1.
Avoid the use of root account.
This was info, the root account was last accessed
using the password key_1 and key_2 back in 2019.
What this says is they shouldn't be logging in as root,
and since they did, that flagged it
as something we want to be aware of.
Number 1.2, this check, which is check12,
is trying to ensure that multi-factor authentication
is enabled for all IAM users that have a console password.
In this case, you can see that all of these particular users
have passwords enabled, but MFA has been disabled,
so if we were making a report on this network,
we would want to recommend that they start enabling MFA
for all of their users
because that is a higher level of security
that'll help prevent data breaches in the future.
If we go to number 1.3,
ensure that anytime credentials are unused
for 90 days or more, they're disabled.
Here you could see a couple of users
have used their credentials in the last 90 days,
including jdow, student-10,
student-16, student-17, student-18, et cetera.
All the ones listed in red haven't logged in
for 90 days or more, so those should be disabled
instead of having those credentials still being active.
If you go to 1.4, you could see this passed,
it ensures that access keys are rotated
every 90 days or less.
In this case, nobody has an access key
that is older than 90 days, so this was considered a pass.
As you continue to go through lots and lots
of other information,
I'm not going to sit here and read it all to you,
but you can go and visit this report by going to Sadcloud
in their GitHub and then looking at this particular report,
you'll notice there are IAM policies,
there are cloud trail information,
there is configuration information,
lots and lots of information,
and in this particular case,
there's a lot of things wrong with this particular cloud,
and that makes sense because Sadcloud was designed
to be intentionally vulnerable.
The last thing I want to point out to you in terms of
Sadcloud,is that when you're installing Sadcloud,
you can set it up and configure
how vulnerable you want it to be.
So if you go down
to the Configure sadcloud section of the readme,
it will tell you how you can comment or uncomment
different modules in the particular configuration file
to determine what things will be found
when you run your scans.
For example, you can uncomment all of your modules
inside of sadcloud/main.tf,
and you can then enter or edit all of the findings flags
inside the Terraform image.
Terraform is essentially the code for the orchestration
that will allow us to create the entire environment
inside of AWS with the different findings that we want.
Now, if you wanted to have only some of the findings
be able to be found when you're running your scans,
you can then uncommon only relevant sections of Sadcloud,
and this will allow you to do something like,
let's just look at the storage vulnerabilities,
and then you could go into AWS
in that environment you just created
and try to fix those different vulnerabilities.
Run the scan again
and see if the things you did to fix it
have actually fixed it.
This is a way that you can gain additional experience
and skill in running these different cloud services
by figuring out what is vulnerable,
how can you properly configure them,
and then run that scan again.
Again, all of that goes way beyond the scope
of this particular exam,
but I just wanted to introduce you
to the way you can read these different reports
inside of ScoutSuite and Prowler
as you start using tools like Sadcloud
to gain some experience working in the cloud
as a vulnerability analyst or a penetration tester.