1
00:00:00,000 --> 00:00:03,720
So what if I told you there is a cyber risk present today in cellular communications

2
00:00:03,720 --> 00:00:09,160
that allows an attacker the ability to send you a phone call and your device is compromised?

3
00:00:09,880 --> 00:00:10,460
That's it?

4
00:00:10,960 --> 00:00:15,600
There's no user interaction, there's no clicking any links, there's no picking up the phone.

5
00:00:15,900 --> 00:00:20,900
Just the simple fact of, or the simple ability for the phone call to be sent.

6
00:00:21,940 --> 00:00:25,160
And this threat vector which is present in cellular communications today

7
00:00:25,160 --> 00:00:30,020
provides an attacker the ability to deliver a no-click remote code execution exploit

8
00:00:30,020 --> 00:00:33,540
over the air, under the radar, to your device.

9
00:00:34,040 --> 00:00:40,620
And to be more accurate, any device that's even momentarily connected to an attacker-controlled cellular tower.

10
00:00:41,180 --> 00:00:43,380
So today we're super excited to be here.

11
00:00:43,540 --> 00:00:44,880
I appreciate everyone joining.

12
00:00:45,040 --> 00:00:48,960
We wanted to talk to you about our review of the Pixel 6 modem stack.

13
00:00:49,520 --> 00:00:52,640
It's been a culmination of many months of our efforts.

14
00:00:53,860 --> 00:00:55,080
I'm Farzan Karimi.

15
00:00:55,160 --> 00:00:57,140
I'm the engineering manager of the Android Red team.

16
00:00:57,300 --> 00:00:59,400
I'm joined by our world-class researchers here,

17
00:00:59,520 --> 00:01:00,780
Xuan Xing, our technical lead,

18
00:01:01,180 --> 00:01:03,340
Eugene Rodinov, and Shilin Gong.

19
00:01:04,780 --> 00:01:06,680
All right, so here's our session agenda.

20
00:01:07,000 --> 00:01:10,760
We'll provide a brief overview of the Pixel 6 modem stack

21
00:01:10,760 --> 00:01:15,660
and share the results of our impactful 2021 Red team engagement of the modem.

22
00:01:16,200 --> 00:01:17,540
2021? Yes.

23
00:01:17,740 --> 00:01:20,920
That's how long it took us to get PR approval to get up here.

24
00:01:22,340 --> 00:01:25,080
Before jumping into what we were able to explore,

25
00:01:25,160 --> 00:01:29,060
we'll set up a bit of context and cover a high-level architecture of the Pixel modem,

26
00:01:29,140 --> 00:01:30,820
followed by our key findings.

27
00:01:31,220 --> 00:01:34,100
We'll then cover two CVEs that if you Google,

28
00:01:34,220 --> 00:01:36,000
you'll see nothing about them on the Internet today,

29
00:01:36,180 --> 00:01:39,400
aside from the fact that they're rated critical severity by NIST

30
00:01:39,400 --> 00:01:40,720
and our Android severity guidelines.

31
00:01:41,660 --> 00:01:45,220
These two CVEs that we identified were integral in our exploit chain.

32
00:01:46,160 --> 00:01:47,880
So we're going to deep dive those.

33
00:01:48,060 --> 00:01:49,860
We're going to show you a demo that's pretty exciting.

34
00:01:51,040 --> 00:01:53,340
And then moving on, actually,

35
00:01:53,400 --> 00:01:55,140
we also want to cover a very,

36
00:01:55,140 --> 00:01:58,620
very important step you can take from a remediation standpoint

37
00:01:58,620 --> 00:01:59,980
that better protect yourself.

38
00:02:00,220 --> 00:02:02,420
So it's probably the most important takeaway from this presentation.

39
00:02:02,740 --> 00:02:03,800
So stay tuned for that.

40
00:02:04,140 --> 00:02:09,800
I do want to emphasize before moving on that everything we're going to present today is fixed.

41
00:02:10,580 --> 00:02:12,100
No zero days. I'm sorry.

42
00:02:14,540 --> 00:02:17,480
So just a really high level.

43
00:02:18,120 --> 00:02:19,020
Actually, I'm sorry.

44
00:02:20,880 --> 00:02:21,380
Yep.

45
00:02:21,440 --> 00:02:24,820
I just wanted to give you like a basic understanding of the

46
00:02:25,140 --> 00:02:27,240
engagement missions that we had for this review.

47
00:02:27,460 --> 00:02:33,540
The primary objective for our review was to get code execution on the pixel six modem stack via the baseband

48
00:02:34,040 --> 00:02:37,960
and then work with our feature teams to fix all these bugs before release.

49
00:02:38,820 --> 00:02:40,580
We did a pretty good job on that.

50
00:02:40,720 --> 00:02:47,040
There was a critical issue that came up that put this talk into jeopardy that Eugene would have all covered in a bit.

51
00:02:47,280 --> 00:02:51,320
And then bonus points for working with our modem OEM to fix everything before release.

52
00:02:51,560 --> 00:02:53,620
As with most DEF CON presentations,

53
00:02:53,900 --> 00:02:54,760
we did achieve.

54
00:02:54,760 --> 00:02:58,520
These are objectives a little bit about us.

55
00:02:58,580 --> 00:02:59,260
We are, as I mentioned,

56
00:02:59,340 --> 00:03:00,100
we're the Android red team.

57
00:03:00,180 --> 00:03:00,840
We work for Google.

58
00:03:01,220 --> 00:03:04,040
Our mission is to increase Android security.

59
00:03:04,240 --> 00:03:07,080
That means we read team devices that run on Android.

60
00:03:07,380 --> 00:03:08,680
It could be Google pixel.

61
00:03:08,760 --> 00:03:11,460
It could be pixel watch a whole ecosystem of devices.

62
00:03:12,280 --> 00:03:16,760
We do that a number of ways through offensive research where we simulate adversarial campaigns.

63
00:03:17,480 --> 00:03:20,580
We build tools so that help us scale.

64
00:03:20,720 --> 00:03:24,660
So we invest a lot in fuzzing and primarily continuous fuzzing.

65
00:03:24,760 --> 00:03:29,920
To help us scale and find bugs while we're doing more manual code reviews and exploit development.

66
00:03:30,340 --> 00:03:44,720
That's the third item exploit dev is a place we spend a lot of time in a lot of people ask like why do you spend weeks on exploit dev and for us it's so important to be able to better articulate these complex issues to leadership with a demo.

67
00:03:45,280 --> 00:03:50,060
It also allows us to find more vulnerabilities as we go through the exploit writing exercise.

68
00:03:50,280 --> 00:03:52,700
So it's a very fruitful investment for us.

69
00:03:54,760 --> 00:04:09,460
And then finally we invest a lot in remediation we work with our feature teams to fix bugs if nobody's fixing our bugs we suck as a red team and so we want to make sure we build a good relationship there and so that's something we really value so let's get right into it.

70
00:04:09,540 --> 00:04:23,320
Why do we pick the modem for starters it's been an emerging area of risk in a mobile connectivity space for a few years now you can see some of the headlines these are all very recent some very recent work by project zero earlier this year on the modem.

71
00:04:24,000 --> 00:04:24,740
Why all this?

72
00:04:24,760 --> 00:04:54,680
Why all this attention now so the short answer is the cost to ride has dramatically decreased in the past few years so if you're looking to get yourself equipment such as a software divine radio and SDR ten years ago that would have put you back ten to twenty thousand dollars today you can get an SDR for two K so it becomes more accessible for security researchers and real hackers to go purchase this equipment and target cellular comms it's also one reason we're seeing more of a recent influx.

73
00:04:54,760 --> 00:05:01,220
Of bugs coming in through our bug bounty program and why we're able to get a bunch of SDRs for our team to find a bunch of bugs.

74
00:05:02,000 --> 00:05:24,120
So what can you do if you actually find a bug in the modem so some earlier mentioned over the air RCE if you're not familiar with that terminology over the air is simply just a form of digital communication usually in the form of a software update that's sent up wirelessly like over the air to your phone sometimes through Wi-Fi networks most of the time it's associated with cellular communications.

75
00:05:24,940 --> 00:05:38,200
In the pixel modem stack getting over the air RCE nets you code execution in a privileged context that's because there's no concept of identity isolation or network segmentation within the component the modem itself.

76
00:05:38,900 --> 00:05:50,720
And so you get code execution what is what can you do right so one thing you can do is now of service and I could already see eyes glazing when I say DOS but in the context of modem it's actually pretty impactful.

77
00:05:51,020 --> 00:05:54,540
So just imagine like a football stadium full with tens of thousands of people.

78
00:05:54,560 --> 00:05:54,740
Right.

79
00:05:54,760 --> 00:06:01,360
All connected to a single attacker controlled cellular tower and then everyone losing connectivity all at once.

80
00:06:01,820 --> 00:06:07,180
If you're more of a nation state profile you have more interesting exploit vectors at your disposal.

81
00:06:07,560 --> 00:06:15,500
You may be interested in pulling SMS text data or RCS sex data and just passively sniff that information.

82
00:06:15,760 --> 00:06:16,380
Right.

83
00:06:16,560 --> 00:06:20,520
You could also spoof messages coming from users that you target.

84
00:06:20,700 --> 00:06:23,680
And all this allows you to do something else.

85
00:06:23,680 --> 00:06:28,580
So you could target OTP code sent over SMS to get yourself MFA bypass.

86
00:06:29,440 --> 00:06:38,280
So we all know like there's forgot your password opportunities to just like get a code sent to your text for a phone and then you can log in.

87
00:06:39,800 --> 00:06:40,360
Wink wink.

88
00:06:40,520 --> 00:06:41,960
That is our demo later today.

89
00:06:42,100 --> 00:06:44,960
So we'll be covering what can be worse than all that.

90
00:06:45,140 --> 00:06:46,840
Well how about a pivot to the kernel.

91
00:06:46,980 --> 00:06:51,880
So with full root kernel privilege access you have the ability to fully own the phone.

92
00:06:52,060 --> 00:06:52,920
All bets are off.

93
00:06:54,360 --> 00:06:58,440
So before getting into our finding as an exploit work a little background on the modem is always helpful.

94
00:06:59,840 --> 00:07:00,280
Wait.

95
00:07:00,380 --> 00:07:01,700
Who snuck this slide in?

