1
00:00:00,880 --> 00:00:01,860
So hey, everyone.

2
00:00:02,060 --> 00:00:03,300
I'm very excited to be here.

3
00:00:04,560 --> 00:00:07,600
And for this talk, I hope you have nerves of steel,

4
00:00:07,800 --> 00:00:11,080
because today's story is a ghost story.

5
00:00:12,460 --> 00:00:15,460
OK, so this story is not your average ghost story.

6
00:00:15,600 --> 00:00:18,340
It's not about a haunted house or a deserted mental hospital.

7
00:00:19,100 --> 00:00:21,520
This one is scary for hackers specifically.

8
00:00:21,900 --> 00:00:25,260
It's about apps having invisible access to your Google account.

9
00:00:25,260 --> 00:00:29,680
So it all started a bit over a year ago, in June 2022.

10
00:00:30,340 --> 00:00:33,020
And while I was playing around with Google Apps,

11
00:00:33,720 --> 00:00:35,460
I discovered the ghost token vulnerability,

12
00:00:35,900 --> 00:00:39,440
which basically allows attackers to create apps that are invisible

13
00:00:39,440 --> 00:00:41,660
while still having access to your Google account.

14
00:00:42,720 --> 00:00:44,880
And this vulnerability is pretty unique.

15
00:00:45,100 --> 00:00:47,360
It's not an XSS or a CSRF,

16
00:00:47,560 --> 00:00:51,800
and it doesn't even fall into any of the cloud vulnerability categories either.

17
00:00:52,160 --> 00:00:54,560
And I think it makes it especially interesting

18
00:00:54,560 --> 00:00:55,240
to understand the fact that

19
00:00:55,240 --> 00:00:56,640
we understand why the vulnerability happened.

20
00:00:57,420 --> 00:00:59,800
And I think that we have a lot to learn from it,

21
00:00:59,880 --> 00:01:02,360
looking into the future, which is something that we'll explore

22
00:01:02,930 --> 00:01:04,120
at the end of the story.

23
00:01:04,760 --> 00:01:07,340
So before we begin, a little bit about myself.

24
00:01:07,720 --> 00:01:10,180
So my name is Tal, and in the past decade,

25
00:01:10,480 --> 00:01:12,860
I was involved in hacking in all sorts of ways.

26
00:01:13,120 --> 00:01:17,500
In my previous job, I hacked vehicle computers on a daily basis.

27
00:01:18,460 --> 00:01:21,260
In 2016, maybe it's finally time to confess that,

28
00:01:21,320 --> 00:01:23,780
I was part of the team that broke Pokemon Go

29
00:01:24,250 --> 00:01:25,120
anti-cheating system.

30
00:01:25,120 --> 00:01:28,980
And I also have a master's degree in theoretical computer science.

31
00:01:29,380 --> 00:01:33,960
And right now, I work as a senior security researcher and team lead

32
00:01:34,640 --> 00:01:36,980
at Astrix Security, where among other things,

33
00:01:37,080 --> 00:01:41,100
I look at how different providers implement machine-to-machine

34
00:01:41,100 --> 00:01:45,520
and non-human identities authorization between each other.

35
00:01:45,720 --> 00:01:47,380
And these are my socials.

36
00:01:47,380 --> 00:01:48,520
Feel free to contact me.

37
00:01:48,580 --> 00:01:52,240
I will be happy to talk about anything that I did in this talk.

38
00:01:52,400 --> 00:01:54,500
And you can also approach me after the talk.

39
00:01:55,120 --> 00:01:55,560
OK.

40
00:01:55,640 --> 00:01:58,340
So we're finally ready to start our story.

41
00:01:58,840 --> 00:02:01,320
The Ghost Hack and Vulnerability is

42
00:02:01,320 --> 00:02:04,520
related to how Google designed and implemented an authorization

43
00:02:04,520 --> 00:02:06,160
framework named OAuth.

44
00:02:07,040 --> 00:02:10,200
First, then, we need to understand what is OAuth,

45
00:02:10,300 --> 00:02:11,700
why it's needed, and how it works.

46
00:02:12,080 --> 00:02:16,040
So let me start by going into the past, the year of 2007,

47
00:02:16,840 --> 00:02:18,240
before OAuth existed.

48
00:02:18,660 --> 00:02:21,220
And the first iPhone was just released, as you can see here.

49
00:02:21,400 --> 00:02:24,580
And everyone wanted one, and whoever had one probably

50
00:02:24,580 --> 00:02:26,400
went and posted about it on Facebook.

51
00:02:27,460 --> 00:02:31,480
So enter a developer named Ann, and Ann has a brilliant idea.

52
00:02:31,800 --> 00:02:36,100
She will create an app in which she will scan your email contacts

53
00:02:36,100 --> 00:02:39,440
and look for them on Facebook so you can connect to each other

54
00:02:39,440 --> 00:02:41,160
and brag about having an iPhone.

55
00:02:41,500 --> 00:02:43,120
So she does create an app.

