1
00:00:00,880 --> 00:00:04,799
so for our next speaker we have Roan Ral

2
00:00:04,799 --> 00:00:06,600
he's a security researcher at Tinder

3
00:00:06,600 --> 00:00:08,880
security Labs he's got s 7 years of

4
00:00:08,880 --> 00:00:10,639
experience identifying vulnerabilities

5
00:00:10,639 --> 00:00:13,440
in open source SAS and Cloud

6
00:00:13,440 --> 00:00:15,759
environments ran has previously

7
00:00:15,759 --> 00:00:17,279
presented his research at conferences

8
00:00:17,279 --> 00:00:20,800
like bsides SF uh the Recon Village uh

9
00:00:20,800 --> 00:00:23,320
defon 30 and in more places today he'll

10
00:00:23,320 --> 00:00:24,840
be going over common vulnerabilities in

11
00:00:24,840 --> 00:00:27,359
gcp Firebase uh with some sample case

12
00:00:27,359 --> 00:00:29,240
studies affecting small and large

13
00:00:29,240 --> 00:00:31,240
organizations so please give a warm

14
00:00:31,240 --> 00:00:33,879
welcome for our

15
00:00:33,879 --> 00:00:37,000
job thank

16
00:00:37,000 --> 00:00:39,879
you all right thank you everyone um yeah

17
00:00:39,879 --> 00:00:42,000
so my name is Rosen uh part of tender

18
00:00:42,000 --> 00:00:44,680
security Labs today I'm going to talk

19
00:00:44,680 --> 00:00:46,879
about identifying and securing firest

20
00:00:46,879 --> 00:00:49,000
Vern abilities at scale it is a

21
00:00:49,000 --> 00:00:50,920
25-minute talk so we're not going to go

22
00:00:50,920 --> 00:00:52,680
fully into details it's more of a high

23
00:00:52,680 --> 00:00:54,719
level looking at some API calls that you

24
00:00:54,719 --> 00:00:56,719
can use to create monitoring and whatnot

25
00:00:56,719 --> 00:00:58,840
and also some of our at scale research

26
00:00:58,840 --> 00:01:01,760
with that uh the first thing is firee is

27
00:01:01,760 --> 00:01:04,239
Big there is a lot of features on it for

28
00:01:04,239 --> 00:01:05,920
this specific talk we only looked at

29
00:01:05,920 --> 00:01:07,880
three features so you'll only be seeing

30
00:01:07,880 --> 00:01:10,040
mention of those three uh first one

31
00:01:10,040 --> 00:01:12,600
being firest o which if we kind of

32
00:01:12,600 --> 00:01:15,320
create a comparison with AWS it's

33
00:01:15,320 --> 00:01:17,720
similar to awas Cognito it has various

34
00:01:17,720 --> 00:01:19,720
social provider logins Google Facebook

35
00:01:19,720 --> 00:01:21,880
all of that sorts but then you also have

36
00:01:21,880 --> 00:01:23,720
other features within Firebase like fir

37
00:01:23,720 --> 00:01:25,840
store which their no SQL document

38
00:01:25,840 --> 00:01:28,479
database now if we go back and compare

39
00:01:28,479 --> 00:01:31,000
that with AWS again that's similar to

40
00:01:31,000 --> 00:01:33,799
Dynamo DV there and then finally

41
00:01:33,799 --> 00:01:35,960
Firebase storage which is also similar

42
00:01:35,960 --> 00:01:38,600
if we go back to AWS to S3 buckets uh

43
00:01:38,600 --> 00:01:41,560
gcp has its own fire or own storage

44
00:01:41,560 --> 00:01:43,520
functionality fire also has same

45
00:01:43,520 --> 00:01:46,240
functionality attached to it but it also

46
00:01:46,240 --> 00:01:48,759
carries over fire o so the reason we

47
00:01:48,759 --> 00:01:50,719
looked at these three features starting

48
00:01:50,719 --> 00:01:52,680
with o is because if we can find

49
00:01:52,680 --> 00:01:54,600
something with O A configuration issue

50
00:01:54,600 --> 00:01:56,960
or whatnot it can then impact fire V

51
00:01:56,960 --> 00:01:59,159
storage or fire store there as well when

52
00:01:59,159 --> 00:02:00,640
you go and look look for vulnerabilities

53
00:02:00,640 --> 00:02:03,479
or configuration issues there um for our

54
00:02:03,479 --> 00:02:05,479
research itself we had kind of broke it

55
00:02:05,479 --> 00:02:07,399
down to three different path of trying

56
00:02:07,399 --> 00:02:08,878
to find out vulnerabilities in

57
00:02:08,878 --> 00:02:10,758
configurations the first one was

58
00:02:10,758 --> 00:02:12,640
manually testing creating our own vable

59
00:02:12,640 --> 00:02:14,959
cases kind of a Sandbox environment

60
00:02:14,959 --> 00:02:16,959
mainly to get an idea of how fire vase

61
00:02:16,959 --> 00:02:19,440
operates if we're going to hit an API

62
00:02:19,440 --> 00:02:21,959
and detect if it's going to be Vernal or

