WEBVTT 00:40.340 --> 00:41.040 Hi there! 00:41.040 --> 00:42.100 Welcome everyone. 00:42.220 --> 00:50.180 We're here with Dylan and Allison, who presented here at DEF CON SAFEMODE on lateral movement and privilege escalation in GCP. 00:50.460 --> 00:53.120 Compromise any organization without dropping an implant. 00:53.220 --> 01:05.360 And I have to say, one of the highest theatrical production values I think I've seen so far in a video, including the hacker with the hoodie doing the whole, you know, hey, let's just pound on things, but with a real hacker. 01:05.720 --> 01:08.500 So, it was pretty entertaining to say the least. 01:08.500 --> 01:11.640 So, welcome both of you to DEF CON here at SAFEMODE. 01:12.400 --> 01:13.240 Thank you. 01:13.240 --> 01:14.360 It's great to be here. 01:14.720 --> 01:15.440 Thank you. 01:15.940 --> 01:27.060 Yeah, so first thing I want to kind of ask, just to get things started, so really, right, you like, has anything changed since the DEF CON, since you recorded your DEF CON talk and it was published? 01:27.060 --> 01:31.160 Any major changes or anything you want to share with the DEF CON community? 01:32.140 --> 01:41.160 Yeah, so there are actually a number of changes that Google's been rolling out, all of which have been super positive. 01:41.380 --> 01:43.800 Oh, it looks like Allison's video cut out. 01:44.360 --> 01:46.300 I guess she'll rejoin. 01:46.300 --> 01:49.160 I'll be answering the question though. 01:49.760 --> 02:04.420 So, I guess most notably, the service accounts or the roles and permissions which can make use of the default service account without ACT-AS are being end of life in 2021. 02:04.980 --> 02:07.340 And that was the direct response to this talk. 02:07.520 --> 02:20.260 And what that means is you will need the ACT-AS permission in addition to the other permission in order to do the action of attaching a service account to those services, even for the default service account. 02:20.580 --> 02:22.980 So, that's going to change things a little bit. 02:22.980 --> 02:30.840 In terms of what the overall security story is, I'm not 100% sure because it will lead to the proliferation of the ACT-AS permission. 02:31.180 --> 02:37.900 Ideally, folks will be applying that at the resource level for least privileged scope service accounts. 02:37.900 --> 02:41.580 But like we showed in the talk, people often apply it at the project level. 02:42.320 --> 02:49.220 So, it sort of opens the opportunity up for you to make yourself more secure, but it also kind of opens up more foot shooting opportunities. 02:50.060 --> 03:07.760 Another interesting change was that the very quick clip that I cut over to GitHub for and showed a bunch of people uploading their GCP service account credentials, I noticed that when I ran the same search on GitHub, those keys are no longer there. 03:07.760 --> 03:13.180 I assume someone went through a lot of effort to get those removed. 03:13.180 --> 03:20.400 And I was just thinking in the back of my mind, you know, they can go through that effort, they're still in that Arctic vault. 03:21.460 --> 03:25.060 So, those keys are immortalized in some capacity. 03:25.460 --> 03:27.440 But it's good that they took them down. 03:27.740 --> 03:32.160 It makes it more tricky to just immediately exploit lots of people at the gate from the talk. 03:32.160 --> 03:33.240 And I'm glad they did that. 03:34.680 --> 03:35.260 Awesome. 03:35.260 --> 03:35.900 Awesome. 03:36.200 --> 03:36.560 Yeah. 03:36.560 --> 03:38.960 So, kind of another kind of thought provoker. 03:38.960 --> 03:44.920 So, as I watch your video, I liked kind of at the beginning how you're like, here's how AWS identity access management works, right? 03:44.920 --> 03:46.800 And kind of here's the GCP model. 03:47.200 --> 03:51.280 You know, based on your experience so far, like, I guess, do you think one is better? 03:51.440 --> 03:51.840 Right? 03:51.840 --> 03:53.480 Do you prefer one model of the other? 03:53.480 --> 03:54.620 Do you think they both have their place? 03:54.620 --> 03:56.020 Kind of what's your take on that? 03:57.620 --> 03:58.920 That's a good question. 03:59.020 --> 04:07.360 There are definitely elements of the GCP platform that are unique and nice to use that AWS doesn't have. 04:08.400 --> 04:16.660 But in terms of the IAM story, I would say, generally speaking, from what I've observed, AWS more follows the principle of least privilege than GCP. 04:17.040 --> 04:20.620 And in that context, I guess it depends on your perspective. 04:20.620 --> 04:28.740 If you're a brand new developer and you want to move really quick and you want to have everything open by default, GCP is an interesting choice. 04:28.900 --> 04:36.640 If you're a security engineer and you want to follow least privilege and lock things down, AWS, from my observations, tends to do that more. 04:37.540 --> 04:40.680 So, actually, there's a question in the chat that kind of goes into that. 04:40.680 --> 04:42.220 So, go ahead and ask it. 04:42.300 --> 04:56.420 It was, for those of us with existing and sprawling GCP environments, given that the org policies aren't retroactive, what are some good approaches for tackling remediation for those deployments? 04:57.240 --> 04:59.560 That's a really good question. 04:59.560 --> 05:10.140 And I think we wanted to go into a little bit more depth into that subject in the video, but we didn't have the time to really dig into it. 05:10.300 --> 05:12.000 Remediation is really tricky. 05:12.000 --> 05:16.680 So, you can enable org policy when you're first starting an organization or later. 05:16.800 --> 05:19.740 And for all new things going forward, they'll get the benefits of it. 05:19.740 --> 05:30.280 But for all the existing projects that are already using the default service account, it's really hard to wean yourself off of it for a couple of reasons. 05:30.320 --> 05:41.980 First is that if you switch service counts on a live VM, which a lot of services are powered by, that VM needs to actually be stopped and started again to get the new service account. 05:42.200 --> 05:55.980 The second is that the default service account is kind of, like, it's not just, like, a set of permissions that's applied to your services, but it's also an IAM policy that's shared across all of your services. 05:55.980 --> 05:59.760 And so, you have two different services using the same policy. 05:59.760 --> 06:03.120 If you want to make modifications to that policy, it's going to affect both services. 06:03.380 --> 06:05.040 So, that makes it a little bit tricky. 06:05.220 --> 06:11.520 And then the way service accounts work is you can both use them as keys and you can use them as attached identities, similar to AWS. 06:11.760 --> 06:20.660 And so, you have to kind of enumerate all the different use cases and kind of systematically knock them out one at a time. 06:20.660 --> 06:27.080 So, you have to see how many keys are exported, you have to see is it attached to any instances, you have to check the stack driver logs to see whether or not they're in use. 06:28.480 --> 06:39.460 All of that can be really tricky, but some tools that do help with that are the Asset Analyzer API to see where the default service accounts are in use. 06:39.460 --> 06:43.960 And then the other one that's handy is the role recommender. 06:44.040 --> 06:55.820 So, you can get some idea of, based on the last 90-day look back period for a given project, how many permissions has the default service account actually used. 06:56.280 --> 07:12.280 Now, that's not the whole story for a number of reasons, one of which is the role recommender will only apply those recommendations sort of, you know, if the role binding is at the project level, it'll make the recommendation at the project level, it won't make the recommendation down at the resource level, 07:12.280 --> 07:30.500 and it also won't recommend that you split your IAM into two different, you know, identities, if maybe multiple services are using the default service account, it'll make a recommendation based on the summation of all those services, it won't say this service should have this scope of permissions and that service should have that scope of permissions. 07:30.720 --> 07:40.540 But it does kind of go a long way in terms of very quick remediation that you can do for looking backward for the things that work policy can't cover. 07:42.720 --> 07:43.360 Gotcha. 07:43.540 --> 07:44.140 Cool. 07:44.740 --> 07:46.860 Yeah, so I kind of had a thought too. 07:46.860 --> 07:57.460 So as I was watching this, I was like, man, this seems like a cool way for, you know, an attacker to maybe gain persistence in one of these, you know, GCP environments, like, you know, setting up an account, and, you know, maybe before some of these changes, 07:57.460 --> 08:01.560 like, hey, could you set up an account, give it privileges, and then does it just fly under the hood? 08:01.960 --> 08:03.580 I guess, what's your thought around that? 08:03.580 --> 08:05.760 Like, could you see that as a potential attack vector? 08:05.760 --> 08:11.290 Or would you see maybe other kind of attack vectors for hiding in the IAM noise of GCP? 08:12.080 --> 08:24.920 Yeah, I mean, I think a lot of what we showed is that this lateral movement, privilege escalation, persistence, it can all be done without dropping implants on a server. 08:25.200 --> 08:30.800 Like, you might for act as want to spin some things up, introduce them into the environment. 08:30.800 --> 08:39.740 For servers that have maybe endpoint software, monitoring malware and things like that, it wouldn't set those things off. 08:39.900 --> 08:42.100 So, I think it is good for persistence in that way. 08:42.100 --> 08:45.540 We'll probably need new tooling to look for these types of attacks. 08:45.600 --> 09:01.920 One of the services that Google offers to kind of help with this is the... I forget exactly what it's called, but it's a service that will monitor your Stackdriver logs and look for bad things and then alert you if it sees bad things. 09:02.540 --> 09:07.660 And so, it's watching those cloud APIs, which will be auditable. 09:09.280 --> 09:17.680 And examples of things they've used in the past are like known bad IP addresses for like crypto miners. 09:17.680 --> 09:19.960 If they ever show up in your Stackdriver logs, they'll send you an alert. 09:19.960 --> 09:24.920 But I expect these types of cloud attacks will become more and more a piece of that story. 09:26.100 --> 09:29.180 We also briefly showed a lot fishing. 09:29.180 --> 09:44.500 I think that's also a great way for persistence because if you get somebody to click an allow link on wide scope open permissions, you can get the permissions of the user without having to get a service account credential and it functions the same way. 09:44.680 --> 09:50.080 So, that's another way that you can sort of use these same techniques and get persistence. 09:50.880 --> 09:53.240 Something to note on this too is service account keys. 09:53.240 --> 10:01.620 So, if someone is able to create a service account and give it access to a resource or something, a project, that the service account keys last for 10 years. 10:01.620 --> 10:09.300 So, if they're never rotated by the organization or deleted, then you have that key for a very long time. 10:11.820 --> 10:12.220 Wow. 10:12.220 --> 10:15.120 Yeah, that's definitely interesting. 10:15.560 --> 10:18.340 Oh, another quick note on that. 10:18.780 --> 10:25.480 The long-lived exported credentials last for 10 years, like Alice mentioned, which is interesting. 10:25.480 --> 10:34.420 The short-lived instance credentials, those last, I think, closer to 10 minutes, but that'll persist after an instance is terminated. 10:34.420 --> 10:48.120 So, if you're an attacker and you're exploiting something like an SSRF or even remote code execution, grab instance credentials, even after the defensive person deletes the instance, the attacker can still persist another 10 minutes. 10:51.120 --> 10:51.720 Okay. 10:51.720 --> 10:58.120 So, we had another question pop up here in chat and kind of along with your follow-up to what you're explaining. 10:58.240 --> 11:01.480 It says, what about abandoned service accounts? 11:01.480 --> 11:02.620 Say they're deleted. 11:02.620 --> 11:07.480 Do you end up with abandoned ACLs that exist on the resources and projects? 11:09.520 --> 11:11.360 That's a good question. 11:11.360 --> 11:13.320 Allison, did you want to take that? 11:13.560 --> 11:28.320 So, there's actually something that is kind of interesting about this where we've run into some bugs, actually, where a service account has been deleted and their IAM bindings were also removed. 11:28.320 --> 11:32.400 So, if a service account is deleted, the IAM binding can still exist there. 11:32.400 --> 11:44.600 So, maybe also if you have a user in your org and you remove them from G Suite, that IAM binding will still exist in your GCP projects with user at gmail.com or whatever that is. 11:44.780 --> 11:58.480 But there's also interesting things that can happen due to the undelete capabilities for service accounts, or if you delete a service account, IAM binding, like you asked, it still exists where that IAM binding was made. 11:59.420 --> 12:04.000 And if you do, if you try to undelete your service account, you're like, oh, maybe I actually need that. 12:04.000 --> 12:16.100 And you had, or you try to create a new service account with that same name, the IAM binding will reference the UID of the service account that was, that was deleted. 12:16.100 --> 12:22.520 So, you can have this weird like caching thing happen where you'll get like permission denied errors if you're using this. 12:22.520 --> 12:40.820 So, if I create service account A and I give it an IAM binding at my project and I delete it, then I recreate a new service account, service count A, that tries to reference that existing IAM policy, it doesn't work because it's referencing the old service account that was deleted by its unique ID. 12:40.820 --> 12:51.340 So, yeah, they exist and this can bring up some really weird bugs if you're trying to create new service accounts with the same name or undelete your service accounts and you're not updating the IAM policies in parallel. 12:53.800 --> 12:54.840 Cool. 12:55.620 --> 13:01.760 Yeah, so we kind of talked about this a little bit and you mentioned this in your talk too, kind of from the defender perspective, right? 13:01.760 --> 13:14.440 Like, there's rolled out like the IAM analyzer, there's the recommender, you know, I guess, what are, are there any other things or advice you'd give to blue teams looking to secure kind of the GCP environment, right? 13:14.440 --> 13:22.280 Or the IAM offerings, like detection opportunities, like the tool you mentioned, log analysis, like, are there any, any good things to try to really dive in? 13:22.280 --> 13:28.820 Like, hey, ingest this log feed and, you know, hey, we'll see all your IAM transactions or anything like that, any advice you give? 13:30.580 --> 13:32.520 That's a good question. 13:32.520 --> 13:51.600 A lot of people will recommend that you can pipe your Stackdriver logs over to BigQuery, so that you get a structured query language that's a little bit easier to work with than the filters in Stackdriver, easier to write detection rules for and such. 13:51.600 --> 14:15.980 I think that definitely the security API that exists at the org level has some very interesting introspections that you can do across your whole fleet, and they provide some suggestions and recommendations around other types of least privilege, like buckets that were left open to the internet and things like that. 14:15.980 --> 14:36.380 There's also a lot of other org policies that we didn't cover that also will improve your security story, but just aren't necessarily related to the content we talked about, like allowing your developers to add users outside of your organization to roles inside your organization. 14:36.380 --> 14:40.400 By default, that's allowed, so you can add a random Gmail account to a project. 14:40.400 --> 14:42.660 You can disable that via org policy. 14:43.100 --> 14:47.660 So it's definitely worth checking out those high-level org policies as well. 14:48.960 --> 15:06.920 And I think that we mentioned this as well in the talk, but we had general positive experiences providing feedback to Google, and in some cases, they actually put us in touch with PMs where we could explain these issues directly to them. 15:07.040 --> 15:16.160 And so in that regard, we strongly recommend people to engage with Google around pain points and tell them what an ideal workflow would look like. 15:16.160 --> 15:19.060 And in our case, they were receptive and worked with us on those things. 15:19.900 --> 15:21.880 Yeah, I was actually going to dive a little into that too. 15:21.880 --> 15:31.640 So again, working with Google that closely, again, it's always an interesting thing when you're approaching someone with base-level issues like that, how do they respond? 15:31.840 --> 15:40.620 Do you have any other tips for folks who'd be in similar situations, like reaching out to a Google or another company, like anything you learned out of that that you'd do better next time? 15:41.620 --> 15:46.680 Well, I think what was interesting is there's kind of two ways to engage with Google. 15:46.700 --> 15:50.540 There's the customer way, and then there's the vulnerability way. 15:50.840 --> 15:56.840 So you can submit to their bug bounty, and they get a very binary, this is a problem, this isn't a problem, right? 15:56.840 --> 15:58.980 If it's a problem, they'll pay you and they'll fix it. 15:58.980 --> 16:01.700 If it's not a problem, they'll close the ticket, and that's the end of the story. 16:02.200 --> 16:03.940 That's the bug bounty way. 16:04.360 --> 16:09.420 And you're interacting with the security engineer when you do that on the other end of that ticket. 16:09.580 --> 16:19.400 When you go the customer route, you're talking with a PM around them building products and giving them feedback about existing products. 16:19.400 --> 16:22.680 And that's a continuous story that doesn't end, and it's not binary. 16:22.860 --> 16:34.700 You have to sort of go through in-depth how security problems manifest themselves and things like that, which you might not have to do if you're talking to a security engineer. 16:34.780 --> 16:38.540 And you get to continue that conversation indefinitely. 16:38.800 --> 16:42.860 It's not a binary, you know, this is a problem, this isn't a problem, okay, ticket closed. 16:42.960 --> 16:46.700 So we pursued both of those paths concurrently. 16:47.320 --> 16:57.200 And I think that probably depends on your particular use case. 16:57.200 --> 17:06.900 But there were some things which we submitted as bugs through the bug bounty, and we thought that they would just be recognized as bugs and fixed. 17:07.260 --> 17:09.980 But they were actually just closed out as working as intended. 17:10.000 --> 17:14.400 And for those things, going the customer route actually proved to be more effective. 17:16.320 --> 17:16.820 Cool. 17:16.820 --> 17:17.600 That's great advice. 17:17.600 --> 17:19.000 Great advice for other people. 17:20.060 --> 17:23.300 I guess the other question I have, too, so it's kind of what's next, right? 17:23.300 --> 17:30.260 You kind of really, I guess, gone into a lot of the problems you've done a lot of improvement on this front with Google. 17:30.500 --> 17:32.120 What's your next for the research front? 17:32.120 --> 17:37.640 Are you going to continue to refine more attacks here, looking at other things, kind of what's next for the both of you? 17:39.060 --> 17:54.100 So recently, I did notice someone sent me some good resources that Rhino Security wrote up on some other GCP privilege escalation techniques, and they released some proof of concept tools. 17:54.520 --> 18:04.520 I think it would be cool if sort of the community helped bundle all of those tools into one framework. 18:04.520 --> 18:10.100 Of course, I'm selfishly hoping that's gsploit, so that we can kind of have like a metasploit for cloud. 18:10.860 --> 18:15.480 So I thought that, you know, that might be fun to consolidate some of that stuff. 18:15.480 --> 18:22.300 But beyond that, I don't have a lot of plans to do more extensive work in GCP. 18:22.300 --> 18:24.180 What about you, Allison? 18:25.180 --> 18:31.980 Yeah, for public research wise, I don't think I'll be elaborating on this topic for a while. 18:31.980 --> 18:49.120 But definitely something that I'm personally interested in learning more about and seeing the state of how different cloud providers, Google and AWS tackle IAM, because it's something that's really difficult, and I think is going to be changing very frequently for a long time, 18:49.120 --> 18:52.200 because it's such a hard problem to try to tackle. 18:52.380 --> 18:57.240 So no public research for the near future, but definitely interested in seeing what happens. 18:59.160 --> 19:03.500 And I have a question that kind of came up when I was watching your talk as well. 19:03.520 --> 19:10.420 Kind of going back to the tooling, you mentioned that you all developed a framework, gsploit. 19:10.420 --> 19:14.380 Is that something that has been or you plan on releasing anytime in the future? 19:14.800 --> 19:16.400 So yeah, it's already live. 19:16.400 --> 19:18.520 We linked to it in the talk. 19:18.520 --> 19:19.760 And you can check it out. 19:19.760 --> 19:21.720 It's on GitHub and Docker Hub. 19:21.720 --> 19:24.380 So it's just a little Docker container you can run. 19:24.680 --> 19:29.960 It was definitely released more on the proof of concept side than production code side. 19:29.960 --> 19:34.240 So some people found some bugs in it already and I'm expecting more. 19:34.340 --> 19:38.720 But it does the things that we videoed. 19:38.720 --> 19:42.860 So those demos, we can reproduce them with the tool. 19:43.520 --> 19:44.080 Cool. 19:44.080 --> 19:47.400 And then it looks like we have one more question in the chat. 19:47.760 --> 19:52.900 From your talk, I got the idea that in AWS, the account holder owns the permissions. 19:53.040 --> 20:00.680 But doesn't that cause a problem for research owners who need or want to provide permissions when the account is not under their control? 20:01.880 --> 20:14.800 I think this kind of gets at the heart of what we opened the talk with, which is whether or not your IAM model is resource-centric or user-centric. 20:14.800 --> 20:19.800 So is it basically the resource owner that controls who can access the resource? 20:19.800 --> 20:25.100 Or is it the identity owner that controls what resources that identity can access? 20:25.100 --> 20:34.040 And I think that's sort of the main difference between the two IAM stories in AWS versus GCP, at least that we opened with. 20:34.240 --> 20:40.840 We talked about some of the challenges that come up with the resource-centric model that's in GCP. 20:40.840 --> 20:45.560 We didn't really touch on the challenges of the inverse of that in AWS. 20:46.460 --> 20:52.480 And to be honest, I'm not an expert in AWS IAM by any means. 20:52.480 --> 20:59.540 And so I'd be curious to know if someone else wanted to do a deep dive on what those cons are. 21:01.980 --> 21:05.680 It also depends on how you're managing your infrastructure. 21:05.680 --> 21:17.380 It depends on are you allowing engineers to manage different infrastructure configurations, or do you have kind of a more centralized way that you're provisioning access within an account, too? 21:17.380 --> 21:18.920 Something to think about. 21:21.020 --> 21:21.960 Cool. 21:21.960 --> 21:25.780 Yeah, and I guess one thing I didn't really ask there, I don't remember, is why GCP? 21:25.800 --> 21:28.980 What kind of drew you to this area for research? 21:28.980 --> 21:31.580 Why did you look at this and the weaknesses here? 21:32.840 --> 21:40.380 Well, I think some of the defaults were definitely a little eye-opening. 21:40.760 --> 21:51.520 I guess the full story of this is someone briefly compressed down in the back of an Uber ride on my way home. 21:51.520 --> 21:53.660 I was sharing a car with someone. 21:53.780 --> 21:57.620 A bunch of crazy things in GCP that I found hard to believe. 21:57.620 --> 22:02.480 Yeah, all these things run as almost full administrator by default. 22:03.160 --> 22:09.820 And those things kind of prompted me to poke into it a little more. 22:10.000 --> 22:16.520 And then I think my poking got Allison poking, and then we just followed the rabbit hole as far as it would go. 22:18.640 --> 22:19.440 Cool. 22:19.460 --> 22:22.420 Yeah, there is one other question here that just came in the chat, too. 22:22.700 --> 22:25.700 And I don't know if you know the answer, but which model does Azure take? 22:25.700 --> 22:27.800 Is it more resource or identity-centric? 22:29.320 --> 22:30.160 Actually, not sure. 22:30.160 --> 22:32.680 I'm not familiar with Azure very much. 22:32.680 --> 22:41.240 I also wouldn't be able to speak to Oracle Cloud, IBM Cloud, or Alibaba Cloud, but I'm very curious to know the case for all of us. 22:42.240 --> 22:44.700 Future research for others to look into. 22:45.780 --> 22:46.740 Yeah, definitely. 22:47.360 --> 22:48.220 Awesome. 22:48.220 --> 22:50.800 Yeah, so we're getting near the end of our time here. 22:50.820 --> 22:53.360 But really, a couple last final ups. 22:53.360 --> 22:59.960 First, what should people look into if they're interested in learning more about the GCP identity access model? 22:59.960 --> 23:06.960 Where would you recommend someone start if they're trying to figure out how does this work, and maybe if they want to dive in themselves? 23:08.380 --> 23:13.800 Yeah, there's actually... the documentation, I think, is really great to start with. 23:13.800 --> 23:15.720 Really, just read it in its entirety. 23:15.720 --> 23:17.420 It's a lot of information. 23:17.500 --> 23:35.120 But from a hardening perspective, Google also recently released a new blog post that outlines some of the... in one place, not in each individual services, IM docs, some of the different steps you can take to harden the IM of the different services that we brought up in our talk. 23:35.720 --> 23:36.260 Oh, yeah. 23:36.260 --> 23:43.760 And on that subject, that blog post is also an answer to earlier questions of what they've done since the talk. 23:43.760 --> 23:46.920 That blog post was done in response to the talk. 23:48.840 --> 23:49.680 Awesome. 23:49.680 --> 23:55.140 Yeah, so someone said GCP is like gone cloud pwning, which seems pretty apt. 23:56.700 --> 24:00.140 But yeah, so really, I kind of opened up the last user. 24:00.140 --> 24:02.100 Anything else you really want to share with anyone? 24:02.100 --> 24:03.680 Any other last thoughts? 24:03.760 --> 24:09.900 Things that you think folks really should know about GCP before we move on? 24:12.750 --> 24:18.310 Oh, I'll just share that I am completely new to Twitter. 24:18.310 --> 24:23.530 I made a Twitter account last week, and I shared the handle in the video. 24:23.530 --> 24:31.210 But if folks want to connect with me there, and make me feel less lonely, because I don't have a lot of followers, feel free. 24:32.150 --> 24:33.850 What Twitter account is that? 24:34.490 --> 24:36.810 Oh, it's Insecure Nature. 24:36.810 --> 24:39.070 And it's linked in the talk. 24:39.070 --> 24:40.970 And I can also link in the chat. 24:43.390 --> 24:46.710 Okay, I guess my final thought would be don't trust the documentation. 24:46.710 --> 24:49.990 I know I said just read the documentation, but don't trust the documentation. 24:50.410 --> 24:57.810 When you're going and assessing things or building things, take kind of like a reverse engineering approach to analyzing things in the cloud. 24:57.810 --> 25:01.590 So test and verify the behaviors. 25:01.590 --> 25:07.670 Don't maybe just take what's in the documentation or what you think it would work, how you think something should work as the truth. 25:08.310 --> 25:08.950 Oh, yeah. 25:08.950 --> 25:15.350 And there are also a couple more privilege escalations, like I mentioned, that we just didn't have time to go into. 25:15.370 --> 25:21.470 We covered most of the ones that compromise a large set of identities. 25:21.470 --> 25:25.730 But there are privilege escalations for getting access to storage and those types of things. 25:25.890 --> 25:32.210 They're covered both in our earlier talk that we gave at BSides that I recommend folks check out. 25:32.310 --> 25:36.870 And like I mentioned, Rhino Security has done some pretty good write-ups recently on it. 25:40.180 --> 25:40.960 Awesome. 25:41.000 --> 25:43.120 Well, thank you both, Dylan and Allison. 25:43.340 --> 25:50.880 Really what I'd suggest too, if you have any particular links or summarized list of links you want to throw into the Discord chat room, that'll be helpful for everyone. 25:50.960 --> 25:54.280 There's lots of folks in there thanking you for the talk. 25:54.280 --> 25:57.260 So definitely well received by everyone here. 25:58.180 --> 26:00.780 But yeah, just want to say thank you again. 26:00.780 --> 26:03.100 Thank you for joining us for the DEF CON Safe Mode talk. 26:03.100 --> 26:09.240 Thanks for presenting in these weird times and hopefully see you in the future out in Vegas when we return. 26:10.020 --> 26:10.960 Sounds good. 26:10.960 --> 26:12.200 Thanks so much for having us. 26:12.200 --> 26:12.720 Thank you so much. 26:12.720 --> 26:13.400 Yeah, thank you. 26:13.400 --> 26:14.240 It's a pleasure. 26:15.200 --> 26:16.340 Take care. 26:16.520 --> 26:17.580 Yeah, thanks.