56
00:02:43,180 --> 00:02:46,020
You give this app your email address and your password,

57
00:02:46,620 --> 00:02:48,180
and it will scan your contacts.

58
00:02:48,420 --> 00:02:48,860
Great.

59
00:02:50,120 --> 00:02:50,600
Yeah.

60
00:02:50,840 --> 00:02:51,320
What?

61
00:02:51,700 --> 00:02:54,440
So actually, this is how the world

62
00:02:54,580 --> 00:02:55,600
looked like without OAuth.

63
00:02:55,680 --> 00:02:57,620
If you wanted to use any third-party application

64
00:02:57,620 --> 00:02:59,420
and give it access to your Google account,

65
00:02:59,740 --> 00:03:02,120
you actually needed to give it your email address

66
00:03:02,120 --> 00:03:02,880
and your password.

67
00:03:04,340 --> 00:03:06,620
And I guess we were fine with it.

68
00:03:06,760 --> 00:03:08,760
And today, I guess it's pretty clear to you

69
00:03:08,760 --> 00:03:10,040
why it's not very good.

70
00:03:10,240 --> 00:03:11,860
But let me state the glaring issues.

71
00:03:12,380 --> 00:03:16,520
So the first one is, while the app only needed partial access

72
00:03:16,520 --> 00:03:19,980
to your account, for instance, in Ann's case,

73
00:03:20,020 --> 00:03:21,260
it only needed access to your contact,

74
00:03:21,500 --> 00:03:23,560
it actually got full access to your Google account.

75
00:03:23,560 --> 00:03:26,000
The second problem is, if you wanted

76
00:03:26,000 --> 00:03:28,140
to remove access to this account after you used it,

77
00:03:28,260 --> 00:03:29,480
you needed to change your password.

78
00:03:29,560 --> 00:03:31,120
This was the only way you can get rid of it.

79
00:03:31,260 --> 00:03:34,240
But then, all other apps you've given access to also lose access.

80
00:03:35,320 --> 00:03:38,920
The third point is, most people, and especially back then,

81
00:03:39,000 --> 00:03:41,700
probably used the same password for their online banking

82
00:03:41,700 --> 00:03:42,160
accounts.

83
00:03:42,380 --> 00:03:44,840
So you don't want to go around and give your password to anyone.

84
00:03:46,320 --> 00:03:48,360
And this is where OAuth comes in.

85
00:03:48,600 --> 00:03:50,880
And in fact, the problem was identified in 2006.

86
00:03:51,180 --> 00:03:53,300
And a working group that was created to solve it,

87
00:03:53,560 --> 00:03:55,840
released a final draft of the open authorization,

88
00:03:56,200 --> 00:03:57,420
which is shortened to OAuth.

89
00:03:57,480 --> 00:03:59,940
And I'm just going to call it OAuth from now on.

90
00:04:00,200 --> 00:04:02,940
And three years later, it was released as an RFC,

91
00:04:03,100 --> 00:04:04,200
the first version of OAuth.

92
00:04:04,980 --> 00:04:09,540
And in the very nice analogy of one of OAuth co-creators,

93
00:04:09,600 --> 00:04:14,320
Iran Hammer, gives the brief outline of how OAuth works.

94
00:04:14,780 --> 00:04:18,300
So luxury cars today come with a special valet key.

95
00:04:18,580 --> 00:04:22,340
It's a special key that will not allow whoever has it

96
00:04:22,340 --> 00:04:22,940
to drive more.

97
00:04:22,940 --> 00:04:23,840
And then a few miles.

98
00:04:24,540 --> 00:04:26,400
Some valet key will not open the trunk.

99
00:04:26,680 --> 00:04:29,560
Others will lock access to your onboard cell phone address book.

100
00:04:30,100 --> 00:04:31,820
And the idea here is very clever.

101
00:04:31,980 --> 00:04:35,920
So you give someone a special key with a limited access

102
00:04:35,920 --> 00:04:37,840
to your car, while using your regular key

103
00:04:37,840 --> 00:04:39,960
to use everything, to unlock everything.

104
00:04:40,260 --> 00:04:44,580
And this idea translates almost directly to OAuth.

105
00:04:46,380 --> 00:04:48,600
Actually, two years after the first version,

106
00:04:49,060 --> 00:04:51,420
the second version of OAuth was released as an RFC.

107
00:04:52,940 --> 00:04:55,000
And the idea here is greatly extending the use cases of OAuth

108
00:04:55,000 --> 00:04:59,120
and simplifying the protocol inside of it.

109
00:04:59,260 --> 00:05:01,460
And as you notice, I highlighted that they decided

110
00:05:01,460 --> 00:05:02,680
to call it the OAuth framework.

111
00:05:02,980 --> 00:05:06,000
So as opposed to other maybe protocols or standard,

112
00:05:07,320 --> 00:05:10,860
OAuth2 lays out the basic foundation

113
00:05:10,860 --> 00:05:12,440
of how the protocol works.