63
00:02:21,959 --> 00:02:24,000
if it's going to return some kind of a

64
00:02:24,000 --> 00:02:25,760
metadata there how do we identify if

65
00:02:25,760 --> 00:02:27,319
it's a varability or something like a

66
00:02:27,319 --> 00:02:29,200
false positive that's where the manual

67
00:02:29,200 --> 00:02:30,879
testing came we created some Vernal

68
00:02:30,879 --> 00:02:33,440
examples targeted specific organizations

69
00:02:33,440 --> 00:02:36,040
that we knew used fireb so we could take

70
00:02:36,040 --> 00:02:37,720
it to kind of like a real life scenario

71
00:02:37,720 --> 00:02:40,640
and then go from there for example cases

72
00:02:40,640 --> 00:02:42,200
and then our second step was to look

73
00:02:42,200 --> 00:02:44,120
through Source graph uh which basically

74
00:02:44,120 --> 00:02:46,319
indexes a lot of GitHub reposts specific

75
00:02:46,319 --> 00:02:48,599
popular or most uh common ones or ones

76
00:02:48,599 --> 00:02:50,560
that have a lot of activities on from

77
00:02:50,560 --> 00:02:52,800
there we're pulling about 15 to 20,000

78
00:02:52,800 --> 00:02:54,760
repos looking through them to find

79
00:02:54,760 --> 00:02:57,000
firest API Keys we'll see a couple of

80
00:02:57,000 --> 00:02:58,360
stats on those at the end of the

81
00:02:58,360 --> 00:03:00,080
presentation as well of what we we found

82
00:03:00,080 --> 00:03:02,599
with those and then finally we explored

83
00:03:02,599 --> 00:03:04,519
with common crawl which basically scans

84
00:03:04,519 --> 00:03:07,280
a lot of websites uh by following the

85
00:03:07,280 --> 00:03:10,080
robots.txt it then contains and stores

86
00:03:10,080 --> 00:03:12,799
their stml responses and request so our

87
00:03:12,799 --> 00:03:14,319
goal was to see if we can find something

88
00:03:14,319 --> 00:03:16,480
there with like fireb API Keys use that

89
00:03:16,480 --> 00:03:18,120
to get an idea of how many companies

90
00:03:18,120 --> 00:03:19,879
could be impacted what does it look like

91
00:03:19,879 --> 00:03:21,879
when we look at in the worldwide web in

92
00:03:21,879 --> 00:03:24,120
a sense creditwise I do want to give a

93
00:03:24,120 --> 00:03:27,400
shout out to a talk by Andres Rancho in

94
00:03:27,400 --> 00:03:29,959
black hat few years back he t h did the

95
00:03:29,959 --> 00:03:32,120
same approach with ads Cognito that kind

96
00:03:32,120 --> 00:03:34,439
of also influenced this is seeing the

97
00:03:34,439 --> 00:03:36,400
level of research there with ads Cognito

98
00:03:36,400 --> 00:03:38,040
we wanted to see how it'll look like

99
00:03:38,040 --> 00:03:39,760
with Firebase and that's where all of

100
00:03:39,760 --> 00:03:40,720
this came

101
00:03:40,720 --> 00:03:43,280
in to start with the first one that

102
00:03:43,280 --> 00:03:45,159
we're going to look at is Firebase o

103
00:03:45,159 --> 00:03:47,040
which again as I mentioned has a lot of

104
00:03:47,040 --> 00:03:49,560
different login providers to it you have

105
00:03:49,560 --> 00:03:51,239
your email and password you have your

106
00:03:51,239 --> 00:03:52,959
social providers which would be things

107
00:03:52,959 --> 00:03:56,439
like Google Twitter um and Facebook but

108
00:03:56,439 --> 00:03:58,280
then also it has similar as I mentioned

109
00:03:58,280 --> 00:04:00,680
before similar to a cogni and one of the

110
00:04:00,680 --> 00:04:03,000
key feature on there that also parallels

111
00:04:03,000 --> 00:04:05,599
to AWS is being able to log in

112
00:04:05,599 --> 00:04:08,239
anonymously now if you look at Incognito

113
00:04:08,239 --> 00:04:10,239
if you are able to do that you usually

114
00:04:10,239 --> 00:04:12,640
can pull IM IM credentials which can

115
00:04:12,640 --> 00:04:14,400
then be utilized to potentially gain

116
00:04:14,400 --> 00:04:16,399
access to some form of adus resources

117
00:04:16,399 --> 00:04:19,959
for that work but in gcp or in Firebase

118
00:04:19,959 --> 00:04:22,240
having the anonymous user can then also

119
00:04:22,240 --> 00:04:24,000
give you the access token for just that

120
00:04:24,000 --> 00:04:26,080
Anonymous user which we can further use

121
00:04:26,080 --> 00:04:28,080
for any kind of login activities and

122
00:04:28,080 --> 00:04:31,599
then try to get access to fire stor

123
00:04:32,120 --> 00:04:34,160
if we take a example request with just

124
00:04:34,160 --> 00:04:36,400
how o works with firebases if you use