96
00:07:01,980 --> 00:07:03,760
It's a 56K modem.

97
00:07:03,820 --> 00:07:04,860
It's not what we're talking about.

98
00:07:06,100 --> 00:07:07,120
It's very clever.

99
00:07:07,780 --> 00:07:09,040
There's zero laughs there.

100
00:07:10,620 --> 00:07:11,500
Thank you.

101
00:07:11,940 --> 00:07:13,720
This is better than Black Hat.

102
00:07:13,820 --> 00:07:14,060
Thanks.

103
00:07:15,420 --> 00:07:16,160
Moving on.

104
00:07:16,620 --> 00:07:18,100
Let's talk about pixel modem.

105
00:07:18,140 --> 00:07:18,760
What even is it?

106
00:07:18,820 --> 00:07:21,560
Well it provides you a means to connect to a cellular network.

107
00:07:21,560 --> 00:07:25,240
So you can check text, surf the web, get phone calls.

108
00:07:25,520 --> 00:07:29,300
It's a critical component with access to sensitive user data like SMS data.

109
00:07:30,180 --> 00:07:36,940
Remotely accessible with radio technologies and it's a high profile target for nation state and project zero.

110
00:07:37,080 --> 00:07:39,560
If you listen to the offensive con talk from earlier this year.

111
00:07:40,180 --> 00:07:44,440
It's been a historical source of vulnerabilities because it's using legacy protocols.

112
00:07:44,940 --> 00:07:47,440
And these all present opportunities for security improvement.

113
00:07:47,980 --> 00:07:51,160
It's also super important to note that, you know,

114
00:07:51,160 --> 00:07:56,480
while we're all on 4G and 5G today, it still supports the 2G standard.

115
00:07:56,800 --> 00:08:00,440
And that's an important theme that we're going to get into in this presentation.

116
00:08:01,840 --> 00:08:06,320
So just a quick visual of our attack surface analysis of the modem.

117
00:08:06,620 --> 00:08:11,880
So everything you see in blue here just kind of represents the different layers and the components of the modem.

118
00:08:12,120 --> 00:08:14,940
All the way from the communication layer down to the physical layer.

119
00:08:15,420 --> 00:08:18,540
Stuff in red is what we targeted during our red team engagement.

120
00:08:19,060 --> 00:08:21,140
Dark red is what we were actually targeting.

121
00:08:21,160 --> 00:08:21,940
And this is what we were actually able to exploit.

122
00:08:22,080 --> 00:08:25,660
So specifically the pre-authentication attack surface in 2G.

123
00:08:26,040 --> 00:08:28,660
As well as some low level decoders such as ASAN 1.

124
00:08:30,640 --> 00:08:35,040
If you see AKA that just basically means authentication and key agreement.

125
00:08:35,320 --> 00:08:41,600
Which is just a common protocol in cellular communications to support mutual off between a device and a carrier.

126
00:08:43,660 --> 00:08:47,940
Before I hand it off to Xuan, I want to get ahead of a question that maybe some of you are already asking.

127
00:08:47,940 --> 00:08:51,800
And it's, well, I'm on a current generation Pixel or iPhone.

128
00:08:52,180 --> 00:08:54,380
And I'm connected to 5G right now.

129
00:08:54,860 --> 00:08:56,080
I'm safe, right?

130
00:08:56,260 --> 00:08:58,580
Why does your presentation matter to me?

131
00:08:58,940 --> 00:09:03,200
Well, there's a lot of ways you can find yourself forced back on 2G.

132
00:09:04,320 --> 00:09:07,260
So just listing a couple here, some of these factors.

133
00:09:07,380 --> 00:09:11,760
And it's important to note that there's a lot of complex logic that goes into how each of these factors are weighted.

134
00:09:12,160 --> 00:09:13,140
It's not straightforward.

135
00:09:13,660 --> 00:09:16,100
But if you think of things like network coverage.

136
00:09:16,520 --> 00:09:17,920
Depending on the country or region.

137
00:09:17,940 --> 00:09:18,560
The region you're in.

138
00:09:18,980 --> 00:09:20,640
2G may be your only option.

139
00:09:21,460 --> 00:09:24,440
So if you're there, you're on 2G if you want to make a phone call.

140
00:09:24,920 --> 00:09:25,840
Emergency calls.

141
00:09:26,300 --> 00:09:29,580
Often over 2G when others aren't available.

142
00:09:30,020 --> 00:09:32,280
Other standards like 4G and 5G.

143
00:09:32,540 --> 00:09:36,260
There's signal strength, network congestion, battery optimization.

144
00:09:36,740 --> 00:09:39,440
So 2G uses less battery than 4G.

145
00:09:39,620 --> 00:09:43,960
So if you're low battery, that might be a factor that influences you to switch over to 2G.

146
00:09:44,660 --> 00:09:47,440
These individual factors actually don't matter too much.

147
00:09:47,940 --> 00:09:53,840
The intent of this slide is to just show that a motivated adversary will find the right combination of these ingredients.

148
00:09:54,160 --> 00:09:56,780
To influence your phone to switch back to 2G.

149
00:09:57,120 --> 00:10:00,360
And it's in 2G that our attack lives and thrives.

150
00:10:00,760 --> 00:10:02,560
So with that, I'll hand it over to Xuan.

151
00:10:02,800 --> 00:10:04,300
Who will cover our methodologies.

152
00:10:08,920 --> 00:10:09,780
Thank you for that.

153
00:10:12,460 --> 00:10:12,900
Okay.

154
00:10:13,220 --> 00:10:14,800
Before we talk about our results.

155
00:10:15,020 --> 00:10:16,380
Let's talk about our approaches.

156
00:10:16,380 --> 00:10:22,800
So for our engagement, we conducted mostly with fuzzing as our primary approach.

157
00:10:23,260 --> 00:10:27,700
The reason that we want fuzzing is that we were given a really large code base.

158
00:10:27,940 --> 00:10:29,440
And it's very complex.

159
00:10:29,860 --> 00:10:32,220
And fuzzing has been proven very effective.

160
00:10:32,460 --> 00:10:35,360
And long lasting for this kind of situations.

161
00:10:36,880 --> 00:10:41,520
For fuzzing, we mostly focused on something we call host-based fuzzing.

162
00:10:41,680 --> 00:10:44,940
Here host is a term coming from Android build system.

163
00:10:45,100 --> 00:10:46,360
It's in comparison to devices.

164
00:10:46,380 --> 00:10:49,920
Host-based fuzzing means that we find our target.

165
00:10:50,120 --> 00:10:54,100
We compile it into a fuzzer that can run on Linux host environment.

166
00:10:54,600 --> 00:10:58,160
And to do that, we need to carefully hack the build system.

167
00:10:58,480 --> 00:11:00,320
And mock the hardware dependencies.

168
00:11:00,540 --> 00:11:06,300
So that we can build our target and run it on the Linux environment without physical devices attached.

169
00:11:07,400 --> 00:11:11,560
We also looked into emulations of full systems.

170
00:11:11,780 --> 00:11:15,640
That allows us to do more closer to the actual hardware attacks.

171
00:11:15,640 --> 00:11:20,060
And lastly, we planned on doing on-device fuzzing at the beginning.

172
00:11:20,300 --> 00:11:21,940
But we were running out of time.

173
00:11:22,040 --> 00:11:22,740
So that was cut.

174
00:11:24,340 --> 00:11:25,780
Fuzzing is our primary approach.

175
00:11:26,000 --> 00:11:27,960
In addition to fuzzing, we also use static analysis.

176
00:11:28,380 --> 00:11:34,320
Here we use code QL as our primary tool for something like exploring the code base or doing variant analysis.

177
00:11:35,100 --> 00:11:43,840
And lastly, manual code review is always our last resort to apply on the areas identified by the above two approaches.

178
00:11:44,080 --> 00:11:45,620
All the areas identified.

179
00:11:45,640 --> 00:11:47,260
Hard to cover by those two approaches.

180
00:11:49,820 --> 00:11:53,080
So by the end of the engagement, we created ten fuzzers.

181
00:11:53,740 --> 00:11:54,880
Host-based fuzzers.

182
00:11:55,440 --> 00:11:58,620
Running our internal fuzzing platform 24-7.

183
00:11:58,960 --> 00:12:01,080
This is benefit that you get from fuzzing.

184
00:12:01,180 --> 00:12:04,020
Is that you get something running all the time after engagement.

185
00:12:04,520 --> 00:12:09,920
And it's very useful to catch regressions or new bugs at long runs.

186
00:12:11,320 --> 00:12:14,640
We also developed a very easy to use framework.

187
00:12:15,640 --> 00:12:23,740
So that we can easily convert any new modern component that we think is suspicious into a host-based fuzzer in future engagement.

188
00:12:24,640 --> 00:12:28,600
And during this engagement, we found fuzzers not only are great at finding bugs.

189
00:12:28,880 --> 00:12:31,580
They also tell you which area you should look into.

190
00:12:31,960 --> 00:12:35,340
By the number of crashes you found, you can jump into the area.

191
00:12:35,640 --> 00:12:45,180
One thing we noticed that fuzzing fuzzers sometimes are blocked by the minor issues like null point reference and one byte OB read.

192
00:12:45,900 --> 00:12:47,220
Those can get fixed.

193
00:12:47,500 --> 00:12:49,940
But to fix this in production code takes time.

194
00:12:50,380 --> 00:12:54,380
Our solution is while it's getting fixed, let's just jump into the code.

195
00:12:54,460 --> 00:12:55,460
Start manual code review.

196
00:12:55,640 --> 00:12:56,740
Auditing the related code.

197
00:12:56,960 --> 00:12:59,780
So that we can speed up our bug finding process.

198
00:13:00,280 --> 00:13:03,060
And find as many as bugs by the end of the engagement.

199
00:13:04,340 --> 00:13:10,380
Another challenge we run into is with large code base, how can we prioritize our component for fuzzing?

200
00:13:10,720 --> 00:13:15,160
We were giving the code base something around 2 gigabytes with source code.

201
00:13:15,160 --> 00:13:15,860
And libraries.

202
00:13:16,220 --> 00:13:20,000
And how can we find out which one is the first target?

203
00:13:20,880 --> 00:13:22,780
It's impossible to look through the source code.

204
00:13:23,000 --> 00:13:25,860
What we did is let's study the 3GPP spec.

