Hi. And welcome. For the next hour, we will be talking about femtocells, a femtocell
is a low cost low coverage, it's a mini cell tower. It's also a Linux box and if you hack
it, you can intercept the phone calls, text messages and web surfing. We will not talk
about Snowden or any of this political stuff. This will focus on technical facts. Mostly
technical facts. There's been many conversations over the last
few days and after lengthy discussions, Verizon has asked us to include these bullets.
(Laughter). And moving on. Before we go too much further,
a quick note on handset pairing. Your phone will associate to a femtocell automatically
and without your knowledge. There may be some members of the audience connected to our network
right now. Those signs out front are not just for show. You may want to put it in airplane
mode. It has everything to do with the tower and very little with the actual phone. We
don't break or alter your phone, at least not yet.
We also want to clearly state before we go too much further, the vendor has addressed
the vulnerabilities to get root. We originally disclosed to the vendor, and they worked very
quickly to release a patch. The security issues we will be discussing apply to more than one
carrier. As you all know nothing is 100% secure and we have architectural concerns related
to femtocells. Than should come as no surprise to you, but we are not first people to have
these concerns. As you can see, research has been popping
femtocells since at least 2010. Latest example was here in Las Vegas at Black Hat in 2011
where a group of hackers hackered the crap out of a femtocell from France. Prior to that
it was a Vodafone box. RSAXVC, and Doug Kelly, was very helpful to us during our earlier
testing. As it turns out, someone looked at these things
and didn't say let's use this for evil. They used this femtocell as a cellular IDS, and
I believe that happens tomorrow. So we will cover some similar topics but on
a carrier that affects 1 in 3 Americans. To the best of our knowledge, no one has publicly
presented an attack on a femtocell on a North American CDMA carrier. If you haven't figured
it out yet, we are talking about Verizon. By the numbers we are talking about 300 million
people in and 100 million Verizon subscribers. I'm not that good at math, but that's about
a third of the country. We will hopefully demonstrate how we can record
and listen to phone calls, text messages, picture messages and data. We can perform
active man in the middle attacks, as well as SSL stripping and if that with respect
enough, we throw in some cloning fraud for good measure.
So to break it down further, we will discuss how we obtained access to the femtocell, what
we did once we got on it, the custom code we wrote to get the traffic we wanted, and
our thoughts on how to fix these things. For those of you that may not be familiar
with a femtocell architecture, here's a high‑level diagram, your phone connects to the femtocell
over a cellular radio. In this case it happens to be CDMA. The femtocell uses a broadband
Internet connection to create an IP sec tunnel back to the carrier's internal network.
Verizon currently has two models of consumer grade femtocell, the CS‑16UC4, and SCS2U01.
The 2‑01 supports six simultaneous users at 3g speeds. We were able to route both of
these devices but we created most of our proof of concept on the 2O01, because it's newer,
faster and better looking. As we were doing some high‑level due diligence,
we discovered that Sprint has a femtocell too. Both Verizon models and one Sprint model
are made by the same manufacturer, Samsung. We didn't have that much time to do a ton
of testing on the Sprint model but the one on the left is similar to the UC4 and is vulnerable
to attacks. But Sprint is replacing this with a newer model. We took a look at the newer
model and it's not vulnerable to the same attacks.
Let's talk about the femtocell we spent most of our time, the 2U01 has an ARM processor
and a lattice FPGA. Externally it has a GPS antenna, a CDMA antenna and either net and
HDMI ports. I know what you are thinking, did he just say HDMI port? Yes, I did!
It's a little tough to make out in this picture but on the bottom of this device, hidden under
a rubber plug is an HDMI port. We knew it couldn't be used for video so we figured it
has to be a console port and we were right. Why is it HDMI port but I do know we know
that Samsung makes a crap load of TVs. (Laughter).
So how does one connect to an HDMI console port. You connect it in half and stick it
on a USB FTDI and connect it and use a company branded pen for the connection because you
are not that good at soldering. (Laughter).
We really have to thank RSAXVC and Doug Kelly for figuring this out.
I want to talk briefly about the range since it's a question we get quite a lot. The device
documentation states that a phone must be within 15 feet to register to the femtocell
and must stay within approximately 40 feet to stay connected but in reality it depends.
Your phone will connect to the tower that has the strongest signal. So if you are in
an area with very good cell coverage. The real towers tend to drown out this small bay
station. We think there's some tweaking that can be done in the software to boost the signal
but probably the biggest thing is to buy a big assed amplified antenna.
If you are in an area that you need something like this, then we imagine the capture range
would be pretty good. We did purchase an after market antenna this creates a nice, tight
cone. All right. So I was not entirely truthful.
One last mention of the older model, on the UC4, could you interrupt the boot process.
That was fixed in the 2U01 so we had our find our way in. We found we could abort the boot
process which drops to you a prompt. Because we are interrupting the boot process before
the device is fully functional we had to manually run some start‑up scripts. One at the proper
run level, death vice will start movie cell binaries and connect to the carrier's network.
As we mentioned, they will no longer get you route on a batch device but they are pretty
handy and will probably be very useful when testing other embedded devices.
So now that we have established a presence on a mini cell tower, let's poke around this
device and see what we can see. The 2U01 Rones Monta Vista Linux 5. It includes a strict
lip U. system and a few diverse drivers to control its operation as a base station. It
includes AuthenTec, which is a kernel model. It's route but it's a pre‑bare bones, Linux: So said, it's a
little unwieldy but we can use it to edit SSHD config to allow password root login.
We did that and flushed the IP tables and it made things easier to work with.
We can SSH in, but we have to run the said command on every boot because the file system
is pulled fresh every time you power cycle. So we figured we could edit and reflash the
firmware but we didn't want to run the risk of creating a door stop. We continued looking
around and eventually we noticed a persistent file system location. The things are starting
to get more interesting, right? We found a persistent place to store files but that doesn't
necessarily give us persistent root access, right? So we cadded all the things and spent
a lot of time in slash ETSI. And we came across a debug mode. For the record that's not our
typo in the echo statement. I want to make that clear.
We created a file named .ubrc and we have a typo in the boot output and it worked.
More importantly, since this .ubirc file, we can put our own commands in there and it
will be executed by root every time the unit boots. It's an incredible time saver. We used
it to patch SSDIC and drop us in a root shell automatically.
So we overcame the next hurdle. We now persistent route access. So let's get some packets and
do some eavesdropping. We will run a dump on the TCP interface and we see encrypted
packets everywhere. What the hell?
It turns out that quick set is a kernel module. It sales the packets and does encryption and
description and sends the items. It seems like the fun is over. Now what?
Well, luckily, it's all just engineering and with that, I will turn it over to Tom.
TOM RITTER: That's a pretty good representation of how that programming worked on this project.
(Laughter). So setting up the ‑‑ certainly not the
good looks. So setting up the cross compilation environment. It was a real pain in the neck.
That's why we have interns. (Laughter)
(Applause). Sorry, Andrew. We were finally able to find
the right version of the Monta Vista and we were able to run on the femtocell. We figured
out that we needed to write the kernel module and insert it in such a way we would be able
to copy the packets going out and after they were decrypted on the way in. With that module
loaded we can pass them out to user land for logging to a PCAP. So with that hurdle over,
we can go after the fun stuff. So we've got some plain text packets, but
it's a mess. Wire struct does not help us and the port structure is completely foreign.
A phone call generates lots of small UDP packets like any VoIP protocol, but who is talking
to who and where is the audio. We could fire wire shark to ATP, to get us a small step
closer. The RTP payload is in the dynamic range and according to the speck, it's do
for whatever you want and don't expect to interoperate with anybody. We had to figure
out what type of codec we did. We downloaded every singing RFC, for codec, and we eventually
found one we thought it might, EVRC. It's one of those random cellular codecs that no
media player implements. What do you do when you hit a dead end and you can't figure something
out? You go to stack overflow.
(Applause). But this had already been asked, and received
no answers. So here's the real secret of productive acres, it's not asking questions on stack
overflow. It's bountying questions on stack overflow. So what we got was a link to the
actual reference implementation of EVRC published by the 3G PPP2 working group thingy. And it
took some fiddling but after passing it through the reference implementation and the SOCs
we were able to get some audio out of that. And with, that let's hopefully go for the
live voice demo. So Doug is placing a call on a phone that
is associated to the femtocell. And hopefully Andrew's phone will ring in just a moment.
Hello. DOUG DePERRY: Andrew, did you fill about
that new phishing scheme, it's off the hook. Talk you to later, Doug.
TOM RITTER: So the call is complete. I need to switch over, actually. Okay. So Andrew
is going to pull it off of the femtocell and parse it ‑‑ pass it through the ‑‑
I hope this works. So that was before the call was placed. Did you know that your mic
was active then? (Laughter).
Now it's ringing. Hello. Hey, Andrew, did you hear about that new phishing scheme, it's
off the hook. Talk you to later, Doug.
TOM RITTER: And there's live voice interception. (Applause).
And this was the backup video. (Laughter)
So for SMS, it took us a while to figure out SMS also, but we will spare you the gory details.
The text message is seven bit blocks so it's a bit of a pain but we can get the data out.
We made a wire struct, but that's not nearly as interesting as doing another live demo.
So let's try for that. So we should be displaying a couple of text
messages that we have asked people to send us. Is that them right there? Okay. So they
have already gone through at the bottom. So they just kind of popped right up. Can we
get another couple sent real quick? There are a lot of encoding formats for SMS
and we don't parse them all. All right. So that's SMS.
(Applause). All right. So we have voice calls and SMS
but we live in the smartphone era. So let's see some actual data and thankfully it was
plain text, so much easier. Everything is parsed and displayed in wire shark. There
are some layers and tunnels that encapsulate the data that I'll talk about in a sec. But
pretty much it's over any LAN capture. With passive interception, we can pick up your
MMS. You did know that didn't go over SSL, right?
So we took a photo of the audience. And sent it because it takes a little bit for MMS to
go out in DEF CON and we will show it to you right now. And there you all are.
(Applause). Okay. So we can few all the plain text. Passive
interception is done and working. Let's do some active attacks. The easiest thing to
do with data is to drop it on the floor. Now, there's a lot of debate about how iMessage
works and how secure it is. It uses SSL to talk home to Apple. We can't see those messages
with passive interception but if you block the SSL connection, iMessage fails over to
SMS and SMS is plain text and we can see that just fine!
Okay. So it is plain text, but it's encapsulated all up and down.
If we are lucky, it's a fairly nice encapsulation that wire shark will handle for us. If we
are unlucky, the normal, IP and HTTP gets used and gets split across GRE packets and
this is what it looks like when you are unlucky. This is HTTP, and these are the TCP and IP.
That's actually the data section of the upper left‑hand inset and then if you can read
the wire shark part, there's the PPP fragments. That's the IP fragment split across multiple
GRE frames. So our goal is to edit a web page in the simplest way possible. And changing
anything in HTTP means changing the TCP checksum. And changing anything also means changing
the PPP checksum. TCP checksum is at the beginning and PPP is at the end and the frames might
be out of order. So it will be a little tricky. The first thing we tried doing was doing it
in line in the kernel. Really quickly, we figured out that the carrier has a transparent
proxy on all of your web browsing on your phone. Let me repeat.
That Verizon hey has a transparent proxy on all the web browsing on your phone. It's kind
of creepy doing this without your knowledge but frankly, we were not really surprised.
One of the things they do with this transparent proxy is apply HTTP compression to anything
that doesn't already have it, which makes sense because HTTP compression does actually
speed things up. We didn't detect any SSL man in the middling or JavaScript injection
and I don't think that Verizon is alone or the only carrier doing this. But nonetheless,
it's there and from a technical standpoint, with he had to work around it. We tried disabling
the compression but no ice. We had to do DNS hijacking. It does their
own DNS lookup on the host header. So then we tried something crazy and this got us pretty
close. We did the DNS hijacking and in the kernel. We rewrote from port 80 to 81. So
the carrier wouldn't proxy it. Our server listens on port 81 and responds back. And
then on the inbound the kernel module rewrites it back to 80 and this worked most of the
time. The problem was there were a couple of corner cases and on hundreds or thousands
of packets for a web page load, that's enough to sync it.
So what ended up working was doing all of that except the server that listens on port
81 will redirect the browser to port 8080 which the carrier also doesn't proxy. So in
the end, what ends up happening, you open a website, say CNN.com. We DNS hijack you.
You try to talk to our server on port 80 but the femtocell kernel module rewrites your
connection to our server on port 81 to bypass the proxy. We respond and the kernel rewrites
it back to port 80. Now, our response actually redirects you to CNN.com on port 8080, which
you don't notice because mobile UI sucks. Then you talk to our server on port 8080 directly
bypassing the proxy with no port rewriting and then we can man in the middle user, we
strip off SSL and pass along the cookies. It's a little bit slow but cellular is a little
bit slow. So because it is a little bit slow, we will ‑‑ it's a little bit slow, we
will show a video of this one. Okay. So in the bottom right‑hand corner,
we are typing in a bank wellsfargo.com. And in the lower left‑hand side you can see
the resource loads so a couple from Google and then we will see the Wells Fargo resources.
In the upper left‑hand is where the user name and password will show up. So there's
Wells Fargo. And we will click on sign in. And then we will type the user name, character
by painful character. And then the password. And there is the user name and password in
the upper left. All right. So that is data middling. And with
that, I will turn it back over to Doug. DOUG DePERRY: So this is all really cool
and we were very excited about it, but these things are mini cell towers. So it's got to
be possible to do more with them, right? So if there's anything cooler than intercepting
and modifying phone calls and text messages, it's becoming the person holding the phone.
For those of you familiar with GSM terms like IMEI or IMSI, the key difference here is that
SIM cards are not typically used in US CDMA networks so instead of IMSI, the MSSDN is
your phone number. It's sometimes not always the same as your phone number. This is an
important distinction. Most, but not all of the communication between the handset and
the carrier uses the ESN and MIM for identification. Unfortunately there's not any obvious correlation
between the MIM and the actual phone number. ESN was previously used as a unique number
but carriers ran out officially in 2010. ESNs have since been superseded by MEIDs. Pseudo‑ESNs
are led by 80. They are not guaranteed to be unique since the MEID is the identifier.
Older model phones use the ESN to identify themselves to the network. Newer phones use
the MEID, but still retain a pseudo‑ESN since it's required for compatible reasons.
So to clone a phone, all you have to do is grab somebody's phone, write down the else
he is or MEID and their phone number and then copy these numbers to another handset to get
a valid clone, right? Well, years ago this used to be all it took.
Since the MIN was usually the same as the phone number and the ESN was printed on any
given device, it was trivial for an attacker to get these values and use someone else's
expensive wireless minutes to make calls. So Qualcomm and the CDMA carriers had to come
up with a solution. The cave authentication method makes it difficult to successfully
clone a CDMA phone. It's authenticates the customer and the call. Manufacturers of CDMA
devices are supposed to make these keys difficult to obtain so that a full clone is not possible.
All that being said, let's see if our rogue femtocell has any more secrets it wants to
give up. Hint! As we mentioned earlier, the femtocell acts
like a typical cell tower, except at least one key difference. The femtocell only uses
the ESN and MIN to authenticate handsets. We are not entirely sure why. We have no idea
but it may suggest a legacy CDMA implementation. The real problem here is that we discovered
that the femtocell does not have CAVE enabled. It behaved like a legacy tower and just ignored
those keys relying solely on the ESN and MIN, and so cloning becomes extremely easy, just
like the good old days. Note that the cloned phone will only work
while connected to the femtocell but it can be any femtocell not necessarily one that's
been modified. So we just need to somehow obtain the ESN and the MIN of our victim and
program those numbers into another handset. You are generally not supposed to be able
to write the ESN, but some phone models will do it.
We wait until the victim goes to the bathroom and grab their phone and clone the phone.
But that's so messy. We have invite the victim out to eat, and wait until they go to the
bathroom. And try in playing shit and spell or words with friends, there's got to be an
easier way to defraud my friends. So remember that time I told you that we can
see every packet that goes through the femtocell? Well, that includes handset registration packets
that include the else he is and MIN of the phone associated to the femtocell. So all
I have to do is capture packets on my rogue femtocell and wait for an unsuspecting cell
phone range to come within range. When it associates with the femtocell, I catch the
ESN and MIN without physical access to the phone and without any indication of the user.
So picture is worth a thousand words. Here it is step by step. The victim phone comes
within range of a malicious femtocell and as the handset registers to the cell phone
network the ESN and MIN is recorded. It would be possible to capture phones in New York
City using a rogue femtocell and email it to an accomplice in Seattle who is using a
stock femtocell. It's almost the perfect crime. While we were testing for cloning, we noticed
or results were inconsistent. If your name was to make money through toll fraud you could
make enough money to buy a boat that has smaller boats inside of it.
(Laughter). We made a couple of ‑‑ maybe a couple
of jet skis too. We suspect our problems may have something to do with the relative signal
strength of neighboring cell towers as we saw slightly different environments in an
urban environment as opposed to a more rural one. The shore answer is we don't know. So
we tested cloning with voice, SMS and data and some of the results were expected and
some were not but probably the most interesting thing we saw was the not quite three‑way
call. So I'm going to describe a few scenarios over
the next few slides and the following definitions will be helpful. Our victim is the person
with the shiny new iPhone whose phone that we want to clone. The target is the bad guy
running this old crappy flip phone and that's been modified to act like a copy or a clone
of the victim phone. So the easiest scenario is the victim's phone
is turned off, jammed otherwise not connected to any cell towers. Everything works as expected.
You have an exact working copy of the victim's phone for all intents and purposes. So when
both phones are associated to the same femtocell, we noticed a few different things. Of course,
the cloned phone, the target, must be associated to the femtocell in order to work properly.
It is only possible to place outgoing calls one at a time. No matter which phone initiates
outgoing call, any subsequent call placed will force that call to drop. It doesn't matter
which phone is which, either the victim or the target can force the victim to drop calls.
We didn't notice any issues with outgoing text messages and for incoming SMS, the usual
behavior seemed to be that both phones would get the text message.
So with incoming calls, sometimes one of two behaviors is possible. The first is that only
one of the two phones rings. It could be the victim or the target. It doesn't matter.
Other times, both phones will ring at the same time. The phone that picks up the call
first usually wins, which means it gets to stay on the call. But the coolest part is
that sometimes if the two phones answered within a few seconds of each other, we got
what we are getting a two and a half way call. What would happen is both the target and the
victim phones would connect and each would be able to hear the inbound caller but not
each other. So the eavesdropping scenario is pretty clear.
The bad guy can clone a phone and as soon as an incoming call comes in, picks up the
call and mutes his mic and can hear everything said by the incoming caller. In the second
scenario, the target is associated to the femtocell as required, but the victim is out
and about connected to an actual cell tower. The phone that gets the incoming call appears
to depend on which phone has had more recent communication with the carrier network, like
a call or a text message. We couldn't reproduce the two and a half way call since both phones
never rang at the same time. SMS was pretty similar. We never got an SMS on both phones
at the same time. So, outgoing calls are a little more interesting.
So let's say the target, the cloned phone, is on an active phone call. This works fine
until our unsuspecting victim places an outgoing call to another party. The bad guy's call
gets dropped and the call of our innocent victim is allowed to connect reliably. However,
if the victim is on an active call, like pictured, and the target places an outgoing call, the
call will connect allowing two independent phone calls. So these implications are clear
as well. Why use your own minutes when you can use someone else's to call 1‑900 numbers
and that's especially cool if you own the 1‑900 number.
As I said earlier, we were going to talk about cloning data and here we are. It appears to
be slightly more difficult to establish a data connection on a clone than it is to clone
voice and text services. Data services on Verizon are needed. Long story short, the
carrier network requires more numerical identifiers for voice and SMS, it's more difficult and
we didn't dig too deep into it. So we have a video to demonstrate a two and
a half way call. Oops. Maybe not. There we go.
All right. So that's me making a phone call to a single number. (Phone ringing).
Both phones are ringing, the victim phone is the one on left and the target is the one
on the right. And we will fast forward obnoxiously. Both calls get answered. Both calls connect
and stay connected. And now we will do some very sophisticated voice testing. Stand by
to prove that the two calls are connected. Hello.
Oh, there it is. Hello.
You just saw an inside secret to phone
testers. It's very technical. I'll handle that.
And so that's that. So we mentioned this at the beginning but
this issue was resolved by Verizon on the back end many months ago, which is great,
because authentication should be checked on the internal network that the carriers control,
not on the small box that they don't. And with that, I will turn it back over to Tom.
TOM RITTER: Okay. So it would be easy to think that this is all about Verizon but this
is really about everybody. There are over 30 carriers worldwide who have femtocell and
three of the four major US carriers. And clearly, there are issues here so what's a multibillion
dollars, multinational corporation to do? Well, you can harden the actual device. But
as we all know, there's nothing you are going to be able to do on the platform to prevent
people with physical access from breaking in. Root is always possible. We didn't have
to do more sophisticated attacks but obviously you shouldn't rule them out. There are lots
of ways to get on to an embedded device and frankly, we went in through the front door.
So what else can a vendor do? Well, you can force registration. Make the femtocell owner
list the phones allowed to connect through their femtocell and then confirm with the
phone owner that they're cool with allowing that and if this they try connecting through
any other femtocell, don't let them and do this white listing inside the carrier network
of course, not on the actual device and this would make it a lot harder to take one of
these down to Times Square or Las Vegas and just start gobbling up everyone around them.
So device registration clearly reduces the attack service. Here's a breakdown of the
major US cell phone carriers and how they handle handset registration on the femtocell,
besides T‑Mobile who doesn't have a femtocell, AT&T is leading in this category because they
require registration. The other carriers, Sprint and Verizon do not.
So phone registration does prevent the easiest attack but it doesn't win us over completely.
It doesn't prevent attacks where I isolate you from the scarier network. Try to make
phone calls and send text messages. Even though I never deliver that up to the carrier, I
will still see them. I can track you and read your SMS and we verified this experimentally.
It's actually what we are doing right now. We isolate any phone that's not white listed
so we don't receive inbound text messages or data sessions or see what you are sending
because we white it out. With more engineering, it would be possible to connect these phone
calls to our phone line and spoof SMS to receive and route the data traffic on the normal Internet
connection and let you browse the Internet without the carrier network knowing. So it's a good minimum level of security but
we don't think it's enough. Really what you should be doing is zipping
them all together. You guys know that there will be bugs in everything, but that said
we like Wi‑Fi calling. If the handset is on Wi‑Fi, not even your own Wi‑Fi but
untrusted Wi‑Fi, and IPSECs or SSL tunnels doing certificate pinning and the phone is
appropriately distrusted from a network perspective so you can't just go Nmapping all of their
crap, we think you have a much stronger architecture. You have to do the same type of cell phone
authentication you do with the tower to avoid theft of service but that's to weaker than
what we have now. And what you get is not needing femtocells.
That's a win, being able to make calls on any random Wi‑Fi and that's a win, and it's
encrypted. So that's a win. Going even further, you build an end to end
encryption to protect the call, against untrusted Wi‑Fi operators and the carrier. There are
individual PAPs that do this but they all require the recipient to have the same PAP.
If Google and Apple and Blackberry supported this, we think there would be a huge increase
in adoption. So I was just talking about this, but let's
sum up and present a couple of other Band‑Aids. Ultimately, a losing proposition. Requiring
registration prevents unargued attacks to some degree, but long term we're pretty nervous
about giving random people, like yourselves small cell phone towers, and just hoping you
don't break into them. Now, can you tell if you are connected to
a femtocell? We said in the beginning, no, but it had an asterisk. We noticed that some
android phones have an icon indicating they are connected to a femtocell this was only
in phones that Verizon had modified. It's not in the Android source or any stock or
Flashed ROMs. An iPhone has no visual indicator. There's a short beep at the beginning of phone
calls and it's really easy to miss, and you have to make a phone call.
Somehow these Android phones were detecting a femtocell and we reversed engineered that.
And then we made our own PAP, the feftocatcher. So using this, we can write a tool to put
a phone into airplane mode when it detects itself being connected to a femtocell. Now,
to be clear we are not marketing this widely or to your extended family. We are building
this because we want it. We would rather not have service than be connected to one of these,
especially at DEF CON. (Laughter).
And we will be sharing it because we thought that you folks in this room might also want
this option. This will be available soon. We have a few kinks to work out. We have to
thank Mira Thambireddy for doing pretty much all the work on. This.
You can encrypt what you do on your phone and there are a multitude of free and paid
apps to do so, if you can convince your communication partner to use the same app.
So, what else can you do if you route this or another femtocell?
And you are operating a small cell tower? Well, there's WAP. WAP is basically web browsing
for cell phones. It does SSL middling whether they tell that you or not. I'm looking at
you Nokia. You might think that WAP is dead but it's used by a couple billion people in
the developing world and smartphone manufacturers and carriers are still developing and investing
heavily in it. We think it's a worth while research target.
And being of course, there's that binary blob that has complete control over your entire
phone that nobody has been able to inspect in any straightforward way, at least not that
we can actually see the results of. You can totally fuzz the base band with a femtocell
and it would probably let you get a little bit deeper into any carrier specific stuff
that they are doing, than just using a general software to find radio.
And since the device makes a VPN into the carrier network, you can poke around inside
of their network. You can look at attacking other femtocells from your femtocells or look
at the carrier's network itself. The talk at two years ago at Black Hat, they were able
to wire tap not just their femtocell, but every single femtocell that was on the French
carrier. And that's a little bit farther than we wanted to go out permission from the carrier.
So we worked hard to wrap up a little bit early because we wanted to leave time for
questions and hopefully another demo. But before questions we have to thank a lot of
people. Andrew is ‑‑ was one of the interns who worked on that really painful cross compilation
but now is full fledged member of iSEC and operating this demo and all the hard stuff.
RSAXVC and Doug Kelly who helped us with a lot of the initial work. Davis and Tim who
also helped us when we got tuck. Mira, Michael, Pratik, and really all of iSEC and, of course,
last but not least our external and internal legal counsels.
(Laughter). So I really have no idea if this is going
to work, but we are going to try and do another demo.
So if you want to send a text message that shows up on the screen, there is the number,
have at it! And I will take questions while it happens. How did we get around the GPS?
Just a long GPS cable will work. Oh, there it is.
(Laughter) Do the custom ROMs have the transparent proxy?
When we were test, all phones have the transparent proxy. It doesn't have to do with the ROM.
AUDIENCE MEMBER: (Inaudible question). TOM RITTER: The question was did we try
to Flash a phone to prefer femtocells? We were waiting for that. So the question was
do we try flashing a ROM to prefer femtocell to wire tapping more easily. No, we did not.
Custom PRL. We looked into it, but we didn't get any success.
AUDIENCE MEMBER: So have you been inside a real cell tower and seen what possibly might
be there and thought maybe this might be applicable to actual real cell towers.
TOM RITTER: Have we been inside of a real cell phone tower, we have not. We would love
to see it if you have real keys to it. AUDIENCE MEMBER: It seems like the device
was supposed to have six people connected. It looks like there's a few more. How do you
manage that? TOM RITTER: So the device allows up to
six. I don't think we have more than six. I'm sorry?
Okay. You can have more passively associated but only six simultaneous voice calls and
the two folks who are the volunteers please come up and see if your phones are associated
and send some text messages. (Laughter)
Hey, NSA, spell check! (Laughter).
You will have to shout. TOM RITTER: Would a Sprint device also
connect to our femtocell? We don't believe so. And ‑‑ yeah, if anyone has a Sprint
device. We don't believe so. And really, like we just created our proof of concept code
on Verizon. This is applicable to like, most femtocells.
AUDIENCE MEMBER: How does Verizon deploy the patches?
TOM RITTER: They push the patch down to the unit. It's not like you have to plug in
a USB stick or anything. It auto updates itself. AUDIENCE MEMBER: (Inaudible).
AUDIENCE MEMBER: You said the mic is active, even before you place a phone call?
TOM RITTER: The question is the mics are active before you place a phone call, is that
the truth even if you are not connected to a femtocell?
I don't know. AUDIENCE MEMBER: You said this device has
3G connections. If you have 4G indicator on, does that mean that ‑‑
TOM RITTER: The question was about 3G and 4G. In our testing, our experience was that
if you have a 4G data connection, we won't see your data but we will see your SMS and
your phone calls. (Laughter)
(Applause) AUDIENCE MEMBER: (Inaudible).
TOM RITTER: Yes, it's the phone that's associated to the femtocell that we intercept,
not the sender. We are just showing the text messages that are coming in. Try sending a
text message. We will see an outgoing one. (Laughter)
AUDIENCE MEMBER: (Inaudible). TOM RITTER: I'm sorry.
AUDIENCE MEMBER: I'm sorry, I still can't hear you.
(Laughter) TOM RITTER: We, I think, something about
a signal amplifier. We have a directional signal antenna. You have more antennas, power
antennas. We didn't really try. We were trying to minimize the number of phones we were getting.
AUDIENCE MEMBER: You mentioned the realtime set. Can you use realtime devices to see if
it uses the same password? TOM RITTER: The question was about the
key for the IP sec tunnel, we looked at multiple devices. The key is not the same across them.
AUDIENCE MEMBER: Have you tried this with Mi‑Fi?
TOM RITTER: We have not tried getting a Mi‑Fi device on to it.
AUDIENCE MEMBER: You have found out what the software process is for Verizon to be
able to push updates and disable it? TOM RITTER: We did look at that a little
bit. (Laughter)
TOM RITTER: If there are no other questions, we will pack up. Thank you very much.
(Applause)