1
00:00:04,720 --> 00:00:07,960
Welcome to Crying Out Cloud, the
podcast that will make you 

2
00:00:07,960 --> 00:00:11,760
laugh, cry, and reconsider all 
of your cloud security fears. 

3
00:00:12,320 --> 00:00:19,840
It's Enan and Amitai yo, and 
today we have you've all on to 

4
00:00:19,840 --> 00:00:24,160
break the news about a super 
cool vulnerability found. 

5
00:00:24,760 --> 00:00:27,000
Yep, Yep, definitely. 
Cool. 

6
00:00:28,040 --> 00:00:33,280
Yuval is a researcher on our 
vulnerability research team. 

7
00:00:33,720 --> 00:00:36,920
Previously he was a principal 
security researcher at Palo 

8
00:00:36,920 --> 00:00:40,960
Alto. 
He is a Microsoft MVR Top 10 as 

9
00:00:40,960 --> 00:00:44,720
a researcher. 
And yeah, he's our colleague and

10
00:00:44,720 --> 00:00:46,400
he's super cool. 
So we're super happy to have him

11
00:00:46,400 --> 00:00:47,920
on. 
Happy to win. 

12
00:00:48,840 --> 00:00:53,240
OK, you've all discovered a flaw
in Amazon's own code build 

13
00:00:53,240 --> 00:00:56,000
projects. 
I'm not going to give too much 

14
00:00:56,000 --> 00:00:59,240
more details on, I'm going to 
let him tell us more himself. 

15
00:01:00,040 --> 00:01:03,360
But let's start off with how did
you get the idea, the 

16
00:01:03,360 --> 00:01:05,200
inspiration to work on this 
research? 

17
00:01:05,480 --> 00:01:10,320
So the idea actually came from a
threat actor right as I was 

18
00:01:10,320 --> 00:01:15,880
joining Wiz. 
This was a blog about an 

19
00:01:15,880 --> 00:01:20,000
attacker that managed to take 
over an AWS Gita repository. 

20
00:01:20,600 --> 00:01:23,440
So we saw that and we thought it
was really peculiar. 

21
00:01:23,440 --> 00:01:25,840
I don't know, I mean, time, 
maybe you remember this attack. 

22
00:01:26,040 --> 00:01:30,080
It was kind of a weird one 
because the entire motivation of

23
00:01:30,080 --> 00:01:33,280
the attacker was to just cause 
destruction. 

24
00:01:33,280 --> 00:01:35,640
He, he apparently didn't like 
the service or something like 

25
00:01:35,720 --> 00:01:38,760
that. 
And he just tried to, you know, 

26
00:01:38,920 --> 00:01:41,760
'cause he didn't try to like 
Krypto Mine or something like 

27
00:01:41,760 --> 00:01:46,880
that, just to cause destruction.
And he, although he had a typo 

28
00:01:46,880 --> 00:01:50,520
in his payload which caused it 
to ultimately fail, he was 

29
00:01:50,520 --> 00:01:53,640
actually able to get his payload
to run on like end user 

30
00:01:53,640 --> 00:01:55,960
computers. 
So it was a really interesting 

31
00:01:55,960 --> 00:02:00,800
attack and that really sparked 
our interest into AWS code build

32
00:02:00,880 --> 00:02:05,720
the service because the entire 
attack was built by abusing that

33
00:02:05,720 --> 00:02:07,160
service. 
So how did you find this? 

34
00:02:07,240 --> 00:02:10,759
Like what were you looking for? 
So when we looked at the 

35
00:02:11,039 --> 00:02:15,160
original attacks, we just try to
understand how is this even 

36
00:02:15,160 --> 00:02:18,320
possible? 
How can you exploit code build 

37
00:02:18,760 --> 00:02:22,160
to take over the underlying 
GitHub repository? 

38
00:02:22,800 --> 00:02:24,920
And what we found out is that 
code build. 

39
00:02:25,400 --> 00:02:29,440
The way it works, when someone 
submits a pull request to the 

40
00:02:29,720 --> 00:02:34,680
GitHub repository, it will 
trigger a build based on the 

41
00:02:34,760 --> 00:02:39,000
pull request branch right? 
And once that happens that the 