205
00:13:26,100 --> 00:13:28,820
Understand which component is dealing with untrusted data.

206
00:13:29,000 --> 00:13:31,580
Or which component is dealing with decoders.

207
00:13:32,660 --> 00:13:36,260
Like for example here, ASM decoder, it's always a hot topic.

208
00:13:36,400 --> 00:13:37,580
So that's our first target.

209
00:13:38,040 --> 00:13:44,400
And another thing like the TLV data structures that commonly used in the 3GPP spec.

210
00:13:44,400 --> 00:13:46,900
Those are all the code targets for our fuzzing.

211
00:13:49,940 --> 00:13:53,560
And in addition, we use CodeQL as our static analysis tools.

212
00:13:54,340 --> 00:13:59,420
Modem not only has large code space, code size, but also has very complex configurations.

213
00:14:00,040 --> 00:14:05,780
These configurations involves compiler macros and redefinitions of some symbols.

214
00:14:06,180 --> 00:14:10,440
It's not easy to pinpoint which function you are looking at.

215
00:14:10,720 --> 00:14:13,300
And CodeQL helps a lot with this thing.

216
00:14:13,300 --> 00:14:18,000
It gives us the exact function that used for the task entry point.

217
00:14:18,180 --> 00:14:19,400
All interrupt handlers.

218
00:14:19,660 --> 00:14:22,920
It also visualizes the interactions between different components.

219
00:14:23,880 --> 00:14:28,200
The other way we use CodeQL is to do general bug findings.

220
00:14:28,620 --> 00:14:30,660
We use that to find certain patterns.

221
00:14:30,860 --> 00:14:36,300
Like memcpy that writes to a fixed size buffer but uses a non-constant size parameter.

222
00:14:36,780 --> 00:14:38,860
It doesn't necessarily have to be an issue.

223
00:14:39,020 --> 00:14:41,840
But there are issues coming from that kind of usages.

224
00:14:41,840 --> 00:14:44,600
And also, fuzzers find bugs.

225
00:14:44,960 --> 00:14:49,080
We use CodeQL errors to try to do valid analysis for those bugs.

226
00:14:49,280 --> 00:14:50,960
Trying to see if we can find similar bugs.

227
00:14:54,260 --> 00:15:00,740
Lastly, by the end of the engagement, we noticed there's a publication research paper called FormWire.

228
00:15:01,180 --> 00:15:03,380
Which is doing emulation-based fuzzing.

229
00:15:03,500 --> 00:15:09,580
Inspired by that, we also create our own full-stack emulation using core-based approach.

230
00:15:10,340 --> 00:15:11,820
We use the hardware later.

231
00:15:11,840 --> 00:15:16,120
With the layers added, we can drop in the FormWire binary and emulate part of the functions.

232
00:15:16,420 --> 00:15:21,040
Which is great for root cause analysis and debugging of our crashes.

233
00:15:23,120 --> 00:15:27,360
By the way, here's how it looks like when we run our emulation-based fuzzer.

234
00:15:27,520 --> 00:15:33,120
And what happens when we throw in the crash test input that we discovered from the host-based fuzzer.

235
00:15:33,300 --> 00:15:39,400
It gives us more information on the memory layout and lots of details that we couldn't have from the host-based fuzzer.

236
00:15:41,840 --> 00:15:44,280
From here, I'll hand over to Eugene to talk about findings.

237
00:15:48,480 --> 00:15:49,380
Thank you, Shuan.

238
00:15:49,820 --> 00:15:55,320
Before we go into details of the vulnerabilities which we identified during fuzzing and code review.

239
00:15:56,340 --> 00:16:02,240
I'd like to bring your attention to a really great research presented earlier this year at the OffensiveCon by Google Project Zero.

240
00:16:03,800 --> 00:16:06,380
How to hack Shannon Baseband from a phone.

241
00:16:07,060 --> 00:16:11,580
Which focuses on a different attack surface that we investigated in our work.

242
00:16:11,840 --> 00:16:14,420
They were hacking modem from a phone.

243
00:16:14,720 --> 00:16:17,760
While we are hacking modem from a malicious base station.

244
00:16:18,040 --> 00:16:19,820
So this is an important distinction here.

245
00:16:20,360 --> 00:16:25,060
At the same time, they mentioned that they were looking at 2G and SN.1 attack surface.

246
00:16:25,440 --> 00:16:28,960
And they mentioned that they didn't find anything interesting there.

247
00:16:29,080 --> 00:16:30,380
Like maybe all the bugs are gone.

248
00:16:31,620 --> 00:16:37,720
Honestly, when our engagement team saw this presentation, we felt very relieved and very rewarded for the statement.

249
00:16:37,880 --> 00:16:40,700
Which might mean that we are...

250
00:16:40,700 --> 00:16:47,980
Our bug hunting work, which took one year earlier, was actually useful and meaningful.

251
00:16:48,660 --> 00:16:50,760
We're not going to take all the credit for that.

252
00:16:50,880 --> 00:16:54,200
There has been other great research contributing to security in this area.

253
00:16:54,640 --> 00:16:57,620
But with the next slide, I would like to introduce some additional context.

254
00:16:59,840 --> 00:17:03,940
During this engagement, which spans about three to four months.

255
00:17:04,300 --> 00:17:10,680
In total, we identified about 120 vulnerabilities in 2G and SN.1.

256
00:17:10,700 --> 00:17:18,020
And about 50 vulnerabilities are specifically in SN.1 decoders.

257
00:17:18,320 --> 00:17:22,220
And as you can see, the vast majority of these bugs were got by fuzzers.

258
00:17:22,560 --> 00:17:25,460
Like about 80% of the vulnerabilities were reported by fuzzers.

259
00:17:26,340 --> 00:17:30,680
And we were mostly relying on stack traces to dedupe the vulnerabilities.

260
00:17:31,120 --> 00:17:33,840
So there is a chance that there is the same root cause.

261
00:17:34,020 --> 00:17:37,120
But it manifests itself in different crashes.

262
00:17:37,240 --> 00:17:38,960
So they got different bugs assignments.

263
00:17:40,120 --> 00:17:40,680
So...

264
00:17:40,700 --> 00:17:44,340
Those fuzzers are running even today on our continuous fuzzing infrastructure.

265
00:17:45,300 --> 00:17:46,200
Fun fact.

266
00:17:46,660 --> 00:17:51,360
Shortly after submitting to Black Hat and DEF CON, one of the fuzzers identified a critical issue.

267
00:17:51,720 --> 00:17:56,900
And we were even thinking about withdrawing from the conferences.

268
00:17:56,920 --> 00:17:59,420
Because we didn't want to release zero days.

269
00:17:59,580 --> 00:18:05,380
And there is no way PRN Legal would clear this presentation to be here.

270
00:18:05,700 --> 00:18:07,080
But, well, here we go.

271
00:18:07,200 --> 00:18:08,240
The issue was fixed.

272
00:18:08,340 --> 00:18:09,760
And we're speaking about it.

273
00:18:10,700 --> 00:18:17,100
By critical vulnerabilities, we mean mostly out of bounds memory rights, which are reachable remotely.

274
00:18:18,080 --> 00:18:20,800
Obviously, not all the criticals are exploitable.

275
00:18:21,060 --> 00:18:28,280
Because we got quite a few off by one rights, which are very difficult to leverage to get code execution on modem in a remote context.

276
00:18:28,640 --> 00:18:33,180
Yet we got quite a few powerful primitives.

277
00:18:33,420 --> 00:18:39,360
So one of them, which we shall be discussing later, the core primitive for demonstrating code execution on modem,

278
00:18:40,700 --> 00:18:41,380
is 17-0.

279
00:18:41,500 --> 00:18:44,740
This is an out-of-bounds writing heap.

280
00:18:44,960 --> 00:18:49,840
There is another vulnerability, which would make exploitation super easy and straightforward.

281
00:18:50,300 --> 00:18:51,380
Well, not super easy.

282
00:18:51,500 --> 00:18:52,720
Definitely not super easy.

283
00:18:52,920 --> 00:18:56,680
But we didn't need to rely on rope-style attacks.

284
00:18:57,540 --> 00:19:02,020
It's MMU misconfiguration, which rendered heap and stack executable.

285
00:19:02,180 --> 00:19:06,480
So simply running a shell code from the heap worked just fine.

286
00:19:07,440 --> 00:19:10,680
And with that, let's take a look.

287
00:19:10,700 --> 00:19:13,280
Let's look at the vulnerability as 2017-0.

288
00:19:13,580 --> 00:19:15,800
This is a linear out-of-bounds writing heap.

289
00:19:16,500 --> 00:19:20,960
This is a classic straightforward out-of-bounds writing heap.

290
00:19:21,280 --> 00:19:25,380
You can see on the code snippet here.

291
00:19:25,640 --> 00:19:25,820
Okay.

292
00:19:25,920 --> 00:19:26,300
Yeah.

293
00:19:26,380 --> 00:19:29,640
So we have one byte buffer allocated at this point.

294
00:19:30,560 --> 00:19:34,940
And this buffer is passed to ACN decode information element function,

295
00:19:35,260 --> 00:19:40,640
which decodes arbitrary number fully attacker controlled bytes into it.

296
00:19:41,440 --> 00:19:48,800
Due to technical constraints, we are able to overwrite only up to 255 bytes on the heap,

297
00:19:48,880 --> 00:19:50,140
but which is still a lot.

298
00:19:50,580 --> 00:19:56,680
And this vulnerability is triggered during the call setup stage.

299
00:19:57,120 --> 00:20:03,220
So before receiving the call and even before showing notification to user that someone is calling them,

300
00:20:03,400 --> 00:20:08,340
there is a number of ACN1 messages sent from the base station to the modem.

301
00:20:08,520 --> 00:20:10,180
And exploitation happens.

302
00:20:10,180 --> 00:20:13,060
The vulnerability is triggered at this stage.

303
00:20:13,220 --> 00:20:15,280
So there is no user interaction involved at all.

304
00:20:15,420 --> 00:20:17,680
User doesn't need to pick up the phone.

305
00:20:19,840 --> 00:20:22,480
So this is a very powerful primitive by itself.

306
00:20:22,820 --> 00:20:26,460
Right now we'll show you how we leverage it to get arbitrary write primitive.

307
00:20:27,100 --> 00:20:30,500
But before doing this, a few words about heap management,

