1
00:00:40,340 --> 00:00:41,040
Hi there!

2
00:00:41,040 --> 00:00:42,100
Welcome everyone.

3
00:00:42,220 --> 00: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.

4
00:00:50,460 --> 00:00:53,120
Compromise any organization without dropping an implant.

5
00:00:53,220 --> 00: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.

6
00:01:05,720 --> 00:01:08,500
So, it was pretty entertaining to say the least.

7
00:01:08,500 --> 00:01:11,640
So, welcome both of you to DEF CON here at SAFEMODE.

8
00:01:12,400 --> 00:01:13,240
Thank you.

9
00:01:13,240 --> 00:01:14,360
It's great to be here.

10
00:01:14,720 --> 00:01:15,440
Thank you.

11
00:01:15,940 --> 00: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?

12
00:01:27,060 --> 00:01:31,160
Any major changes or anything you want to share with the DEF CON community?

13
00:01:32,140 --> 00: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.

14
00:01:41,380 --> 00:01:43,800
Oh, it looks like Allison's video cut out.

15
00:01:44,360 --> 00:01:46,300
I guess she'll rejoin.

16
00:01:46,300 --> 00:01:49,160
I'll be answering the question though.

17
00:01:49,760 --> 00: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.

18
00:02:04,980 --> 00:02:07,340
And that was the direct response to this talk.

19
00:02:07,520 --> 00: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.

20
00:02:20,580 --> 00:02:22,980
So, that's going to change things a little bit.

21
00:02:22,980 --> 00: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.

22
00:02:31,180 --> 00:02:37,900
Ideally, folks will be applying that at the resource level for least privileged scope service accounts.

23
00:02:37,900 --> 00:02:41,580
But like we showed in the talk, people often apply it at the project level.

24
00:02:42,320 --> 00: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.

25
00:02:50,060 --> 00: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.

26
00:03:07,760 --> 00:03:13,180
I assume someone went through a lot of effort to get those removed.

27
00:03:13,180 --> 00: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.

28
00:03:21,460 --> 00:03:25,060
So, those keys are immortalized in some capacity.

29
00:03:25,460 --> 00:03:27,440
But it's good that they took them down.

30
00:03:27,740 --> 00:03:32,160
It makes it more tricky to just immediately exploit lots of people at the gate from the talk.

31
00:03:32,160 --> 00:03:33,240
And I'm glad they did that.

32
00:03:34,680 --> 00:03:35,260
Awesome.

33
00:03:35,260 --> 00:03:35,900
Awesome.

34
00:03:36,200 --> 00:03:36,560
Yeah.

35
00:03:36,560 --> 00:03:38,960
So, kind of another kind of thought provoker.

36
00:03:38,960 --> 00: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?

37
00:03:44,920 --> 00:03:46,800
And kind of here's the GCP model.

38
00:03:47,200 --> 00:03:51,280
You know, based on your experience so far, like, I guess, do you think one is better?

39
00:03:51,440 --> 00:03:51,840
Right?

40
00:03:51,840 --> 00:03:53,480
Do you prefer one model of the other?

41
00:03:53,480 --> 00:03:54,620
Do you think they both have their place?

42
00:03:54,620 --> 00:03:56,020
Kind of what's your take on that?

43
00:03:57,620 --> 00:03:58,920
That's a good question.

44
00:03:59,020 --> 00:04:07,360
There are definitely elements of the GCP platform that are unique and nice to use that AWS doesn't have.

45
00:04:08,400 --> 00: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.

46
00:04:17,040 --> 00:04:20,620
And in that context, I guess it depends on your perspective.

47
00:04:20,620 --> 00: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.

48
00:04:28,900 --> 00: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.

49
00:04:37,540 --> 00:04:40,680
So, actually, there's a question in the chat that kind of goes into that.

50
00:04:40,680 --> 00:04:42,220
So, go ahead and ask it.

51
00:04:42,300 --> 00: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?

52
00:04:57,240 --> 00:04:59,560
That's a really good question.

53
00:04:59,560 --> 00: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.

54
00:05:10,300 --> 00:05:12,000
Remediation is really tricky.

55
00:05:12,000 --> 00:05:16,680
So, you can enable org policy when you're first starting an organization or later.

56
00:05:16,800 --> 00:05:19,740
And for all new things going forward, they'll get the benefits of it.

57
00:05:19,740 --> 00: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.