42
00:02:39,000 --> 00:02:42,920
code of the build runs in an 
environment that has a 

43
00:02:43,000 --> 00:02:46,800
credentials to GitHub, like a 
GitHub token, because code bill 

44
00:02:46,800 --> 00:02:50,120
needs to do stuff like update 
the commit status if the build 

45
00:02:50,480 --> 00:02:53,920
failed or succeeded and turn It 
turns out that more often than 

46
00:02:53,920 --> 00:02:57,840
not, those bills are those. 
This token is quite privileged. 

47
00:02:58,240 --> 00:03:01,680
And we saw that in a lot of 
cases, it will actually let you 

48
00:03:01,680 --> 00:03:05,960
take over the entire repository.
So we immediately, when we saw 

49
00:03:05,960 --> 00:03:11,960
this with, we went to look for 
how does AWS recommend to, you 

50
00:03:11,960 --> 00:03:13,440
know, not allow this kind of 
attack? 

51
00:03:13,440 --> 00:03:17,200
Because it's kind of crazy. 
And we saw that the main 

52
00:03:17,480 --> 00:03:20,960
mechanism back there was using 
something that's called an 

53
00:03:20,960 --> 00:03:25,960
actual ID filter, which 
basically is just a, you know, a

54
00:03:25,960 --> 00:03:31,640
list of user IDs whose pull 
requests are allowed to trigger 

55
00:03:31,800 --> 00:03:34,960
builds. 
So we, we looked at it and while

56
00:03:34,960 --> 00:03:39,200
we, it seemed like a, you know, 
a valid solution, we thought it 

57
00:03:39,200 --> 00:03:42,680
was like not the best user 
experience. 

58
00:03:43,120 --> 00:03:46,720
Like for each time someone joins
your team, you need to figure 

59
00:03:46,720 --> 00:03:50,520
out his GitHub user ID and then 
update this, you know, list on 

60
00:03:51,040 --> 00:03:53,560
AWS. 
So we were kind of suspicious 

61
00:03:53,560 --> 00:03:56,760
and we wanted to check whether, 
you know, people are actually 

62
00:03:56,760 --> 00:03:58,920
implementing this correctly, 
right? 

63
00:03:59,160 --> 00:04:04,560
Like as a misconfiguration. 
Yep, definitely the if people 

64
00:04:04,560 --> 00:04:07,480
are actually configuring their 
code build correctly. 

65
00:04:07,480 --> 00:04:12,040
So we wrote like a script that 
looks at GitHub and tries to 

66
00:04:12,320 --> 00:04:17,160
find something that's called 
public code build projects. 

67
00:04:17,959 --> 00:04:21,200
So in code build you can 
actually set something that 

68
00:04:21,200 --> 00:04:25,120
makes your code build settings 
public just on a web page. 

69
00:04:25,560 --> 00:04:28,320
So that was extremely helpful 
for us because we could search 

70
00:04:28,320 --> 00:04:32,120
for those and actually see their
configuration, whether they use 

71
00:04:32,120 --> 00:04:36,440
an actor ID filter. 
We ran, we found a bunch of AWS 

72
00:04:36,440 --> 00:04:39,400
repositories that use the actor 
ID filter. 

73
00:04:39,440 --> 00:04:43,000
So we're like OK, good for them.
Like nice, they'll be actually 

74
00:04:43,360 --> 00:04:46,480
doing what their documentation 
says you need to do. 

75
00:04:46,600 --> 00:04:49,640
And we kind of left it at that 
and continue to other stuff 

76
00:04:50,120 --> 00:04:55,600
until like 1 evening. 
I just, I don't know why it 

77
00:04:55,600 --> 00:04:58,880
popped into my head and 
something about the syntax of 

78
00:04:58,880 --> 00:05:01,480
the list seemed a bit off Seemed
weird. 

79
00:05:02,200 --> 00:05:05,520
You would expect expect it to be
like a list of numbers separated

80
00:05:05,520 --> 00:05:07,840
by like a comma or something 
like that, just a list. 

81
00:05:08,360 --> 00:05:12,360
But it actually was the 
separation was a pipe character 

82
00:05:12,360 --> 00:05:16,840
like I don't know if this is a 
good indication, just a pipe 

