1
00:00:00,179 --> 00:00:07,179
 Hi. And welcome. For the next hour, we
will be talking about femtocells, a femtocell

2
00:00:09,380 --> 00:00:16,380
is a low cost low coverage, it's a mini cell
tower. It's also a Linux box and if you hack

3
00:00:18,280 --> 00:00:22,890
it, you can intercept the phone calls, text
messages and web surfing. We will not talk

4
00:00:22,890 --> 00:00:29,890
about Snowden or any of this political stuff.
This will focus on technical facts. Mostly

5
00:00:31,640 --> 00:00:34,890
technical facts.
There's been many conversations over the last

6
00:00:34,890 --> 00:00:41,890
few days and after lengthy discussions, Verizon
has asked us to include these bullets.

7
00:00:49,130 --> 00:00:56,130
(Laughter).
And moving on. Before we go too much further,

8
00:01:02,739 --> 00:01:07,830
a quick note on handset pairing. Your phone
will associate to a femtocell automatically

9
00:01:07,830 --> 00:01:14,820
and without your knowledge. There may be some
members of the audience connected to our network

10
00:01:14,820 --> 00:01:18,920
right now. Those signs out front are not just
for show. You may want to put it in airplane

11
00:01:18,920 --> 00:01:25,060
mode. It has everything to do with the tower
and very little with the actual phone. We

12
00:01:25,060 --> 00:01:30,390
don't break or alter your phone, at least
not yet.

13
00:01:30,390 --> 00:01:33,640
We also want to clearly state before we go
too much further, the vendor has addressed

14
00:01:33,640 --> 00:01:39,720
the vulnerabilities to get root. We originally
disclosed to the vendor, and they worked very

15
00:01:39,720 --> 00:01:46,610
quickly to release a patch. The security issues
we will be discussing apply to more than one

16
00:01:46,610 --> 00:01:52,520
carrier. As you all know nothing is 100% secure
and we have architectural concerns related

17
00:01:52,520 --> 00:01:56,770
to femtocells. Than should come as no surprise
to you, but we are not first people to have

18
00:01:56,770 --> 00:02:01,430
these concerns.
As you can see, research has been popping

19
00:02:01,430 --> 00:02:07,939
femtocells since at least 2010. Latest example
was here in Las Vegas at Black Hat in 2011

20
00:02:07,939 --> 00:02:13,019
where a group of hackers hackered the crap
out of a femtocell from France. Prior to that

21
00:02:13,019 --> 00:02:20,019
it was a Vodafone box. RSAXVC, and Doug Kelly,
was very helpful to us during our earlier

22
00:02:22,799 --> 00:02:26,359
testing.
As it turns out, someone looked at these things

23
00:02:26,359 --> 00:02:33,359
and didn't say let's use this for evil. They
used this femtocell as a cellular IDS, and

24
00:02:36,389 --> 00:02:41,499
I believe that happens tomorrow.
So we will cover some similar topics but on

25
00:02:41,499 --> 00:02:47,599
a carrier that affects 1 in 3 Americans.
To the best of our knowledge, no one has publicly

26
00:02:47,599 --> 00:02:52,540
presented an attack on a femtocell on a North
American CDMA carrier. If you haven't figured

27
00:02:52,540 --> 00:02:57,379
it out yet, we are talking about Verizon.
By the numbers we are talking about 300 million

28
00:02:57,379 --> 00:03:04,379
people in and 100 million Verizon subscribers.
I'm not that good at math, but that's about

29
00:03:05,290 --> 00:03:10,180
a third of the country.
We will hopefully demonstrate how we can record

30
00:03:10,180 --> 00:03:13,849
and listen to phone calls, text messages,
picture messages and data. We can perform

31
00:03:13,849 --> 00:03:18,609
active man in the middle attacks, as well
as SSL stripping and if that with respect

32
00:03:18,609 --> 00:03:23,279
enough, we throw in some cloning fraud for
good measure.

33
00:03:23,279 --> 00:03:27,870
So to break it down further, we will discuss
how we obtained access to the femtocell, what

34
00:03:27,870 --> 00:03:32,349
we did once we got on it, the custom code
we wrote to get the traffic we wanted, and

35
00:03:32,349 --> 00:03:37,319
our thoughts on how to fix these things.
For those of you that may not be familiar

36
00:03:37,319 --> 00:03:43,239
with a femtocell architecture, here's a high‑level
diagram, your phone connects to the femtocell

37
00:03:43,239 --> 00:03:48,059
over a cellular radio. In this case it happens
to be CDMA. The femtocell uses a broadband

38
00:03:48,059 --> 00:03:55,059
Internet connection to create an IP sec tunnel
back to the carrier's internal network.

39
00:03:55,969 --> 00:04:02,969
Verizon currently has two models of consumer
grade femtocell, the CS‑16UC4, and SCS2U01.

40
00:04:09,919 --> 00:04:16,919
The 2‑01 supports six simultaneous users
at 3g speeds. We were able to route both of

41
00:04:16,970 --> 00:04:22,520
these devices but we created most of our proof
of concept on the 2O01, because it's newer,

42
00:04:22,520 --> 00:04:28,360
faster and better looking.
As we were doing some high‑level due diligence,

43
00:04:28,360 --> 00:04:34,189
we discovered that Sprint has a femtocell
too. Both Verizon models and one Sprint model

44
00:04:34,189 --> 00:04:39,680
are made by the same manufacturer, Samsung.
We didn't have that much time to do a ton

45
00:04:39,680 --> 00:04:44,590
of testing on the Sprint model but the one
on the left is similar to the UC4 and is vulnerable

46
00:04:44,590 --> 00:04:51,590
to attacks. But Sprint is replacing this with
a newer model. We took a look at the newer

47
00:04:54,050 --> 00:05:00,250
model and it's not vulnerable to the same
attacks.

48
00:05:00,250 --> 00:05:06,050
Let's talk about the femtocell we spent most
of our time, the 2U01 has an ARM processor

49
00:05:06,050 --> 00:05:13,050
and a lattice FPGA. Externally it has a GPS
antenna, a CDMA antenna and either net and

50
00:05:16,159 --> 00:05:23,159
HDMI ports. I know what you are thinking,
did he just say HDMI port? Yes, I did!

51
00:05:23,800 --> 00:05:27,180
It's a little tough to make out in this picture
but on the bottom of this device, hidden under

52
00:05:27,180 --> 00:05:33,530
a rubber plug is an HDMI port. We knew it
couldn't be used for video so we figured it

53
00:05:33,530 --> 00:05:39,270
has to be a console port and we were right.
Why is it HDMI port but I do know we know

54
00:05:39,270 --> 00:05:45,050
that Samsung makes a crap load of TVs.
(Laughter).

55
00:05:45,050 --> 00:05:51,430
So how does one connect to an HDMI console
port. You connect it in half and stick it

56
00:05:51,430 --> 00:05:57,039
on a USB FTDI and connect it and use a company
branded pen for the connection because you