58
00:05:30,320 --> 00: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.

59
00:05:42,200 --> 00: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.

60
00:05:55,980 --> 00:05:59,760
And so, you have two different services using the same policy.

61
00:05:59,760 --> 00:06:03,120
If you want to make modifications to that policy, it's going to affect both services.

62
00:06:03,380 --> 00:06:05,040
So, that makes it a little bit tricky.

63
00:06:05,220 --> 00: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.

64
00:06:11,760 --> 00: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.

65
00:06:20,660 --> 00: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.

66
00:06:28,480 --> 00: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.

67
00:06:39,460 --> 00:06:43,960
And then the other one that's handy is the role recommender.

68
00:06:44,040 --> 00: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.

69
00:06:56,280 --> 00: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,

70
00:07:12,280 --> 00: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.

71
00:07:30,720 --> 00: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.

72
00:07:42,720 --> 00:07:43,360
Gotcha.

73
00:07:43,540 --> 00:07:44,140
Cool.

74
00:07:44,740 --> 00:07:46,860
Yeah, so I kind of had a thought too.

75
00:07:46,860 --> 00: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,

76
00:07:57,460 --> 00:08:01,560
like, hey, could you set up an account, give it privileges, and then does it just fly under the hood?

77
00:08:01,960 --> 00:08:03,580
I guess, what's your thought around that?

78
00:08:03,580 --> 00:08:05,760
Like, could you see that as a potential attack vector?

79
00:08:05,760 --> 00:08:11,290
Or would you see maybe other kind of attack vectors for hiding in the IAM noise of GCP?

80
00:08:12,080 --> 00: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.

81
00:08:25,200 --> 00:08:30,800
Like, you might for act as want to spin some things up, introduce them into the environment.

82
00:08:30,800 --> 00:08:39,740
For servers that have maybe endpoint software, monitoring malware and things like that, it wouldn't set those things off.

83
00:08:39,900 --> 00:08:42,100
So, I think it is good for persistence in that way.

84
00:08:42,100 --> 00:08:45,540
We'll probably need new tooling to look for these types of attacks.

85
00:08:45,600 --> 00: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.

86
00:09:02,540 --> 00:09:07,660
And so, it's watching those cloud APIs, which will be auditable.

87
00:09:09,280 --> 00:09:17,680
And examples of things they've used in the past are like known bad IP addresses for like crypto miners.

88
00:09:17,680 --> 00:09:19,960
If they ever show up in your Stackdriver logs, they'll send you an alert.

89
00:09:19,960 --> 00:09:24,920
But I expect these types of cloud attacks will become more and more a piece of that story.

90
00:09:26,100 --> 00:09:29,180
We also briefly showed a lot fishing.

91
00:09:29,180 --> 00: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.

92
00:09:44,680 --> 00:09:50,080
So, that's another way that you can sort of use these same techniques and get persistence.

93
00:09:50,880 --> 00:09:53,240
Something to note on this too is service account keys.

94
00:09:53,240 --> 00: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.

95
00:10:01,620 --> 00:10:09,300
So, if they're never rotated by the organization or deleted, then you have that key for a very long time.

96
00:10:11,820 --> 00:10:12,220
Wow.

97
00:10:12,220 --> 00:10:15,120
Yeah, that's definitely interesting.

98
00:10:15,560 --> 00:10:18,340
Oh, another quick note on that.

99
00:10:18,780 --> 00:10:25,480
The long-lived exported credentials last for 10 years, like Alice mentioned, which is interesting.

100
00:10:25,480 --> 00: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.

101
00:10:34,420 --> 00: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.

102
00:10:51,120 --> 00:10:51,720
Okay.

103
00:10:51,720 --> 00: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.

104
00:10:58,240 --> 00:11:01,480
It says, what about abandoned service accounts?

105
00:11:01,480 --> 00:11:02,620
Say they're deleted.

106
00:11:02,620 --> 00:11:07,480
Do you end up with abandoned ACLs that exist on the resources and projects?

107
00:11:09,520 --> 00:11:11,360
That's a good question.

108
00:11:11,360 --> 00:11:13,320
Allison, did you want to take that?

109
00:11:13,560 --> 00: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.

110
00:11:28,320 --> 00:11:32,400
So, if a service account is deleted, the IAM binding can still exist there.

111
00:11:32,400 --> 00: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.

112
00:11:44,780 --> 00: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.