114
00:05:13,060 --> 00:05:17,200
But it leaves a lot of places for the implementers of OAuth

115
00:05:17,200 --> 00:05:18,500
to decide how to do.

116
00:05:18,680 --> 00:05:22,920
And this, you'll see in a few slides, was one of the main things

117
00:05:22,920 --> 00:05:27,540
reasons the ghost token vulnerability existed in the first place. Now it's an

118
00:05:27,540 --> 00:05:31,740
excellent time to go back to the present and today let me tell you that OAuth is

119
00:05:31,740 --> 00:05:35,360
everywhere. Every time you see an app, a machine-to-machine authorization,

120
00:05:35,800 --> 00:05:39,340
anything related to authorization without using a password, it is done

121
00:05:39,340 --> 00:05:44,700
based on OAuth 2.0. You also have public marketplaces offering millions of

122
00:05:44,700 --> 00:05:49,680
apps used by millions of people. Here you can see Slack, Google and

123
00:05:49,680 --> 00:05:55,100
Microsoft public marketplaces. Okay, so now we know why we needed OAuth and

124
00:05:55,620 --> 00:06:00,140
how it's used, but let's see how it works. So this is how the framework

125
00:06:00,140 --> 00:06:05,080
looks like in a very simplified view .We have Ann, who hasn't aged a day since 2007

126
00:06:05,660 --> 00:06:09,660
and now she wants to use OAuth to create her app. So the first thing she

127
00:06:09,660 --> 00:06:15,540
does is approach Google and register her app and Google, in return, gives Ann

128
00:06:15,540 --> 00:06:19,580
two values, a unique identifier called the client ID, which identifies her

129
00:06:19,680 --> 00:06:25,780
app, and a second secret value. Now, sometimes later, a user named Vikram wants to use Anne's

130
00:06:25,780 --> 00:06:32,480
app. So Anne sends Vikram to Google alongside the client that they identify her app and a list of

131
00:06:32,480 --> 00:06:38,540
permissions that the app needs to operate. Google, in response, shows Vikram what's called a consent

132
00:06:38,540 --> 00:06:43,320
page. It's a page where Vikram can see the name of the app, in this case, example app, and the list

133
00:06:43,320 --> 00:06:48,960
of permissions that it needs to operate. And Vikram has the ability to either consent to

134
00:06:48,960 --> 00:06:54,980
this authorization or not. Let's say that Vikram wants to use the app and he consents to this app.

135
00:06:56,600 --> 00:07:03,160
Then, what happens is Google generates a one-time code and sends it through Vikram to Anne.

136
00:07:03,780 --> 00:07:08,740
As a final step, Anne takes this one-time code generated by Google and the secret value she got

137
00:07:08,740 --> 00:07:14,840
in the first step, approaches Google, exchanges these two values for a token, and this token

138
00:07:14,840 --> 00:07:18,500
is used to access Vikram's data. So what happens is that Anne

139
00:07:18,960 --> 00:07:24,460
holds a special token with a limited permission to Vikram's account. In this case, she only asks

140
00:07:24,460 --> 00:07:31,040
for the email address. So this token has only access to this. Okay, so, oops, sorry.

141
00:07:33,000 --> 00:07:37,620
So this is how OAuth is laid out in the framework. However, I'm actually going to focus

142
00:07:37,620 --> 00:07:43,400
not on this part of OAuth, but actually the things that were unsaid. So I'm going to call

143
00:07:43,400 --> 00:07:48,560
it the OAuth missing pieces. There are two missing pieces. We're basically kind of the

144
00:07:48,960 --> 00:07:53,360
source of the ghost token vulnerability. The first one, I glanced over it very quickly,

145
00:07:53,480 --> 00:07:57,600
but it's the process of app registration. So I just said Anne goes to Google, she registers

146
00:07:57,600 --> 00:08:03,560
an app, and everyone is happy. But in fact, this is how it is laid out in the RFC itself.

147
00:08:03,840 --> 00:08:10,100
So besides two technical things that Anne needs to provide Google, then the last thing,

148
00:08:10,140 --> 00:08:16,020
which is I think the most important thing, like information about Anne and her app, is actually

149
00:08:16,020 --> 00:08:18,200
completely up to Google to decide how to implement.

150
00:08:18,200 --> 00:08:21,980
So the framework really doesn't deal with all of that. And there are many questions

151
00:08:21,980 --> 00:08:27,200
where there's still an answer here, like exactly what information is required for Anne to provide

152
00:08:27,200 --> 00:08:32,580
when she registers her app, and maybe more importantly, what part of this information

153
00:08:32,580 --> 00:08:38,200
is verified and showed to Vikram when Vikram comes and wants to authorize this app.

154
00:08:39,440 --> 00:08:43,980
The second missing piece is the part of what I call the user management,

155
00:08:44,420 --> 00:08:48,080
the user's app management feature. And you notice there's nothing from the