308
00:20:30,680 --> 00:20:35,140
because it is important to understand how we are getting arbitrary write.

309
00:20:35,420 --> 00:20:39,460
So every buffer allocated on the heap is prefixed

310
00:20:39,460 --> 00:20:43,060
with a 32-byte heater, which contains metadata for the allocation,

311
00:20:43,280 --> 00:20:48,840
such as how many bytes were requested, what is the task ID, allocating memory.

312
00:20:49,380 --> 00:20:53,140
And a very important information stored in the very beginning,

313
00:20:53,260 --> 00:20:56,980
the first two bytes, is the identifier of the allocation driver.

314
00:20:57,360 --> 00:21:00,760
So it appears there is multiple allocation drivers used by malloc.

315
00:21:01,360 --> 00:21:04,260
And one of them is a partitioned memory driver,

316
00:21:04,440 --> 00:21:08,220
which corresponds to 0400, highlighted here in red.

317
00:21:08,220 --> 00:21:15,100
Essentially, it allocates memory from an array of fixed-size memory blocks,

318
00:21:15,340 --> 00:21:18,640
which grow with the power of two.

319
00:21:18,980 --> 00:21:25,280
The state of the memory blocks is kept in the additional bitmap.

320
00:21:27,000 --> 00:21:29,760
And looking at this partitioned memory driver,

321
00:21:29,980 --> 00:21:36,460
we didn't find anything what we can do with this to override something useful.

322
00:21:36,740 --> 00:21:38,200
However, looking at this partitioned memory driver,

323
00:21:38,220 --> 00:21:40,800
looking around, we identified there is another allocation driver,

324
00:21:41,160 --> 00:21:44,660
system dynamic memory driver, which has ID 0100.

325
00:21:45,120 --> 00:21:51,020
And luckily for us, but unluckily for modem,

326
00:21:51,260 --> 00:21:57,320
they are using double-linked lists with unsafe un-linking.

327
00:21:57,540 --> 00:22:01,200
And this double-linked list is also in the heap heater,

328
00:22:01,300 --> 00:22:02,400
which we are able to override.

329
00:22:02,820 --> 00:22:06,980
So this is pretty straightforward, classical unsafe un-linking technique

330
00:22:06,980 --> 00:22:08,280
to get arbitrary right.

331
00:22:08,860 --> 00:22:19,240
In our case, the adjacent object, which follows the vulnerable buffer,

332
00:22:19,480 --> 00:22:26,320
is very reliably allocated during the vulnerability exploitation stage.

333
00:22:26,820 --> 00:22:31,100
So I think in 90% of cases, well, maybe even closer to 99,

334
00:22:31,420 --> 00:22:36,540
there is always another object following right after the vulnerable buffer.

335
00:22:36,980 --> 00:22:41,240
So as you can see on this image, the address starts at 3A0,

336
00:22:41,540 --> 00:22:46,620
is actually the vulnerable buffer, which corresponds to the one-byte buffer,

337
00:22:46,840 --> 00:22:52,120
and at the address 3C0 is the heater of the next adjacent object.

338
00:22:52,400 --> 00:22:56,580
So we simply override it, we change the allocation driver ID to 0100,

339
00:22:56,960 --> 00:23:02,160
we forge the double-linked list, and luckily for us,

340
00:23:02,240 --> 00:23:04,060
and again, luckily for modem,

341
00:23:04,060 --> 00:23:08,180
this buffer is very reliably freed after the override operation.

342
00:23:08,680 --> 00:23:12,560
So we almost have a very reliable arbitrary right primitive,

343
00:23:12,800 --> 00:23:16,520
and we use this primitive to hook free function.

344
00:23:18,020 --> 00:23:21,040
The implementation of the free function in this modem is quite generic.

345
00:23:21,260 --> 00:23:25,640
It's just a stub which calls real implementation using function pointer,

346
00:23:25,960 --> 00:23:27,360
which is stored in global variables.

347
00:23:27,700 --> 00:23:32,300
So we simply override this global pointer, and this is how we hook the function.

348
00:23:32,300 --> 00:23:38,020
Just to summarize everything together, how is the getting RCN modem looks like.

349
00:23:38,420 --> 00:23:41,400
Before the overflow, we have buffer A and buffer B.

350
00:23:41,540 --> 00:23:48,980
Buffer B has partition memory driver allocation driver ID.

351
00:23:49,340 --> 00:23:52,940
We override it and change to system dynamic allocator.

352
00:23:53,160 --> 00:23:55,060
We forge the double-linked list.

353
00:23:55,360 --> 00:24:00,620
So we modify field to point to a malicious system heater,

354
00:24:00,620 --> 00:24:07,120
which is located in the global data, which is readable, writable, and executable,

355
00:24:07,260 --> 00:24:09,020
thanks to the MMU misconfiguration.

356
00:24:10,400 --> 00:24:15,160
And this is also part of the stage 0 payload, which contains shellcode.

357
00:24:15,480 --> 00:24:19,880
And once this buffer is freed, during unsafe unlinking,

358
00:24:20,080 --> 00:24:23,640
we modify the free function pointer, redirect it to our shellcode,

359
00:24:24,440 --> 00:24:25,720
and here is how it works.

360
00:24:26,360 --> 00:24:28,720
There is one unclear piece here.

361
00:24:28,960 --> 00:24:30,520
Well, at least one for me.

362
00:24:30,620 --> 00:24:33,440
How did you get stage 0 payload here?

363
00:24:33,860 --> 00:24:37,800
This is what I'm going to be discussing here.

364
00:24:38,100 --> 00:24:44,480
So before triggering the vulnerability, we need to send the stage 0 shellcode.

365
00:24:45,640 --> 00:24:48,900
And we identify the primitive for doing this,

366
00:24:49,120 --> 00:24:55,440
which allows us to send from the malicious base station to the victim device up to 80 bytes.

367
00:24:55,660 --> 00:24:58,540
And we know where exactly those 80 bytes are stored

368
00:24:58,540 --> 00:25:07,580
because we need to know the virtual address at which this malicious 0 shellcode is located.

369
00:25:08,060 --> 00:25:09,320
There is no ASLR.

370
00:25:10,120 --> 00:25:11,780
So this address is fixed.

371
00:25:12,660 --> 00:25:18,260
Once we have it, we trigger CV 2017-0 to free function.

372
00:25:18,700 --> 00:25:22,180
And at this point, we're invoking our stage 0 shellcode.

373
00:25:22,420 --> 00:25:27,220
At every free operation, it is very convenient because we're able to inspect contents

374
00:25:27,220 --> 00:25:28,520
of the free buffer.

375
00:25:28,860 --> 00:25:32,620
And the heap is used very frequently in many cases in modems

376
00:25:32,620 --> 00:25:35,900
or we can intercept and inspect for a lot of data.

377
00:25:36,940 --> 00:25:42,820
80 bytes is actually not a lot to implement anything meaningful for stage 0 shellcode

378
00:25:42,820 --> 00:25:44,180
because it's not only shellcode.

379
00:25:44,300 --> 00:25:48,920
It's also the malicious system dynamic heap heater.

380
00:25:49,180 --> 00:25:56,100
And what stage 0 shellcode is doing is just functionality to receive stage 1 shellcode,

381
00:25:56,100 --> 00:25:59,320
which is also sent in chunks, 80 bytes per iteration.

382
00:26:00,100 --> 00:26:02,020
Later, Shalink will show you a demo.

383
00:26:02,260 --> 00:26:06,240
And you can see how we're sending stage 1 shellcode there.

384
00:26:06,500 --> 00:26:10,920
Stage 0 shellcode assembles stage 1 shellcode altogether,

385
00:26:11,440 --> 00:26:14,700
copies it into your executable heap,

386
00:26:14,900 --> 00:26:16,980
and re-hooks free function.

387
00:26:17,340 --> 00:26:21,700
And at this point, we can implement arbitrary complexity functionality in stage 1 shellcode.

388
00:26:21,960 --> 00:26:24,420
We implemented SMS forwarding functionality,

389
00:26:24,420 --> 00:26:29,860
which forwards SMS messages from the victim device to the attacker control number.

390
00:26:30,320 --> 00:26:32,340
And at this point, we are ready for the demo.

391
00:26:40,660 --> 00:26:45,080
So let's go to the remote code execution into modern firmware.

392
00:26:46,980 --> 00:26:49,580
So here is how the attack looks like.

393
00:26:49,940 --> 00:26:54,400
The first step, the victim connects to a digital serial network.

394
00:26:54,420 --> 00:26:58,380
Either 3G, 4G, or 5G, it doesn't matter.

395
00:26:58,780 --> 00:27:03,880
The only requirement is that the victim enables 2G on his phone.

396
00:27:04,580 --> 00:27:10,640
But, you know, 2G is default enabled on the PS6 and on most of the phones.

397
00:27:11,840 --> 00:27:16,140
So now we can set up a malicious base station.

398
00:27:16,480 --> 00:27:18,180
It's a 2G base station.

399
00:27:18,400 --> 00:27:22,320
We are setting it up and waiting for the victim to connect to it.

400
00:27:22,320 --> 00:27:26,680
You know, there are a lot of purpose and methods

401
00:27:27,320 --> 00:27:31,420
about how to get a victim connected to a fake 2G base station.

402
00:27:31,680 --> 00:27:33,460
So this is not a problem.

403
00:27:34,400 --> 00:27:38,380
Then we are waiting for the victim to connect to it.

404
00:27:38,640 --> 00:27:41,960
And once the victim connects to the 2G base station,

405
00:27:42,120 --> 00:27:43,260
we can start our attack.

406
00:27:44,480 --> 00:27:46,040
Once the attack succeeds,

407
00:27:46,780 --> 00:27:50,740
we will have fully controlled the victim's baseband firmware.

408
00:27:50,740 --> 00:27:53,160
We are in the victim's model.

409
00:27:53,700 --> 00:27:56,700
So now we can do a lot of funny stuff.

410
00:27:57,140 --> 00:27:59,200
For example, we can use the job

411
00:27:59,200 --> 00:28:04,300
or intercept the victim's incoming phone call.

412
00:28:04,600 --> 00:28:08,300
Also, we can modify the incoming SMS message

413
00:28:08,300 --> 00:28:12,280
or send out SMS message on behalf of the victim.

414
00:28:13,040 --> 00:28:14,340
Here, for demo purpose,