125
00:04:36,400 --> 00:04:39,240
the identity toolkit API it will take in

126
00:04:39,240 --> 00:04:41,039
a username and a password and you can

127
00:04:41,039 --> 00:04:43,280
also pass in a Boolean return secure

128
00:04:43,280 --> 00:04:45,360
token if you mark it as true it will

129
00:04:45,360 --> 00:04:47,840
return the access token for that user

130
00:04:47,840 --> 00:04:49,919
but if the anonymous feature is enabled

131
00:04:49,919 --> 00:04:52,440
on this account you can then also send a

132
00:04:52,440 --> 00:04:54,639
request without email and password which

133
00:04:54,639 --> 00:04:56,199
will then return the access token just

134
00:04:56,199 --> 00:04:58,479
for the anonymous user which we then use

135
00:04:58,479 --> 00:05:00,280
later on for any kind kind of like fire

136
00:05:00,280 --> 00:05:01,160
store

137
00:05:01,160 --> 00:05:03,240
vulnerabilities moving on just carrying

138
00:05:03,240 --> 00:05:05,639
it over to a fire store it is basically

139
00:05:05,639 --> 00:05:08,160
document DV as I said has R API and

140
00:05:08,160 --> 00:05:09,479
that's where the authentication things

141
00:05:09,479 --> 00:05:12,320
come in mind is you can basically send a

142
00:05:12,320 --> 00:05:15,320
regular request to the fir store API uh

143
00:05:15,320 --> 00:05:17,320
with your project name which in this

144
00:05:17,320 --> 00:05:20,440
case is test triple1 cd14 and then the

145
00:05:20,440 --> 00:05:21,840
collection name which in this case is

146
00:05:21,840 --> 00:05:24,039
users if it is Vernal you'll be able to

147
00:05:24,039 --> 00:05:26,000
see data if not you won't be able to so

148
00:05:26,000 --> 00:05:28,720
if we did dive further a sample Vernal

149
00:05:28,720 --> 00:05:30,479
rule that is pretty common in a lot of

150
00:05:30,479 --> 00:05:33,360
fire store cases where it's Vernal would

151
00:05:33,360 --> 00:05:34,919
be something like this where it

152
00:05:34,919 --> 00:05:37,520
basically says match any document or

153
00:05:37,520 --> 00:05:40,039
Collections and give it read WR access

154
00:05:40,039 --> 00:05:42,360
if by setting the if true now this is

155
00:05:42,360 --> 00:05:44,520
also the default configuration there if

156
00:05:44,520 --> 00:05:47,440
you deploy it on development environment

157
00:05:47,440 --> 00:05:49,720
uh a or Google has development and

158
00:05:49,720 --> 00:05:51,600
production environment that you can set

159
00:05:51,600 --> 00:05:53,319
if you set development by default this

160
00:05:53,319 --> 00:05:55,520
configuration will be used Google has

161
00:05:55,520 --> 00:05:57,560
added a security rule where after 30

162
00:05:57,560 --> 00:05:59,000
days your production it will just

163
00:05:59,000 --> 00:06:01,080
automatically switch to production so if

164
00:06:01,080 --> 00:06:02,639
companies do misconfigure it they will

165
00:06:02,639 --> 00:06:04,440
be Vernal for 30 days and then it will

166
00:06:04,440 --> 00:06:06,240
go to production but they can go and

167
00:06:06,240 --> 00:06:08,960
revert that fixes the other really

168
00:06:08,960 --> 00:06:11,039
common rule that we have seen is setting

169
00:06:11,039 --> 00:06:13,680
specific rules per collections so if we

170
00:06:13,680 --> 00:06:15,800
look at example of this the first rule

171
00:06:15,800 --> 00:06:18,280
says if a user is authenticated then

172
00:06:18,280 --> 00:06:19,880
only let them see and write to the

173
00:06:19,880 --> 00:06:22,440
user's collection but if they are not

174
00:06:22,440 --> 00:06:24,720
then do not give them access but if we

175
00:06:24,720 --> 00:06:26,360
go to the second one it says for the

176
00:06:26,360 --> 00:06:28,319
organizations collection they should be

177
00:06:28,319 --> 00:06:30,240
able to read write access regardless of

178
00:06:30,240 --> 00:06:32,280
that and this is actually pretty common

179
00:06:32,280 --> 00:06:34,120
from what we have seen it is hard to

180
00:06:34,120 --> 00:06:35,759
detect this when you're doing blackbox

181
00:06:35,759 --> 00:06:37,639
cuz you'll usually see access Deni most

182
00:06:37,639 --> 00:06:39,120
of the time unless you find the right

183
00:06:39,120 --> 00:06:41,280
collection that's burnable to it uh but

184
00:06:41,280 --> 00:06:43,240
there are some ways to automate those as

185
00:06:43,240 --> 00:06:46,080
well by just brof forcing them now if

186
00:06:46,080 --> 00:06:47,520
we'll just look at the request and

187
00:06:47,520 --> 00:06:49,160
response of if you want to detect it at

188
00:06:49,160 --> 00:06:51,440
scale or just API wise and kind of get