156
00:08:48,200 --> 00:08:55,200
RFC here because the RFC doesn't talk about it at all. So let's say Vikram installs 10 different

157
00:08:55,200 --> 00:08:59,920
apps, and now Vikram wants to see a list of his apps, what permissions they got, and maybe remove

158
00:08:59,920 --> 00:09:06,940
their access. So the RFC doesn't really mind all of that and doesn't say if this thing even

159
00:09:07,640 --> 00:09:14,040
must be implemented. And even most providers today do give this management feature, and

160
00:09:14,040 --> 00:09:17,820
you have a list of apps where you can decide to remove,

161
00:09:18,200 --> 00:09:22,180
but there's still questions here, like what information is displayed?

162
00:09:22,620 --> 00:09:26,480
Can I see the last time the app accessed my data? Which data was accessed?

163
00:09:26,940 --> 00:09:30,820
And indeed, both of these questions and all the questions about the app registration

164
00:09:31,400 --> 00:09:36,100
basically go unanswered in RFC, leading to different providers implementing them

165
00:09:36,100 --> 00:09:41,700
very differently. There's a big gap in how each provider implemented these things. And for our

166
00:09:41,700 --> 00:09:45,660
case, for the Ghost Token Vulnerability, let's look at how Google decided to implement them.

167
00:09:46,600 --> 00:09:48,180
So for the AppReferencer,

168
00:09:48,200 --> 00:09:53,040
process it used to be very simple you just go to Google say hi hello my name

169
00:09:53,040 --> 00:09:56,220
is Tal I want to register an app and you get the client ID and secret you need it

170
00:09:56,220 --> 00:10:01,820
everyone happy but about six years ago Google made a move in which they made

171
00:10:01,820 --> 00:10:07,460
app being contained inside Google Cloud Platform project so as a developer that

172
00:10:07,460 --> 00:10:11,720
wants to use to make a new app the first thing you need actually need to do is

173
00:10:11,720 --> 00:10:17,080
register for Google Cloud Platform GCP and then create a GCP project once you

174
00:10:17,080 --> 00:10:21,740
have a GCP project inside this project you can set up your consent screen which

175
00:10:21,740 --> 00:10:26,880
means providing some values most of them are optional about your app and then

176
00:10:26,880 --> 00:10:32,840
only then you can get your client ID and secret that you needed so I mean my

177
00:10:32,840 --> 00:10:37,000
guess is basically maybe Google made this move in order to sway developers

178
00:10:37,000 --> 00:10:40,260
into using one of the services contained inside GCP because they're already

179
00:10:40,920 --> 00:10:44,880
registered and they have to do that in order to create an app so this is how

180
00:10:44,880 --> 00:10:46,480
app registration works today in Google

181
00:10:47,100 --> 00:10:51,420
for the second thing missing piece the management page for users a actually

182
00:10:51,420 --> 00:10:55,580
there is a designated setting page in each of one of your Google account on

183
00:10:55,580 --> 00:10:58,960
which you can see all apps will be an access to and what kind of permission

184
00:10:58,960 --> 00:11:02,720
you gave them and you have the ability to remove the access and it's important

185
00:11:02,720 --> 00:11:06,340
know for the rest of the talk that there's no other place in which

186
00:11:06,340 --> 00:11:10,260
you can move. The noticed ole' page where you can see all those apps you've given

187
00:11:10,260 --> 00:11:14,760
access to and can remove them and if you want you can scan this QR code and go

188
00:11:14,760 --> 00:11:17,060
to your settings page and see all apps that we're going to grow it together so you can see all those apps you've got an access to and can remove them and if you want you can

189
00:11:17,080 --> 00:11:23,340
access to. But if you don't really like scanning QR codes, I also provided an image of how this

190
00:11:23,340 --> 00:11:28,580
app looks like. And you can see a number of apps I've given access to. And if I click on one of

191
00:11:28,580 --> 00:11:34,220
these apps, I can see the permission that I gave them. For instance, this AI mail assistance has

192
00:11:34,220 --> 00:11:39,120
access to my email, but doesn't have access to my drive. And I also have a button on which I can

193
00:11:39,120 --> 00:11:48,480
click and remove the access of this app. Okay. So we've seen why we need OAuth, how it works, and

194
00:11:48,480 --> 00:11:53,560
the missing pieces of OAuth and how they were implemented in Google. Now we're finally ready to

195
00:11:53,560 --> 00:11:59,220
see some ghosts. So the discovery of the ghost token vulnerability happened like many other

196
00:11:59,220 --> 00:12:05,980
vulnerabilities. It was very unexpected. So at my job, we do a routine analysis of Google

197
00:12:05,980 --> 00:12:09,100
environments of different customers. And in one customer, there was a ghost token. And in the

198
00:12:09,100 --> 00:12:14,480
customer, we noticed something weird. We noticed an app whose name was suddenly changed to be its

199
00:12:14,480 --> 00:12:20,320
identifier. Usually we see app names that are human readable. And suddenly it was changed to the same