83
00:05:16,840 --> 00:05:20,640
character and and then it 
clicked to ask that this is 

84
00:05:20,640 --> 00:05:24,080
actually a regex. 
It's not the simple list and 

85
00:05:24,080 --> 00:05:26,800
it's it's well documented. 
We just didn't like who didn't 

86
00:05:26,800 --> 00:05:29,200
saw that it's actually a regex 
filter. 

87
00:05:30,600 --> 00:05:33,560
And the reason is because the 
actor ID filter is not the only 

88
00:05:33,560 --> 00:05:37,160
type of filter you could have 
like file system path filters 

89
00:05:37,160 --> 00:05:40,560
and other filters where regex 
makes sense and that's why it's 

90
00:05:40,560 --> 00:05:45,520
the underlying engine. 
But for a list of IDs it's it's 

91
00:05:45,520 --> 00:05:50,560
not really the best solution. 
And immediately what we thought 

92
00:05:50,560 --> 00:05:53,680
about is whether this list was 
encode. 

93
00:05:54,120 --> 00:05:57,040
What does that mean? 
That you put 2 characters at the

94
00:05:57,040 --> 00:06:00,040
end and beginning of a list to 
ensure that what you are 

95
00:06:00,040 --> 00:06:05,720
matching is exactly the match. 
Otherwise regex would match even

96
00:06:05,720 --> 00:06:09,040
if the string contains it. 
So let's say you're searching 

97
00:06:09,040 --> 00:06:12,920
for ABC with regex. 
If you don't put the encores 

98
00:06:13,280 --> 00:06:17,440
also 123ABC567 will also match 
right? 

99
00:06:17,920 --> 00:06:21,120
So immediately we thought, wow, 
if this is possible, we might be

100
00:06:21,680 --> 00:06:25,080
able to bypass this filter. 
So what does that look like? 

101
00:06:25,080 --> 00:06:28,880
I mean, cuz it sounds like you'd
need to have at least a partial 

102
00:06:28,880 --> 00:06:30,920
match, right? 
In order to make this work, 

103
00:06:31,400 --> 00:06:32,920
yeah. 
So how do you exploit that? 

104
00:06:33,480 --> 00:06:36,280
I I would say that Neil didn't 
thought it was exploitable. 

105
00:06:36,280 --> 00:06:39,320
Neil is our head of research. 
He didn't think it would work. 

106
00:06:39,320 --> 00:06:41,840
I, I immediately called him and 
I was like, wow, we we might be 

107
00:06:41,840 --> 00:06:44,680
able to bypass and he was like, 
no way this is going to work. 

108
00:06:44,680 --> 00:06:47,000
I was like, we're putting this 
on the record that Neil did not 

109
00:06:47,000 --> 00:06:51,560
believe this could work. 
I put this on record, but after 

110
00:06:52,440 --> 00:06:54,640
he saw that he was supportive at
the end anyway. 

111
00:06:54,640 --> 00:06:59,160
So, so like you say, we want, we
wanted to be able to understand 

112
00:06:59,160 --> 00:07:03,800
if we could even get like a 
GitHub user whose ID is a super 

113
00:07:03,800 --> 00:07:07,080
string of like an approved 
maintainer ID, right? 

114
00:07:07,920 --> 00:07:12,640
So that got us to look into, you
know, how even GitHub IDs are 

115
00:07:12,720 --> 00:07:16,680
distributed and it turns out 
that they are just a sequential 

116
00:07:16,760 --> 00:07:20,280
like list. 
So the first GitHub user has ID 

117
00:07:20,280 --> 00:07:27,280
one, then like in 2015 IDs have 
like 4 digits, then in 220 they 

118
00:07:27,320 --> 00:07:31,520
put balloon to like 7 digits and
today they are already at the 9 

119
00:07:31,520 --> 00:07:33,320
digits. 
What did you do next? 

120
00:07:33,360 --> 00:07:36,680
You figured this out and then. 
And then we had a lot of luck 

121
00:07:36,880 --> 00:07:42,880
because AWS actually employs 
really I would say early GitHub 

122
00:07:42,880 --> 00:07:45,640
users. 
So their ideas were kind of 