189
00:06:51,440 --> 00:06:53,440
an idea of like okay why when is this

190
00:06:53,440 --> 00:06:55,720
Vernal the first one to look at is by

191
00:06:55,720 --> 00:06:58,280
passing just a non-existing collection

192
00:06:58,280 --> 00:07:00,720
so if you hit the fire store API with a

193
00:07:00,720 --> 00:07:02,639
collection that you know does not exist

194
00:07:02,639 --> 00:07:04,440
on that database or in fir store

195
00:07:04,440 --> 00:07:06,080
database in general for that

196
00:07:06,080 --> 00:07:08,160
organization and if it returns an empty

197
00:07:08,160 --> 00:07:10,440
structure that basically means that

198
00:07:10,440 --> 00:07:12,919
there's a rule that says any document

199
00:07:12,919 --> 00:07:14,800
should be accessible to any users

200
00:07:14,800 --> 00:07:16,680
regardless of their authentication so

201
00:07:16,680 --> 00:07:18,599
even if they are not authenticated give

202
00:07:18,599 --> 00:07:21,199
them access to the database in another

203
00:07:21,199 --> 00:07:22,680
situation like the other rule that we

204
00:07:22,680 --> 00:07:24,840
saw you will see things like the users's

205
00:07:24,840 --> 00:07:27,120
collection will return access denied say

206
00:07:27,120 --> 00:07:28,680
you are missing permissions you won't be

207
00:07:28,680 --> 00:07:30,879
able to do much activities there but

208
00:07:30,879 --> 00:07:32,680
then when you hit the organizations

209
00:07:32,680 --> 00:07:34,240
collection so if you brute force and

210
00:07:34,240 --> 00:07:36,240
find the right collection you'll be able

211
00:07:36,240 --> 00:07:38,440
to get access to the

212
00:07:38,440 --> 00:07:40,680
database but there's also a catch with

213
00:07:40,680 --> 00:07:42,680
that if you looked at the previous rule

214
00:07:42,680 --> 00:07:44,919
when we go back you'll see that it has

215
00:07:44,919 --> 00:07:47,440
request. o is not equal to null so it's

216
00:07:47,440 --> 00:07:49,479
not checking if the user has certain

217
00:07:49,479 --> 00:07:51,800
permissions all it is checking is if the

218
00:07:51,800 --> 00:07:53,960
user is authenticated and if the

219
00:07:53,960 --> 00:07:55,720
organization now has sign up or

220
00:07:55,720 --> 00:07:57,759
Anonymous sign up enabled you can

221
00:07:57,759 --> 00:08:01,360
basically send a anonymous login request

222
00:08:01,360 --> 00:08:02,639
which will then give you the access

223
00:08:02,639 --> 00:08:04,599
token you can then use the access token

224
00:08:04,599 --> 00:08:07,479
further to exchange it and get the users

225
00:08:07,479 --> 00:08:09,319
uh collection there as well and this was

226
00:08:09,319 --> 00:08:11,560
also really common in a lot of uh test

227
00:08:11,560 --> 00:08:13,560
cases that we saw where they were using

228
00:08:13,560 --> 00:08:15,360
settings where if you were able to just

229
00:08:15,360 --> 00:08:17,479
pass in an anonymous users token you're

230
00:08:17,479 --> 00:08:19,159
able to access the entire database there

231
00:08:19,159 --> 00:08:20,240
as

232
00:08:20,240 --> 00:08:22,759
well similar settings will exist with

233
00:08:22,759 --> 00:08:24,800
fire storage as well which is basically

234
00:08:24,800 --> 00:08:27,840
S3 buckets uh you can set allow read you

235
00:08:27,840 --> 00:08:29,759
will see again it has the if request at

236
00:08:29,759 --> 00:08:32,399
o not equals null if it's not null let

237
00:08:32,399 --> 00:08:35,440
the user access it in most uh onof cases

238
00:08:35,440 --> 00:08:36,880
you'll basically be able to list all the

239
00:08:36,880 --> 00:08:39,120
objects and then go through each object

240
00:08:39,120 --> 00:08:40,880
and get access to their uh specific

241
00:08:40,880 --> 00:08:43,599
contents there hitting it is as simple

242
00:08:43,599 --> 00:08:45,320
as just hitting firest storage Google

243
00:08:45,320 --> 00:08:48,080
API you do have to pass in the project

244
00:08:48,080 --> 00:08:50,959
name appspot.com and then list all the

245
00:08:50,959 --> 00:08:52,959
objects from there you can then access

246
00:08:52,959 --> 00:08:55,760
all the objects if it's FAL um in case

247
00:08:55,760 --> 00:08:58,240
where there's uh or authenticated access

248
00:08:58,240 --> 00:08:59,760
will give you access to but if it's

249
00:08:59,760 --> 00:09:01,600
Vernal it will give you the content of

250
00:09:01,600 --> 00:09:02,480
that

251
00:09:02,480 --> 00:09:05,320
bucket now going back to risto same

252
00:09:05,320 --> 00:09:07,880
issue if they were using risto is not

