WEBVTT 00:00.000 --> 00:07.240 She's one of Nany's Google Cloud Platform subject matter experts, which is just a few SME, a couple of TLAs. 00:08.520 --> 00:12.720 And she's really hard at work enhancing and delivering just a few things that's been coming up. 00:12.720 --> 00:14.940 So, round of applause for Shannon. 00:20.080 --> 00:21.580 Alright, hey everybody. 00:21.720 --> 00:26.660 If you cannot hear me at any point in the talk, just put up two hands. 00:26.660 --> 00:27.240 Ready everyone? 00:27.240 --> 00:27.860 Let's practice. 00:27.860 --> 00:28.960 One, two, three. 00:30.440 --> 00:31.720 Thanks, thanks guys. 00:31.720 --> 00:36.300 Okay, so, my name is Shannon McHale. 00:36.300 --> 00:38.320 I am 23 years old. 00:38.320 --> 00:40.460 I'm originally from Long Island, New York. 00:40.460 --> 00:45.940 So, when I talk really fast, throughout these 80 slides, when my accent comes out or from the above, you can do it. 00:46.100 --> 00:48.000 I'm a consultant for Mandiant. 00:48.000 --> 00:50.100 I was actually promoted recently. 00:50.160 --> 00:52.400 And this is my first time at DEF CON ever. 00:52.400 --> 00:53.240 And it's pretty fun. 00:53.240 --> 00:55.340 So, let's have some fun here. 00:57.840 --> 01:03.080 For today's talk, I'm going to be running through a little bit of a background and my motivation of the talk. 01:03.080 --> 01:05.960 I'm going to talk about each default that I have here today. 01:05.960 --> 01:07.100 I think there's like six. 01:07.340 --> 01:08.880 Why the default is bad. 01:08.880 --> 01:10.580 How to be abused by attackers. 01:10.860 --> 01:12.940 How to fix the default at scale. 01:12.940 --> 01:14.260 And then we're going to clap, clap, clap. 01:14.260 --> 01:15.500 And we're going to snip, snip, snip. 01:15.500 --> 01:16.620 Because we are in Vegas. 01:16.620 --> 01:17.320 Let's hear it. 01:18.680 --> 01:20.260 Get some energy. 01:21.520 --> 01:22.320 Yeah. 01:22.560 --> 01:23.360 Alright. 01:23.360 --> 01:27.740 So, the services we're going to look at today are Service Accounts and Qt Engine. 01:27.740 --> 01:30.580 I was going to go through the Storage Accounts and the Cloud Shell. 01:30.580 --> 01:31.920 But, we ran out of time. 01:31.920 --> 01:33.540 So, I'll have to come back next year. 01:35.700 --> 01:36.220 Alright. 01:36.220 --> 01:38.200 So, a little bit of story time. 01:38.820 --> 01:46.340 For the first five months of my full-time career, I studied to get my GCP Cloud Security Engineer certification. 01:46.720 --> 01:49.400 While studying, I would go through a lot of the training. 01:49.400 --> 01:50.580 I would look at the defaults. 01:50.580 --> 01:51.880 And I would go like, Ew. 01:52.420 --> 01:53.300 This is not good. 01:53.300 --> 01:55.280 I'm going to have to change this every single time. 01:55.280 --> 01:56.960 And I also went, Ooh. 01:56.960 --> 01:58.040 This is fun for me. 01:58.040 --> 02:01.840 Every time that I'm on a red team engagement, I can look for this. 02:02.200 --> 02:05.640 So, I thought that it would be a really good talk to end here. 02:05.900 --> 02:10.720 And the motivations behind that were really to help the users protect themselves. 02:10.720 --> 02:16.200 So, as you may know in cloud, it really is on the users to set up a really good structured environment. 02:16.900 --> 02:19.580 I'm not going to be going through a bunch of zero days today. 02:19.580 --> 02:21.420 I'm not really here to wreck GCP. 02:21.420 --> 02:23.040 I'm not going to really like GCP. 02:23.040 --> 02:25.080 That's why I spend all my time doing it. 02:25.860 --> 02:35.580 And as you go through this talk, a lot of the content has already been pointed out by researchers, by Google's publications themselves and their documentation. 02:36.300 --> 02:38.020 And there's going to be... 02:38.020 --> 02:44.000 I'm going to make a quick list of the defaults and how users should change them to protect themselves. 02:44.000 --> 02:56.280 I wanted them to have a quick list to look through to just run through as an engineer or a blue teamer to set up a systematic change across their organization with a policy and to harden their environment. 02:56.580 --> 02:59.660 Overall, though, these are things that attackers would abuse. 02:59.660 --> 03:01.380 I would abuse as a red teamer. 03:01.380 --> 03:05.760 We've seen attackers abuse them at Mandiant from our incident response side of the house. 03:05.920 --> 03:13.640 I'm really hoping the whole thing is easy to set up at the end of the day and that people can reference this talk, which I will re-record at a different time. 03:13.640 --> 03:18.380 And then they will be able to protect themselves. 03:18.380 --> 03:24.980 And also, just to get more people inspired with GCP, because I really like it and I want more people to learn about it and get excited about it, too. 03:25.980 --> 03:29.820 And then this is where my little Kanye West preachy moment comes in. 03:29.820 --> 03:34.960 So I also really think that DEF CON is here. 03:34.960 --> 03:41.940 And this is not just a ZP problem, but I like to think that I'm really passionate about protecting users. 03:41.940 --> 03:52.140 And I like to think that we come to these conferences not to just meet people and have fun and drink, but we come here to point out things so that they get fixed. 03:52.140 --> 03:56.600 Point out vulnerabilities so that they get fixed by the companies that are there. 03:56.600 --> 04:07.760 And I think that it is really good to tell vendors about this so that they get excited and that they also just set it up and fix it for their users. 04:07.760 --> 04:12.720 Kind of like baby-primping the environment for them so that they don't even have to think about it, but they're just safe. 04:14.540 --> 04:17.360 Unfortunately, the Illuminati makes that kind of hard. 04:18.600 --> 04:20.480 So it just needs to work, right? 04:20.480 --> 04:25.500 There's going to be many reasons that people have these settings in their environment. 04:25.500 --> 04:27.880 There's a reason that they are defaults in the first place. 04:27.880 --> 04:30.320 It's because it makes it all run a lot faster. 04:30.340 --> 04:31.780 And that's why they exist. 04:32.380 --> 04:40.060 So yeah, I understand that not everything in today's talk will be easy for everyone to turn off immediately and that they might have a use case for it. 04:40.060 --> 04:44.760 But in general, this is the best practice to do because it really can be leveraged in your environment. 04:45.180 --> 04:47.080 That's the end of my Kanye rant. 04:48.040 --> 04:49.560 Jesus is the best, though. 04:49.900 --> 04:50.880 Back to the story. 04:50.880 --> 04:56.160 I went up to my coworkers, my managers, and I said, like, this is a really good talk. 04:56.160 --> 04:57.180 I'm going to give it at DEF CON. 04:57.180 --> 04:58.280 It's going to be really fun. 04:58.540 --> 05:03.300 And they were kind of like, uh, you doing GCP? 05:03.500 --> 05:05.720 At DEF CON, are you going to call out some GCP stuff? 05:05.720 --> 05:14.340 Because I don't know if you guys have heard or not, but, uh, yeah, kind of risking a couple billion dollars up here. 05:14.340 --> 05:15.320 Yeah, no biggie. 05:15.320 --> 05:20.500 So me and Ian was just kind of like, okay, we're going to just, like, tell Google about this. 05:20.500 --> 05:22.060 We don't actually work for Google yet. 05:22.060 --> 05:25.780 We're a stacker company, so we can do whatever we want at Manium. 05:25.780 --> 05:28.960 But they were definitely like, uh, okay, we're going to tell them. 05:29.160 --> 05:32.940 And then Google gave me all the attention that my parents never did. 05:32.940 --> 05:35.920 So they met with me for a little while. 05:36.360 --> 05:37.620 They were really, really great. 05:37.620 --> 05:43.580 I only happened with a bunch of different researchers throughout DEF CON, Black Hat, both counties, but they really are good. 05:43.580 --> 05:45.480 They really do want things to be fixed. 05:45.580 --> 05:50.780 I got to meet with a lot of people really high up early in my career, which was really rewarding for me. 05:50.780 --> 05:57.340 And I got to ask them a lot of questions and talk problem-solve solutions to them to get the best recommendations. 05:57.340 --> 06:00.960 So a big thank you to Google for actually, like, giving me the time that I'll need. 06:00.960 --> 06:02.460 Because it was really nice. 06:02.820 --> 06:07.920 I also think it's good to point out that they are working on this in different ways. 06:07.920 --> 06:15.660 So GKE has Autopilot, which if you see here, there's just a list of security stuff and a list of, you know, optional stuff. 06:15.660 --> 06:22.420 And if you just went through the security one and you just said, ba-ba-ba-ba-ba, and you implemented all of them, you'd be pretty set up. 06:22.420 --> 06:23.840 So this is an option. 06:23.840 --> 06:24.920 It's something they're working on. 06:24.920 --> 06:29.520 I also would have put GKE in here because there are a lot of stuff that would be fun with. 06:29.520 --> 06:35.180 But overall, just so I don't get fired, for legal reasons, these are my opinions. 06:35.320 --> 06:36.240 They are not Google's. 06:36.240 --> 06:37.660 These are my recommendations. 06:37.660 --> 06:39.100 They are not Google's. 06:39.800 --> 06:40.700 Yeah. 06:40.940 --> 06:43.360 So let's get into it. 06:43.360 --> 06:44.340 Let's do this thing. 06:44.340 --> 06:45.260 Let's go. 06:46.600 --> 06:48.520 So, service accounts. 06:48.780 --> 06:53.880 The number one thing that has been talked about within GCP, actually, is the default service account. 06:53.880 --> 07:03.860 So this service account, every time you create a compute instance or an application in App Engine, this one service account will be created for your whole project. 07:03.860 --> 07:06.200 It's there to communicate with different APIs. 07:06.640 --> 07:09.660 And the default service account will be there. 07:09.660 --> 07:18.060 It will have editor role privileges, which means it will have 5,000 permissions and counting in your environment, which is a heck of a lot. 07:18.060 --> 07:23.480 This was actually presented on about 2018 by Dylan and Allison. 07:23.480 --> 07:25.400 They did a really good talk on it. 07:25.780 --> 07:27.780 And back then it was 2,000 permissions. 07:27.780 --> 07:29.120 Now it's up to 5,000. 07:29.120 --> 07:30.880 So it's only going to keep growing. 07:31.000 --> 07:36.780 And having this service account in your environment is a little bit risky just because it is so privileged. 07:37.120 --> 07:44.040 And we're going to talk about later how someone can actually privilege us to get access to that default service account. 07:44.320 --> 07:53.740 But for those of you who do not spend all your time researching GCP and have seen all this stuff, this has been talked about a lot, so I'm not going to go too into it. 07:54.220 --> 07:58.940 Yeah, these are all the resources that I'll post all of these slides later. 07:59.060 --> 08:01.500 But there's a lot of talks on this. 08:01.540 --> 08:07.320 So it's pretty much like getting AD in a Windows environment. 08:07.320 --> 08:09.000 This would be the equivalent of that. 08:09.440 --> 08:11.140 Google's also talked about this a lot. 08:11.140 --> 08:13.120 They have warnings all over. 08:13.120 --> 08:17.180 They have it in this documentation, in this documentation. 08:17.320 --> 08:19.160 They also have it in IAM. 08:19.160 --> 08:25.140 They have something phenomenal called IAM Recommender where they go, hey, you have a lot of excessive permissions. 08:25.140 --> 08:28.580 If you just want to click this button, we'll get rid of the ones you're not using. 08:28.580 --> 08:30.060 We've been tracking it for 90 days. 08:30.060 --> 08:31.060 We'll let you know. 08:31.960 --> 08:36.340 Yeah, not to put any more beats on that horse, you know, but it's kind of a big deal. 08:36.340 --> 08:38.040 And it's talked about a lot in the industry. 08:38.040 --> 08:41.180 So we won't look at it too, too much. 08:41.260 --> 08:43.280 There are some mitigations to fix this. 08:43.280 --> 08:45.020 You can create a better service account. 08:45.020 --> 08:51.340 You'll have to do this first before getting rid of the editor default service account, or else your whole thing is going to break. 08:51.340 --> 08:54.640 So always do the principle of least privilege. 08:54.640 --> 08:59.340 Again, IAM Recommender is a really good way to see what will work, what will not work. 08:59.380 --> 09:03.660 And then you can set an org policy where it never happens again throughout your organization. 09:03.800 --> 09:06.240 This org policy will just turn it off. 09:06.240 --> 09:08.180 No one can ever put it again. 09:08.340 --> 09:10.720 Like I said, IAM Recommender, great tool to use. 09:10.720 --> 09:12.400 Can't recommend it enough. 09:14.580 --> 09:19.080 Talking about the organization policies, I wanted to just show you what they look like. 09:19.080 --> 09:20.840 So they have the list and the Boolean. 09:21.020 --> 09:31.500 So everything I say today, you can either do a Boolean where it's true or false across your organization, or I wanted to let you know that you can also fit exceptions for where you might still need these things. 09:31.560 --> 09:38.640 So this is a really good thing, just for your knowledge, in case you're thinking, oh my gosh, how am I going to implement this? 09:40.260 --> 09:43.560 So service account key expiration, this is a fun one. 09:43.700 --> 09:47.780 So I went through to see how this would go from a default perspective. 09:47.860 --> 09:53.620 When you create the default service account, or any service account, there is no key automatically there. 09:53.620 --> 10:02.000 So you go in, you add a key, you hit the add key button in the console, really cool. 10:02.220 --> 10:05.180 You decide what type of file you want it to be. 10:06.100 --> 10:09.740 And then you have a default service account key. 10:09.940 --> 10:12.020 Congratulations, very cool for you. 10:12.020 --> 10:13.140 You have a service account key, right? 10:13.140 --> 10:14.500 Easy peasy, one, two, three. 10:15.920 --> 10:16.740 That's it. 10:16.740 --> 10:19.660 And yeah, we'll be there until I'm 8,000 years old. 10:19.840 --> 10:25.360 So that is going to be there forever, and that's kind of the problem that I'm pointing out here. 10:25.420 --> 10:31.960 To change this expiration date, as you saw in the console, there was no option to have it within those steps. 10:31.960 --> 10:34.420 There was no, hey, how long do you want this to be here? 10:34.420 --> 10:37.200 And now that it exists, you actually cannot get rid of it. 10:37.200 --> 10:45.540 You can delete the account, you can delete the key altogether, but you cannot change the expiration date. 10:46.320 --> 10:49.400 Google does have some documentation on this. 10:49.400 --> 10:51.380 I'm sure there is more than just this. 10:51.400 --> 11:02.540 But they even say, yeah, so you can set an organization policy, which will be the theme of the presentation, that sets the keys to expire at a certain time. 11:02.540 --> 11:06.120 So the keys that already exist, again, will not be expired. 11:06.540 --> 11:09.060 They also recommend that this is not done in production. 11:09.060 --> 11:14.900 So you don't actually want to set up an expiration time in production because things could break. 11:14.900 --> 11:23.140 Instead, you should manage the key lifecycle by using tools like Key Rotator, or there are some other funky ways that you can do it. 11:23.140 --> 11:27.080 It's really particular to which services you use and what you're using it for. 11:27.080 --> 11:36.260 So Key Rotator, which is a Python script published by Google, is not a one-fits-all thing, but you should be rotating the key if it does exist. 11:37.040 --> 11:45.700 I do want to point out why this key freaks me out so much before giving you all of the mitigations for it, just so you understand why you should be going and fixing it. 11:46.160 --> 11:48.660 And that really comes in with service account logging. 11:49.020 --> 11:51.940 So I came across this blog from an ex-Googler. 11:52.020 --> 11:53.840 He wrote it in 2020. 11:53.840 --> 12:01.260 I don't know if he was even working for Google at the time, but at some point he was on the Strategic Security Engineer team, I think it's called. 12:01.820 --> 12:03.140 It's a great team. 12:03.140 --> 12:08.160 They produce really phenomenal blogs about how to best secure your infrastructure. 12:08.160 --> 12:10.080 I'll reference them a couple times here. 12:10.080 --> 12:16.060 But they think of really creative ways to do really secure implementations of cloud security architecture. 12:16.060 --> 12:17.180 So they're really great. 12:17.180 --> 12:22.920 He's not at Google anymore, but I thought it would be cool to just read this blog in 2022, two years later. 12:23.760 --> 12:27.820 And lucky enough, it was still something that I could play with. 12:27.820 --> 12:41.320 So when you use service account impersonation with the service account token creator privileges, you are saying, I'm going to impersonate this service account from the CLI. 12:41.320 --> 12:43.760 And the CLI will track who's doing this. 12:43.760 --> 12:48.720 So they will say, okay, Shannon is impersonating the default service account. 12:48.720 --> 12:53.680 And that will be logged there in the first party principal as a principal email. 12:54.800 --> 13:03.340 However, if you do authenticate using the service account key, it will not have that same log. 13:03.340 --> 13:07.180 It will not tell you who the principal email user was. 13:07.180 --> 13:12.740 It will just say that the service account key has been used. 13:13.000 --> 13:18.500 More so, which makes it very difficult to find patient zero in a incident, right? 13:18.500 --> 13:19.920 So you can't track it back. 13:19.920 --> 13:26.840 You would have to go see who created the key to begin with, and then track it back to them, and then see where it went from there, and blah, blah, blah. 13:26.840 --> 13:27.920 So it's a lot. 13:28.120 --> 13:31.320 It's not logged, is the point of that, in that way. 13:32.520 --> 13:37.100 Not to mention, there isn't actually logging when the key is used for authentication. 13:37.520 --> 13:40.660 So once you start running actions, GCloud will see it. 13:40.660 --> 13:43.080 So if you say, I want to list, I want to get, etc. 13:43.080 --> 13:46.320 It will be in the audit logs that the service account is completing these actions. 13:46.320 --> 13:52.220 But when someone actually authenticates with that key to your service account, there is no log for that. 13:52.480 --> 13:59.520 There is, however, a way to turn on, in monitoring, the use of a service account key. 13:59.520 --> 14:02.660 So it's just a dot that says, key has been used. 14:02.660 --> 14:04.700 There's not detailed logging of it. 14:04.700 --> 14:06.380 It's just saying that a key was used. 14:06.380 --> 14:07.440 And you have to set that up. 14:07.440 --> 14:08.720 It's not there by default. 14:08.720 --> 14:16.040 So it freaks me out a lot that you can use this key, which will almost never expire. 14:16.040 --> 14:18.420 It's usually more privileged than you were. 14:18.640 --> 14:23.420 And then you can, yeah, you don't really get logged too much. 14:23.420 --> 14:26.140 Not every single thing is logged when you're there. 14:26.140 --> 14:28.140 It's less attributable, etc. 14:28.140 --> 14:29.900 So, some things you can do. 14:29.900 --> 14:35.200 You can set up an organization policy to disable service account creations altogether. 14:35.900 --> 14:43.140 You can set an expiration time for your keys that are going to exist, not the ones that do exist. 14:43.140 --> 14:45.920 You can get rid of the ones that do exist altogether. 14:46.060 --> 14:51.780 You can set key rotation if you are using the keys in production. 14:51.780 --> 14:53.760 You should set up rotation for those. 14:53.760 --> 14:56.500 Work with your vendors to do that if they require it. 14:56.500 --> 14:58.560 And then you can use short-term access tokens. 14:58.560 --> 15:01.100 So that's how impersonation works in GCP. 15:02.740 --> 15:05.680 You're able to do that with that create service account token. 15:05.680 --> 15:13.860 There's a blog, again by that strategic team at Google, that goes through how you can set up one service account to impersonate the other. 15:14.000 --> 15:19.880 And you would have to impersonate that middle man to get to the other one instead of using the key. 15:19.880 --> 15:24.980 That last one will use the key for you, but at least it attributes to some principle at the end of the day. 15:26.140 --> 15:30.020 And then, of course, always follow the least privileged on service account. 15:30.940 --> 15:34.100 So that's the service account section of my talk. 15:34.440 --> 15:39.940 The compute engine section of my talk, we're now going to go through and make a compute engine. 15:39.940 --> 15:43.960 We're going to keep all the default settings there. 15:43.960 --> 15:46.240 We're going to make a Linux VM. 15:46.340 --> 15:48.060 It's going to be 1, 2, 3. 15:48.060 --> 15:49.140 We're going to use the console. 15:49.140 --> 15:52.000 This is like a developer wanting to test stuff really quick. 15:52.360 --> 15:54.280 Probably not at an enterprise level. 15:54.280 --> 16:01.300 They're going to be doing this one by one because they're going to be using Terraform hopefully or something like that to spin up machines with better setup. 16:01.800 --> 16:04.380 So yeah, just going to do that. 16:04.380 --> 16:05.820 Sorry, I don't have live demos. 16:05.820 --> 16:07.640 I don't take risks like that. 16:08.540 --> 16:09.560 And there we have it. 16:09.560 --> 16:12.100 We have a VM. 16:12.100 --> 16:13.400 It's a Linux VM. 16:13.540 --> 16:18.420 And it happens to have a public IP address. 16:18.420 --> 16:22.080 So that public IP address has nothing in between it and the Internet. 16:22.080 --> 16:23.780 It's very much so open to the Internet. 16:23.780 --> 16:28.120 It's there so that the developers who are using the machine can use the Internet. 16:28.420 --> 16:36.040 However, having the public IP directly accessible does open up your attack surface for attackers to get in. 16:36.360 --> 16:43.160 And I believe it would be safer if Google would implement something that forces a user to turn this on. 16:43.160 --> 16:46.180 So I'm not saying that no one should ever have public IP addresses, etc. 16:46.220 --> 16:48.040 I'm saying that it should be a choice. 16:48.040 --> 16:49.700 It should be something that's thoughtful. 16:49.700 --> 16:53.800 And it should be promoting that security mindset for people. 16:53.940 --> 16:55.400 Also, just a neat fact. 16:55.400 --> 17:00.740 Any internal IP, the first time you make a compute instance, it has the same internal IP. 17:00.740 --> 17:04.480 So that's kind of fun for me as an attacker because I know it might be there once I'm internal. 17:04.480 --> 17:06.500 So I just think GCP is neat. 17:06.500 --> 17:07.440 I like it. 17:07.820 --> 17:09.820 Some indications for this. 17:09.820 --> 17:16.000 There is, of course, an organization policy that prevents the external IP addresses from being made. 17:16.000 --> 17:20.760 This means that someone who does want an external IP address would have to go to their admin, etc. 17:20.760 --> 17:22.620 and say, please let me do this. 17:22.620 --> 17:26.960 And then hopefully the admin will make a good decision as to whether or not they should. 17:27.740 --> 17:39.500 Alternatively, if you want, you can set up Cloud NAT so that the instance-based proxy can be in between and then set up some identity access there. 17:40.800 --> 17:46.740 There's just some sort of boundary between the public one and the outside forces. 17:47.820 --> 17:53.160 Also, when you set up a default Compute Engine instance, you will have GCE firewall rules set up. 17:53.160 --> 17:55.220 There will be four firewall rules set up. 17:55.220 --> 17:56.560 Count 1, 2, 3, 4. 17:56.560 --> 18:03.240 It will be default allow ISCMP, default allow SSH, default allow internal, and default allow RDP. 18:03.240 --> 18:07.960 RDP and SSH will only matter if you're using a Windows host versus a Linux host. 18:07.960 --> 18:09.940 But yeah, it will be there. 18:09.940 --> 18:17.840 So allow SSH on the Linux host that we created will require key authentication, but it is there. 18:17.840 --> 18:24.820 So an attacker would need gcloud access in the first place to use it, which means they would have the IAM credentials to do it. 18:24.820 --> 18:29.780 And then they would also need a SSH key to get in from the outside. 18:30.940 --> 18:36.940 In addition to that, it would be RDP, which does not have the same keys, so there's no MFA on this. 18:36.940 --> 18:41.100 You do have to set a Windows password, so you would have to have Windows users using it. 18:41.100 --> 18:50.920 But if you have a Windows instance, then anyone can phish or do brute force attacks to get into the Windows machine that is there. 18:52.940 --> 18:58.360 Default allow internal, so there's just a lot that are there. 18:59.740 --> 19:17.840 So default allow internal, I don't think this is something that Google should actually change, or maybe it won't implement off of that, but it does allow people in the same VPC network, on your same subnet, to contact your box through any port that exists, 19:17.840 --> 19:25.480 which means it kind of promotes a chatbot for lateral movement or access to administrative services. 19:25.480 --> 19:37.740 So these are the administrative services that Vaniant has seen and used to abuse and get into different administrative services, not necessarily all lateral movement, but just to get access to those services. 19:38.320 --> 19:43.520 They're all remote admin ports, and this would be used for lateral movement, like I said. 19:43.520 --> 19:56.700 So just to set up some safe practices, it might be good to create a rule that would just block these, especially the top five, since we're seeing so many of those be abused by attackers. 19:56.700 --> 20:01.420 We always say that this is something that you should block when we're dealing with clients. 20:03.280 --> 20:09.740 So mitigations for this, configure a better default firewall rule on a per project basis. 20:09.740 --> 20:16.120 You'll have to do this, you'll have to delete the old ones and then add the new ones so that they work really well. 20:16.120 --> 20:23.580 You can also do an org policy then to skip the default network creation, you can set it to true. 20:23.580 --> 20:27.400 You can use Identity-Aware Proxy for TCP forwarding. 20:27.540 --> 20:33.780 And you can also set off that allow, internal, and block, all of those ports, that might be good. 20:33.780 --> 20:38.160 And then of course, add MFA on any of the administrative services where you can. 20:38.160 --> 20:38.460 So the 20:41.620 --> 20:45.700 default service account, once again, was created when we created the compute engine. 20:45.700 --> 20:51.580 So right there in the settings, we could have changed it, but since it was there, we wanted it to stay there. 20:52.360 --> 20:55.380 And we were just not changing anything, all things. 20:55.380 --> 20:58.100 We also needed it to work because I had to set up a different service account. 20:58.100 --> 21:01.940 So it has those 5,000 permissions at the project level. 21:02.840 --> 21:10.940 And from a compute instance, to access a compute instance, you need the IAM service account act as role. 21:10.940 --> 21:15.860 This means when you log on to the compute instance, you are acting as the service account. 21:15.860 --> 21:19.240 You are authenticated as the service account, as seen here. 21:19.240 --> 21:23.600 That top screen shot, that's gcloud offlist, that's telling me who I am right now. 21:23.600 --> 21:26.960 And it happens to be the default service account, just because I logged in. 21:26.960 --> 21:30.620 I didn't do anything else, I just accessed the box, and there I am. 21:30.900 --> 21:35.040 Other than that, you can also now contact the metadata. 21:35.040 --> 21:42.180 And the metadata actually has limited permissions versus the acting as the service account. 21:42.180 --> 21:51.340 So this is kind of cool, because when I learned about the default service account, I thought, oh no, anyone on the compute instance can automatically escalate and get all 5,000 of those permissions. 21:51.340 --> 21:52.820 But that's not actually true. 21:52.820 --> 22:05.020 You can actually scope down the permissions that you have on the compute instance with these access scopes that are listed there, instead of just giving them full editor roles. 22:05.020 --> 22:17.920 So this curl shows the permissions that I would have if I were to curl down the access token from the metadata and use it to impersonate the service account elsewhere. 22:18.640 --> 22:24.780 So what I decided to do, as I said here, you get permission denied. 22:24.780 --> 22:35.180 So even when I was acting as the service account and I tried to create keys, I wasn't allowed to, because of these scopes defined for the VM, and these are the default scopes that Google gives you. 22:36.360 --> 22:42.720 So the next thing I did was curl down that access token, and I wanted to see what I could do with specifically that. 22:42.880 --> 22:44.640 And here's where it gets interesting. 22:44.640 --> 22:52.280 So I decided to make a S3 bucket, not an S3 bucket, a storage bucket. 22:52.280 --> 22:56.180 And I set up this storage bucket. 22:56.180 --> 22:59.540 It had this Welcome to Good Burger. 22:59.540 --> 23:04.320 I put a picture in it, and I, as the editor, had access to it. 23:04.920 --> 23:15.300 So from the console, with the act as permissions, I was able to list the storage buckets that existed and find their name. 23:15.300 --> 23:21.580 And I was also able to list any of the items in it, so list objects. 23:22.780 --> 23:27.740 And then I was not able to copy into it, so access was denied for that. 23:27.960 --> 23:43.360 So I decided to go outside of my scope and take that access key that I had retrieved while on the VM and see if I can use that outside of my organization on an attacker box to pull down what objects were in the bucket. 23:43.360 --> 23:51.300 Now this wouldn't have been possible if I wasn't on the VM specifically, because you do need to know the name of the bucket to pull stuff down. 23:52.780 --> 24:02.300 So without the name of the bucket using the act as, I would not have been able to use the access token to list the names of the buckets. 24:02.300 --> 24:08.760 So you need both, but most likely you have that act as if you're able to access the metadata server in the first place. 24:08.760 --> 24:17.520 So I decided to pull down what was on the bucket, which as you can see there is an incorrectly spelled Danny DeVito picture. 24:18.200 --> 24:19.100 There he is! 24:19.100 --> 24:19.820 Got him! 24:19.820 --> 24:20.300 Woohoo! 24:20.300 --> 24:21.260 Hey Danny! 24:21.300 --> 24:26.800 So I pulled him down, and now that I have access to this, so why would an attacker do this? 24:26.800 --> 24:30.880 Obviously Danny DeVito is very valuable to our culture, to our society, yes. 24:30.880 --> 24:37.140 But an attacker would be doing this to pull down anything that's stored in the bucket. 24:37.140 --> 24:42.160 So that could be locks, financial information, anything that you put up there. 24:42.160 --> 24:47.500 And now that it's all offline and I have access to it, I am able to edit it. 24:47.500 --> 24:50.740 So I'm able to make him Dekon DeVito. 24:51.180 --> 24:51.740 Woohoo! 24:51.740 --> 24:53.120 Our new favorite game. 24:53.540 --> 24:54.440 And that's about it. 24:54.440 --> 24:56.580 So some mitigations for that. 24:56.640 --> 25:06.000 Again, you can see slide 25 when I post these slides and the recording to see what you can do to mitigate the default service account privileges. 25:06.520 --> 25:13.740 And make sure that you understand that anyone on the VM can access that VM service account and act as them. 25:13.740 --> 25:17.480 So you want to set the limited permissions on the service account. 25:17.480 --> 25:22.760 Enable the cloud platform access policy only when it's least privileged. 25:22.760 --> 25:24.040 So this is really interesting. 25:24.040 --> 25:39.740 Once you do the cloud platform access policy, instead of going in and setting up those individual policies that were listed, they will then have all of the permissions of the service account by using the cloud platform policy. 25:39.760 --> 25:43.420 And this is going to be used to get the full editor service account privileges. 25:43.420 --> 25:50.220 So if you are going to be doing this, you want to make sure that you have already set the least privileged service account possible. 25:50.660 --> 25:58.280 So scope down those permissions on your compute instance using those access scopes if you're going to use Compute Engine at any time. 25:59.500 --> 26:15.300 So in summary of the defaults to disable and limit the service account's default service account, the key expiration time, the logging of the authentication versus an impersonation, and then in Compute Engine, you're going to want to get rid of those public IP addresses. 26:15.440 --> 26:19.340 You're going to want to make sure RDP and SSH are not open to the internet. 26:19.340 --> 26:20.260 That would be cool. 26:20.260 --> 26:27.400 And then you want to make sure that your default service account and their access scopes are the least privileged as possible. 26:28.920 --> 26:29.880 And that's it. 26:29.880 --> 26:34.900 So if anyone wants to come pack cloud with me, I'm looking for GCP mentors. 26:34.900 --> 26:37.860 Not a lot of people do it, but it is a really cool cloud. 26:37.860 --> 26:39.920 You should all come work for Mannion. 26:39.920 --> 26:40.980 We do it with me. 26:40.980 --> 26:42.480 It'll be fun, you know? 26:42.480 --> 26:43.420 It'll be fun. 26:43.560 --> 26:46.560 So yeah, if you're interested in that, check out my Twitter. 26:46.780 --> 26:49.960 I've got some referral links up there if you're looking to red team cloud. 26:49.960 --> 26:51.120 But that's about it. 26:51.120 --> 26:52.580 Thank you so much for your time. 26:52.660 --> 26:53.820 Any questions? 27:12.470 --> 27:17.390 Have I seen any data-like compromises in my data link? 27:17.390 --> 27:18.410 No, I have not.