57
00:05:57,039 --> 00:06:01,319
are not that good at soldering.
(Laughter).

58
00:06:01,319 --> 00:06:05,340
We really have to thank RSAXVC and Doug Kelly
for figuring this out.

59
00:06:05,340 --> 00:06:12,340
I want to talk briefly about the range since
it's a question we get quite a lot. The device

60
00:06:12,379 --> 00:06:17,639
documentation states that a phone must be
within 15 feet to register to the femtocell

61
00:06:17,639 --> 00:06:22,560
and must stay within approximately 40 feet
to stay connected but in reality it depends.

62
00:06:22,560 --> 00:06:25,759
Your phone will connect to the tower that
has the strongest signal. So if you are in

63
00:06:25,759 --> 00:06:29,889
an area with very good cell coverage. The
real towers tend to drown out this small bay

64
00:06:29,889 --> 00:06:33,819
station. We think there's some tweaking that
can be done in the software to boost the signal

65
00:06:33,819 --> 00:06:37,150
but probably the biggest thing is to buy a
big assed amplified antenna.

66
00:06:37,150 --> 00:06:42,240
If you are in an area that you need something
like this, then we imagine the capture range

67
00:06:42,240 --> 00:06:49,240
would be pretty good. We did purchase an after
market antenna this creates a nice, tight

68
00:06:53,249 --> 00:06:57,639
cone.
All right. So I was not entirely truthful.

69
00:06:57,639 --> 00:07:03,300
One last mention of the older model, on the
UC4, could you interrupt the boot process.

70
00:07:03,300 --> 00:07:10,300
That was fixed in the 2U01 so we had our find
our way in. We found we could abort the boot

71
00:07:10,590 --> 00:07:17,590
process which drops to you a prompt. Because
we are interrupting the boot process before

72
00:07:18,060 --> 00:07:22,849
the device is fully functional we had to manually
run some start‑up scripts. One at the proper

73
00:07:22,849 --> 00:07:29,849
run level, death vice will start movie cell
binaries and connect to the carrier's network.

74
00:07:30,270 --> 00:07:34,550
As we mentioned, they will no longer get you
route on a batch device but they are pretty

75
00:07:34,550 --> 00:07:41,550
handy and will probably be very useful when
testing other embedded devices.

76
00:07:42,689 --> 00:07:46,819
So now that we have established a presence
on a mini cell tower, let's poke around this

77
00:07:46,819 --> 00:07:53,819
device and see what we can see. The 2U01 Rones
Monta Vista Linux 5. It includes a strict

78
00:07:57,379 --> 00:08:04,169
lip U. system and a few diverse drivers to
control its operation as a base station. It

79
00:08:04,169 --> 00:08:11,169
includes AuthenTec, which is a kernel model.
It's route but it's 
a pre‑bare bones, Linux: So said, it's a

80
00:08:24,789 --> 00:08:31,300
little unwieldy but we can use it to edit
SSHD config to allow password root login.

81
00:08:31,300 --> 00:08:37,800
We did that and flushed the IP tables and
it made things easier to work with.

82
00:08:37,800 --> 00:08:42,959
We can SSH in, but we have to run the said
command on every boot because the file system

83
00:08:42,959 --> 00:08:47,639
is pulled fresh every time you power cycle.
So we figured we could edit and reflash the

84
00:08:47,639 --> 00:08:53,010
firmware but we didn't want to run the risk
of creating a door stop. We continued looking

85
00:08:53,010 --> 00:08:59,300
around and eventually we noticed a persistent
file system location. The things are starting

86
00:08:59,300 --> 00:09:03,670
to get more interesting, right? We found a
persistent place to store files but that doesn't

87
00:09:03,670 --> 00:09:08,980
necessarily give us persistent root access,
right? So we cadded all the things and spent

88
00:09:08,980 --> 00:09:15,980
a lot of time in slash ETSI. And we came across
a debug mode. For the record that's not our

89
00:09:16,470 --> 00:09:21,220
typo in the echo statement.
I want to make that clear.

90
00:09:21,220 --> 00:09:28,220
We created a file named .ubrc and we have
a typo in the boot output and it worked.

91
00:09:31,540 --> 00:09:37,019
More importantly, since this .ubirc file,
we can put our own commands in there and it

92
00:09:37,019 --> 00:09:43,350
will be executed by root every time the unit
boots. It's an incredible time saver. We used

93
00:09:43,350 --> 00:09:50,350
it to patch SSDIC and drop us in a root shell
automatically.

94
00:09:50,810 --> 00:09:55,579
So we overcame the next hurdle. We now persistent
route access. So let's get some packets and

95
00:09:55,579 --> 00:10:02,579
do some eavesdropping. We will run a dump
on the TCP interface and we see encrypted

96
00:10:03,899 --> 00:10:06,769
packets everywhere.
What the hell?

97
00:10:06,769 --> 00:10:13,769
It turns out that quick set is a kernel module.
It sales the packets and does encryption and

98
00:10:16,060 --> 00:10:23,060
description and sends the items. It seems
like the fun is over. Now what?

99
00:10:24,290 --> 00:10:28,150
Well, luckily, it's all just engineering and
with that, I will turn it over to Tom.

100
00:10:28,150 --> 00:10:35,150
 TOM RITTER: That's a pretty good representation
of how that programming worked on this project.

101
00:10:37,209 --> 00:10:41,100
(Laughter).
So setting up the ‑‑ certainly not the

102
00:10:41,100 --> 00:10:46,540
good looks. So setting up the cross compilation
environment. It was a real pain in the neck.

103
00:10:46,540 --> 00:10:50,389
That's why we have interns.
(Laughter)

104
00:10:50,389 --> 00:10:56,079
(Applause).
Sorry, Andrew. We were finally able to find

105
00:10:56,079 --> 00:11:03,079
the right version of the Monta Vista and we
were able to run on the femtocell. We figured

106
00:11:05,389 --> 00:11:09,449
out that we needed to write the kernel module
and insert it in such a way we would be able

107
00:11:09,449 --> 00:11:16,350
to copy the packets going out and after they
were decrypted on the way in. With that module

108
00:11:16,350 --> 00:11:22,649
loaded we can pass them out to user land for
logging to a PCAP. So with that hurdle over,

109
00:11:22,649 --> 00:11:27,149
we can go after the fun stuff.
So we've got some plain text packets, but

110
00:11:27,149 --> 00:11:33,470
it's a mess. Wire struct does not help us
and the port structure is completely foreign.

111
00:11:33,470 --> 00:11:39,470
A phone call generates lots of small UDP packets
like any VoIP protocol, but who is talking

112
00:11:39,470 --> 00:11:46,470
to who and where is the audio. We could fire
wire shark to ATP, to get us a small step

113
00:11:46,860 --> 00:11:53,860
closer. The RTP payload is in the dynamic
range and according to the speck, it's do