113
00:11:59,420 --> 00:12:04,000
And if you do, if you try to undelete your service account, you're like, oh, maybe I actually need that.

114
00:12:04,000 --> 00: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.

115
00:12:16,100 --> 00: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.

116
00:12:22,520 --> 00: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.

117
00:12:40,820 --> 00: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.

118
00:12:53,800 --> 00:12:54,840
Cool.

119
00:12:55,620 --> 00: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?

120
00:13:01,760 --> 00: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?

121
00:13:14,440 --> 00: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?

122
00:13:22,280 --> 00: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?

123
00:13:30,580 --> 00:13:32,520
That's a good question.

124
00:13:32,520 --> 00: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.

125
00:13:51,600 --> 00: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.

126
00:14:15,980 --> 00: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.

127
00:14:36,380 --> 00:14:40,400
By default, that's allowed, so you can add a random Gmail account to a project.

128
00:14:40,400 --> 00:14:42,660
You can disable that via org policy.

129
00:14:43,100 --> 00:14:47,660
So it's definitely worth checking out those high-level org policies as well.

130
00:14:48,960 --> 00: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.

131
00:15:07,040 --> 00: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.

132
00:15:16,160 --> 00:15:19,060
And in our case, they were receptive and worked with us on those things.

133
00:15:19,900 --> 00:15:21,880
Yeah, I was actually going to dive a little into that too.

134
00:15:21,880 --> 00: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?

135
00:15:31,840 --> 00: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?

136
00:15:41,620 --> 00:15:46,680
Well, I think what was interesting is there's kind of two ways to engage with Google.

137
00:15:46,700 --> 00:15:50,540
There's the customer way, and then there's the vulnerability way.

138
00:15:50,840 --> 00: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?

139
00:15:56,840 --> 00:15:58,980
If it's a problem, they'll pay you and they'll fix it.

140
00:15:58,980 --> 00:16:01,700
If it's not a problem, they'll close the ticket, and that's the end of the story.

141
00:16:02,200 --> 00:16:03,940
That's the bug bounty way.

142
00:16:04,360 --> 00:16:09,420
And you're interacting with the security engineer when you do that on the other end of that ticket.

143
00:16:09,580 --> 00: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.

144
00:16:19,400 --> 00:16:22,680
And that's a continuous story that doesn't end, and it's not binary.

145
00:16:22,860 --> 00: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.

146
00:16:34,780 --> 00:16:38,540
And you get to continue that conversation indefinitely.

147
00:16:38,800 --> 00:16:42,860
It's not a binary, you know, this is a problem, this isn't a problem, okay, ticket closed.

148
00:16:42,960 --> 00:16:46,700
So we pursued both of those paths concurrently.

149
00:16:47,320 --> 00:16:57,200
And I think that probably depends on your particular use case.

150
00:16:57,200 --> 00: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.

151
00:17:07,260 --> 00:17:09,980
But they were actually just closed out as working as intended.

152
00:17:10,000 --> 00:17:14,400
And for those things, going the customer route actually proved to be more effective.

153
00:17:16,320 --> 00:17:16,820
Cool.

154
00:17:16,820 --> 00:17:17,600
That's great advice.

155
00:17:17,600 --> 00:17:19,000
Great advice for other people.

156
00:17:20,060 --> 00:17:23,300
I guess the other question I have, too, so it's kind of what's next, right?

157
00:17:23,300 --> 00: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.

158
00:17:30,500 --> 00:17:32,120
What's your next for the research front?

159
00:17:32,120 --> 00: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?

160
00:17:39,060 --> 00: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.

161
00:17:54,520 --> 00:18:04,520
I think it would be cool if sort of the community helped bundle all of those tools into one framework.

162
00:18:04,520 --> 00:18:10,100
Of course, I'm selfishly hoping that's gsploit, so that we can kind of have like a metasploit for cloud.

163
00:18:10,860 --> 00:18:15,480
So I thought that, you know, that might be fun to consolidate some of that stuff.

164
00:18:15,480 --> 00:18:22,300
But beyond that, I don't have a lot of plans to do more extensive work in GCP.

165
00:18:22,300 --> 00:18:24,180
What about you, Allison?

166
00:18:25,180 --> 00:18:31,980
Yeah, for public research wise, I don't think I'll be elaborating on this topic for a while.

167
00:18:31,980 --> 00: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,