200
00:12:20,320 --> 00:12:26,100
thing as the unique ID given to the app. And we didn't really know what happened. But we speculated

201
00:12:26,100 --> 00:12:31,860
that this happens if the app is being deleted by the developer of the app. So the backend in Google

202
00:12:31,860 --> 00:12:38,300
gets confused and doesn't know where to take the app name from. So it defaults to this ID. So we

203
00:12:38,300 --> 00:12:38,840
tested it.

204
00:12:39,100 --> 00:12:48,920
So the good research is due. We created a GCP project. We then we created an app. We installed it on some test users. And then we went into this project and deleted the client

205
00:12:48,920 --> 00:12:58,060
ID that we generated for this app. And once we did, the following things happen. So first, the name of the app became its client ID. So we were able to reproduce this

206
00:12:58,060 --> 00:13:08,160
weirdness. But as, again, good researchers do, we didn't stop there and we tried to abuse this. So we took the client ID we just deleted and tried to use it. And we got this error,

207
00:13:08,160 --> 00:13:10,140
error, which says that the client ID is deleted.

208
00:13:11,120 --> 00:13:14,300
Also, all tokens previously given by Google,

209
00:13:14,420 --> 00:13:16,660
authorizing the app, stopped working.

210
00:13:16,920 --> 00:13:18,160
So we couldn't use them anymore.

211
00:13:18,340 --> 00:13:19,620
The developer couldn't use them anymore.

212
00:13:19,980 --> 00:13:23,240
And also, the app disappeared from the management pages

213
00:13:23,240 --> 00:13:24,700
of all users who installed it.

214
00:13:25,940 --> 00:13:28,360
So now you look at this and you say, well,

215
00:13:28,440 --> 00:13:29,880
that seems reasonable, right?

216
00:13:29,980 --> 00:13:30,720
The app is deleted.

217
00:13:31,120 --> 00:13:33,460
I expect it to be completely removed

218
00:13:33,460 --> 00:13:35,100
from everywhere it was.

219
00:13:35,920 --> 00:13:39,180
But I want you to recall that I said that today, app

220
00:13:39,180 --> 00:13:42,140
registration in Google, when you create a client ID,

221
00:13:42,280 --> 00:13:44,700
it's actually contained within a GCP project.

222
00:13:45,140 --> 00:13:47,320
So this begs the question, what if instead

223
00:13:47,320 --> 00:13:50,720
of deleting the client ID, we deleted the entire GCP

224
00:13:50,720 --> 00:13:51,140
project?

225
00:13:52,380 --> 00:13:54,360
So we went ahead and tried that.

226
00:13:54,480 --> 00:13:58,700
So we went to some project in GCP that had an app inside of it

227
00:13:58,700 --> 00:13:59,720
that some users installed.

228
00:14:00,060 --> 00:14:01,100
And we deleted it.

229
00:14:01,280 --> 00:14:02,900
And once you delete a GCP project,

230
00:14:03,140 --> 00:14:04,880
it enters a special limbo state.

231
00:14:05,100 --> 00:14:07,840
They call it a pending deletion state.

232
00:14:08,760 --> 00:14:11,520
And once the project was in pending deletion state,

233
00:14:11,800 --> 00:14:14,060
the app contained within this project

234
00:14:14,420 --> 00:14:17,960
behaved similarly to when it was deleted directly.

235
00:14:18,440 --> 00:14:20,240
So the client ID couldn't be used anymore.

236
00:14:20,580 --> 00:14:23,380
All tokens previously given to the app stopped working.

237
00:14:23,680 --> 00:14:26,800
And also, the app disappeared from the user management pages

238
00:14:26,800 --> 00:14:27,680
who installed it.

239
00:14:28,440 --> 00:14:30,540
But as you can see on the image here,

240
00:14:30,720 --> 00:14:32,580
you have a button to restore projects.

241
00:14:32,900 --> 00:14:34,920
So once you delete a project in GCP,

242
00:14:34,920 --> 00:14:37,540
you have 30 days to regret your decision deleting it

243
00:14:37,540 --> 00:14:39,520
and actually restore it to a previous state.

244
00:14:40,640 --> 00:14:43,740
So what would happen to the tokens of the app

245
00:14:43,740 --> 00:14:45,020
if we restore the project?

246
00:14:45,500 --> 00:14:48,140
So you might have guessed it, or not, I don't know.

247
00:14:48,340 --> 00:14:51,700
But actually, all tokens given previously to the app

248
00:14:51,700 --> 00:14:54,100
started working again once we restored the project.

249
00:14:55,400 --> 00:14:56,640
Do you notice the ghost?

250
00:14:57,780 --> 00:15:00,220
So let's recap what just happened.

251
00:15:00,400 --> 00:15:02,360
Let's say our developer from before, Ann,

252
00:15:03,020 --> 00:15:04,840
decided to turn evil and become an attacker.

253
00:15:04,920 --> 00:15:07,080
So we'll call her Evil Ann.