114
00:11:54,639 --> 00:11:58,740
for whatever you want and don't expect to
interoperate with anybody. We had to figure

115
00:11:58,740 --> 00:12:05,740
out what type of codec we did. We downloaded
every singing RFC, for codec, and we eventually

116
00:12:11,389 --> 00:12:17,949
found one we thought it might, EVRC. It's
one of those random cellular codecs that no

117
00:12:17,949 --> 00:12:24,949
media player implements. What do you do when
you hit a dead end and you can't figure something

118
00:12:26,029 --> 00:12:32,459
out?
You go to stack overflow.

119
00:12:32,459 --> 00:12:35,790
(Applause).
But this had already been asked, and received

120
00:12:35,790 --> 00:12:41,170
no answers. So here's the real secret of productive
acres, it's not asking questions on stack

121
00:12:41,170 --> 00:12:48,089
overflow. It's bountying questions on stack
overflow. So what we got was a link to the

122
00:12:48,089 --> 00:12:55,089
actual reference implementation of EVRC published
by the 3G PPP2 working group thingy. And it

123
00:12:55,329 --> 00:13:01,569
took some fiddling but after passing it through
the reference implementation and the SOCs

124
00:13:01,569 --> 00:13:06,329
we were able to get some audio out of that.
And with, that let's hopefully go for the

125
00:13:06,329 --> 00:13:13,329
live voice demo.
So Doug is placing a call on a phone that

126
00:13:17,180 --> 00:13:23,570
is associated to the femtocell. And hopefully
Andrew's phone will ring in just a moment.

127
00:13:23,570 --> 00:13:30,160
 Hello.
 DOUG DePERRY: Andrew, did you fill about

128
00:13:30,160 --> 00:13:37,160
that new phishing scheme, it's off the hook.
 Talk you to later, Doug.

129
00:13:38,540 --> 00:13:45,540
 TOM RITTER: So the call is complete. I
need to switch over, actually. Okay. So Andrew

130
00:13:50,779 --> 00:13:55,279
is going to pull it off of the femtocell and
parse it ‑‑ pass it through the ‑‑

131
00:13:55,279 --> 00:14:02,279
 I hope this works. So that was before the
call was placed. Did you know that your mic

132
00:14:02,459 --> 00:14:07,589
was active then?
(Laughter).

133
00:14:07,589 --> 00:14:12,410
Now it's ringing. Hello. Hey, Andrew, did
you hear about that new phishing scheme, it's

134
00:14:12,410 --> 00:14:15,290
off the hook.
 Talk you to later, Doug.

135
00:14:15,290 --> 00:14:22,290
 TOM RITTER: And there's live voice interception.
(Applause).

136
00:14:29,300 --> 00:14:34,069
And this was the backup video.
(Laughter)

137
00:14:34,069 --> 00:14:39,670
So for SMS, it took us a while to figure out
SMS also, but we will spare you the gory details.

138
00:14:39,670 --> 00:14:46,670
The text message is seven bit blocks so it's
a bit of a pain but we can get the data out.

139
00:14:46,860 --> 00:14:52,360
We made a wire struct, but that's not nearly
as interesting as doing another live demo.

140
00:14:52,360 --> 00:14:59,360
So let's try for that.
So we should be displaying a couple of text

141
00:15:02,910 --> 00:15:09,910
messages that we have asked people to send
us. Is that them right there? Okay. So they

142
00:15:10,040 --> 00:15:15,680
have already gone through at the bottom. So
they just kind of popped right up. Can we

143
00:15:15,680 --> 00:15:22,680
get another couple sent real quick?
There are a lot of encoding formats for SMS

144
00:15:27,750 --> 00:15:34,750
and we don't parse them all. All right. So
that's SMS.

145
00:15:39,300 --> 00:15:45,829
(Applause).
All right. So we have voice calls and SMS

146
00:15:45,829 --> 00:15:50,519
but we live in the smartphone era. So let's
see some actual data and thankfully it was

147
00:15:50,519 --> 00:15:55,019
plain text, so much easier. Everything is
parsed and displayed in wire shark. There

148
00:15:55,019 --> 00:15:59,790
are some layers and tunnels that encapsulate
the data that I'll talk about in a sec. But

149
00:15:59,790 --> 00:16:05,110
pretty much it's over any LAN capture. With
passive interception, we can pick up your

150
00:16:05,110 --> 00:16:12,110
MMS. You did know that didn't go over SSL,
right?

151
00:16:12,430 --> 00:16:18,500
So we took a photo of the audience. And sent
it because it takes a little bit for MMS to

152
00:16:18,500 --> 00:16:25,500
go out in DEF CON and we will show it to you
right now. And there you all are.

153
00:16:27,350 --> 00:16:34,350
(Applause).
Okay. So we can few all the plain text. Passive

154
00:16:36,529 --> 00:16:41,100
interception is done and working. Let's do
some active attacks. The easiest thing to

155
00:16:41,100 --> 00:16:46,370
do with data is to drop it on the floor.
Now, there's a lot of debate about how iMessage

156
00:16:46,370 --> 00:16:52,829
works and how secure it is. It uses SSL to
talk home to Apple. We can't see those messages

157
00:16:52,829 --> 00:16:58,709
with passive interception but if you block
the SSL connection, iMessage fails over to

158
00:16:58,709 --> 00:17:04,650
SMS and SMS is plain text and we can see that
just fine!

159
00:17:04,650 --> 00:17:10,500
Okay. So it is plain text, but it's encapsulated
all up and down.

160
00:17:10,500 --> 00:17:14,620
If we are lucky, it's a fairly nice encapsulation
that wire shark will handle for us. If we

161
00:17:14,620 --> 00:17:21,620
are unlucky, the normal, IP and HTTP gets
used and gets split across GRE packets and

162
00:17:22,970 --> 00:17:29,970
this is what it looks like when you are unlucky.
This is HTTP, and these are the TCP and IP.

163
00:17:31,790 --> 00:17:37,440
That's actually the data section of the upper
left‑hand inset and then if you can read

164
00:17:37,440 --> 00:17:44,440
the wire shark part, there's the PPP fragments.
That's the IP fragment split across multiple

165
00:17:44,480 --> 00:17:51,480
GRE frames. So our goal is to edit a web page
in the simplest way possible. And changing

166
00:17:52,230 --> 00:17:59,230
anything in HTTP means changing the TCP checksum.
And changing anything also means changing

167
00:17:59,730 --> 00:18:06,600
the PPP checksum. TCP checksum is at the beginning
and PPP is at the end and the frames might

168
00:18:06,600 --> 00:18:12,080
be out of order. So it will be a little tricky.
The first thing we tried doing was doing it

169
00:18:12,080 --> 00:18:16,710
in line in the kernel. Really quickly, we
figured out that the carrier has a transparent

170
00:18:16,710 --> 00:18:20,430
proxy on all of your web browsing on your
phone. Let me repeat.