123
00:07:45,680 --> 00:07:50,360
relatively short. 
They had like 6 or 7 seven digit

124
00:07:50,360 --> 00:07:53,080
ideas. 
So that meant that right now, 

125
00:07:53,080 --> 00:07:56,280
because they are already 9 digit
ideas, we could actually find 

126
00:07:56,280 --> 00:08:00,840
that ID that is like a super 
string like contains the idea of

127
00:08:00,840 --> 00:08:03,680
an approved the maintainer. 
Oh, interesting. 

128
00:08:03,880 --> 00:08:06,880
Yeah, yeah. 
So how did you action this? 

129
00:08:06,880 --> 00:08:09,760
What did you do? 
So we we needed to claim an ID 

130
00:08:09,760 --> 00:08:14,000
that actually contains the the 
smaller ID like the approved ID.

131
00:08:14,000 --> 00:08:15,800
We know that those ideas are out
there. 

132
00:08:16,040 --> 00:08:21,000
The thing is that GitHub creates
like 200,000 users every day, 

133
00:08:21,360 --> 00:08:24,480
right? 
So it's kind of how to get a 

134
00:08:24,480 --> 00:08:28,560
specific ID because a lot of 
users are being created all the 

135
00:08:28,560 --> 00:08:30,920
time, right? 
So we needed a way to like 

136
00:08:31,040 --> 00:08:36,159
automatically create a lot of 
users in an like in a second so 

137
00:08:36,159 --> 00:08:38,840
we can catch the idea that we 
want, right? 

138
00:08:38,840 --> 00:08:41,799
We had the target idea that we 
want to catch and we wanted to, 

139
00:08:41,799 --> 00:08:44,560
when we see that this is the 
idea is about to come up, it's 

140
00:08:44,560 --> 00:08:47,840
about to be created. 
We wanted to just create a flood

141
00:08:47,840 --> 00:08:52,960
of new users and we found a way 
to do that using a GitHub apps. 

142
00:08:53,560 --> 00:08:56,360
It turns out that when you 
register an app, it also creates

143
00:08:56,360 --> 00:08:59,680
like a bot user. 
So when we did that, we're 

144
00:08:59,680 --> 00:09:04,400
actually able to create a lot of
GitHub apps very quickly, and 

145
00:09:04,400 --> 00:09:07,040
that allowed us to create a 
flood of new users and actually 

146
00:09:07,040 --> 00:09:12,280
claim an ID that was a super 
string of an approved maintainer

147
00:09:12,280 --> 00:09:15,040
ID. 
Could you use this to like for 

148
00:09:15,040 --> 00:09:18,000
other reasons? 
Like let's say you really want a

149
00:09:18,000 --> 00:09:21,040
specific ID number like a vanity
license plate. 

150
00:09:21,480 --> 00:09:23,160
Like could that could the same 
technique be about? 

151
00:09:23,960 --> 00:09:26,680
I love Eden, yeah. 
You could, you could definitely 

152
00:09:26,680 --> 00:09:30,120
do something like that. 
I don't know if Gitab will patch

153
00:09:30,120 --> 00:09:32,520
it soon, but as of right now you
can do that, yeah. 

154
00:09:33,480 --> 00:09:35,120
You should buy them while 
they're hot, while they're 

155
00:09:35,120 --> 00:09:36,440
still, while it's still 
possible. 

156
00:09:37,320 --> 00:09:39,720
Yeah. 
OK, So tell us about, let's call

157
00:09:39,720 --> 00:09:43,200
it D-Day, the day that you you 
ran the script to actually to do

158
00:09:43,200 --> 00:09:44,960
this in the flesh. 
What happened? 

159
00:09:45,080 --> 00:09:47,800
What did you have for breakfast?
How'd you run the script? 

160
00:09:47,800 --> 00:09:51,600
How long did it take? 
Yeah, so we actually, there were

161
00:09:52,160 --> 00:09:54,120
two D days. 
We were like preparing 

162
00:09:54,120 --> 00:09:57,760
everything and then it was 
already like 8 in the evening 

163
00:09:57,840 --> 00:10:00,640
and we near we looked each other
in the eyes and we're like, OK, 

164
00:10:00,640 --> 00:10:02,360
we're not let's not do an all 
nighter. 