253
00:09:07,880 --> 00:09:09,680
equals to null you can again extend the

254
00:09:09,680 --> 00:09:11,880
access token and then get access to the

255
00:09:11,880 --> 00:09:13,959
collection of the bucket but now we

256
00:09:13,959 --> 00:09:15,560
wanted to automate this so we have an

257
00:09:15,560 --> 00:09:17,399
idea that this is how it works these are

258
00:09:17,399 --> 00:09:19,519
the responses how do we automate how do

259
00:09:19,519 --> 00:09:21,600
we break it apart and start scanning at

260
00:09:21,600 --> 00:09:24,760
scale with it so the first step we used

261
00:09:24,760 --> 00:09:26,519
by is by breaking it down into three

262
00:09:26,519 --> 00:09:29,240
steps of the script uh process one is

263
00:09:29,240 --> 00:09:31,600
identifying the API type if you have

264
00:09:31,600 --> 00:09:33,399
used Google API before you will know

265
00:09:33,399 --> 00:09:35,920
that not like it follows the same API

266
00:09:35,920 --> 00:09:37,959
design resx wise but not everything is

267
00:09:37,959 --> 00:09:39,720
using virus it could be a Google Maps

268
00:09:39,720 --> 00:09:41,720
API key and we don't want to Brute Force

269
00:09:41,720 --> 00:09:43,160
any scan with that if it's not going to

270
00:09:43,160 --> 00:09:45,920
yield any result that's where we use um

271
00:09:45,920 --> 00:09:48,000
identity toolkit as a way to kind of

272
00:09:48,000 --> 00:09:49,720
design like okay if it's using identity

273
00:09:49,720 --> 00:09:51,600
toolkit there's a chance it's using more

274
00:09:51,600 --> 00:09:53,279
of Firebase so we can go and explore

275
00:09:53,279 --> 00:09:55,800
further with that next was scanning fire

276
00:09:55,800 --> 00:09:57,519
store with three different checks is

277
00:09:57,519 --> 00:09:59,240
first check can we access his

278
00:09:59,240 --> 00:10:01,240
unauthenticated second if it gives us

279
00:10:01,240 --> 00:10:03,320
authentication issue can we access that

280
00:10:03,320 --> 00:10:04,800
with the anonymous login if that's

281
00:10:04,800 --> 00:10:06,399
enabled and the third case was just

282
00:10:06,399 --> 00:10:08,079
brute forcing with common collection

283
00:10:08,079 --> 00:10:11,079
names like users profile user account

284
00:10:11,079 --> 00:10:13,640
attachments all of that and then finally

285
00:10:13,640 --> 00:10:15,560
Looking Through Fire storage which will

286
00:10:15,560 --> 00:10:17,640
then allow us to view uh any kind of

287
00:10:17,640 --> 00:10:19,720
bucket instances and same rule applies

288
00:10:19,720 --> 00:10:21,680
there if it is on off we'll be able to

289
00:10:21,680 --> 00:10:23,800
list it if not try using the anonymous

290
00:10:23,800 --> 00:10:25,600
login which at that point we'll

291
00:10:25,600 --> 00:10:27,040
potentially be able to still access

292
00:10:27,040 --> 00:10:30,160
documents there the first part of the

293
00:10:30,160 --> 00:10:32,200
identify API type if we break it down

294
00:10:32,200 --> 00:10:34,720
further we use identity toolkit because

295
00:10:34,720 --> 00:10:37,120
it also has a benefit of a case let's

296
00:10:37,120 --> 00:10:39,320
say if we have an API key but we do not

297
00:10:39,320 --> 00:10:41,440
know the project name which we need for

298
00:10:41,440 --> 00:10:44,519
fire store or fire fire uh based storage

299
00:10:44,519 --> 00:10:46,839
we can use identity toolkit to dump all

300
00:10:46,839 --> 00:10:48,880
authorized domains for that firus

301
00:10:48,880 --> 00:10:51,000
project which will include the app spot

302
00:10:51,000 --> 00:10:52,720
and web app links for it which then you

303
00:10:52,720 --> 00:10:54,800
can use as a way to pass into fir store

304
00:10:54,800 --> 00:10:57,200
API calls this will also allow you to

305
00:10:57,200 --> 00:10:59,160
know that okay this is using fire AU we

306
00:10:59,160 --> 00:11:01,560
can test the anonymous signup

307
00:11:01,560 --> 00:11:04,279
there next we'll just test a regular

308
00:11:04,279 --> 00:11:06,480
Anonymous signup pull the access token

309
00:11:06,480 --> 00:11:08,680
if it gives us admin one operation error

310
00:11:08,680 --> 00:11:10,839
which usually can happen which basically

311
00:11:10,839 --> 00:11:12,480
means it is disabled and it will allow

312
00:11:12,480 --> 00:11:14,320
email and password in that case we can

313
00:11:14,320 --> 00:11:16,320
still try email and password sign up but

314
00:11:16,320 --> 00:11:17,959
Anonymous is the easiest way to go if

315
00:11:17,959 --> 00:11:20,519
it's enabled there and then from there