171
00:18:20,430 --> 00:18:26,420
That Verizon hey has a transparent proxy on
all the web browsing on your phone. It's kind

172
00:18:26,420 --> 00:18:29,570
of creepy doing this without your knowledge
but frankly, we were not really surprised.

173
00:18:29,570 --> 00:18:34,550
One of the things they do with this transparent
proxy is apply HTTP compression to anything

174
00:18:34,550 --> 00:18:39,000
that doesn't already have it, which makes
sense because HTTP compression does actually

175
00:18:39,000 --> 00:18:43,950
speed things up. We didn't detect any SSL
man in the middling or JavaScript injection

176
00:18:43,950 --> 00:18:49,260
and I don't think that Verizon is alone or
the only carrier doing this. But nonetheless,

177
00:18:49,260 --> 00:18:53,020
it's there and from a technical standpoint,
with he had to work around it. We tried disabling

178
00:18:53,020 --> 00:19:00,020
the compression but no ice.
We had to do DNS hijacking. It does their

179
00:19:02,960 --> 00:19:08,550
own DNS lookup on the host header. So then
we tried something crazy and this got us pretty

180
00:19:08,550 --> 00:19:15,550
close. We did the DNS hijacking and in the
kernel. We rewrote from port 80 to 81. So

181
00:19:16,280 --> 00:19:22,300
the carrier wouldn't proxy it. Our server
listens on port 81 and responds back. And

182
00:19:22,300 --> 00:19:28,040
then on the inbound the kernel module rewrites
it back to 80 and this worked most of the

183
00:19:28,040 --> 00:19:32,160
time. The problem was there were a couple
of corner cases and on hundreds or thousands

184
00:19:32,160 --> 00:19:37,370
of packets for a web page load, that's enough
to sync it.

185
00:19:37,370 --> 00:19:41,400
So what ended up working was doing all of
that except the server that listens on port

186
00:19:41,400 --> 00:19:47,460
81 will redirect the browser to port 8080
which the carrier also doesn't proxy. So in

187
00:19:47,460 --> 00:19:53,500
the end, what ends up happening, you open
a website, say CNN.com. We DNS hijack you.

188
00:19:53,500 --> 00:19:58,300
You try to talk to our server on port 80 but
the femtocell kernel module rewrites your

189
00:19:58,300 --> 00:20:05,300
connection to our server on port 81 to bypass
the proxy. We respond and the kernel rewrites

190
00:20:06,060 --> 00:20:13,060
it back to port 80. Now, our response actually
redirects you to CNN.com on port 8080, which

191
00:20:13,490 --> 00:20:20,290
you don't notice because mobile UI sucks.
Then you talk to our server on port 8080 directly

192
00:20:20,290 --> 00:20:26,390
bypassing the proxy with no port rewriting
and then we can man in the middle user, we

193
00:20:26,390 --> 00:20:30,910
strip off SSL and pass along the cookies.
It's a little bit slow but cellular is a little

194
00:20:30,910 --> 00:20:35,350
bit slow. So because it is a little bit slow,
we will ‑‑ it's a little bit slow, we

195
00:20:35,350 --> 00:20:42,350
will show a video of this one.
Okay. So in the bottom right‑hand corner,

196
00:20:44,050 --> 00:20:48,830
we are typing in a bank wellsfargo.com. And
in the lower left‑hand side you can see

197
00:20:48,830 --> 00:20:55,830
the resource loads so a couple from Google
and then we will see the Wells Fargo resources.

198
00:20:57,060 --> 00:21:02,320
In the upper left‑hand is where the user
name and password will show up. So there's

199
00:21:02,320 --> 00:21:09,320
Wells Fargo. And we will click on sign in.
And then we will type the user name, character

200
00:21:09,490 --> 00:21:16,490
by painful character. And then the password.
And there is the user name and password in

201
00:21:19,580 --> 00:21:26,360
the upper left.
All right. So that is data middling. And with

202
00:21:26,360 --> 00:21:33,360
that, I will turn it back over to Doug.
 DOUG DePERRY: So this is all really cool

203
00:21:34,920 --> 00:21:39,190
and we were very excited about it, but these
things are mini cell towers. So it's got to

204
00:21:39,190 --> 00:21:45,040
be possible to do more with them, right?
So if there's anything cooler than intercepting

205
00:21:45,040 --> 00:21:51,440
and modifying phone calls and text messages,
it's becoming the person holding the phone.

206
00:21:51,440 --> 00:21:58,440
For those of you familiar with GSM terms like
IMEI or IMSI, the key difference here is that

207
00:22:01,530 --> 00:22:07,150
SIM cards are not typically used in US CDMA
networks so instead of IMSI, the MSSDN is

208
00:22:07,150 --> 00:22:14,150
your phone number. It's sometimes not always
the same as your phone number. This is an

209
00:22:15,090 --> 00:22:20,290
important distinction. Most, but not all of
the communication between the handset and

210
00:22:20,290 --> 00:22:27,290
the carrier uses the ESN and MIM for identification.
Unfortunately there's not any obvious correlation

211
00:22:27,710 --> 00:22:34,710
between the MIM and the actual phone number.
ESN was previously used as a unique number

212
00:22:37,300 --> 00:22:44,300
but carriers ran out officially in 2010. ESNs
have since been superseded by MEIDs. Pseudo‑ESNs

213
00:22:45,520 --> 00:22:52,520
are led by 80. They are not guaranteed to
be unique since the MEID is the identifier.

214
00:23:00,770 --> 00:23:04,780
Older model phones use the ESN to identify
themselves to the network. Newer phones use

215
00:23:04,780 --> 00:23:11,780
the MEID, but still retain a pseudo‑ESN
since it's required for compatible reasons.

216
00:23:12,200 --> 00:23:16,260
So to clone a phone, all you have to do is
grab somebody's phone, write down the else

217
00:23:16,260 --> 00:23:20,620
he is or MEID and their phone number and then
copy these numbers to another handset to get

218
00:23:20,620 --> 00:23:25,350
a valid clone, right?
Well, years ago this used to be all it took.

219
00:23:25,350 --> 00:23:29,640
Since the MIN was usually the same as the
phone number and the ESN was printed on any

220
00:23:29,640 --> 00:23:34,230
given device, it was trivial for an attacker
to get these values and use someone else's

221
00:23:34,230 --> 00:23:41,180
expensive wireless minutes to make calls.
So Qualcomm and the CDMA carriers had to come

222
00:23:41,180 --> 00:23:47,650
up with a solution. The cave authentication
method makes it difficult to successfully

223
00:23:47,650 --> 00:23:54,650
clone a CDMA phone. It's authenticates the
customer and the call. Manufacturers of CDMA

224
00:23:55,910 --> 00:24:01,640
devices are supposed to make these keys difficult
to obtain so that a full clone is not possible.

225
00:24:01,640 --> 00:24:05,340
All that being said, let's see if our rogue
femtocell has any more secrets it wants to