165
00:10:02,360 --> 00:10:05,160
Let's just go to sleep and do it
fresh in the morning. 

166
00:10:05,160 --> 00:10:08,600
So we came fresh in the morning 
and we we chose a target. 

167
00:10:08,600 --> 00:10:12,400
The target was the AWSSDK for 
JavaScript. 

168
00:10:12,400 --> 00:10:15,960
It was one of the, you know, 
affected the repositories that 

169
00:10:15,960 --> 00:10:19,040
had this vulnerable actor ID 
filter. 

170
00:10:19,640 --> 00:10:24,760
So we we created a demo 
environment first, but when we 

171
00:10:24,760 --> 00:10:30,320
actually did it, it was 
definitely nerve racking and it 

172
00:10:30,320 --> 00:10:34,040
actually took much more time 
than we expected because they 

173
00:10:34,040 --> 00:10:37,280
use like a huge machine for 
their build with like, I don't 

174
00:10:37,280 --> 00:10:42,720
know, 70 CPUs and huge memory. 
So everything was so slow, which

175
00:10:42,720 --> 00:10:47,800
really added to the to the 
pressure, I would say. 

176
00:10:48,120 --> 00:10:51,840
But after we submitted the PR 
from the user that we created 

177
00:10:51,840 --> 00:10:55,240
that had the correct ID that 
could bypass the filter, it 

178
00:10:55,240 --> 00:10:57,480
worked. 
We got the GitHub token from the

179
00:10:57,480 --> 00:11:00,320
build environment. 
We checked its permission. 

180
00:11:00,320 --> 00:11:04,280
It was quite a powerful user. 
It was basically, it was 

181
00:11:04,280 --> 00:11:06,160
basically an admin of the 
repository. 

182
00:11:06,800 --> 00:11:10,440
And that was, you know, we, we 
expected it to happen, but it 

183
00:11:10,440 --> 00:11:12,040
was still definitely quite 
shocking. 

184
00:11:12,960 --> 00:11:14,520
So what could an attacker have 
done with this? 

185
00:11:14,520 --> 00:11:20,440
Like if, if, if the evil Yuval 
somewhere in Russia, let's say, 

186
00:11:21,880 --> 00:11:25,560
would have would have brought 
this to his boss, the evil near 

187
00:11:26,240 --> 00:11:28,600
and decided to pursue this. 
What? 

188
00:11:28,600 --> 00:11:31,120
What could they have done with? 
This a lot actually because this

189
00:11:31,120 --> 00:11:34,960
specifically this repository. 
We chose it because we thought 

190
00:11:35,200 --> 00:11:39,360
it really demonstrated the 
impact because it is present in 

191
00:11:39,360 --> 00:11:43,800
our based on our analysis in 
like 2/3 of cloud environments, 

192
00:11:43,840 --> 00:11:48,600
it is heavily used this SDK and 
one of its user is actually the 

193
00:11:48,600 --> 00:11:51,640
AWS console. 
So this code in this repository 

194
00:11:51,640 --> 00:11:56,400
runs inside database console, 
which is basically the brain of 

195
00:11:56,720 --> 00:12:00,000
like the entire AWS cloud. 
Every user uses it. 

196
00:12:00,360 --> 00:12:03,600
So if you manage to use this 
admin privileges of the 

197
00:12:03,600 --> 00:12:08,400
repository to push, you know, 
malicious code that could 

198
00:12:08,400 --> 00:12:12,080
potentially end up in like 
1,000,000 of AWS consoles, which

199
00:12:12,080 --> 00:12:15,760
is quite scary. 
And it's not, you know, we 

200
00:12:15,760 --> 00:12:18,560
obviously decided not to do 
that, not to do like a POC of 

201
00:12:18,560 --> 00:12:21,360
that because we were like, we 
didn't want to touch something 

202
00:12:21,360 --> 00:12:23,200
that. 
Because you're the good you are.

203
00:12:23,320 --> 00:12:24,520
You're not. 
You're not the evil you are. 

204
00:12:24,760 --> 00:12:29,000
Yeah, definitely. 
But it's not like only a 

205
00:12:29,000 --> 00:12:32,440
theoretical attack because just 
a month before we saw like the 