415
00:28:14,600 --> 00:28:20,720
we can capture and transfer all the incoming SMS messages

416
00:28:20,740 --> 00:28:22,540
to our phone

417
00:28:22,540 --> 00:28:25,740
so that we can take over the victim's Twitter account.

418
00:28:27,800 --> 00:28:29,540
Here are the devices we are using.

419
00:28:29,720 --> 00:28:30,920
We are using three devices.

420
00:28:31,200 --> 00:28:34,200
On the left is the victim using Pixel 6.

421
00:28:34,420 --> 00:28:37,360
And in the middle is the OpenBTS.

422
00:28:37,680 --> 00:28:41,060
We built this fake base station using OpenBTS.

423
00:28:41,360 --> 00:28:43,760
And we will modify the source code,

424
00:28:43,900 --> 00:28:45,960
inject our malicious package,

425
00:28:46,660 --> 00:28:47,680
and do our attack.

426
00:28:48,000 --> 00:28:50,160
And on the right is another phone.

427
00:28:50,740 --> 00:28:51,380
This is a regular phone.

428
00:28:52,120 --> 00:28:54,500
Any phone can make a call.

429
00:28:54,580 --> 00:28:55,200
It works for us.

430
00:28:56,300 --> 00:28:56,360
Okay.

431
00:28:58,140 --> 00:29:00,200
So let's play the demo.

432
00:29:03,100 --> 00:29:03,960
It's all working.

433
00:29:07,140 --> 00:29:08,700
Let me figure out why.

434
00:29:09,980 --> 00:29:12,640
I think we can click it.

435
00:29:15,240 --> 00:29:17,700
Okay, so we are playing the demo.

436
00:29:17,800 --> 00:29:19,260
You can see the victim is going to connect

437
00:29:20,740 --> 00:29:20,860
to the station.

438
00:29:21,080 --> 00:29:22,480
Once the victim is connected,

439
00:29:22,760 --> 00:29:24,460
we can start our attack.

440
00:29:24,820 --> 00:29:27,740
The first step is to send out the initial payload.

441
00:29:28,040 --> 00:29:29,740
This is a small piece of code.

442
00:29:29,960 --> 00:29:32,640
So we will broadcast this piece of code

443
00:29:32,640 --> 00:29:35,180
into the victim's modern firmware memory.

444
00:29:35,540 --> 00:29:38,300
So now it's inside the victim's modern memory,

445
00:29:38,480 --> 00:29:39,240
but it's not running.

446
00:29:39,600 --> 00:29:41,680
We are going to run it by calling the victim.

447
00:29:42,000 --> 00:29:44,240
Once the victim receives the call,

448
00:29:44,460 --> 00:29:46,300
the victim doesn't have to do anything.

449
00:29:47,060 --> 00:29:48,860
Our vulnerability will be triggered.

450
00:29:48,860 --> 00:29:51,240
And this initial payload will be triggered.

451
00:29:51,620 --> 00:29:52,860
So at this moment,

452
00:29:53,020 --> 00:29:55,820
we already have a small piece of code running

453
00:29:55,820 --> 00:29:57,360
inside the victim's modern,

454
00:29:57,580 --> 00:29:59,360
but it's just a small piece of code.

455
00:29:59,540 --> 00:30:01,100
We want to do a more complicated task.

456
00:30:01,300 --> 00:30:03,140
So we are sending more code.

457
00:30:03,260 --> 00:30:05,600
We are sending them piece by piece.

458
00:30:05,800 --> 00:30:07,500
And the first stage payload

459
00:30:07,500 --> 00:30:09,700
will receive and assemble them together.

460
00:30:10,080 --> 00:30:11,940
Once all the code received,

461
00:30:13,500 --> 00:30:15,720
the shared code will be running

462
00:30:15,720 --> 00:30:18,780
and send out a message back

463
00:30:18,860 --> 00:30:20,020
so you can see now.

464
00:30:20,160 --> 00:30:23,020
We received a message from the victim

465
00:30:23,020 --> 00:30:25,040
and the content is the pound.

466
00:30:25,220 --> 00:30:28,260
So this SMS message is sending out

467
00:30:28,760 --> 00:30:30,520
from the victim's modern firmware

468
00:30:30,520 --> 00:30:32,020
by all shared code.

469
00:30:32,300 --> 00:30:34,160
So that means all shared code

470
00:30:34,160 --> 00:30:37,380
is running successfully inside the victim's modern

471
00:30:37,380 --> 00:30:39,820
and we have fully controlled the victim's modern.

472
00:30:40,540 --> 00:30:41,100
Okay.

473
00:30:41,560 --> 00:30:43,740
This is the first part of the demo.

474
00:30:43,940 --> 00:30:44,800
For the second part,

475
00:30:45,020 --> 00:30:45,740
we are going to demo

476
00:30:45,740 --> 00:30:48,500
we can take over the victim's Twitter account

477
00:30:48,860 --> 00:30:50,780
to do that let's put the victim

478
00:30:50,780 --> 00:30:52,300
back to a normal base station.

479
00:30:52,540 --> 00:30:54,660
So you can see now the victim

480
00:30:55,780 --> 00:30:58,520
connect back to the normal base station.

481
00:30:59,440 --> 00:31:02,060
That's simply we stop our base station

482
00:31:02,060 --> 00:31:04,760
then the victim will connect back.

483
00:31:05,020 --> 00:31:07,840
So the victim can log into Twitter

484
00:31:07,840 --> 00:31:08,820
or GitHub.

485
00:31:09,260 --> 00:31:09,620
Yeah.

486
00:31:10,100 --> 00:31:10,700
Okay.

487
00:31:11,360 --> 00:31:14,680
So now the victim open his Twitter account

488
00:31:14,680 --> 00:31:16,680
check him for the new message

489
00:31:16,680 --> 00:31:18,300
and also

490
00:31:18,860 --> 00:31:19,640
his profile.

491
00:31:20,040 --> 00:31:21,720
You can see he's very handsome

492
00:31:21,720 --> 00:31:25,540
and he has a brilliant profile

493
00:31:25,540 --> 00:31:27,000
and also

494
00:31:27,000 --> 00:31:28,800
anyone know who is the victim?

495
00:31:30,020 --> 00:31:30,620
Okay.

496
00:31:31,040 --> 00:31:31,640
Yeah.

497
00:31:31,820 --> 00:31:32,460
I think

498
00:31:32,460 --> 00:31:34,260
if you now come to us

499
00:31:34,260 --> 00:31:35,080
and get the bonus.

500
00:31:35,820 --> 00:31:36,420
Okay.

501
00:31:36,780 --> 00:31:39,160
So if you have a Twitter account

502
00:31:39,160 --> 00:31:41,260
but you don't remember the password

503
00:31:41,860 --> 00:31:42,800
you will tell Twitter

504
00:31:42,800 --> 00:31:44,000
I forgot my password.

505
00:31:44,240 --> 00:31:45,200
The Twitter will say

506
00:31:45,200 --> 00:31:46,980
okay give me your phone number.

507
00:31:46,980 --> 00:31:48,840
I will send you a SMS message

508
00:31:48,840 --> 00:31:51,420
which contains an authentication code.

509
00:31:51,720 --> 00:31:53,500
You give us this code back

510
00:31:54,080 --> 00:31:55,340
so we can confirm

511
00:31:55,340 --> 00:31:57,860
you own this account.

512
00:31:58,160 --> 00:31:59,540
So that's how the attack works.

513
00:31:59,920 --> 00:32:00,540
You can see

514
00:32:00,540 --> 00:32:03,020
we enter the victim's phone number

515
00:32:03,020 --> 00:32:05,600
and the victim receives this SMS

516
00:32:05,600 --> 00:32:06,960
this message.

517
00:32:07,200 --> 00:32:09,340
So you know we have a shell code

518
00:32:09,340 --> 00:32:10,660
running inside the victim's model

519
00:32:10,660 --> 00:32:13,380
so this message will be forwarded to us.

520
00:32:13,560 --> 00:32:14,640
So you can see

521
00:32:14,640 --> 00:32:16,640
we received the same message.

522
00:32:16,980 --> 00:32:20,020
So using the code inside this message

523
00:32:20,700 --> 00:32:23,820
we can bypass the authentication from Twitter

524
00:32:23,820 --> 00:32:27,480
and get into the victim's Twitter account

525
00:32:27,480 --> 00:32:29,140
and reset the password.

526
00:32:30,100 --> 00:32:30,700
Yeah.

527
00:32:31,200 --> 00:32:32,900
Here you can see the victim

528
00:32:32,900 --> 00:32:35,840
can see this message on his phone

529
00:32:35,840 --> 00:32:37,560
but this is just for demo purpose.

530
00:32:37,820 --> 00:32:38,660
In a real attack

531
00:32:38,660 --> 00:32:39,920
we can hide this message

532
00:32:39,920 --> 00:32:40,780
make it invisible.

533
00:32:41,220 --> 00:32:41,860
So.

534
00:32:42,060 --> 00:32:42,720
Okay.

535
00:32:43,660 --> 00:32:46,120
Now we have bypassed

536
00:32:46,120 --> 00:32:46,840
the authentication

537
00:32:46,980 --> 00:32:48,900
and modified the password.

538
00:32:49,580 --> 00:32:51,560
So we are sending it to

539
00:32:51,560 --> 00:32:53,780
a very strong password

540
00:32:54,380 --> 00:32:54,940
and

541
00:32:55,860 --> 00:32:56,700
I think

542
00:32:56,700 --> 00:32:57,740
we're done.

543
00:32:58,000 --> 00:32:58,560
Yeah.

544
00:32:58,700 --> 00:32:59,280
That's all.

545
00:33:00,060 --> 00:33:00,620
Yeah.

546
00:33:00,720 --> 00:33:01,920
We have to take over the account.

547
00:33:05,100 --> 00:33:05,660
Yeah.

548
00:33:06,440 --> 00:33:07,000
So.

549
00:33:07,340 --> 00:33:08,900
That's the account we have.

550
00:33:09,480 --> 00:33:10,040
Yeah.

551
00:33:10,140 --> 00:33:10,740
That's the demo

552
00:33:10,740 --> 00:33:12,600
into the remote code execution

553
00:33:13,160 --> 00:33:14,340
of modern firmware.