226
00:24:05,340 --> 00:24:10,260
give up. Hint!
As we mentioned earlier, the femtocell acts

227
00:24:10,260 --> 00:24:15,330
like a typical cell tower, except at least
one key difference. The femtocell only uses

228
00:24:15,330 --> 00:24:20,350
the ESN and MIN to authenticate handsets.
We are not entirely sure why. We have no idea

229
00:24:20,350 --> 00:24:27,350
but it may suggest a legacy CDMA implementation.
The real problem here is that we discovered

230
00:24:27,750 --> 00:24:33,070
that the femtocell does not have CAVE enabled.
It behaved like a legacy tower and just ignored

231
00:24:33,070 --> 00:24:39,050
those keys relying solely on the ESN and MIN,
and so cloning becomes extremely easy, just

232
00:24:39,050 --> 00:24:43,220
like the good old days.
Note that the cloned phone will only work

233
00:24:43,220 --> 00:24:47,480
while connected to the femtocell but it can
be any femtocell not necessarily one that's

234
00:24:47,480 --> 00:24:53,120
been modified. So we just need to somehow
obtain the ESN and the MIN of our victim and

235
00:24:53,120 --> 00:24:57,380
program those numbers into another handset.
You are generally not supposed to be able

236
00:24:57,380 --> 00:25:00,900
to write the ESN, but some phone models will
do it.

237
00:25:00,900 --> 00:25:07,900
We wait until the victim goes to the bathroom
and grab their phone and clone the phone.

238
00:25:08,260 --> 00:25:12,530
But that's so messy. We have invite the victim
out to eat, and wait until they go to the

239
00:25:12,530 --> 00:25:19,530
bathroom. And try in playing shit and spell
or words with friends, there's got to be an

240
00:25:25,230 --> 00:25:31,150
easier way to defraud my friends.
So remember that time I told you that we can

241
00:25:31,150 --> 00:25:36,570
see every packet that goes through the femtocell?
Well, that includes handset registration packets

242
00:25:36,570 --> 00:25:42,370
that include the else he is and MIN of the
phone associated to the femtocell. So all

243
00:25:42,370 --> 00:25:46,880
I have to do is capture packets on my rogue
femtocell and wait for an unsuspecting cell

244
00:25:46,880 --> 00:25:51,230
phone range to come within range. When it
associates with the femtocell, I catch the

245
00:25:51,230 --> 00:25:58,230
ESN and MIN without physical access to the
phone and without any indication of the user.

246
00:25:58,740 --> 00:26:03,330
So picture is worth a thousand words. Here
it is step by step. The victim phone comes

247
00:26:03,330 --> 00:26:10,330
within range of a malicious femtocell and
as the handset registers to the cell phone

248
00:26:11,420 --> 00:26:18,420
network the ESN and MIN is recorded. It would
be possible to capture phones in New York

249
00:26:20,310 --> 00:26:24,690
City using a rogue femtocell and email it
to an accomplice in Seattle who is using a

250
00:26:24,690 --> 00:26:31,690
stock femtocell. It's almost the perfect crime.
While we were testing for cloning, we noticed

251
00:26:31,790 --> 00:26:38,790
or results were inconsistent. If your name
was to make money through toll fraud you could

252
00:26:40,890 --> 00:26:45,390
make enough money to buy a boat that has smaller
boats inside of it.

253
00:26:45,390 --> 00:26:48,150
(Laughter).
We made a couple of ‑‑ maybe a couple

254
00:26:48,150 --> 00:26:52,670
of jet skis too. We suspect our problems may
have something to do with the relative signal

255
00:26:52,670 --> 00:26:57,160
strength of neighboring cell towers as we
saw slightly different environments in an

256
00:26:57,160 --> 00:27:02,320
urban environment as opposed to a more rural
one. The shore answer is we don't know. So

257
00:27:02,320 --> 00:27:06,280
we tested cloning with voice, SMS and data
and some of the results were expected and

258
00:27:06,280 --> 00:27:10,830
some were not but probably the most interesting
thing we saw was the not quite three‑way

259
00:27:10,830 --> 00:27:12,970
call.
So I'm going to describe a few scenarios over

260
00:27:12,970 --> 00:27:18,450
the next few slides and the following definitions
will be helpful. Our victim is the person

261
00:27:18,450 --> 00:27:23,370
with the shiny new iPhone whose phone that
we want to clone. The target is the bad guy

262
00:27:23,370 --> 00:27:28,620
running this old crappy flip phone and that's
been modified to act like a copy or a clone

263
00:27:28,620 --> 00:27:34,410
of the victim phone.
So the easiest scenario is the victim's phone

264
00:27:34,410 --> 00:27:41,410
is turned off, jammed otherwise not connected
to any cell towers. Everything works as expected.

265
00:27:41,790 --> 00:27:48,790
You have an exact working copy of the victim's
phone for all intents and purposes. So when

266
00:27:48,920 --> 00:27:54,620
both phones are associated to the same femtocell,
we noticed a few different things. Of course,

267
00:27:54,620 --> 00:27:59,080
the cloned phone, the target, must be associated
to the femtocell in order to work properly.

268
00:27:59,080 --> 00:28:04,630
It is only possible to place outgoing calls
one at a time. No matter which phone initiates

269
00:28:04,630 --> 00:28:09,690
outgoing call, any subsequent call placed
will force that call to drop. It doesn't matter

270
00:28:09,690 --> 00:28:14,720
which phone is which, either the victim or
the target can force the victim to drop calls.

271
00:28:14,720 --> 00:28:20,320
We didn't notice any issues with outgoing
text messages and for incoming SMS, the usual

272
00:28:20,320 --> 00:28:25,670
behavior seemed to be that both phones would
get the text message.

273
00:28:25,670 --> 00:28:31,200
So with incoming calls, sometimes one of two
behaviors is possible. The first is that only

274
00:28:31,200 --> 00:28:35,550
one of the two phones rings. It could be the
victim or the target. It doesn't matter.

275
00:28:35,550 --> 00:28:39,420
Other times, both phones will ring at the
same time. The phone that picks up the call

276
00:28:39,420 --> 00:28:44,770
first usually wins, which means it gets to
stay on the call. But the coolest part is

277
00:28:44,770 --> 00:28:48,960
that sometimes if the two phones answered
within a few seconds of each other, we got

278
00:28:48,960 --> 00:28:53,820
what we are getting a two and a half way call.
What would happen is both the target and the

279
00:28:53,820 --> 00:28:58,210
victim phones would connect and each would
be able to hear the inbound caller but not

280
00:28:58,210 --> 00:29:01,730
each other.
So the eavesdropping scenario is pretty clear.

281
00:29:01,730 --> 00:29:05,910
The bad guy can clone a phone and as soon
as an incoming call comes in, picks up the

282
00:29:05,910 --> 00:29:12,910
call and mutes his mic and can hear everything
said by the incoming caller. In the second