206
00:12:32,480 --> 00:12:34,600
the attack that we discussed at 
the beginning that someone 

207
00:12:34,600 --> 00:12:38,160
actually did that and managed to
get his payload to end users. 

208
00:12:38,400 --> 00:12:41,320
So we know this is actually 
something that, you know, it 

209
00:12:41,320 --> 00:12:44,840
could work. 
So we're really happy that we we

210
00:12:44,840 --> 00:12:48,840
found it in time and we were 
able to get it this close to 

211
00:12:49,040 --> 00:12:51,160
AWS. 
But let's say right now, first 

212
00:12:51,160 --> 00:12:53,000
of all, it's super cool, but 
let's say right now you're an 

213
00:12:53,520 --> 00:12:55,640
AWS customer, which likely you 
are. 

214
00:12:55,880 --> 00:12:57,680
Do you need to be concerned 
about this? 

215
00:12:57,680 --> 00:13:00,680
Like AWS is using their SDK also
internally. 

216
00:13:00,680 --> 00:13:04,200
So what's the impact on any 
given AWS user? 

217
00:13:04,480 --> 00:13:07,880
It could have been massive, but 
thankfully AWS patched it. 

218
00:13:07,880 --> 00:13:12,520
It's no longer an issue so right
now you shouldn't be concerned. 

219
00:13:12,520 --> 00:13:17,160
I I'd say you could like if you 
are using AWS code build, there 

220
00:13:17,160 --> 00:13:19,960
are definitely lessons here for 
you as well because AWS series 

221
00:13:19,960 --> 00:13:24,280
basically a user of AWS code 
build with, you know a big 

222
00:13:24,400 --> 00:13:27,120
misconfiguration or flaw. 
So the misconfiguration is still

223
00:13:27,120 --> 00:13:30,440
possible, like someone else 
could make the same mistake 

224
00:13:30,440 --> 00:13:33,080
again tomorrow. 
Yep, Yep, definitely. 

225
00:13:33,080 --> 00:13:37,680
But it's AWS released actually 
some features now that make it 

226
00:13:37,880 --> 00:13:44,760
easier to like make sure only 
approve maintenance are able to 

227
00:13:44,760 --> 00:13:48,200
create the builds. 
So there are actually new 

228
00:13:48,200 --> 00:13:52,200
improvements that AWS introduced
as a response to that original 

229
00:13:52,200 --> 00:13:54,960
attack that allow you to not be 
able. 

230
00:13:55,080 --> 00:13:57,640
You don't need to maintain a 
list anymore, right? 

231
00:13:58,240 --> 00:14:00,240
You just you just need to enable
it. 

232
00:14:00,240 --> 00:14:06,000
And AWS behind the scenes checks
the permission of the user that 

233
00:14:06,000 --> 00:14:10,000
created the PR and if he has an 
appropriate permission like, you

234
00:14:10,000 --> 00:14:12,080
can see that he's the owner of 
the repository. 

235
00:14:12,360 --> 00:14:15,520
Only then a build will be 
triggered. 

236
00:14:15,800 --> 00:14:18,600
But The thing is that this is 
only for a new code build 

237
00:14:18,600 --> 00:14:20,520
projects. 
This is only enabled by default 

238
00:14:20,520 --> 00:14:23,720
for new code build projects. 
And so if you have an existing 

239
00:14:23,720 --> 00:14:26,680
1, you should really like. 
It's also the biggest 

240
00:14:26,680 --> 00:14:28,960
recommendation in the blog post.
You should definitely enable 

241
00:14:28,960 --> 00:14:30,440
this feature, it's super 
important. 

242
00:14:30,760 --> 00:14:34,800
What would be the equivalent 
here in in other platforms? 

243
00:14:34,800 --> 00:14:35,960
Similar to code build? 
Like? 

244
00:14:36,240 --> 00:14:41,760
Is it likely that their 
customers have of other of other

245
00:14:41,760 --> 00:14:44,200
competing platforms might need 
to be worried about this sort of

246
00:14:44,200 --> 00:14:46,400
thing as well? 
I think it's relevant in 

247
00:14:46,440 --> 00:14:50,920
anywhere that you have like an 
external CI system to where your