554
00:33:14,560 --> 00:33:14,860
Thank you.

555
00:33:18,480 --> 00:33:18,920
Yeah.

556
00:33:19,060 --> 00:33:20,300
I'll hand it over to Xuanyuan

557
00:33:20,300 --> 00:33:21,120
for the next part.

558
00:33:22,440 --> 00:33:23,260
Thank you, Xilin.

559
00:33:23,960 --> 00:33:25,360
A very impressive video.

560
00:33:32,320 --> 00:33:32,760
Okay.

561
00:33:34,960 --> 00:33:35,960
Just to clarify

562
00:33:35,960 --> 00:33:36,960
that in the video

563
00:33:36,960 --> 00:33:38,320
you see a lot of operations

564
00:33:38,320 --> 00:33:39,360
on the victim's phone

565
00:33:39,860 --> 00:33:41,360
but those are just for them

566
00:33:41,360 --> 00:33:42,640
for us to speed up the demo.

567
00:33:42,820 --> 00:33:43,880
In real case

568
00:33:43,880 --> 00:33:45,880
victim doesn't need to do anything.

569
00:33:45,880 --> 00:33:47,300
This is a zero click

570
00:33:47,640 --> 00:33:49,620
fully remote attack.

571
00:33:50,780 --> 00:33:52,280
To get the attack to happen

572
00:33:52,280 --> 00:33:53,640
there are some prerequisites.

573
00:33:53,960 --> 00:33:55,520
First the victim's device

574
00:33:55,520 --> 00:33:57,020
needs to have 2G stack enabled

575
00:33:57,020 --> 00:33:58,780
which is by default

576
00:33:58,780 --> 00:34:00,080
on Pixel 6

577
00:34:00,080 --> 00:34:01,580
and many other modern devices.

578
00:34:02,180 --> 00:34:04,020
And also the victim needs to be

579
00:34:04,020 --> 00:34:04,980
in the nearby range

580
00:34:04,980 --> 00:34:06,400
for us to deploy the attack.

581
00:34:06,640 --> 00:34:08,300
Depending on what hardware

582
00:34:08,300 --> 00:34:08,900
you're using

583
00:34:08,900 --> 00:34:10,520
this nearby range

584
00:34:10,520 --> 00:34:12,280
can be up to five miles range.

585
00:34:13,460 --> 00:34:14,900
Once we launch the attack

586
00:34:14,900 --> 00:34:16,700
we get a full modern

587
00:34:16,700 --> 00:34:17,460
firmware compromise.

588
00:34:17,760 --> 00:34:18,560
We have full control

589
00:34:18,560 --> 00:34:19,320
of the modern firmware.

590
00:34:19,540 --> 00:34:20,580
If I have time

591
00:34:20,580 --> 00:34:21,460
I can write a debugger

592
00:34:21,460 --> 00:34:22,880
for debug modern firmware.

593
00:34:23,660 --> 00:34:26,340
And in demo we just showed

594
00:34:26,340 --> 00:34:27,140
how to demonstrate

595
00:34:27,140 --> 00:34:28,380
the Twitter account takeover

596
00:34:28,900 --> 00:34:30,240
but the real consequences

597
00:34:30,240 --> 00:34:31,300
can be much worse.

598
00:34:31,660 --> 00:34:32,720
You can take over

599
00:34:32,720 --> 00:34:34,200
somebody's Bitcoin account

600
00:34:34,660 --> 00:34:36,380
get all their monies.

601
00:34:36,440 --> 00:34:38,900
Or you can even send messages

602
00:34:38,900 --> 00:34:39,960
on behalf of them.

603
00:34:41,440 --> 00:34:43,940
We also during the engagement

604
00:34:43,940 --> 00:34:44,380
found

605
00:34:44,900 --> 00:34:45,620
other bugs

606
00:34:45,620 --> 00:34:47,480
that hinting it's possible

607
00:34:47,480 --> 00:34:49,220
to pivoting from modern

608
00:34:49,220 --> 00:34:50,220
to the Android OS.

609
00:34:50,540 --> 00:34:51,860
That can lead to

610
00:34:51,860 --> 00:34:52,780
full system compromise.

611
00:34:53,200 --> 00:34:54,760
However we ran out of time

612
00:34:54,760 --> 00:34:56,300
so we didn't dig further

613
00:34:56,300 --> 00:34:57,120
in that direction.

614
00:34:58,640 --> 00:35:00,280
And the issues utilized

615
00:35:00,280 --> 00:35:01,380
by this exploit

616
00:35:01,380 --> 00:35:02,280
there are three issues.

617
00:35:02,660 --> 00:35:04,100
The first one is the root cause.

618
00:35:04,360 --> 00:35:05,600
We have attacker controlled

619
00:35:05,600 --> 00:35:07,620
heap override in the GSM stack.

620
00:35:08,040 --> 00:35:09,860
And second we have

621
00:35:09,860 --> 00:35:11,460
a misconfiguration in the MMU

622
00:35:11,460 --> 00:35:13,120
that allows us to have

623
00:35:13,120 --> 00:35:14,600
writable and executable

624
00:35:14,600 --> 00:35:14,820
memory.

625
00:35:15,260 --> 00:35:17,200
And lastly the lack of

626
00:35:17,200 --> 00:35:18,780
standard security mitigations

627
00:35:18,780 --> 00:35:20,820
making our exploit easier.

628
00:35:22,880 --> 00:35:25,020
Yeah before modern engagement

629
00:35:25,020 --> 00:35:26,860
I always thinking hacking modern

630
00:35:27,470 --> 00:35:29,640
over the air is a very high tech

631
00:35:29,640 --> 00:35:30,940
complex task.

632
00:35:31,140 --> 00:35:32,620
It requires very expensive devices.

633
00:35:33,480 --> 00:35:36,040
But our setup really surprised

634
00:35:36,040 --> 00:35:37,240
and scared me.

635
00:35:37,460 --> 00:35:39,680
As you can see it's pretty simple.

636
00:35:39,900 --> 00:35:41,400
The core part of this setup

637
00:35:41,400 --> 00:35:43,800
is that white box under the phones.

638
00:35:43,800 --> 00:35:45,200
This is the SDR device.

639
00:35:45,660 --> 00:35:48,120
In our case we use USRPB200.

640
00:35:50,160 --> 00:35:52,160
And then we have a bunch of cables.

641
00:35:52,580 --> 00:35:53,680
For legal compliances

642
00:35:53,680 --> 00:35:55,100
we also have Faraday cage.

643
00:35:55,340 --> 00:35:57,220
So that we don't interfere

644
00:35:57,220 --> 00:35:58,720
with neighborhood telecommunications.

645
00:35:59,040 --> 00:36:00,620
So if you are malicious attackers

646
00:36:00,620 --> 00:36:02,320
make sure you have this box

647
00:36:02,320 --> 00:36:03,760
so that you don't break the law.

648
00:36:04,500 --> 00:36:06,380
You don't want the FCC showed.

649
00:36:06,540 --> 00:36:08,080
Yeah it's very important.

650
00:36:08,460 --> 00:36:10,320
Anyway and for softwares

651
00:36:10,320 --> 00:36:12,640
we have software based GSM solutions.

652
00:36:12,640 --> 00:36:13,640
There are many of them.

653
00:36:14,380 --> 00:36:15,340
OpenBTS, ETPTS.

654
00:36:15,660 --> 00:36:18,380
They are either free or open source to use.

655
00:36:18,500 --> 00:36:19,120
Very accessible.

656
00:36:19,480 --> 00:36:22,020
This entire setup is very accessible.

657
00:36:22,160 --> 00:36:23,500
It's less than a couple thousand dollars.

658
00:36:23,740 --> 00:36:24,720
And you can get even cheaper

659
00:36:24,720 --> 00:36:26,460
with the cheaper SDR devices.

660
00:36:28,840 --> 00:36:30,960
And like other exploitations

661
00:36:30,960 --> 00:36:32,360
we always run into challenges.

662
00:36:32,920 --> 00:36:34,600
For this one the first challenge

663
00:36:34,600 --> 00:36:35,580
we run into is that

664
00:36:35,580 --> 00:36:39,940
when we put everything into the Faraday cage

665
00:36:39,940 --> 00:36:42,620
they interfere with each other.

666
00:36:42,640 --> 00:36:45,980
And the radio is totally black magic to me.

667
00:36:46,100 --> 00:36:47,960
So I have no idea how to solve it correctly.

668
00:36:48,340 --> 00:36:50,740
What a way to just manually take the positions

669
00:36:50,740 --> 00:36:52,180
so that they work.

670
00:36:53,640 --> 00:36:55,740
And of course we also need to mix

671
00:36:55,740 --> 00:36:57,660
a couple of softwares working together.

672
00:36:57,860 --> 00:36:59,000
They are all complex softwares.

673
00:36:59,280 --> 00:37:01,360
We have to carefully take the configurations

674
00:37:01,360 --> 00:37:03,400
so we can get a reliable exploitation.

675
00:37:04,960 --> 00:37:06,180
Because this is exploitation

676
00:37:06,180 --> 00:37:08,120
we do this on production images.

677
00:37:08,460 --> 00:37:11,480
And debugging shell code on production image

678
00:37:11,480 --> 00:37:12,200
is a pain.

679
00:37:12,640 --> 00:37:15,020
Luckily we were able to collect RAM dump

680
00:37:15,020 --> 00:37:19,120
and inspect the memory status when it crashes.

681
00:37:19,480 --> 00:37:21,780
We also modified some of the command handlers

682
00:37:22,390 --> 00:37:26,220
to confirm the successful deployment of exploitations.

683
00:37:27,200 --> 00:37:28,740
Lastly, as Eugene mentioned

684
00:37:28,740 --> 00:37:32,200
our first stage payload needs to fit 80 bytes space.

685
00:37:32,560 --> 00:37:33,880
It's less than 80 bytes

686
00:37:33,880 --> 00:37:39,320
because we also need to fit in some fake heap primitives.

687
00:37:40,440 --> 00:37:41,460
It's not easy.

688
00:37:41,460 --> 00:37:44,140
We have to go through all the ARM instructions set

689
00:37:44,140 --> 00:37:46,460
trying to see if that works.

690
00:37:47,080 --> 00:37:48,280
Eventually we got it to work.

691
00:37:48,680 --> 00:37:50,260
So there comes the demo.