283
00:29:13,660 --> 00:29:17,700
scenario, the target is associated to the
femtocell as required, but the victim is out

284
00:29:17,700 --> 00:29:22,030
and about connected to an actual cell tower.
The phone that gets the incoming call appears

285
00:29:22,030 --> 00:29:25,730
to depend on which phone has had more recent
communication with the carrier network, like

286
00:29:25,730 --> 00:29:29,970
a call or a text message. We couldn't reproduce
the two and a half way call since both phones

287
00:29:29,970 --> 00:29:34,980
never rang at the same time. SMS was pretty
similar. We never got an SMS on both phones

288
00:29:34,980 --> 00:29:39,990
at the same time.
So, outgoing calls are a little more interesting.

289
00:29:39,990 --> 00:29:45,730
So let's say the target, the cloned phone,
is on an active phone call. This works fine

290
00:29:45,730 --> 00:29:51,250
until our unsuspecting victim places an outgoing
call to another party. The bad guy's call

291
00:29:51,250 --> 00:29:57,860
gets dropped and the call of our innocent
victim is allowed to connect reliably. However,

292
00:29:57,860 --> 00:30:04,340
if the victim is on an active call, like pictured,
and the target places an outgoing call, the

293
00:30:04,340 --> 00:30:10,030
call will connect allowing two independent
phone calls. So these implications are clear

294
00:30:10,030 --> 00:30:14,300
as well. Why use your own minutes when you
can use someone else's to call 1‑900 numbers

295
00:30:14,300 --> 00:30:19,080
and that's especially cool if you own the
1‑900 number.

296
00:30:19,080 --> 00:30:26,080
As I said earlier, we were going to talk about
cloning data and here we are. It appears to

297
00:30:26,510 --> 00:30:30,420
be slightly more difficult to establish a
data connection on a clone than it is to clone

298
00:30:30,420 --> 00:30:37,420
voice and text services. Data services on
Verizon are needed. Long story short, the

299
00:30:39,350 --> 00:30:46,350
carrier network requires more numerical identifiers
for voice and SMS, it's more difficult and

300
00:30:46,660 --> 00:30:53,610
we didn't dig too deep into it.
So we have a video to demonstrate a two and

301
00:30:53,610 --> 00:31:00,610
a half way call. Oops. Maybe not. There we
go.

302
00:31:02,810 --> 00:31:09,810
All right. So that's me making a phone call
to a single number. (Phone ringing).

303
00:31:09,930 --> 00:31:15,550
Both phones are ringing, the victim phone
is the one on left and the target is the one

304
00:31:15,550 --> 00:31:22,550
on the right. And we will fast forward obnoxiously.
Both calls get answered. Both calls connect

305
00:31:22,920 --> 00:31:29,920
and stay connected. And now we will do some
very sophisticated voice testing. Stand by

306
00:31:30,660 --> 00:31:35,590
to prove that the two calls are connected.
 Hello.

307
00:31:35,590 --> 00:31:39,100
 Oh, there it is.
 Hello.

308
00:31:39,100 --> 00:31:44,730
 Hello.
 You just saw an inside secret to phone

309
00:31:44,730 --> 00:31:49,880
testers. It's very technical. I'll handle
that.

310
00:31:49,880 --> 00:31:53,260
And so that's that.
So we mentioned this at the beginning but

311
00:31:53,260 --> 00:31:58,080
this issue was resolved by Verizon on the
back end many months ago, which is great,

312
00:31:58,080 --> 00:32:02,410
because authentication should be checked on
the internal network that the carriers control,

313
00:32:02,410 --> 00:32:06,760
not on the small box that they don't. And
with that, I will turn it back over to Tom.

314
00:32:06,760 --> 00:32:13,760
 TOM RITTER: Okay. So it would be easy to
think that this is all about Verizon but this

315
00:32:16,710 --> 00:32:22,310
is really about everybody. There are over
30 carriers worldwide who have femtocell and

316
00:32:22,310 --> 00:32:27,340
three of the four major US carriers. And clearly,
there are issues here so what's a multibillion

317
00:32:27,340 --> 00:32:33,760
dollars, multinational corporation to do?
Well, you can harden the actual device. But

318
00:32:33,760 --> 00:32:37,320
as we all know, there's nothing you are going
to be able to do on the platform to prevent

319
00:32:37,320 --> 00:32:43,360
people with physical access from breaking
in. Root is always possible. We didn't have

320
00:32:43,360 --> 00:32:47,980
to do more sophisticated attacks but obviously
you shouldn't rule them out. There are lots

321
00:32:47,980 --> 00:32:53,200
of ways to get on to an embedded device and
frankly, we went in through the front door.

322
00:32:53,200 --> 00:32:58,620
So what else can a vendor do? Well, you can
force registration. Make the femtocell owner

323
00:32:58,620 --> 00:33:03,610
list the phones allowed to connect through
their femtocell and then confirm with the

324
00:33:03,610 --> 00:33:07,680
phone owner that they're cool with allowing
that and if this they try connecting through

325
00:33:07,680 --> 00:33:13,060
any other femtocell, don't let them and do
this white listing inside the carrier network

326
00:33:13,060 --> 00:33:17,360
of course, not on the actual device and this
would make it a lot harder to take one of

327
00:33:17,360 --> 00:33:24,220
these down to Times Square or Las Vegas and
just start gobbling up everyone around them.

328
00:33:24,220 --> 00:33:28,100
So device registration clearly reduces the
attack service. Here's a breakdown of the

329
00:33:28,100 --> 00:33:34,960
major US cell phone carriers and how they
handle handset registration on the femtocell,

330
00:33:34,960 --> 00:33:39,540
besides T‑Mobile who doesn't have a femtocell,
AT&T is leading in this category because they

331
00:33:39,540 --> 00:33:45,190
require registration. The other carriers,
Sprint and Verizon do not.

332
00:33:45,190 --> 00:33:50,260
So phone registration does prevent the easiest
attack but it doesn't win us over completely.

333
00:33:50,260 --> 00:33:57,260
It doesn't prevent attacks where I isolate
you from the scarier network. Try to make

334
00:33:58,290 --> 00:34:03,040
phone calls and send text messages. Even though
I never deliver that up to the carrier, I

335
00:34:03,040 --> 00:34:08,000
will still see them. I can track you and read
your SMS and we verified this experimentally.

336
00:34:08,000 --> 00:34:12,240
It's actually what we are doing right now.
We isolate any phone that's not white listed

337
00:34:12,240 --> 00:34:17,519
so we don't receive inbound text messages
or data sessions or see what you are sending

338
00:34:17,519 --> 00:34:21,359
because we white it out. With more engineering,
it would be possible to connect these phone

339
00:34:21,359 --> 00:34:28,359
calls to our phone line and spoof SMS to receive
and route the data traffic on the normal Internet