316
00:11:20,519 --> 00:11:22,440
we pull the access tokens use it later

317
00:11:22,440 --> 00:11:24,639
on in fire store the first check again

318
00:11:24,639 --> 00:11:26,800
is with the unauthenticated access so

319
00:11:26,800 --> 00:11:28,240
now we're going to pass in the project

320
00:11:28,240 --> 00:11:30,519
name we pull from identity toolkit and

321
00:11:30,519 --> 00:11:32,399
then later on reference it on the API

322
00:11:32,399 --> 00:11:34,800
call to say let's hit this non-existing

323
00:11:34,800 --> 00:11:38,519
document if it returns a 200 uh with

324
00:11:38,519 --> 00:11:40,200
empty result we know it is going to be

325
00:11:40,200 --> 00:11:42,240
vulnerable versus if it returns

326
00:11:42,240 --> 00:11:44,000
something like a missing or insufficient

327
00:11:44,000 --> 00:11:45,560
permissions now we need to explore

328
00:11:45,560 --> 00:11:47,240
further because there could be two cases

329
00:11:47,240 --> 00:11:49,120
where all documents may require

330
00:11:49,120 --> 00:11:51,440
authentication or some may require brute

331
00:11:51,440 --> 00:11:53,000
force and we just need to pass in

332
00:11:53,000 --> 00:11:54,959
different collection names and see what

333
00:11:54,959 --> 00:11:57,519
happens then finally for authenticated

334
00:11:57,519 --> 00:11:59,120
access with fir store we can can

335
00:11:59,120 --> 00:12:00,680
basically pass in the access tokens for

336
00:12:00,680 --> 00:12:02,720
the anonymous user that we've pulled

337
00:12:02,720 --> 00:12:05,040
utilize that to see if onon login allows

338
00:12:05,040 --> 00:12:07,079
us to access document some cases it may

339
00:12:07,079 --> 00:12:09,000
not if they're checking the user ID when

340
00:12:09,000 --> 00:12:10,880
they're accessing the fir store uh

341
00:12:10,880 --> 00:12:12,480
database

342
00:12:12,480 --> 00:12:15,279
there similar process with storage we

343
00:12:15,279 --> 00:12:17,360
can hit the fire storage see what

344
00:12:17,360 --> 00:12:19,160
happens if it's Vernal it will list all

345
00:12:19,160 --> 00:12:21,560
the files if not it will go into the

346
00:12:21,560 --> 00:12:23,600
permit and denied and then we can rerun

347
00:12:23,600 --> 00:12:25,680
our uh checks again to make sure we can

348
00:12:25,680 --> 00:12:27,320
try with the onon login and see what

349
00:12:27,320 --> 00:12:30,480
happens there finally if we script it in

350
00:12:30,480 --> 00:12:31,839
the end it will look something like this

351
00:12:31,839 --> 00:12:34,000
where you'll pass in a Google API key it

352
00:12:34,000 --> 00:12:35,639
will give you a full stats of if this

353
00:12:35,639 --> 00:12:38,000
fire project is Vernal or not and from

354
00:12:38,000 --> 00:12:39,519
there you can analyze further if what

355
00:12:39,519 --> 00:12:41,360
kind of data it will

356
00:12:41,360 --> 00:12:44,199
have uh when we did that we started

357
00:12:44,199 --> 00:12:45,800
scanning the web as I said before so if

358
00:12:45,800 --> 00:12:48,880
we move into stats wise we carried all

359
00:12:48,880 --> 00:12:50,880
of this over ran it with Source craft we

360
00:12:50,880 --> 00:12:53,160
pulled about 15,000 Google API keys with

361
00:12:53,160 --> 00:12:56,079
that out of which there was 4,000 unique

362
00:12:56,079 --> 00:12:58,040
so it doesn't necessarily meant that

363
00:12:58,040 --> 00:12:59,720
there were some dup duplications mainly

364
00:12:59,720 --> 00:13:02,000
because these apis are like forked uh

365
00:13:02,000 --> 00:13:03,519
repos and all of those so we got some

366
00:13:03,519 --> 00:13:06,040
duplicates there got 4,000 API keys with

367
00:13:06,040 --> 00:13:08,680
it out of with 1,700 hat identity

368
00:13:08,680 --> 00:13:10,920
toolkit so it allowed us like okay these

369
00:13:10,920 --> 00:13:13,320
guaranteed run Firebase now when we go

370
00:13:13,320 --> 00:13:15,720
further and break it down we found about

371
00:13:15,720 --> 00:13:18,240
249 of them to have Anonymous signup

372
00:13:18,240 --> 00:13:21,199
enabled later on exploring further we

373
00:13:21,199 --> 00:13:22,959
found about 35 of them to have their

374
00:13:22,959 --> 00:13:25,079
database publicly accessible regardless

375
00:13:25,079 --> 00:13:27,199
of authentication type and then if we go

376
00:13:27,199 --> 00:13:29,160
to storage buckets wise there's about 20

377
00:13:29,160 --> 00:13:30,639
of them that were veriable to that as