692
00:37:51,820 --> 00:37:54,380
So from here I'll hand over to Eugene

693
00:37:54,380 --> 00:37:55,660
to talk about remediations.

694
00:37:59,580 --> 00:38:00,320
Thank you.

695
00:38:02,000 --> 00:38:04,240
Speaking of remediation and hardening work

696
00:38:04,240 --> 00:38:05,980
besides finding vulnerabilities

697
00:38:06,880 --> 00:38:08,660
via fuzzing and manual code review

698
00:38:09,300 --> 00:38:10,400
Android security is also

699
00:38:10,400 --> 00:38:12,720
trying to reduce attack surface

700
00:38:12,720 --> 00:38:15,120
and make exploitation of classes of the vulnerabilities

701
00:38:15,120 --> 00:38:15,840
more difficult.

702
00:38:16,220 --> 00:38:19,020
And one of the features

703
00:38:19,020 --> 00:38:21,700
which was recently shipped with Android 12

704
00:38:21,700 --> 00:38:25,800
which is supported on certain versions of Radio Hell

705
00:38:26,260 --> 00:38:30,040
is ability to disallow 2G networks

706
00:38:30,040 --> 00:38:31,940
in various SIM settings.

707
00:38:32,160 --> 00:38:33,720
And these mitigations would essentially

708
00:38:34,120 --> 00:38:35,620
make you immune to the attacks

709
00:38:35,620 --> 00:38:36,640
which we just demonstrated

710
00:38:36,640 --> 00:38:37,880
because in this case

711
00:38:38,200 --> 00:38:39,400
the enforcement works

712
00:38:39,400 --> 00:38:41,520
at the hardware and the firmware level

713
00:38:41,520 --> 00:38:43,540
and when this toggle is off

714
00:38:43,540 --> 00:38:47,240
the modem simply won't scan for 2G networks.

715
00:38:48,260 --> 00:38:49,500
Insecurity of 2G

716
00:38:52,460 --> 00:38:54,860
protocol stack is a known topic.

717
00:38:55,080 --> 00:38:57,520
There are many security features missing

718
00:38:57,520 --> 00:38:58,920
including mutual authentication

719
00:38:58,920 --> 00:39:00,880
and this is one of the reasons

720
00:39:01,370 --> 00:39:04,000
why we specifically looked in this attack surface.

721
00:39:04,540 --> 00:39:08,720
So you don't need to have the pixel device to do this.

722
00:39:09,400 --> 00:39:12,340
It should be available on the supported versions

723
00:39:12,340 --> 00:39:15,140
since Android 12 and supported Radio Hell version.

724
00:39:15,400 --> 00:39:17,040
So if you haven't done this

725
00:39:17,040 --> 00:39:20,080
Android users in this audience

726
00:39:20,080 --> 00:39:21,620
this is what I recommend doing

727
00:39:21,620 --> 00:39:23,480
especially since we are here at DEF CON.

728
00:39:25,620 --> 00:39:27,660
And in addition to that

729
00:39:28,600 --> 00:39:30,540
we are exploring options

730
00:39:30,540 --> 00:39:33,600
on enabling compiler based mitigations

731
00:39:33,600 --> 00:39:35,640
for bare metal code in production.

732
00:39:36,620 --> 00:39:37,220
Unfortunately

733
00:39:38,300 --> 00:39:40,940
state of the compiler based mitigations

734
00:39:40,940 --> 00:39:41,840
for bare metal code

735
00:39:41,840 --> 00:39:44,120
is behind of user space code

736
00:39:44,120 --> 00:39:45,900
and even kernel

737
00:39:46,700 --> 00:39:48,120
for various reasons.

738
00:39:49,540 --> 00:39:51,040
Significant resource constraints

739
00:39:51,040 --> 00:39:52,600
missing support from the tool chain.

740
00:39:52,860 --> 00:39:55,520
So this is what we are currently exploring

741
00:39:55,520 --> 00:39:56,100
and playing with

742
00:39:56,100 --> 00:39:57,780
to enable bound sanitizer

743
00:39:57,780 --> 00:39:58,780
integer sanitizer

744
00:39:58,780 --> 00:40:01,960
for the modem firmware

745
00:40:01,960 --> 00:40:04,660
running not only on the

746
00:40:05,220 --> 00:40:06,660
pre-release test devices

747
00:40:06,660 --> 00:40:08,800
but also to be used on production

748
00:40:08,800 --> 00:40:09,740
in production.

749
00:40:12,260 --> 00:40:13,740
And with that

750
00:40:13,740 --> 00:40:15,260
I'm passing it to you Farzan

751
00:40:15,260 --> 00:40:16,020
for concluding thoughts.

752
00:40:16,320 --> 00:40:17,060
Thanks Eugene.

753
00:40:19,900 --> 00:40:22,280
Just some final thoughts

754
00:40:22,280 --> 00:40:23,440
to wrap up this session.

755
00:40:23,660 --> 00:40:25,780
We again red teamed

756
00:40:25,780 --> 00:40:27,760
to secure the pixel modem.

757
00:40:28,580 --> 00:40:30,740
We found over 20 criticals

758
00:40:31,240 --> 00:40:32,640
and 50 of them in ASAN alone.

759
00:40:32,860 --> 00:40:34,060
So a big attack surface

760
00:40:34,600 --> 00:40:35,600
lots of value

761
00:40:35,600 --> 00:40:37,740
and focusing in that stack alone.

762
00:40:38,400 --> 00:40:40,240
We invested a lot in fuzzing.

763
00:40:40,300 --> 00:40:41,660
That's how we found most of our bugs.

764
00:40:42,180 --> 00:40:43,700
So we continue to do that.

765
00:40:44,140 --> 00:40:45,380
Just as Eugene mentioned

766
00:40:45,380 --> 00:40:47,480
2G is an outdated protocol.

767
00:40:47,740 --> 00:40:49,180
Please flip that toggle off

768
00:40:49,180 --> 00:40:50,420
if you have an Android phone.

769
00:40:51,100 --> 00:40:52,200
There's been reports

770
00:40:52,200 --> 00:40:53,440
and some articles already

771
00:40:53,440 --> 00:40:54,400
that there's a couple

772
00:40:54,400 --> 00:40:55,700
of fake 2G base stations

773
00:40:55,700 --> 00:40:56,480
around DEF CON.

774
00:40:56,720 --> 00:40:57,580
If you're in

775
00:40:57,580 --> 00:40:58,900
what was it Paris

776
00:40:58,900 --> 00:41:00,320
and Caesars

777
00:41:00,320 --> 00:41:01,340
probably here by now too.

778
00:41:02,360 --> 00:41:03,720
This is your friendly reminder

779
00:41:03,720 --> 00:41:05,040
to disable 2G.

780
00:41:05,920 --> 00:41:07,140
And if you're

781
00:41:07,140 --> 00:41:09,140
if you can't find that 2G toggle

782
00:41:09,140 --> 00:41:10,740
you may be on an iPhone.

783
00:41:13,480 --> 00:41:14,800
On the mitigation side

784
00:41:14,800 --> 00:41:16,080
we're doing more work in this space.

785
00:41:16,240 --> 00:41:17,300
There's actually a great article

786
00:41:17,300 --> 00:41:18,040
that was released

787
00:41:18,040 --> 00:41:19,520
by our connectivity security team

788
00:41:20,020 --> 00:41:20,740
two days ago

789
00:41:20,740 --> 00:41:21,920
that talks about

790
00:41:21,920 --> 00:41:22,740
what you can do more

791
00:41:22,740 --> 00:41:24,260
than just disabling 2G

792
00:41:24,260 --> 00:41:25,640
or what we've already done.

793
00:41:25,820 --> 00:41:26,900
So check out that article

794
00:41:26,900 --> 00:41:28,260
links on the bottom right.

795
00:41:28,540 --> 00:41:29,700
And it talks about

796
00:41:29,700 --> 00:41:30,640
like doing things like

797
00:41:30,640 --> 00:41:31,880
disabling null cipher support

798
00:41:31,880 --> 00:41:33,120
on cellular networks.

799
00:41:33,400 --> 00:41:34,780
So lots of investment

800
00:41:34,780 --> 00:41:35,400
in this space.

801
00:41:35,600 --> 00:41:36,760
Our work is never done.

802
00:41:37,000 --> 00:41:37,960
Just mentioning

803
00:41:37,960 --> 00:41:39,220
Red Team is just one thing

804
00:41:39,220 --> 00:41:40,600
we do out of many things

805
00:41:40,600 --> 00:41:41,120
at Google.

806
00:41:42,040 --> 00:41:43,940
So the special thanks

807
00:41:43,940 --> 00:41:45,480
to all the work streams here

808
00:41:45,480 --> 00:41:46,880
and all these teams

809
00:41:46,880 --> 00:41:48,020
that participated heavily

810
00:41:48,020 --> 00:41:49,320
in our review.

811
00:41:49,460 --> 00:41:50,040
We couldn't have found

812
00:41:50,040 --> 00:41:50,540
all these bugs

813
00:41:50,540 --> 00:41:51,980
without some help.

814
00:41:52,240 --> 00:41:53,760
So we really appreciate

815
00:41:53,760 --> 00:41:54,800
everyone's contributions.

816
00:41:55,820 --> 00:41:56,960
Last thing I'll

817
00:41:56,960 --> 00:41:58,080
we'll all leave you with

818
00:41:58,080 --> 00:41:59,300
is that this has been

819
00:41:59,300 --> 00:42:00,800
a very exciting review for us

820
00:42:00,800 --> 00:42:02,480
but our work isn't done.

821
00:42:02,760 --> 00:42:04,480
We teased a pivot

822
00:42:04,480 --> 00:42:04,760
to the right

823
00:42:04,760 --> 00:42:05,300
at a kernel earlier.

824
00:42:05,760 --> 00:42:06,820
So who knows?

825
00:42:06,900 --> 00:42:07,700
Maybe you'll hear more

826
00:42:07,700 --> 00:42:09,220
about that at a conference

827
00:42:09,220 --> 00:42:09,840
near you soon.

828
00:42:10,700 --> 00:42:11,300
Thank you.

829
00:42:21,120 --> 00:42:22,420
We have two minutes

830
00:42:22,420 --> 00:42:23,120
for Q&A

831
00:42:23,120 --> 00:42:24,420
if anybody has any questions.