340
00:34:28,829 --> 00:34:35,829
connection and let you browse the Internet
without the carrier network knowing. So 
it's a good minimum level of security but

341
00:34:43,019 --> 00:34:47,609
we don't think it's enough.
Really what you should be doing is zipping

342
00:34:47,609 --> 00:34:51,619
them all together. You guys know that there
will be bugs in everything, but that said

343
00:34:51,619 --> 00:34:56,909
we like Wi‑Fi calling. If the handset is
on Wi‑Fi, not even your own Wi‑Fi but

344
00:34:56,909 --> 00:35:03,269
untrusted Wi‑Fi, and IPSECs or SSL tunnels
doing certificate pinning and the phone is

345
00:35:03,269 --> 00:35:07,869
appropriately distrusted from a network perspective
so you can't just go Nmapping all of their

346
00:35:07,869 --> 00:35:12,930
crap, we think you have a much stronger architecture.
You have to do the same type of cell phone

347
00:35:12,930 --> 00:35:17,359
authentication you do with the tower to avoid
theft of service but that's to weaker than

348
00:35:17,359 --> 00:35:22,089
what we have now.
And what you get is not needing femtocells.

349
00:35:22,089 --> 00:35:28,250
That's a win, being able to make calls on
any random Wi‑Fi and that's a win, and it's

350
00:35:28,250 --> 00:35:35,250
encrypted. So that's a win.
Going even further, you build an end to end

351
00:35:35,970 --> 00:35:42,470
encryption to protect the call, against untrusted
Wi‑Fi operators and the carrier. There are

352
00:35:42,470 --> 00:35:47,369
individual PAPs that do this but they all
require the recipient to have the same PAP.

353
00:35:47,369 --> 00:35:53,490
If Google and Apple and Blackberry supported
this, we think there would be a huge increase

354
00:35:53,490 --> 00:35:57,390
in adoption.
So I was just talking about this, but let's

355
00:35:57,390 --> 00:36:04,390
sum up and present a couple of other Band‑Aids.
Ultimately, a losing proposition. Requiring

356
00:36:05,759 --> 00:36:10,789
registration prevents unargued attacks to
some degree, but long term we're pretty nervous

357
00:36:10,789 --> 00:36:15,829
about giving random people, like yourselves
small cell phone towers, and just hoping you

358
00:36:15,829 --> 00:36:20,519
don't break into them.
Now, can you tell if you are connected to

359
00:36:20,519 --> 00:36:26,180
a femtocell? We said in the beginning, no,
but it had an asterisk. We noticed that some

360
00:36:26,180 --> 00:36:31,009
android phones have an icon indicating they
are connected to a femtocell this was only

361
00:36:31,009 --> 00:36:35,359
in phones that Verizon had modified. It's
not in the Android source or any stock or

362
00:36:35,359 --> 00:36:41,799
Flashed ROMs. An iPhone has no visual indicator.
There's a short beep at the beginning of phone

363
00:36:41,799 --> 00:36:47,190
calls and it's really easy to miss, and you
have to make a phone call.

364
00:36:47,190 --> 00:36:52,990
Somehow these Android phones were detecting
a femtocell and we reversed engineered that.

365
00:36:52,990 --> 00:36:59,990
And then we made our own PAP, the feftocatcher.
So using this, we can write a tool to put

366
00:37:07,759 --> 00:37:12,460
a phone into airplane mode when it detects
itself being connected to a femtocell. Now,

367
00:37:12,460 --> 00:37:16,650
to be clear we are not marketing this widely
or to your extended family. We are building

368
00:37:16,650 --> 00:37:21,029
this because we want it. We would rather not
have service than be connected to one of these,

369
00:37:21,029 --> 00:37:23,269
especially at DEF CON.
(Laughter).

370
00:37:23,269 --> 00:37:27,740
And we will be sharing it because we thought
that you folks in this room might also want

371
00:37:27,740 --> 00:37:32,279
this option. This will be available soon.
We have a few kinks to work out. We have to

372
00:37:32,279 --> 00:37:39,279
thank Mira Thambireddy for doing pretty much
all the work on. This.

373
00:37:40,279 --> 00:37:44,089
You can encrypt what you do on your phone
and there are a multitude of free and paid

374
00:37:44,089 --> 00:37:50,849
apps to do so, if you can convince your communication
partner to use the same app.

375
00:37:50,849 --> 00:37:57,779
So, what else can you do if you route this
or another femtocell?

376
00:37:57,779 --> 00:38:04,710
And you are operating a small cell tower?
Well, there's WAP. WAP is basically web browsing

377
00:38:04,710 --> 00:38:11,609
for cell phones. It does SSL middling whether
they tell that you or not. I'm looking at

378
00:38:11,609 --> 00:38:18,609
you Nokia. You might think that WAP is dead
but it's used by a couple billion people in

379
00:38:18,650 --> 00:38:23,779
the developing world and smartphone manufacturers
and carriers are still developing and investing

380
00:38:23,779 --> 00:38:28,880
heavily in it. We think it's a worth while
research target.

381
00:38:28,880 --> 00:38:32,430
And being of course, there's that binary blob
that has complete control over your entire

382
00:38:32,430 --> 00:38:36,930
phone that nobody has been able to inspect
in any straightforward way, at least not that

383
00:38:36,930 --> 00:38:41,250
we can actually see the results of. You can
totally fuzz the base band with a femtocell

384
00:38:41,250 --> 00:38:45,279
and it would probably let you get a little
bit deeper into any carrier specific stuff

385
00:38:45,279 --> 00:38:51,309
that they are doing, than just using a general
software to find radio.

386
00:38:51,309 --> 00:38:55,970
And since the device makes a VPN into the
carrier network, you can poke around inside

387
00:38:55,970 --> 00:39:00,700
of their network. You can look at attacking
other femtocells from your femtocells or look

388
00:39:00,700 --> 00:39:07,250
at the carrier's network itself. The talk
at two years ago at Black Hat, they were able

389
00:39:07,250 --> 00:39:11,940
to wire tap not just their femtocell, but
every single femtocell that was on the French

390
00:39:11,940 --> 00:39:18,940
carrier. And that's a little bit farther than
we wanted to go out permission from the carrier.

391
00:39:19,109 --> 00:39:22,130
So we worked hard to wrap up a little bit
early because we wanted to leave time for

392
00:39:22,130 --> 00:39:26,630
questions and hopefully another demo. But
before questions we have to thank a lot of

393
00:39:26,630 --> 00:39:33,630
people. Andrew is ‑‑ was one of the interns
who worked on that really painful cross compilation

394
00:39:33,930 --> 00:39:40,930
but now is full fledged member of iSEC and
operating this demo and all the hard stuff.

395
00:39:41,250 --> 00:39:48,250
RSAXVC and Doug Kelly who helped us with a
lot of the initial work. Davis and Tim who

396
00:39:48,640 --> 00:39:55,640
also helped us when we got tuck. Mira, Michael,
Pratik, and really all of iSEC and, of course,