168
00:18:49,120 --> 00:18:52,200
because it's such a hard problem to try to tackle.

169
00:18:52,380 --> 00:18:57,240
So no public research for the near future, but definitely interested in seeing what happens.

170
00:18:59,160 --> 00:19:03,500
And I have a question that kind of came up when I was watching your talk as well.

171
00:19:03,520 --> 00:19:10,420
Kind of going back to the tooling, you mentioned that you all developed a framework, gsploit.

172
00:19:10,420 --> 00:19:14,380
Is that something that has been or you plan on releasing anytime in the future?

173
00:19:14,800 --> 00:19:16,400
So yeah, it's already live.

174
00:19:16,400 --> 00:19:18,520
We linked to it in the talk.

175
00:19:18,520 --> 00:19:19,760
And you can check it out.

176
00:19:19,760 --> 00:19:21,720
It's on GitHub and Docker Hub.

177
00:19:21,720 --> 00:19:24,380
So it's just a little Docker container you can run.

178
00:19:24,680 --> 00:19:29,960
It was definitely released more on the proof of concept side than production code side.

179
00:19:29,960 --> 00:19:34,240
So some people found some bugs in it already and I'm expecting more.

180
00:19:34,340 --> 00:19:38,720
But it does the things that we videoed.

181
00:19:38,720 --> 00:19:42,860
So those demos, we can reproduce them with the tool.

182
00:19:43,520 --> 00:19:44,080
Cool.

183
00:19:44,080 --> 00:19:47,400
And then it looks like we have one more question in the chat.

184
00:19:47,760 --> 00:19:52,900
From your talk, I got the idea that in AWS, the account holder owns the permissions.

185
00:19:53,040 --> 00: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?

186
00:20:01,880 --> 00: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.

187
00:20:14,800 --> 00:20:19,800
So is it basically the resource owner that controls who can access the resource?

188
00:20:19,800 --> 00:20:25,100
Or is it the identity owner that controls what resources that identity can access?

189
00:20:25,100 --> 00: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.

190
00:20:34,240 --> 00:20:40,840
We talked about some of the challenges that come up with the resource-centric model that's in GCP.

191
00:20:40,840 --> 00:20:45,560
We didn't really touch on the challenges of the inverse of that in AWS.

192
00:20:46,460 --> 00:20:52,480
And to be honest, I'm not an expert in AWS IAM by any means.

193
00:20:52,480 --> 00: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.

194
00:21:01,980 --> 00:21:05,680
It also depends on how you're managing your infrastructure.

195
00:21:05,680 --> 00: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?

196
00:21:17,380 --> 00:21:18,920
Something to think about.

197
00:21:21,020 --> 00:21:21,960
Cool.

198
00:21:21,960 --> 00:21:25,780
Yeah, and I guess one thing I didn't really ask there, I don't remember, is why GCP?

199
00:21:25,800 --> 00:21:28,980
What kind of drew you to this area for research?

200
00:21:28,980 --> 00:21:31,580
Why did you look at this and the weaknesses here?

201
00:21:32,840 --> 00:21:40,380
Well, I think some of the defaults were definitely a little eye-opening.

202
00:21:40,760 --> 00: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.

203
00:21:51,520 --> 00:21:53,660
I was sharing a car with someone.

204
00:21:53,780 --> 00:21:57,620
A bunch of crazy things in GCP that I found hard to believe.

205
00:21:57,620 --> 00:22:02,480
Yeah, all these things run as almost full administrator by default.

206
00:22:03,160 --> 00:22:09,820
And those things kind of prompted me to poke into it a little more.

207
00:22:10,000 --> 00: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.

208
00:22:18,640 --> 00:22:19,440
Cool.

209
00:22:19,460 --> 00:22:22,420
Yeah, there is one other question here that just came in the chat, too.

210
00:22:22,700 --> 00:22:25,700
And I don't know if you know the answer, but which model does Azure take?

211
00:22:25,700 --> 00:22:27,800
Is it more resource or identity-centric?

212
00:22:29,320 --> 00:22:30,160
Actually, not sure.

213
00:22:30,160 --> 00:22:32,680
I'm not familiar with Azure very much.

214
00:22:32,680 --> 00: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.

215
00:22:42,240 --> 00:22:44,700
Future research for others to look into.

216
00:22:45,780 --> 00:22:46,740
Yeah, definitely.

