Hi. And welcome. For the next hour, we're going to be talking about femtocells. A femtocell
is a low cost, low power consumer product designed to increase cellular signal coverage.
It's basically a mini cell tower. It's also a Linux box. If you hack it, you can intercept
the phone calls, text messages and web surfing of nearly anyone within range. We're not going
to talk about Prism or Snowden or any of that political stuff. This presentation is going
to 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.
And moving on. Before we go too much further, quick note on handset pairing. Your phone will
associate to a femtocell automatically and without your knowledge. It's not like joining
a Wi‑Fi network. You don't have a choice. In fact, there may be some members of the
audience connected to our network right now. Those signs out front are not just for show.
You might want to put your phone in airplane mode. And one more thing. This research has
everything to do with the tower and very little to do with the actual phone. We don't break
or alter anything on your phone, at least not yet.
We also want to clearly state before we go too much further that the vendor has addressed
the vulnerabilities that we use to get root on the device. We originally disclosed to
the vendor just about eight months ago and they worked very quickly over Christmas to
release a patch. It bears mentioning that the security issues we'll be discussing apply
to more than just one carrier. And as you all know, nothing is 100% secure and we do
have some architectural concerns related to femtocells. And this should come as no surprise
to you, but we're not the first people to have these concerns.
As you can see, research has been popping femtocells since at least 2010. The latest
example was here in Las Vegas at Black Hat in 2011 where a group of hackers on the crap
out of a femtocell from a French carrier. Prior to them, the hacker's choice picked
on a Vodafone box. We also want to mention that RSAXVC and Doug Kelly and their tear
down hacking of the same model femtocell was very helpful to us during our earlier testing.
As it turns out, someone looked at these things and didn't immediately know what was going on.
So we immediately think let's use this for evil. A team from LMG security will be presenting
a talk using the same model femtocell as a cellular IDS and I believe that happens tomorrow.
So we're going to cover some similar topics but on a carrier that affects one in three
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're talking
about Verizon. By the numbers, we're talking roughly
100 million people in the U.S. and roughly 100 million Verizon subscribers. I'm really
not that good at math, but if my calculations are correct, 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 even perform active man in the middle attacks on data connections
as well as SSL stripping and if that weren't 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 and how we obtained access to the femtocell and 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 the femtocell architecture, here's a
high level diagram. Your phone connects to the femtocell over cellular radio. In this
case it happens to be CDMA. The femtocell then uses a broadband Internet connection to
create an IPSec tunnel back to the carrier's internal network. Verizon currently has two
models of consumer grade femtocells, the SCS26UC4 and the SCS2UO1. The UC4 was released
in early 2009 and only supports three simultaneous users at 1X speeds. The 2UO1 was released
in late 2010 and supports six simultaneous users at 3G speeds. We were able to root both
of these devices but we created most of our proof of concept code on the 2UO1 because
it's newer, faster and better looking. As we were doing some research, we found out that
Sprint has a femtocell too. As it turns out, both Verizon models and one Sprint model
are made by the same manufacturer, Samsung. We really didn't have that much time to do
a ton of testing on the Sprint model but the one on the left is very similar to the
UC4 and is vulnerable to similar attacks. However, we are told that Sprint is end-of-life
in this model of femtocell next month and replacing it with a newer model. We took
a quick look at this newer model and we can say it's not vulnerable to the exact same
attacks. So let's talk about the femtocell we spent
most of our time on. The 2UO1 has an ARM processor, one NAND flash memory and a lattice FPGA which
we assume is for digital signal processing. Externally, it's got a GPS antenna, a CDMA
antenna, as well as Ethernet and HDMI ports. I know what you're 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 the device, hidden under a rubber plug, is an HDMI port. So we knew it could impossibly
be used for video so we figured it has to be a console port and we were right. Why is
it HDMI? We don't really know but I do know that Samsung makes a crap load of TVs.
So how does one connect to an HDMI console port? Well, you cut an HDMI cable in half,
you stick it on a USB FTDI cable and you use a company branded pen to protect the connection
because you're really not that good at soldering.
We really have to thank RSAXVC and Doug Kelly for figuring this one out.
One more thing. I'd like to talk briefly about the range of this thing 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's got the strongest
signal. So if you're in an area with very good signal, you'll be able to connect to
cell coverage, the real towers tend to drown out this small base station.
We think there's some tweaking that can be done in the software to boost the signal,
but probably the easiest thing to do is just buy a big‑ass amplified antenna. Of course,
if you're in an area where you actually need something like this, then we imagine the
capture range will probably be pretty good. We did purchase an after‑market directional
antenna, mostly because we want to minimize the number of phones that we capture, and
this antenna creates a nice tight cone. All right. So I want to talk a little bit about
this. That wasn't entirely truthful. One last mention of the older model femtocell.
On the UC4, you can get root by interrupting the boot process. That was patched a while
ago and it's fixed in the 2U01, so we had to find our own way in. On the newer model,
we found that we could abort the boot process using the magic sysret key, which drops you
to a prompt where you can log in as root. Because we're interrupting the boot process
before the device is fully functional, we then had to manually run some startup scripts.
Once at the proper run level, the device will start custom UBI cell binaries and connect
the device to the carrier's network. And as we mentioned, these techniques will no
longer get you root on a patched device, but they're pretty handy and could probably come
in ‑‑ will probably be very useful when testing other embedded devices.
So now that we've established a presence on a mini cell tower, let's poke around this
device and see what we can see. The 2U01 runs a customized version of monovista Linux
5, kernel version 2618.
It includes a very stripped down Linux system, a few device divers and proprietary software
to control its operation as a base station. It also includes Authentic's QuickSec VPN client,
which is packaged as a kernel module. And I'll get more into that later.
So this is great. We're root, but it's a pretty bare bones Linux system and there's
not too many helpful commands available. There's no text editor. If you start a long‑running
command, you can't control C to kill it, stuff like that. It's very annoying. So said,
it's a little unwieldy. But we can use it to edit files. We can also use it to edit
SSHD config to allow interactive password root log‑in. So we did that. We flushed
IP tables and it made things much easier to work with.
So great. We can SSH in, but we still 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 really didn't want to run the risk of creating a door stop.
So we continued looking around and eventually we noticed a persistent file system location.
Things are starting to get a little more interesting. We found a persistent place to
store files, but that doesn't necessarily give us persistent root access, right? So we
just catted all the things and spent a lot of time in slash Etsy and we finally came
across a script that appears to control some kind of debug mode. And for the record, that's
not our typo in the echo statement. So I want to make that clear.
We created a file named .ubrc, put it in the mount on end directory and were rewarded with
a typo in the boot output. It worked. More importantly, since this .ubrc file gets
executed on startup, we can put our own commands in there and they'll be executed by root every
time the unit boots. So it's an incredible time saver. We use it to patch SSHD, flush
IP tables and then drop us in a root shell automatically.
So we overcame the next hurdle. We now have persistent root access, so let's get some
packets and do some eavesdropping.
It should be easy, right? We'll just run TCP dump on the tunnel interface and nothing.
All we see are encrypted IPsec packets everywhere. What the hell? So it turns out that QuickSec
is implemented as a net filter kernel module. It steals the packets before they ever hit
a regular network interface, does encryption decryption and sends the traffic so you can't
see anything good using a normal packet capture utility like TCP dump. So it seems like the
fun is over. Now what? Well, luckily it's all just engineering
and with that I'll turn it over to Tom.
That's a pretty good representation of how the programming worked on this project.
So setting up the cross compilation environment for this was a real pain in the neck, but
that's why we have interns.
We were finally able to find the right version
of the Monta Vista Linux tool chain and then we could compile our code against that to
make binaries and kernel modules that would run on the femtocell.
So we figured out that we needed to write our kernel module and insert it in such a
way, we would be able to copy the packets before they were encrypted going out and after
they were decrypted on the way in.
It took a little trial and error, but with that module loaded, we can pass the packets
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.
Wireshark doesn't really parse much that helps us and the ports shown are completely foreign.
We can surmise that a phone call generates lots of small UDP packets as any VoIP protocol
will do, but who's talking to who and where is the audio?
We could tell Wireshark
to interpret the data as RTP, which gets us a small step closer, but as you can see
circled here, the RTP payload type is in the dynamic range and according to the spec,
dynamic is code for do whatever you want and don't expect to interoperate with anybody.
So we had to try and figure out what type of codec we were dealing with, which we did
by downloading every single RFC and grepping through them en masse for codecs whose frame
sizes matched what we saw.
And we eventually found one we thought it might be.
EVRC.
Now EVRC is one of those random cellular codecs that no media player implements, so we couldn't
just pop it into VLC.
So what do you do when you can't figure something out and you've hit a dead end?
You go to Stack Overflow.
But this had already been asked and received no answers.
So here's the real secret of productive hackers.
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 that was published
by the 3G PP2 multi-carrier working group thingy.
And it took some nd and byte fiddling, but after passing it through the reference implementation
and the Linux utility socks, we were able to get some audio out of it.
And with that, let's hopefully go for the live voice demo.
Okay.
All right.
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?
Hey, Andrew.
Did you hear about that new phishing scheme?
It's off the hook.
Talk to you later, Doug.
All right.
So the call is complete.
So I need to switch over, actually.
Okay.
So Andrew is going to pull it off of the femtocell and pass it through the
voice.
I hope this works.
So that was before the call was placed.
Did you know your mic was active then?
Now it's ringing.
Hello?
Hey, Andrew.
Did you hear about that new phishing scheme?
It's off the hook.
Talk to you later, Doug.
And there's live voice interception.
And this was the backup video.
So for SMS, it took us a while to figure out SMS also, but we'll spare you the gory details
this time.
The text message itself is encoded in 7-bit blocks, so it's a bit of a pain, but we can
get the data out.
And in fact, we made a Wireshark dissector, 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've asked people to send us.
Is that them right there?
Okay.
So they've 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 all of them.
Okay.
There's a couple more.
All right.
So that's SMS.
Thank you.
Thank you.
So we've got 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 Wireshark.
There are some layers and tunnels that encapsulate the data that I'll talk about in a sec, but
overall it looks like pretty much any other land capture.
So 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.
Okay.
Okay.
So we can view all the plain text.
Passive interception is done and working.
Let's do some active attacks.
And 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, just how secure it is, but what's certain
is that it uses SSL to talk home to Apple.
So we can't see those messages with passive interception.
But if you block the SSL connection back home to Apple, you can't see it.
So 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're lucky, it's a fairly nice encapsulation that Wirestrike will handle for us.
If we're unlucky, the normal IP, TCP and HTTP that you're used to gets encoded and
then split across GRE packets.
And this is what it looks like when you're unlucky.
In the lower right, you can see some normal HTTP.
This is what it looks like when you're unlucky.
The bytes in front of that are the IP and TCP headers.
But that's actually the data section of the upper left hand inset.
And then if you can read the Wireshark part, there's these 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 since we're encapsulated
in PPP, changing anything also means changing the PPP checksum.
TCP checksum is at the beginning, PPP checksum is at the end, and the frames might be out
of order.
So it's going to be a little tricky.
The first thing we tried doing was doing it inline in the kernel.
Really quickly we figured out that the carrier has a transparent proxy on all your web browsing
on your phone.
Let me repeat that.
Verizon 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 weren't really surprised.
One of the things that 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 we had to work around it.
We tried disabling the compression but no dice.
So we tried doing DNS hijacking but the transparent proxy ignores the IP address that you actually
try and talk to and 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 the traffic from port 80 to port
81 so that 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 is 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 listen on 81, 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.
So 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 the user pretty effectively.
We strip off SSL, 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're going to show a video of this one.
Okay, so in the bottom right-hand corner we are typing in a bank, wellsfargo.com.
In the lower left-hand corner you can see the resource loads.
So a couple from Google.
You can 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're going to 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.
Okay.
All right.
So that is data middling.
And with that I'll turn it back over to Doug.
So this is all really cool, and we're 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.
Okay.
For those of you familiar with GSM terms like IMEI or IMSI, CDMA has their own slightly
different identifiers that serve the same purpose.
The key difference here is that SIM cards aren't typically used in U.S. CDMA networks.
So instead of an IMSI, the MIN is just a ten digit phone number.
This is sometimes the same as your actual phone number, but not always because of porting numbers
between carriers.
This is an important distinction because we discovered that most, but not all, of the
communication between the handset and the carrier usually doesn't work.
It uses the ESN and MIN for identification.
And unfortunately there's not really any obvious correlation between the MIN and the actual
phone number.
The ESN is an analog of the IMEI.
It was previously used as a unique number, but carriers ran out officially in 2010.
ESNs have since been superseded by MEIDs.
Pseudo ESNs are always prefixed with 80, the remaining bytes of the 24 least significant
bits.
Pseudo ESNs are not guaranteed to be unique since the MEID is the unique identifier for
those handsets that have one.
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 is required for compatibility
reasons.
So to clone a phone, all you have to do is grab somebody's phone, write down the ESN
or MEID in their phone number, 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.
We won't get into a ton of detail, but the cave authentication mechanism makes it very
difficult to successfully clone a CDMA phone.
Additional keys are used in a challenge response protocol to authenticate 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 femto cell has any more secrets it wants to
give up.
Hint.
As we mentioned earlier, the femto cell acts like a typical cell tower, except with at
least one key difference.
The femto cell only uses the ESN and MIN to authenticate handsets.
We're not done.
Not entirely sure why, we really have no idea, but it may suggest a legacy CDMA implementation.
But the real problem here is that we discovered that the femto cell did not have cave enabled.
It behaved like a legacy tower and just ignored those keys, relying solely on the ESN and MIN
for authentication.
So cloning becomes extremely easy, just like the good old days.
Note that the cloned phone will only work while connected to the femto cell.
But it can be any femto cell, not necessarily one that's been modified.
So we're going to go ahead and do that.
So we just need to somehow obtain the ESN and MIN of our victim and program those numbers
into another handset.
You're generally not supposed to be able to write the ESN, but some phone models do
allow it.
So it's just like the movies, right?
We wait until our victim runs to the bathroom, grab their phone, write down the ESN and MIN
and clone the phone, right?
But it's just so messy.
We have to invite our victim out to eat.
We have to wait until they go to the bathroom.
We have to risk getting caught going through their phone.
And what happens if they take their phone with them to the bathroom?
And trying to play shit and spell or words with friends, whatever that game is.
But listen, it's just not worth it.
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
femto cell?
Well, that includes handset registration packets that contain the ESN and MIN of the phone
associated to the femto cell.
So all I have to do is capture packets on my rogue femto cell, wait for an unsuspecting
mobile phone to come within range.
When the phone associates to the femto cell, I catch the ESN and MIN without physical access
to the phone and without any indication of the user.
So a picture is worth a thousand words, right?
Here it is step by step.
The victim phone comes within range of a malicious femto cell and as the handset registers to
the carrier network, the ESN and MIN are captured and written to a separate target handset.
The target handset can then be used as a perfect clone of the victim as long as it is associated
to the femto cell.
It would be possible to capture phones in New York City using a rogue femto cell and
e‑mail the numbers to an accomplice in Seattle who is using a stock femto cell.
It's almost the perfect crime.
While we were testing for cloning, we noticed our results were a little inconsistent.
It wouldn't work too well if you were trying to use it as your personal cell phone.
But if your aim was to make money through toll fraud, you could probably make enough
money to buy a boat that has smaller boats inside of it.
.
Maybe a couple 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 results when testing in an urban
environment as opposed to a more rural one.
But the short answer is we just 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 with the next few slides.
And the following definitions will be helpful.
Our victim is the person with a 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 clone of the victim phone.
So the easiest scenario is if the victim's phone is turned off, jammed, otherwise not
connected to any cell towers.
Everything works as expected.
There's no issues with service.
You've got an exact working copy of the victim's phone.
So when both phones are associated to the same femtocell, we noticed a few different
things.
Of course, the clone 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 the 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 cause each other
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're calling a two and a half way call.
So what would happen is both phones would get the text message.
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 here is pretty clear.
Bad guy can clone a phone and as soon as an incoming call comes in, picks up the call,
mutes his mic and can hear everything said by the incoming caller.
In our second scenario, the target is associated to the femto cell 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 the target.
We can'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
run up a huge bill?
Which is especially awesome if you're the one who owns the 1-900 number.
So I said it.
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's network are required for MMS, account management features, and
Internet connectivity.
Long story short, the carrier network requires more numerical identifiers for data connection
than for voice and SMS.
We're not saying it's impossible, but it's just more difficult.
We didn't really dig too deep into it.
So we have a video.
We're going to demonstrate a two-and-a-half-way call.
Whoops.
Maybe not.
Okay.
There we go.
All right.
So that's me making a phone call to a single number.
Both phones are ringing.
The victim phone is the one on the left and the target is the one on the right.
We're going to fast forward obnoxiously.
Both calls get answered.
Both calls connect and stay connected.
And now we're going to do some very sophisticated voice testing.
Stand by.
To prove that the two calls are connected.
Hello?
Oh, there it is.
Hello?
Just an inside secret to phone testers.
It's very technical if you don't all handle that.
All right.
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'll turn it back over to the code ‑‑ Tom.
TOM GJELTENBAUM.
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 femtocells and three of the four major U.S.
carriers.
And clearly there are issues here, so what's a multibillion dollar multinational corporation
to do?
Well, you can harden the actual device, but as we all know, there's nothing you're 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 onto an embedded device, and frankly, we went in through
the 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 they try connecting through any other femtocell, don't let them.
And do this whitelisting inside the carrier network, of course, not on the actual device.
And this would make it a lot harder to do.
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 carriers and how they handle handset registration on
their femtocells, at least according to their documentation.
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.
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 carrier network.
You'll still see four bars, send beacons with your MIN and ESN, try and make phone calls
and send text messages.
And even though I never deliver any of that up to the carrier, I'll still see them.
I can track you and read your SMS, and we verified this experimentally.
It's actually what we're doing right now.
We isolate any phone that's not whitelisted so we don't receive inbound text messages
or data sessions.
Or actually see what you're sending because we white it out.
With more engineering, it would be possible to connect these phone calls to our phone
line, spoof SMSs for you to receive, and even route the data traffic out the femtocell
on the normal Internet connection and let you browse the Internet all without connecting
to the carrier network.
So the carrier never knows that you're attached.
So device registration where the phone opts in to using a femtocell and the femtocell
opts in to using a phone, it's a good minimum level security, but we don't think it's enough.
Really.
What you should be doing is ditching 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 it
IP sex or SSL tunnels into the carrier network, doing certificate pinning, and the phone is
appropriately distrusted from a network perspective so you can't just go N mapping all their crap,
we think you get 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 no 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, that's a win.
And those calls are encrypted against the Wi‑Fi operator, which is a win and pretty
necessary.
So going even further, you can build in end‑to‑end encryption to protect the contents of the
call against both untrusted Wi‑Fi operators and the carrier.
As you all know, there are individual apps that do this, but they all require the recipient
to have the same app.
If Google and Apple and Blackberry built this into their phones and carriers supported the
model, 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
that you can try.
Hardening the femtocells is due diligence, but ultimately a losing proposition.
Requiring registration prevents untargeted 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're 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.
Now this was only in phones that Verizon had modified.
It's not in the Android source or any stock or flash ROMs.
An iPhone, for the record, has no visual indicator at all.
There's a short beep at the beginning of phone calls, but it's really easy to miss.
And you have to make a phone call.
But somehow these Android phones were detecting femtocells and showing an icon.
So we reverse engineered that and then we're halfway done with our own app.
The femto catcher.
So we noticed that the network ID indicates if it's a femtocell.
And although it's possible to lie about that, we didn't really investigate how hard it would
be.
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're not going to do that.
We're not marketing this widely or to your extended family.
We're building this because we want it.
We would rather not have service than be connected to one of these, especially at DEF CON.
And we're going to be sharing it because we thought that you folks in this room might
also want that option.
And this is going to be available soon.
We have a few kinks to work out.
We have to thank Mira Thamboretti a lot for pretty much doing all the work on this.
So what else can you do proactively?
Well, you can encrypt what you do on your phone.
And there are a multitude of ways to do that.
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 root this or another femtocell and you are operating
a small cell tower?
Well, there's WAP.
WAP is basically web browsing for flip phones.
It uses custom protocols.
It's heavily proxied.
It does SSL middling, whether they tell you that or not.
I'm looking at you, Nokia.
And you might think that WAP is dead, right?
But it's actually used by a couple billion people in the developing world.
And smartphone manufacturers and carriers are still developing and investing heavily
in it.
So we think it's a worthwhile research target.
And 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 could totally fuzz the baseband with a femtocell and it would probably let you get
a little bit deeper into any carrier-specific stuff that they're doing than just using
a general software-defined 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 femtocell or look at the carrier's
network itself.
And the talk from two years ago at Black Hat did this with fantastic results.
They were actually able to wiretap 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 without 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.com.
And Doug Kelly who helped us with a lot of the initial work.
We used their research.
Davis and Tim who also helped us when we got stuck.
Mira, Michael, Peter Ehlert, our COO Joel, really all of ISEC and of course last but
not least our external and internal legal counsels.
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 that happens.
How did we get around the GPS?
So the device needs a GPS signal.
Long ‑‑ just a long GPS cable.
The signal will work.
Do the custom ROMs have the transparent proxy?
When we were testing, all phones were sent through the transparent proxy.
It doesn't have to do with the ROM.
.
Okay.
The question was, did we try flashing a phone to prefer femtocells?
We were waiting for that.
So the question was, did we try flashing a ROM to prefer femtocells to wiretap people
more easily?
No, we did not.
Custom PRL.
We looked into it, but we didn't get any success.
Have we been inside a real cell tower and seen if any of this might apply there?
We have not.
We would love to get in one if you have real keys to it.
.
It's a lock key.
It's a lock key.
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 oh, I forgot.
The two folks who are the volunteers, please come up and see if your phones are working.
They're associated and send some text messages.
.
Any other questions?
Yes.
You, sir, standing up.
You're going to have to shout.
Sorry.
.
Would a Sprint device also connect to our femtocell?
We don't believe so.
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.
How does Verizon deploy the patches?
They push the patch down to the unit.
It's not like you have to plug in a USB stick or anything.
It's auto updates itself.
.
.
.
The question was, the mics are active before you place a phone call.
Is that the truth in if you're not connected to a femtocell?
I don't know.
.
.
.
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.
Any ‑‑ yes?
Yes, it's the phone that is associated to the femtocell that we intercept, not the sender.
We're just showing the text messages that are coming in.
Try sending a text message.
We'll see an outgoing one.
Okay.
I'm sorry, do you ‑‑ I'm sorry, I still can't hear you.
We ‑‑ .
I think something about a signal amplifier.
We have an external antenna, a directional one.
You could certainly hook up more antennas, powered antennas.
We're not ‑‑ I mean, we didn't really try.
We're trying to minimize the number of phones we were getting.
.
The question was about the key ‑‑
The key for the IP sec tunnel.
We did look at multiple devices.
The key is not the same across them.
Have you tried this with MiFi?
Have we tried this with MiFi?
We have not tried getting a MiFi device onto it.
Question?
So have you found out what the software process is for us to be able to push updates and
disable it?
What's your advice here?
We did.
We did look at that a little bit.
If there are no other questions, we will pack up.
Thank you very much.