248
00:14:51,240 --> 00:14:55,040
source code is. 
So because a lot of time that CI

249
00:14:55,040 --> 00:15:00,000
system needs to be able to 
interact back to the source 

250
00:15:00,000 --> 00:15:02,320
depository. 
So normally GitHub, but it could

251
00:15:02,320 --> 00:15:05,920
be GitLab would be bucket or any
of those platforms and it needs 

252
00:15:05,920 --> 00:15:09,160
to like report it. 
It needs a token to report back 

253
00:15:09,160 --> 00:15:13,320
what happens in the build, and 
it's the job of the underlying 

254
00:15:13,320 --> 00:15:17,400
CI system to make sure that that
token, if possible, isn't 

255
00:15:17,400 --> 00:15:20,520
exposed to build and that by 
default it doesn't have a lot of

256
00:15:20,520 --> 00:15:22,640
permission. 
A few months ago there was 

257
00:15:23,480 --> 00:15:27,680
another issue in a cold rabbit, 
I think that was pretty severe 

258
00:15:27,680 --> 00:15:31,080
that had something to do similar
to that where the credentials 

259
00:15:31,080 --> 00:15:34,520
were in the build. 
So it's definitely important to 

260
00:15:34,520 --> 00:15:39,360
make sure the permit, the token,
the privileges that you give 

261
00:15:39,360 --> 00:15:43,680
your CI system over the source 
code are limited. 

262
00:15:43,880 --> 00:15:46,000
Yeah, we. 
Worked closely with Amazon 

263
00:15:46,000 --> 00:15:48,680
around the disclosure, 
obviously. 

264
00:15:48,680 --> 00:15:51,040
What was that like? 
Oh, they were great. 

265
00:15:51,160 --> 00:15:54,320
They actually fixed it I think 
in less than. 

266
00:15:54,880 --> 00:15:59,240
I don't know if it was 24 or 48 
hours, but they immediately 

267
00:15:59,240 --> 00:16:03,880
disabled the projects and then 
introduced the fixes. 

268
00:16:03,880 --> 00:16:06,480
And also they made this, you 
know, amazing feature, which is 

269
00:16:06,640 --> 00:16:09,920
a much, much easier to use. 
So everyone can actually benefit

270
00:16:10,400 --> 00:16:16,600
from a better, you know, better 
configuration for COVID. 

271
00:16:16,840 --> 00:16:18,840
OK. 
Anything else you want to impart

272
00:16:19,080 --> 00:16:21,400
to people about this 
vulnerability? 

273
00:16:21,400 --> 00:16:26,080
Anything else they should know? 
I think the really the lesson is

274
00:16:26,080 --> 00:16:31,440
that you should never have built
with privileged permissions that

275
00:16:31,440 --> 00:16:34,240
can be triggered from external 
pull request. 

276
00:16:34,280 --> 00:16:37,120
This is like the first. 
There are a lot of improvements 

277
00:16:37,120 --> 00:16:41,000
that you can make to your CICD 
system defenses, but this is 

278
00:16:41,000 --> 00:16:45,520
like #1 you shouldn't allow 
external users to be able to 

279
00:16:45,520 --> 00:16:47,120
trigger bills in your 
environment. 

280
00:16:47,120 --> 00:16:49,920
That's like the most important 
thing and the most important 

281
00:16:49,920 --> 00:16:52,120
lesson. 
We should print that with our 

282
00:16:52,120 --> 00:16:54,320
title. 
Yuval, Congrats. 

283
00:16:54,320 --> 00:16:57,040
This is super cool and thank you
for explaining it to people. 

284
00:16:57,240 --> 00:16:59,720
Even I understood it, which 
means I think everyone can 

285
00:16:59,720 --> 00:17:03,240
understand it. 
Yeah, have a good one. 

286
00:17:03,280 --> 00:17:06,520
If you enjoy the show, be sure 
to subscribe and share a link to

287
00:17:06,520 --> 00:17:09,000
the podcast, but not your cloud 
keys. 

288
00:17:09,079 --> 00:17:12,599
And as always, if your cloud 
security strategy is making you 

289
00:17:12,599 --> 00:17:14,880
cry, don't worry. 
Just go out.