254
00:15:07,660 --> 00:15:10,900
So let's say Vikram installs one of Ann's apps.

255
00:15:11,480 --> 00:15:14,040
And now, if Ann combines the fact

256
00:15:14,040 --> 00:15:17,400
that once she deletes the project associated with the app,

257
00:15:17,780 --> 00:15:20,740
the user, Vikram, can't see the app anymore

258
00:15:20,740 --> 00:15:21,880
and remove its access.

259
00:15:22,520 --> 00:15:25,740
But when Ann restores the project associated with the app,

260
00:15:26,360 --> 00:15:29,300
the token belonging to Vikram starts working again,

261
00:15:29,440 --> 00:15:31,040
and Ann can access Vikram's data.

262
00:15:31,260 --> 00:15:34,560
What she can do is actually keep the project in,

263
00:15:34,560 --> 00:15:35,560
in a pending deletion state.

264
00:15:35,800 --> 00:15:37,500
And whenever she wants to access Vikram's data,

265
00:15:37,700 --> 00:15:40,660
she restores it, access the data, and then removes it again.

266
00:15:40,900 --> 00:15:42,880
So Vikram can't remove her app.

267
00:15:43,220 --> 00:15:47,020
And in essence, Ann holds some kind of a ghost token

268
00:15:47,020 --> 00:15:50,020
to Vikram's data that Vikram cannot get rid of.

269
00:15:51,480 --> 00:15:52,980
So you can relax.

270
00:15:53,140 --> 00:15:54,300
The vulnerability is patched now.

271
00:15:54,460 --> 00:15:55,800
I'll talk about it in a few slides.

272
00:15:56,700 --> 00:15:58,940
But unfortunately, it means there's no live demo.

273
00:15:59,160 --> 00:16:03,200
I did pre-record the demo of me exploiting this on a victim

274
00:16:03,200 --> 00:16:03,480
account.

275
00:16:03,480 --> 00:16:05,260
So let's see it.

276
00:16:05,760 --> 00:16:08,940
So here, we have a victim that is convinced

277
00:16:08,940 --> 00:16:10,700
to install my totally innocent app.

278
00:16:10,820 --> 00:16:12,920
And I promised you it was totally innocent at the time.

279
00:16:13,420 --> 00:16:15,600
So this is how the consent screen looks like.

280
00:16:15,680 --> 00:16:19,240
And the victims give access to their drive files.

281
00:16:19,920 --> 00:16:22,800
And once they do it, this is the attacker point of view.

282
00:16:22,920 --> 00:16:25,400
I immediately get the token belonging to the victim.

283
00:16:25,680 --> 00:16:28,940
And then I quickly run over to the GCP project associated

284
00:16:28,940 --> 00:16:29,720
with the app.

285
00:16:30,000 --> 00:16:31,560
And I delete it.

286
00:16:31,760 --> 00:16:33,460
And once I do it, it enters the pending deletion state.

287
00:16:33,460 --> 00:16:36,280
And this can happen automatically.

288
00:16:36,460 --> 00:16:38,820
You can even write a two-line script that does it for you.

289
00:16:38,880 --> 00:16:41,220
You don't have to do it manually if you're lazy like me.

290
00:16:42,340 --> 00:16:44,520
And let's go back to the victim's point of view.

291
00:16:44,560 --> 00:16:46,960
You can see this is the victim because of the V on the top

292
00:16:46,960 --> 00:16:47,760
right there.

293
00:16:47,940 --> 00:16:50,680
And this is the list of all apps the victim

294
00:16:51,540 --> 00:16:52,520
given access to.

295
00:16:52,580 --> 00:16:54,760
As you can notice, totally innocent app

296
00:16:54,760 --> 00:16:56,580
is not present on this list.

297
00:16:56,900 --> 00:16:59,320
So the victim, at any point in time,

298
00:16:59,400 --> 00:17:00,640
cannot do anything about it.

299
00:17:00,780 --> 00:17:03,440
The victim can't even know that the app is installed.

300
00:17:03,440 --> 00:17:04,600
It's not installed on their account.

301
00:17:05,840 --> 00:17:09,480
But notice that this is back to the attacker point of view.

302
00:17:09,640 --> 00:17:12,880
At any time that I want to, I can restore the GCP project

303
00:17:12,880 --> 00:17:13,500
that I deleted.

304
00:17:14,740 --> 00:17:16,320
Oh, we lost a thing there.

305
00:17:16,440 --> 00:17:16,740
OK.

306
00:17:17,180 --> 00:17:19,540
So at any time, we can restore the GCP project

307
00:17:19,540 --> 00:17:23,080
that we deleted before, and then use the same token

308
00:17:23,080 --> 00:17:26,200
that we received before to access the user's drive files.

309
00:17:26,440 --> 00:17:27,780
This is what happens here.

310
00:17:27,960 --> 00:17:30,320
And once we do that, we can immediately,

311
00:17:30,480 --> 00:17:33,020
after getting the victim's files,