217
00:22:47,360 --> 00:22:48,220
Awesome.

218
00:22:48,220 --> 00:22:50,800
Yeah, so we're getting near the end of our time here.

219
00:22:50,820 --> 00:22:53,360
But really, a couple last final ups.

220
00:22:53,360 --> 00:22:59,960
First, what should people look into if they're interested in learning more about the GCP identity access model?

221
00:22:59,960 --> 00: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?

222
00:23:08,380 --> 00:23:13,800
Yeah, there's actually... the documentation, I think, is really great to start with.

223
00:23:13,800 --> 00:23:15,720
Really, just read it in its entirety.

224
00:23:15,720 --> 00:23:17,420
It's a lot of information.

225
00:23:17,500 --> 00: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.

226
00:23:35,720 --> 00:23:36,260
Oh, yeah.

227
00:23:36,260 --> 00: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.

228
00:23:43,760 --> 00:23:46,920
That blog post was done in response to the talk.

229
00:23:48,840 --> 00:23:49,680
Awesome.

230
00:23:49,680 --> 00:23:55,140
Yeah, so someone said GCP is like gone cloud pwning, which seems pretty apt.

231
00:23:56,700 --> 00:24:00,140
But yeah, so really, I kind of opened up the last user.

232
00:24:00,140 --> 00:24:02,100
Anything else you really want to share with anyone?

233
00:24:02,100 --> 00:24:03,680
Any other last thoughts?

234
00:24:03,760 --> 00:24:09,900
Things that you think folks really should know about GCP before we move on?

235
00:24:12,750 --> 00:24:18,310
Oh, I'll just share that I am completely new to Twitter.

236
00:24:18,310 --> 00:24:23,530
I made a Twitter account last week, and I shared the handle in the video.

237
00:24:23,530 --> 00: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.

238
00:24:32,150 --> 00:24:33,850
What Twitter account is that?

239
00:24:34,490 --> 00:24:36,810
Oh, it's Insecure Nature.

240
00:24:36,810 --> 00:24:39,070
And it's linked in the talk.

241
00:24:39,070 --> 00:24:40,970
And I can also link in the chat.

242
00:24:43,390 --> 00:24:46,710
Okay, I guess my final thought would be don't trust the documentation.

243
00:24:46,710 --> 00:24:49,990
I know I said just read the documentation, but don't trust the documentation.

244
00:24:50,410 --> 00: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.

245
00:24:57,810 --> 00:25:01,590
So test and verify the behaviors.

246
00:25:01,590 --> 00: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.

247
00:25:08,310 --> 00:25:08,950
Oh, yeah.

248
00:25:08,950 --> 00: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.

249
00:25:15,370 --> 00:25:21,470
We covered most of the ones that compromise a large set of identities.

250
00:25:21,470 --> 00:25:25,730
But there are privilege escalations for getting access to storage and those types of things.

251
00:25:25,890 --> 00:25:32,210
They're covered both in our earlier talk that we gave at BSides that I recommend folks check out.

252
00:25:32,310 --> 00:25:36,870
And like I mentioned, Rhino Security has done some pretty good write-ups recently on it.

253
00:25:40,180 --> 00:25:40,960
Awesome.

254
00:25:41,000 --> 00:25:43,120
Well, thank you both, Dylan and Allison.

255
00:25:43,340 --> 00: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.

256
00:25:50,960 --> 00:25:54,280
There's lots of folks in there thanking you for the talk.

257
00:25:54,280 --> 00:25:57,260
So definitely well received by everyone here.

258
00:25:58,180 --> 00:26:00,780
But yeah, just want to say thank you again.

259
00:26:00,780 --> 00:26:03,100
Thank you for joining us for the DEF CON Safe Mode talk.

260
00:26:03,100 --> 00:26:09,240
Thanks for presenting in these weird times and hopefully see you in the future out in Vegas when we return.

261
00:26:10,020 --> 00:26:10,960
Sounds good.

262
00:26:10,960 --> 00:26:12,200
Thanks so much for having us.

263
00:26:12,200 --> 00:26:12,720
Thank you so much.

264
00:26:12,720 --> 00:26:13,400
Yeah, thank you.

265
00:26:13,400 --> 00:26:14,240
It's a pleasure.

266
00:26:15,200 --> 00:26:16,340
Take care.

267
00:26:16,520 --> 00:26:17,580
Yeah, thanks.