397
00:39:57,440 --> 00:40:00,769
last but not least our external and internal
legal counsels.

398
00:40:00,769 --> 00:40:06,680
(Laughter).
So I really have no idea if this is going

399
00:40:06,680 --> 00:40:13,680
to work, but we are going to try and do another
demo.

400
00:40:15,279 --> 00:40:21,609
So if you want to send a text message that
shows up on the screen, there is the number,

401
00:40:21,609 --> 00:40:28,609
have at it! And I will take questions while
it happens. How did we get around the GPS?

402
00:40:41,390 --> 00:40:48,390
Just a long GPS cable will work.
 Oh, there it is.

403
00:40:53,170 --> 00:41:00,170
(Laughter)
Do the custom ROMs have the transparent proxy?

404
00:41:00,420 --> 00:41:07,309
When we were test, all phones have the transparent
proxy. It doesn't have to do with the ROM.

405
00:41:07,309 --> 00:41:14,309
 AUDIENCE MEMBER: (Inaudible question).
 TOM RITTER: The question was did we try

406
00:41:18,670 --> 00:41:25,670
to Flash a phone to prefer femtocells? We
were waiting for that. So the question was

407
00:41:28,079 --> 00:41:35,009
do we try flashing a ROM to prefer femtocell
to wire tapping more easily. No, we did not.

408
00:41:35,009 --> 00:41:42,009
Custom PRL. We looked into it, but we didn't
get any success.

409
00:41:42,969 --> 00:41:49,969
 AUDIENCE MEMBER: So have you been inside
a real cell tower and seen what possibly might

410
00:41:55,769 --> 00:41:56,880
be there and thought maybe this might be applicable
to actual real cell towers.

411
00:41:56,880 --> 00:41:58,730
 TOM RITTER: Have we been inside of a real
cell phone tower, we have not. We would love

412
00:41:58,730 --> 00:42:03,710
to see it if you have real keys to it.
 AUDIENCE MEMBER: It seems like the device

413
00:42:03,710 --> 00:42:10,710
was supposed to have six people connected.
It looks like there's a few more. How do you

414
00:42:15,529 --> 00:42:19,910
manage that?
 TOM RITTER: So the device allows up to

415
00:42:19,910 --> 00:42:26,910
six. I don't think we have more than six.
I'm sorry?

416
00:42:27,509 --> 00:42:32,499
Okay. You can have more passively associated
but only six simultaneous voice calls and

417
00:42:32,499 --> 00:42:36,779
the two folks who are the volunteers please
come up and see if your phones are associated

418
00:42:36,779 --> 00:42:40,450
and send some text messages.
(Laughter)

419
00:42:40,450 --> 00:42:47,450
 Hey, NSA, spell check!
(Laughter).

420
00:42:48,290 --> 00:42:55,290
 You will have to shout.
 TOM RITTER: Would a Sprint device also

421
00:43:00,230 --> 00:43:07,230
connect to our femtocell? We don't believe
so. And ‑‑ yeah, if anyone has a Sprint

422
00:43:08,299 --> 00:43:11,779
device. We don't believe so. And really, like
we just created our proof of concept code

423
00:43:11,779 --> 00:43:16,940
on Verizon. This is applicable to like, most
femtocells.

424
00:43:16,940 --> 00:43:22,799
 AUDIENCE MEMBER: How does Verizon deploy
the patches?

425
00:43:22,799 --> 00:43:25,960
 TOM RITTER: They push the patch down to
the unit. It's not like you have to plug in

426
00:43:25,960 --> 00:43:32,960
a USB stick or anything. It auto updates itself.
 AUDIENCE MEMBER: (Inaudible).

427
00:43:35,589 --> 00:43:42,589
 AUDIENCE MEMBER: You said the mic is active,
even before you place a phone call?

428
00:43:43,289 --> 00:43:46,809
 TOM RITTER: The question is the mics are
active before you place a phone call, is that

429
00:43:46,809 --> 00:43:49,220
the truth even if you are not connected to
a femtocell?

430
00:43:49,220 --> 00:43:54,849
I don't know.
 AUDIENCE MEMBER: You said this device has

431
00:43:54,849 --> 00:44:01,849
3G connections. If you have 4G indicator on,
does that mean that ‑‑

432
00:44:02,080 --> 00:44:09,080
 TOM RITTER: The question was about 3G and
4G. In our testing, our experience was that

433
00:44:09,140 --> 00:44:13,589
if you have a 4G data connection, we won't
see your data but we will see your SMS and

434
00:44:13,589 --> 00:44:18,319
your phone calls.
(Laughter)

435
00:44:18,319 --> 00:44:25,319
(Applause)
 AUDIENCE MEMBER: (Inaudible).

436
00:44:26,800 --> 00:44:33,800
 TOM RITTER: Yes, it's the phone that's
associated to the femtocell that we intercept,

437
00:44:38,069 --> 00:44:45,069
not the sender. We are just showing the text
messages that are coming in. Try sending a

438
00:44:45,970 --> 00:44:49,730
text message. We will see an outgoing one.
(Laughter)

439
00:44:49,730 --> 00:44:56,730
 AUDIENCE MEMBER: (Inaudible).
 TOM RITTER: I'm sorry.

440
00:44:59,000 --> 00:45:06,000
 AUDIENCE MEMBER: I'm sorry, I still can't
hear you.

441
00:45:10,920 --> 00:45:17,920
(Laughter)
 TOM RITTER: We, I think, something about

442
00:45:21,529 --> 00:45:28,529
a signal amplifier. We have a directional
signal antenna. You have more antennas, power

443
00:45:28,680 --> 00:45:35,680
antennas. We didn't really try. We were trying
to minimize the number of phones we were getting.

444
00:45:39,369 --> 00:45:46,369
 AUDIENCE MEMBER: You mentioned the realtime
set. Can you use realtime devices to see if

445
00:45:49,259 --> 00:45:50,349
it uses the same password?
 TOM RITTER: The question was about the

446
00:45:50,349 --> 00:45:57,190
key for the IP sec tunnel, we looked at multiple
devices. The key is not the same across them.

447
00:45:57,190 --> 00:46:04,029
 AUDIENCE MEMBER: Have you tried this with
Mi‑Fi?

448
00:46:04,029 --> 00:46:06,839
 TOM RITTER: We have not tried getting a
Mi‑Fi device on to it.

449
00:46:06,839 --> 00:46:13,839
 AUDIENCE MEMBER: You have found out what
the software process is for Verizon to be

450
00:46:15,130 --> 00:46:21,410
able to push updates and disable it?
 TOM RITTER: We did look at that a little

451
00:46:21,410 --> 00:46:24,689
bit.
(Laughter)

452
00:46:24,689 --> 00:46:31,689
 TOM RITTER: If there are no other questions,
we will pack up. Thank you very much.

453
00:46:34,900 --> 00:46:35,150
(Applause)