312
00:17:33,440 --> 00:17:34,900
we can shut down the project again

313
00:17:34,900 --> 00:17:37,640
and restore it to its deleted state,

314
00:17:37,760 --> 00:17:41,360
pending the recent state, so the victim cannot remove it.

315
00:17:42,300 --> 00:17:44,660
OK, so we reported the vulnerability to Google

316
00:17:44,660 --> 00:17:45,740
when we discovered it.

317
00:17:45,880 --> 00:17:48,360
And we worked together on a fix, which wasn't as simple,

318
00:17:48,440 --> 00:17:51,220
because it involves some deep infrastructural changes

319
00:17:51,220 --> 00:17:51,880
to Google.

320
00:17:53,040 --> 00:17:57,120
So you can read more about what the patch did exactly

321
00:17:57,120 --> 00:18:00,780
to solve this vulnerability, as well as some little details

322
00:18:00,780 --> 00:18:03,020
about the research that I didn't have time to go through here.

323
00:18:03,440 --> 00:18:04,960
In the blog post, I wrote about it.

324
00:18:04,980 --> 00:18:07,160
Just search it online, ghost token, you'll find it.

325
00:18:07,880 --> 00:18:10,600
OK, so we've seen the ghost token vulnerability.

326
00:18:11,080 --> 00:18:13,900
And let's discuss some takeaways of this vulnerability.

327
00:18:15,780 --> 00:18:19,120
OK, so first, the vulnerability, in my opinion,

328
00:18:19,180 --> 00:18:21,480
has probably been open ever since Google made the move

329
00:18:21,480 --> 00:18:24,400
to contain apps inside GCP, which

330
00:18:24,400 --> 00:18:25,860
happened around six years ago.

331
00:18:26,180 --> 00:18:29,960
And actually, because the management page of the users

332
00:18:30,300 --> 00:18:32,980
is so severely lacking in audit of who

333
00:18:32,980 --> 00:18:35,380
access your data and when, it's basically

334
00:18:35,380 --> 00:18:38,140
impossible to know if someone exploited this vulnerability.

335
00:18:38,740 --> 00:18:40,540
Let's imagine one of the developers

336
00:18:40,540 --> 00:18:42,780
having one of the million of apps.

337
00:18:42,940 --> 00:18:45,660
One developer was bad and decided

338
00:18:45,660 --> 00:18:48,400
to exploit his vulnerability.

339
00:18:48,980 --> 00:18:49,960
Would we even notice?

340
00:18:50,200 --> 00:18:51,120
Would anyone know that?

341
00:18:51,420 --> 00:18:52,780
There's no way to know that.

342
00:18:52,960 --> 00:18:55,000
And I think this makes the threat potential of ghost token

343
00:18:55,600 --> 00:18:56,440
pretty huge.

344
00:18:56,580 --> 00:18:58,880
We have no idea if it was ever exploited.

345
00:19:00,760 --> 00:19:04,800
The second takeaway is, actually, if you recall back

346
00:19:04,800 --> 00:19:06,880
to the two missing pieces, so the fact

347
00:19:06,880 --> 00:19:10,840
that Google made it so apps are contained inside GCP project,

348
00:19:11,160 --> 00:19:14,420
together with the fact that they have not enough audit logs

349
00:19:14,420 --> 00:19:18,620
related to how apps access your data, together made two

350
00:19:18,620 --> 00:19:20,280
mistakes, made the vulnerability happen.

351
00:19:20,720 --> 00:19:23,620
And these mistakes, I don't hold it against Google.

352
00:19:23,860 --> 00:19:26,320
It's actually things that are not mentioned in the RFC at all.

353
00:19:26,500 --> 00:19:28,380
So maybe this is a message to you,

354
00:19:28,440 --> 00:19:28,860
if you're interested.

355
00:19:28,880 --> 00:19:30,960
If you're ever involved in implementing OAuth

356
00:19:30,960 --> 00:19:33,320
in your organization, you need to put special attention,

357
00:19:33,840 --> 00:19:36,220
actually, on the things that are not written in RFC,

358
00:19:36,400 --> 00:19:38,260
how you implement them and make sure there's

359
00:19:38,260 --> 00:19:39,920
no such vulnerability in them as well.

360
00:19:40,980 --> 00:19:44,200
The third point is directed at researchers in the cloud,

361
00:19:44,320 --> 00:19:45,940
which I think are most of you here.

362
00:19:46,300 --> 00:19:50,320
So I've been doing stuff related to all vulnerabilities

363
00:19:50,320 --> 00:19:51,840
in the past five years or so.

364
00:19:52,040 --> 00:19:56,340
And whenever I read information regarding vulnerabilities,

365
00:19:56,680 --> 00:19:58,780
it's always very confusing and convoluted.

366
00:19:58,880 --> 00:20:02,720
And I hope this one was a bit clearer regarding OAuth.

367
00:20:03,040 --> 00:20:07,320
But I see many researchers shy away from looking