378
00:13:30,639 --> 00:13:32,639
well but now if we go back to the

379
00:13:32,639 --> 00:13:35,320
anonymous signup since we have about 249

380
00:13:35,320 --> 00:13:37,320
that had Anonymous signup enabled some

381
00:13:37,320 --> 00:13:39,240
of them were giving access denied on Fir

382
00:13:39,240 --> 00:13:41,440
store uh database and Firebase or

383
00:13:41,440 --> 00:13:43,760
Firebase stories but if we go further

384
00:13:43,760 --> 00:13:45,760
down we'll see we were able to access 10

385
00:13:45,760 --> 00:13:47,639
fir store instances that had

386
00:13:47,639 --> 00:13:49,480
authentication requirement but we have

387
00:13:49,480 --> 00:13:51,639
Anonymous login so we can just use that

388
00:13:51,639 --> 00:13:54,399
to actually dunk the content and then

389
00:13:54,399 --> 00:13:56,839
finally we found about five fire storage

390
00:13:56,839 --> 00:13:59,920
vernales with the source graph case

391
00:13:59,920 --> 00:14:02,320
now if we go in the end to the common

392
00:14:02,320 --> 00:14:04,839
craw portion where we scanned a lot more

393
00:14:04,839 --> 00:14:07,320
we actually only pulled 1, firas API

394
00:14:07,320 --> 00:14:09,240
Keys now the reason the number is

395
00:14:09,240 --> 00:14:11,800
smaller than 15,000 API Keys is we

396
00:14:11,800 --> 00:14:13,759
changed our scanning to one look for

397
00:14:13,759 --> 00:14:15,880
Firebase cases so the way we'll approach

398
00:14:15,880 --> 00:14:17,800
that is let's look for Rex in common

399
00:14:17,800 --> 00:14:20,160
craw where it will have a Google API key

400
00:14:20,160 --> 00:14:21,759
and see if there's mention of firis

401
00:14:21,759 --> 00:14:23,480
client or whether it's using any kind of

402
00:14:23,480 --> 00:14:25,959
firest client JS if it is we'll move

403
00:14:25,959 --> 00:14:28,199
further in scanning it we identified

404
00:14:28,199 --> 00:14:30,480
about six 92 of them to have identity

405
00:14:30,480 --> 00:14:32,279
toate enabled and this was actual

406
00:14:32,279 --> 00:14:34,959
companies and organizations and all out

407
00:14:34,959 --> 00:14:36,959
of which 80 of them had Anonymous sign

408
00:14:36,959 --> 00:14:39,519
up enabled if we further break it down

409
00:14:39,519 --> 00:14:41,639
55 of them had their database publicly

410
00:14:41,639 --> 00:14:43,959
accessible to the world and then 15 of

411
00:14:43,959 --> 00:14:45,959
them had their storage buckets publicly

412
00:14:45,959 --> 00:14:47,199
accessible as

413
00:14:47,199 --> 00:14:49,519
well now if we look through Anonymous

414
00:14:49,519 --> 00:14:51,600
side we were able to access T database

415
00:14:51,600 --> 00:14:53,920
that require login but by using

416
00:14:53,920 --> 00:14:55,800
Anonymous sign up where 80 of them had

417
00:14:55,800 --> 00:14:57,759
it enabled were able to access T of

418
00:14:57,759 --> 00:14:59,480
their databases there

419
00:14:59,480 --> 00:15:01,079
and then 10 also we were able to access

420
00:15:01,079 --> 00:15:03,839
their stories also with that now if we

421
00:15:03,839 --> 00:15:05,160
break down the categories without

422
00:15:05,160 --> 00:15:07,160
mentioning the company names that were

423
00:15:07,160 --> 00:15:09,600
veriable to it couple of examples of

424
00:15:09,600 --> 00:15:11,759
organizations that were vable we saw is

425
00:15:11,759 --> 00:15:14,079
early stage startups so anyone that's

426
00:15:14,079 --> 00:15:15,600
starting their new business or starting

427
00:15:15,600 --> 00:15:17,079
new products they are likely to use

428
00:15:17,079 --> 00:15:19,880
things like Firebase uh or AWS Lambda or

429
00:15:19,880 --> 00:15:22,040
AWS like serverless models and

430
00:15:22,040 --> 00:15:24,040
misconfigured those instance same thing

431
00:15:24,040 --> 00:15:25,480
with Firebase where they had used

432
00:15:25,480 --> 00:15:27,560
development environment but users had

433
00:15:27,560 --> 00:15:29,199
started to sign up so some of those were

434
00:15:29,199 --> 00:15:31,839
vulnerable in those cases in other cases

435
00:15:31,839 --> 00:15:33,440
we also noticed a lot of new AI

436
00:15:33,440 --> 00:15:35,319
companies that are slowly adding

437
00:15:35,319 --> 00:15:37,600
conversational apis or using open AI

438
00:15:37,600 --> 00:15:39,319
product were also Vernal because they

439
00:15:39,319 --> 00:15:41,160
were building first and then securing

440
00:15:41,160 --> 00:15:43,800
later kind of uh plan with those so we