832
00:42:26,180 --> 00:42:26,820
There's a line?

833
00:42:26,940 --> 00:42:27,280
Okay.

834
00:42:27,380 --> 00:42:28,380
There's a line in the center.

835
00:42:31,840 --> 00:42:33,000
You could also come up

836
00:42:33,000 --> 00:42:33,600
if you don't want to

837
00:42:34,080 --> 00:42:34,740
ask your question.

838
00:42:34,760 --> 00:42:35,220
There's no questions allowed.

839
00:42:46,960 --> 00:42:48,500
Have we released any

840
00:42:48,500 --> 00:42:49,500
of the fuzzing framework

841
00:42:49,500 --> 00:42:50,100
for the public?

842
00:42:51,020 --> 00:42:52,240
Uh, we...

843
00:42:54,200 --> 00:42:56,140
I can answer that.

844
00:42:56,540 --> 00:42:57,260
Unfortunately,

845
00:42:57,660 --> 00:42:58,740
the full framework

846
00:42:58,740 --> 00:43:00,140
is ready to the source code

847
00:43:00,140 --> 00:43:02,700
that we cannot release.

848
00:43:03,340 --> 00:43:04,740
So this is totally

849
00:43:04,760 --> 00:43:05,660
internal use.

850
00:43:11,540 --> 00:43:12,180
Yes?

851
00:43:12,520 --> 00:43:14,700
How much of that 2G toggle

852
00:43:14,700 --> 00:43:16,640
of the actual attack surface

853
00:43:16,640 --> 00:43:17,900
does that reduce

854
00:43:17,900 --> 00:43:18,560
?

855
00:43:20,520 --> 00:43:21,440
Yeah, great question.

856
00:43:21,600 --> 00:43:23,100
So how much of that 2G toggle

857
00:43:23,100 --> 00:43:24,580
reduces the attack surface

858
00:43:24,580 --> 00:43:25,200
we've seen?

859
00:43:25,800 --> 00:43:27,480
So most of our attack surface

860
00:43:27,480 --> 00:43:28,380
can be eliminated

861
00:43:28,380 --> 00:43:29,080
or mitigated

862
00:43:29,080 --> 00:43:30,520
by flipping the 2G toggle.

863
00:43:30,760 --> 00:43:31,660
But, you know,

864
00:43:31,680 --> 00:43:33,180
emergency calls use 2G.

865
00:43:33,180 --> 00:43:35,880
So you can't fully disable it.

866
00:43:35,920 --> 00:43:37,320
We don't disable it by default.

867
00:43:37,500 --> 00:43:38,560
That's the reason we don't.

868
00:43:38,820 --> 00:43:39,380
So...

869
00:43:39,380 --> 00:43:40,060
But you have the option

870
00:43:40,060 --> 00:43:41,000
to manually.

871
00:43:41,540 --> 00:43:42,100
Yeah.

872
00:43:42,200 --> 00:43:43,320
To comment on that.

873
00:43:43,460 --> 00:43:45,220
So I think what happens

874
00:43:45,220 --> 00:43:46,720
is 2G by default

875
00:43:46,720 --> 00:43:47,820
will be disabled

876
00:43:47,820 --> 00:43:48,840
if you flip the toggle.

877
00:43:49,100 --> 00:43:50,860
But if you are making

878
00:43:50,860 --> 00:43:51,860
911 calls,

879
00:43:52,940 --> 00:43:54,180
that 2G stack

880
00:43:54,180 --> 00:43:55,700
will then be enabled.

881
00:43:55,840 --> 00:43:56,740
Just to make sure

882
00:43:56,740 --> 00:43:57,800
you get enough coverage.

883
00:43:58,940 --> 00:43:59,220
Yeah.

884
00:44:00,680 --> 00:44:01,240
Yes?

885
00:44:01,240 --> 00:44:02,980
.

886
00:44:12,280 --> 00:44:15,180
The question is

887
00:44:15,180 --> 00:44:16,920
why do we still

888
00:44:16,920 --> 00:44:18,400
allow 2G

889
00:44:18,620 --> 00:44:19,880
for the most part?

890
00:44:23,200 --> 00:44:24,560
.

891
00:44:24,560 --> 00:44:25,980
.

892
00:44:31,240 --> 00:44:32,060
Why can't we fix

893
00:44:32,060 --> 00:44:33,060
the client protocol

894
00:44:33,060 --> 00:44:34,120
and the device drivers?

895
00:44:34,520 --> 00:44:34,780
Yeah.

896
00:44:34,880 --> 00:44:35,500
Can I...

897
00:44:35,500 --> 00:44:36,600
Let me try to answer

898
00:44:36,600 --> 00:44:37,140
this question

899
00:44:37,140 --> 00:44:38,280
from my perspective.

900
00:44:39,360 --> 00:44:40,560
So, first,

901
00:44:40,760 --> 00:44:41,900
2G itself

902
00:44:43,000 --> 00:44:43,960
is by design

903
00:44:43,960 --> 00:44:44,760
lack of lots

904
00:44:44,760 --> 00:44:45,740
of security issues.

905
00:44:46,260 --> 00:44:46,940
So, like,

906
00:44:46,960 --> 00:44:48,620
there's no way

907
00:44:48,620 --> 00:44:49,120
to...

908
00:44:49,120 --> 00:44:50,140
For the device

909
00:44:50,140 --> 00:44:51,020
to know that

910
00:44:51,020 --> 00:44:52,260
if they are talking

911
00:44:52,260 --> 00:44:52,860
to a legit

912
00:44:52,860 --> 00:44:54,200
2G base station

913
00:44:54,200 --> 00:44:55,680
are malicious ones.

914
00:44:56,040 --> 00:44:57,480
So this opens

915
00:44:57,480 --> 00:44:58,880
a big attack surface

916
00:44:58,880 --> 00:45:00,440
that we cannot

917
00:45:00,440 --> 00:45:01,500
fix it by spec.

918
00:45:02,160 --> 00:45:03,700
And second is,

919
00:45:04,880 --> 00:45:05,560
software,

920
00:45:05,960 --> 00:45:07,400
by default,

921
00:45:07,580 --> 00:45:08,740
there's always bugs.

922
00:45:09,580 --> 00:45:11,280
Nobody can guarantee

923
00:45:11,280 --> 00:45:13,380
there's 100%

924
00:45:13,380 --> 00:45:14,780
bug free software.

925
00:45:15,280 --> 00:45:15,760
So,

926
00:45:16,240 --> 00:45:17,260
the way that

927
00:45:17,260 --> 00:45:18,780
we mitigate this

928
00:45:18,780 --> 00:45:19,740
is to reduce

929
00:45:19,740 --> 00:45:20,520
the attack surface.

930
00:45:20,860 --> 00:45:21,600
And of course,

931
00:45:21,640 --> 00:45:22,420
fixing the bugs

932
00:45:22,420 --> 00:45:23,740
is another perspective.

933
00:45:24,140 --> 00:45:24,840
And we are doing

934
00:45:24,840 --> 00:45:25,720
that all the time.

935
00:45:25,940 --> 00:45:26,580
It's just,

936
00:45:26,640 --> 00:45:27,740
you cannot guarantee

937
00:45:27,740 --> 00:45:28,660
your software

938
00:45:28,660 --> 00:45:29,300
is running

939
00:45:29,300 --> 00:45:30,640
only 100% bug free.

940
00:45:39,380 --> 00:45:39,920
Correct.

941
00:45:40,200 --> 00:45:40,440
Yeah,

942
00:45:40,500 --> 00:45:41,940
the design of 2G

943
00:45:41,940 --> 00:45:42,800
doesn't have

944
00:45:42,800 --> 00:45:44,140
proper authentications.

945
00:45:49,440 --> 00:45:50,860
Any other questions?

946
00:45:56,420 --> 00:45:57,220
All right.

947
00:45:57,260 --> 00:45:57,960
Well, thanks, everyone.

948
00:45:58,080 --> 00:45:58,700
Appreciate your time.

949
00:45:59,420 --> 00:46:00,020
Oh,

950
00:46:00,120 --> 00:46:00,900
there is one more.

951
00:46:01,000 --> 00:46:01,300
Sorry.

952
00:46:07,420 --> 00:46:08,020
.

953
00:46:12,820 --> 00:46:13,420
.

954
00:46:15,520 --> 00:46:16,120
.

955
00:46:19,960 --> 00:46:20,560
.

956
00:46:20,560 --> 00:46:21,060
.

957
00:46:21,060 --> 00:46:21,340
.

958
00:46:22,760 --> 00:46:23,360
.

959
00:46:23,360 --> 00:46:23,540
.

960
00:46:23,540 --> 00:46:23,600
.

961
00:46:23,600 --> 00:46:23,780
.

962
00:46:23,780 --> 00:46:23,800
.

963
00:46:23,800 --> 00:46:24,660
.

964
00:46:24,660 --> 00:46:25,680
.

965
00:46:33,000 --> 00:46:34,080
. .

966
00:46:34,080 --> 00:46:34,240
. .

967
00:46:34,240 --> 00:46:35,240
. .

968
00:46:35,240 --> 00:46:37,200
. . .

969
00:46:37,200 --> 00:46:54,900
. . .

970
00:46:54,900 --> 00:46:55,140
. . .

971
00:46:55,140 --> 00:46:56,180
. . . .

972
00:46:58,180 --> 00:47:11,880
or oh everything off yeah I mean there's always you know you have any thoughts on

973
00:47:11,880 --> 00:47:19,640
this one I I don't know how this airplane mode and Wi-Fi disability is

974
00:47:19,640 --> 00:47:26,220
implemented so my understanding is if you disable them an airplane mode

975
00:47:26,220 --> 00:47:33,240
model should be like shut down and it shouldn't be working at all but I heard

976
00:47:33,240 --> 00:47:40,160
some brand they have this so we turn off Wi-Fi the Wi-Fi is actually not

977
00:47:40,160 --> 00:47:45,280
completely turn off for some reason which I don't know any details for that

978
00:47:45,280 --> 00:47:49,140
and I don't know which device has that but

979
00:47:49,140 --> 00:47:54,200
the modem should be turned off completely if you turn on airplane mode

980
00:47:54,200 --> 00:47:55,400
I think that's by law

981
00:48:06,320 --> 00:48:09,720
I think we're done on time right cool thanks again guys thanks