368
00:20:07,320 --> 00:20:09,100
at these areas of OAuth.

369
00:20:09,240 --> 00:20:12,780
I think that actually, because OAuth is just a framework

370
00:20:12,780 --> 00:20:16,280
and the implementation differs a lot between providers,

371
00:20:17,100 --> 00:20:19,000
it's actually a very good, rich surface

372
00:20:19,000 --> 00:20:19,960
for vulnerability research.

373
00:20:20,100 --> 00:20:22,640
And I implore you to look at it at your next research.

374
00:20:24,280 --> 00:20:28,560
To wrap up this talk, I would like to finally look into the,

375
00:20:28,580 --> 00:20:28,860
uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh, uh.

376
00:20:29,500 --> 00:20:33,800
I would like to give some sort of a vision of how I see

377
00:20:33,800 --> 00:20:35,620
the next iteration of OAuth.

378
00:20:36,860 --> 00:20:40,300
So the first thing I want to see is a change of how

379
00:20:40,300 --> 00:20:43,840
we register apps, uh, in different platforms.

380
00:20:44,080 --> 00:20:47,220
So today you need to go to each individual platform you need,

381
00:20:47,260 --> 00:20:49,840
you want to make an app for, to GitHub, to Slack,

382
00:20:50,060 --> 00:20:52,540
to Google, et cetera, and you need to register your app

383
00:20:52,540 --> 00:20:55,380
separately, and each of them has a completely separate way

384
00:20:55,380 --> 00:20:58,040
to verify and, and do this all registration process.

385
00:20:58,040 --> 00:21:08,500
And I imagine a consolidated, centralized platform where developers can one time register their app, and it will be immediately available in all platforms they want it to be.

386
00:21:09,080 --> 00:21:15,300
Additionally, while they register, they can either be completely anonymous and basically don't give any information about their app,

387
00:21:15,460 --> 00:21:21,120
or maybe they are a very well-respected company who has no problem verifying a lot of information about themselves,

388
00:21:21,380 --> 00:21:24,680
and they can give all this information to this centralized platform.

389
00:21:24,680 --> 00:21:30,480
Of course, the important thing here is that when a user comes to authorize an app,

390
00:21:30,620 --> 00:21:34,140
all this information will be fully transparent and shown to the user,

391
00:21:34,300 --> 00:21:41,740
helping the user make way better decisions when deciding whether to allow or deny access to apps they want to use.

392
00:21:43,000 --> 00:21:45,640
The second part is about the user management page.

393
00:21:45,860 --> 00:21:53,220
So indeed, today, all providers that I've looked at provide a list of all apps they've given access to and the ability to remove it.

394
00:21:53,380 --> 00:21:54,660
But I think that's still left.

395
00:21:54,680 --> 00:22:00,080
I, as a user, would like to know which app accessed my data, which data was accessed,

396
00:22:00,300 --> 00:22:05,620
and maybe more identify details about the access, like IP address or user agent,

397
00:22:05,740 --> 00:22:10,060
so I can be more in control of where my data is and who is accessing it.

398
00:22:11,300 --> 00:22:16,240
These two fixes, by the way, will also fix the problem with the ghost vulnerability.

399
00:22:17,600 --> 00:22:19,900
The last part of the vision is a bit of a smaller one.

400
00:22:20,220 --> 00:22:22,940
So, OAuth has many use cases today in the RFC,

401
00:22:22,940 --> 00:22:25,680
and even three years ago, another use case was added.

402
00:22:26,260 --> 00:22:33,760
I think there are many parts, many use cases still present today in the RFC that are a bit outdated,

403
00:22:33,980 --> 00:22:37,460
and nobody really uses them anymore, and I would be happy to see them gone.

404
00:22:37,820 --> 00:22:39,400
I don't like backwards compatibility.

405
00:22:40,480 --> 00:22:46,720
Additionally, one of the most promising use cases that we see everywhere today is machine-to-machine authorization.

406
00:22:47,360 --> 00:22:51,460
Right now, people implementing machine-to-machine authorization use OAuth

407
00:22:51,460 --> 00:22:55,040
in some weird backwards way in order to implement that,

408
00:22:55,160 --> 00:22:59,060
and I would be happy to see a specific use case in the OAuth RFC

409
00:22:59,060 --> 00:23:06,040
designed to lay the foundation of how machine-to-machine authorization works.

410
00:23:06,860 --> 00:23:13,800
So, to wrap up this talk, I presented a full overview of a unique vulnerability in Google OAuth's design.

411
00:23:14,020 --> 00:23:19,640
We analyzed how maybe the insufficient OAuth framework was partly to blame for this bug,

412
00:23:19,640 --> 00:23:26,520
and finally we discussed some ways that we as a community should make in order to change how OAuth works like

413
00:23:26,520 --> 00:23:32,640
and prevent from potentially having this kind of catastrophic vulnerabilities in the future.

414
00:23:32,920 --> 00:23:35,720
Thank you all for listening. Have a good day.