441
00:15:43,800 --> 00:15:45,880
were able to access a lot of open a API

442
00:15:45,880 --> 00:15:47,560
keys with those which we did report to

443
00:15:47,560 --> 00:15:49,160
openai and they were able to revoke and

444
00:15:49,160 --> 00:15:50,519
work with the companies to make sure

445
00:15:50,519 --> 00:15:52,560
those were secured as

446
00:15:52,560 --> 00:15:55,160
well um another really interesting case

447
00:15:55,160 --> 00:15:56,519
that we found is a lot of demo

448
00:15:56,519 --> 00:15:58,720
applications which we expect to have

449
00:15:58,720 --> 00:16:00,959
database public so for example if you go

450
00:16:00,959 --> 00:16:02,720
on GitHub and you find angular database

451
00:16:02,720 --> 00:16:05,759
or angular uh Firebase kind of clients

452
00:16:05,759 --> 00:16:07,199
they will usually have a demo app to

453
00:16:07,199 --> 00:16:09,600
show how that whole project works the

454
00:16:09,600 --> 00:16:11,600
issue was with these projects the fir

455
00:16:11,600 --> 00:16:14,160
store uh database were publicly

456
00:16:14,160 --> 00:16:16,160
accessible and users were actually

457
00:16:16,160 --> 00:16:17,800
testing this demo applications to see

458
00:16:17,800 --> 00:16:19,759
how it works and actually putting their

459
00:16:19,759 --> 00:16:21,560
real pii like their email address their

460
00:16:21,560 --> 00:16:23,480
phone number in these applications so

461
00:16:23,480 --> 00:16:25,639
there were some cases like those as well

462
00:16:25,639 --> 00:16:27,360
quite a bit of those really interesting

463
00:16:27,360 --> 00:16:30,199
case as well uh but that said this is

464
00:16:30,199 --> 00:16:31,639
pretty much like what I wanted to talk

465
00:16:31,639 --> 00:16:34,000
about in general there are cases you can

466
00:16:34,000 --> 00:16:36,120
add for security wise you can I highly

467
00:16:36,120 --> 00:16:37,920
recommend not using the request at off

468
00:16:37,920 --> 00:16:39,680
kind of thing because it is one

469
00:16:39,680 --> 00:16:41,720
recommending users to add authentication

470
00:16:41,720 --> 00:16:43,240
but if you have Anonymous authentication

471
00:16:43,240 --> 00:16:45,800
it defs the purpose there also super

472
00:16:45,800 --> 00:16:47,560
common for new companies to misconfigure

473
00:16:47,560 --> 00:16:48,920
it so you'll probably see a company

474
00:16:48,920 --> 00:16:50,920
Vernal for 30 days and then be secure

475
00:16:50,920 --> 00:16:52,680
later on pretty standard if they use the

476
00:16:52,680 --> 00:16:55,600
development instance uh but with that if

477
00:16:55,600 --> 00:16:57,079
you want to follow us I'll highly

478
00:16:57,079 --> 00:16:58,920
recommend following Tinder we post other

479
00:16:58,920 --> 00:17:00,519
blogs with GitHub actions and all of the

480
00:17:00,519 --> 00:17:02,079
other research that we do so you'll be

481
00:17:02,079 --> 00:17:03,839
able to keep up to date with that and

482
00:17:03,839 --> 00:17:06,420
I'll open it up to questions

483
00:17:06,420 --> 00:17:11,439
[Applause]

484
00:17:11,439 --> 00:17:14,119
now yes are uh are any of those

485
00:17:14,119 --> 00:17:16,160
automated PC is going to be available

486
00:17:16,160 --> 00:17:18,839
that on screen there uh we are trying to

487
00:17:18,839 --> 00:17:20,160
get that open source so we'll see if

488
00:17:20,160 --> 00:17:21,199
we'll be able to release the whole

489
00:17:21,199 --> 00:17:23,559
script with that if I follow you can I

490
00:17:23,559 --> 00:17:25,599
find like depositories or something for

491
00:17:25,599 --> 00:17:27,640
this um yeah the question was if if you

492
00:17:27,640 --> 00:17:29,320
followed if you be able to find repost

493
00:17:29,320 --> 00:17:30,559
if we make it open source we will

494
00:17:30,559 --> 00:17:33,280
publish it uh both on Tinder and and my

495
00:17:33,280 --> 00:17:35,320
personal account uh if you also go it's

496
00:17:35,320 --> 00:17:37,039
not mened here if you go to Tinder SEC

497
00:17:37,039 --> 00:17:39,200
that's our organization GitHub repo so

498
00:17:39,200 --> 00:17:40,520
that's where all of our tools will live

499
00:17:40,520 --> 00:17:42,000
whenever we open source any kind of

500
00:17:42,000 --> 00:17:43,039
tools

501
00:17:43,039 --> 00:17:47,210
there awesome any other

502
00:17:47,210 --> 00:17:50,240
[Music]

503
00:17:50,240 --> 00:17:54,520
questions we're good

504
00:17:54,520 --> 00:17:59,000
yep okay thank you everyone