Instructor: In this lesson, 2 2
we're going to spend some time looking at a couple 3 3
of reports when you're conducting cloud auditing. 4 4
Now for the exam, you don't need to be able 5 5
to go through all these reports and understand them 6 6
step by step by step, 7 7
but I just want to give you a good overview 8 8
so you can then explore more on your own. 9 9
We're going to take a look 10 10
at a couple of auditing reports based upon 11 11
a misconfigured cloud environment. 12 12
To do this, we're going to use a tool known as sadcloud. 13 13
Now, sadcloud is an intentionally vulnerable distribution 14 14
of a cloud infrastructure 15 15
and it's for use inside of the Amazon Web Services cloud. 16 16
If you'd like to be able to spin this up yourself, you can. 17 17
All the instructions are on their GitHub 18 18
at github/nccgroup/sadcloud. 19 19
Now, the makers 20 20
of sadcloud are the same people who make ScoutSuite 21 21
and so they provided this as a way 22 22
for us to learn how to use that tool, 23 23
look at the different auditing reports 24 24
that are generated from it, 25 25
and then use other tools against it as well. 26 26
Think about sadcloud like you would Metasploitable 2. 27 27
Metasploitable 2 is a vulnerable virtual machine 28 28
that you can then attack using Kali Linux. 29 29
Well, sadcloud is a vulnerable cloud infrastructure 30 30
with servers and other misconfigurations 31 31
that you can then look at 32 32
using the different tools 33 33
in the cloud area to be able to get better 34 34
at using those tools and using them for the real world. 35 35
If you go over to github.com/nccgroup/sadcloud, 36 36
you could scroll down through their readme. 37 37
In the readme, they explain a little bit 38 38
about what this particular system is. 39 39
As you can see here, there are 22 AWS services 40 40
with 84 different misconfigurations 41 41
that they put inside of sadcloud. 42 42
They do this so they can then look at it using tools 43 43
like ScoutSuite, Prowler, and many others. 44 44
Now, sadcloud was, as I said, 45 45
a way for security researchers to be able to learn more 46 46
about cloud vulnerabilities inside of AWS 47 47
and it's a great tool for us as future penetration testers. 48 48
Now, if you're going to do this, you need to know 49 49
that you will incur some cost by running sadcloud. 50 50
It costs about $10 per day for the cloud compute time, 51 51
so if you are going to use sadcloud, 52 52
you don't want to leave this running 24 hours a day, 53 53
seven days a week 54 54
because it'll start eating up a lot of money 55 55
inside of your budget for cloud computing. 56 56
Instead though, you can go ahead and turn it on. 57 57
You can run your scans or run your hacks against it 58 58
and then you can shut it back down again. 59 59
There are instructions of how to do all of that 60 60
here in the GitHub for sadcloud. 61 61
Now, in this particular lesson, we're going to focus 62 62
on the actual outputs of those scans that you would get 63 63
by using something like ScoutSuite or Prowler as opposed 64 64
to running those scans ourself. 65 65
Now, if you want to run those scans yourself, 66 66
it's not really difficult to do. 67 67
If you go over to the GitHub for nccgroup, 68 68
you'll also find one called nccgroup/ScoutSuite 69 69
and this is the actual tool for ScoutSuite. 70 70
If you scroll down in the readme, 71 71
there are instructions of how to run this tool 72 72
and it really is simple to run it. 73 73
You're simply going to type in Scout Space AWS 74 74
if you're doing it against sadcloud 75 75
and AWS --profile and then basc -F 76 76
and this will go through and run a scan against 77 77
that sadcloud infrastructure that you have then deployed. 78 78
But what we're going to do is instead of running it 79 79
we are going to look at the report that comes from it 80 80
and if you go over to the sadcloud GitHub, there are links 81 81
to this audit report as well that you can go through 82 82
on your own and explore it a little bit more in depth. 83 83
When you run ScoutSuite, 84 84
you are going to get a report like this generated based 85 85
on this cloud that you have just scanned. 86 86
You could see here all 87 87
of the services listed on the main dashboard 88 88
the resources, the rules, the findings, and the checks. 89 89
Each of these is for a different service 90 90
inside of Amazon Web Services. 91 91
You'll notice if we scroll down, the EC2 is one 92 92
of the largest that we have with the most vulnerabilities. 93 93
Now, why is that? 94 94
Well, because EC2 is elastic computing 95 95
and that means virtual servers. 96 96
These are virtual machines and there's lots 97 97
of different vulnerabilities that are associated with that. 98 98
The other one that is really high 99 99
that you can see with the red exclamation is IAM 100 100
which are identity and access management. 101 101
So as we go through, you can click on any of these. 102 102
For instance, let's go ahead and click on EC2. 103 103
By clicking on EC2, 104 104
we can now see all the vulnerabilities we have. 105 105
Now, as you can see going across the top, 106 106
we do have four filters. 107 107
We have show all, good, warning and danger. 108 108
If I click on good, I'm only going to see the things 109 109
that pass the vulnerability scan. 110 110
In this case, the public EBS snapshot was good. 111 111
If I want to see the details, I can click on the plus 112 112
and here I'll get a description 113 113
that the snapshots should never be public 114 114
because that could risk exposing sensitive data 115 115
and in this case, there was one snapshot 116 116
and it was not public, so this was considered a good check. 117 117
Now these snapshots are considered backups 118 118
and they contain all the state information 119 119
from a particular virtual machine. 120 120
Now, if I want to see all the things that were warnings, 121 121
I could click on warning 122 122
and you could see there are several warning areas here 123 123
including all ports being open, 124 124
the default security groups in use, 125 125
non empty rule sets for default security groups and others. 126 126
Again, if you want to get more details about what it found 127 127
just go ahead and click here, 128 128
and in this case it checks 73 rules 129 129
and there is 26 open ports 130 130
so we'd have to go in further to be able to figure that out 131 131
as we look through some of the tabs of ScoutSuite. 132 132
Next, if we go to danger 133 133
we will see everything that is a big danger area 134 134
that we really need to take care of. 135 135
In this case, again, we have all ports being open 136 136
and we had two rules that were flagged here 137 137
out of 69 that were checked. 138 138
If I look at DNS port, that's open to all. 139 139
We could see again, one rule was flagged 140 140
with EBS not being encrypted. 141 141
There is one snapshot check and one was flagged 142 142
so there was no encryption on that snapshot. 143 143
Again, the EBS volume itself was not encrypted. 144 144
That was again, we had three volumes checked 145 145
and three of them were flagged 146 146
so these are things that we'd want to go 147 147
and fix as somebody who is a network defender. 148 148
Next, we can go click back onto ScoutSuite 149 149
to see our main dashboard again 150 150
and we can pick another area. 151 151
Let's go ahead and choose IAM. 152 152
IAM is our identity and access management 153 153
and this is all about rules, roles, and permissions, 154 154
and so as we go through, 155 155
we can see some things that are lacking. 156 156
For instance, we have a cross account assumerole policy 157 157
lacks external ID and multifactor authentication. 158 158
This says that 159 159
when you're authorizing cross account role assumption, 160 160
you should require multifactor authentication. 161 161
In this case, we checked it against 13 accounts or 13 roles 162 162
and one of those was flagged 163 163
and so we'd want to figure that one out 164 164
and then go dive into that to get that fixed. 165 165
Now, in addition to looking at each individual thing 166 166
that comes up on the dashboard 167 167
we can actually dive down a little bit deeper as well. 168 168
To do that, just go up here to security, click on that 169 169
and then go to IAM, and instead of going to dashboard 170 170
we can actually look at the password policy, 171 171
the permissions, or the IAM configuration itself. 172 172
Let's go ahead and take a look 173 173
at the roles underneath IAM config. 174 174
Underneath the roles, 175 175
you'll see lots of good information. 176 176
Here we have AWS Config example role 177 177
and in this case we see the ID, 178 178
we see the Amazon resource number, the description, 179 179
the creation date, the path, 180 180
and the maximum session duration. 181 181
Underneath role trust policy, 182 182
we can click that to see details 183 183
and in this case we see that this is an assumed role. 184 184
The effect is allow, the service is config.amazonaws.com 185 185
and it was created with version 2012 10 17. 186 186
We can see the supplies to zero instances, 187 187
zero inline policies, and zero managed policies. 188 188
Then we have the next role, and we can keep going through 189 189
all of these roles as we're looking at them. 190 190
Additionally, we can go back up here 191 191
and we can go to our IAM 192 192
and we can go to our credential report. 193 193
Under our credential report, we can learn information 194 194
about the particular passwords and authentications 195 195
that are currently in use. 196 196
So based on this credential report, 197 197
we can see the user rami never used their password. 198 198
There is no date available and there is no MFA 199 199
or multifactor authentication active. 200 200
They do have access keys 1 and 2 that are active 201 201
and we could see that those were last used back in 2019 202 202
and 2020, which was over two and three years ago. 203 203
If we go to the next user, we see sadcloudinlineUser 204 204
and again, we have the password that was never used, 205 205
MFA being false, 206 206
and in this case we do not have any active keys. 207 207
We scroll the next person. 208 208
We have the root account. 209 209
The root account has the password last used in 2020. 210 210
MFA is true, so they are using multifactor authentication 211 211
but they do not have access keys 1 and 2 active. 212 212
To go to jdow, 213 213
we can see this person also has MFA turned off. 214 214
They have access key 1 is true. 215 215
Access key 2 is false 216 216
and we can see the password was last used in 2019. 217 217
Alright. 218 218
As we continue to go through, 219 219
you can find more and more information 220 220
as you go through the different services. 221 221
In this case, I'm looking at S3 222 222
which is our buckets that contain our objects 223 223
which is another way of saying our folders and our files 224 224
and here you can see there are two dangers listed. 225 225
All actions authorized to all principles 226 226
and get actions authorized to all principles. 227 227
If I look at that, I can see that the buckets were checked, 228 228
there was seven, and one of them was flagged. 229 229
Only one of them has an issue, and again, we are looking 230 230
at the summary level when we're on the dashboard. 231 231
To dig in deeper and find out which ones it would be 232 232
we would click down here onto buckets 233 233
and this would give us more information 234 234
about those particular buckets, and that's where 235 235
we'd be able to find the information and the ACLs for each 236 236
of these different buckets, whether they have list, 237 237
upload delete, view permissions, or edit permissions 238 238
as well as the groups with access, the roles with access 239 239
and the users with access based on these particular buckets 240 240
as you go through all of them. 241 241
As you can see, ScoutSuite does a really good job 242 242
of collecting all the information and putting it 243 243
into a graphical way for you to start digging through it. 244 244
Alright, let's go over and take a look at Prowler. 245 245
Here's a report that we generated 246 246
using Prowler against sadcloud. 247 247
Now, in this case, Prowler is being used 248 248
to look at all the different vulnerabilities that may exist 249 249
against that particular cloud inside of AWS. 250 250
As you can see, this HTML file is not nearly as pretty 251 251
or well laid out as the ScoutSuite report 252 252
but it is something that we can get a lot 253 253
of information from in one place, 254 254
and it's all kind of listed in one area. 255 255
As you see anything in brown, 256 256
that's going to be considered informational. 257 257
Anything that's green means it was passed, 258 258
it was the recommended security value. 259 259
Anything that's red is something that has failed 260 260
and needs to have a fix applied. 261 261
So let's go down here into 1.1. 262 262
Avoid the use of root account. 263 263
This was info, the root account was last accessed 264 264
using the password key 1 and key 2 back in 2019. 265 265
What this says is they shouldn't be logging in as root 266 266
and since they did, 267 267
that flagged it as something we want to be aware of. 268 268
Number 1.2, this check, which is check 12 269 269
is trying to ensure 270 270
that multifactor authentication is enabled 271 271
for all IAM users that have a console password. 272 272
In this case, you can see 273 273
that all of these particular users have passwords enabled 274 274
but MFA has been disabled, so if we were making a report 275 275
on this network, we would want to recommend 276 276
that they start enabling MFA for all 277 277
of their users because that is a higher level of security. 278 278
They'll help prevent data breaches in the future. 279 279
If we go to number 1.3, 280 280
ensure that anytime credentials are unused 281 281
for 90 days or more, they're disabled. 282 282
Here you could see a couple 283 283
of users have used their credentials in the last 90 days, 284 284
including jdow, student 10, student 16, 285 285
student 17, student 18, et cetera. 286 286
All the ones listed in red haven't logged in 287 287
for 90 days or more, so those should be disabled instead 288 288
of having those credentials still being active. 289 289
If you go to 1.4, you could see this passed, it ensures 290 290
that access keys are rotated every 90 days or less 291 291
and in this case, nobody has an access key that is older 292 292
than 90 days, so this was considered a pass. 293 293
As you continue to go through lots and lots 294 294
of other information 295 295
I'm not going to sit here and read it all to you 296 296
but you can go and visit this report by going to sadcloud 297 297
in their GitHub and then looking at this particular report. 298 298
You'll notice there are IAM policies, 299 299
there are cloud trail information, 300 300
there is configuration information, 301 301
lots and lots of information, and in this particular case 302 302
there's a lot of things wrong with this particular cloud 303 303
and that makes sense because sadcloud was designed 304 304
to be intentionally vulnerable. 305 305
The last thing I want to point out to you in terms 306 306
of sadcloud is that when you're installing sadcloud, 307 307
you can set it up 308 308
and configure how vulnerable you want it to be. 309 309
So if you go down to the configure sadcloud section 310 310
of the readme, it will tell you how you can comment 311 311
or uncomment different modules 312 312
in the particular configuration file 313 313
to determine what things will be found 314 314
when you run your scans. 315 315
For example, you could uncomment all 316 316
of your modules inside of sadcloud/main.tf 317 317
and you can then enter or edit all 318 318
of the findings flags inside the Terraform image. 319 319
Terraform is essentially the code 320 320
for the orchestration that will allow us 321 321
to create the entire environment inside 322 322
of AWS with the different findings that we want. 323 323
Now, if you wanted to have only some of the findings 324 324
be able to be found when you're running your scans 325 325
you can then uncomment only relevant sections of sadcloud 326 326
and this will allow you to do something like 327 327
let's just look at the storage vulnerabilities 328 328
and then you could go into AWS 329 329
in that environment you just created 330 330
and try to fix those different vulnerabilities, 331 331
run the scan again and see 332 332
if the things you did to fix it have actually fixed it. 333 333
This is a way that you can gain additional experience 334 334
and skill in running these different cloud services 335 335
by figuring out what is vulnerable, 336 336
how can you properly configure them 337 337
and then run that scan again. 338 338
Again, all of that goes way beyond the scope 339 339
of this particular exam, but I just wanted to introduce you 340 340
to the way you can read these different reports inside 341 341
of ScoutSuite and Prowler as you start using tools 342 342
like sadcloud to gain some experience working the cloud 343 343
as a vulnerability analyst or a penetration tester.