Hey guys,
as some of you may have noticed, just recently at ShmooCon we gave our talk “LTE
vs. Darwin” (Slides
here).
There we presented some results of our research in 4G telco network security.
Some of those originate from our research contribution to
ASMONIA, but we expanded the scope and also took a look at the
air interface. Both the air interface and the backend links & protocols must be
secured appropriately; otherwise communication may be eavesdropped or sensitive
information may be compromised. In the following we want to provide an overview
of LTE main components and potential attack vectors.
First of all we start with one of the main new 4G components, the eNodeB.
The eNodeB
eNodeBs provide the actual air interfaces in LTE networks. Having a LAN link on
one side and antennas on the other, the eNB constitutes also the termination
point for different encryption channels (UE rf encryption and eNB to back end
encryption). This makes an eNB quite an interesting target. But where is it
usually located? Due to the nature of antenna cables, the eNB has to be placed
“close to the antennas”, depending on the kind/size of eNB it can actually be up
on the mast or down below on the ground, potentially located somewhere on the
top of a roof or in the woods, all in all in “very secure” locations
Another interesting aspect on eNBs is that they use multiple antennas. Surely
LTE is a MIMO system needing
multiple antennas, but an eNB is actually able to be part of multiple cells.
Using directional antennas multiple cells in different directions can be fed
from a single eNB. So if you walk round the mast you might get a different cell
on each side!
For more information on eNBs see below in the SON part.
The UE Perspective
One question we want to answer with our research is: what does User Equipment
(short: UE) feel, see and hear? User Equipment in 3GPP terminology describes all
devices connected to the radio access network controlled by the user (e.g.
smartphones, laptops). It must be aware of a Physical Cell ID (PCI), a Tracking
Area Code (TAC), some reception levels and its position. The PCI and the TAC
might be particularly interesting pieces.
The PCI is similar to the Cell ID in GSM networks and should be known to most
readers as an identifier for a single network cell. There are 512 different PCIs
in LTE networks but surely more than 512 cells. It’s just important that no
adjacent cells have the same cell id, or rather to say a single cell may only be
adjacent to one cell with a certain PCI, not two.
The TAC on the other hand can include multiple cells and is quite often compared
to GSM’s LAC. Now in LTE the TAC is the area in which i.e. paging messages are
broadcasted. So in theory everybody in a given TAC can see all pages for all
mobiles in the same TAC. This might allow attacks similar to those Nico Golde
described for GSM networks in his presentation at the
Troopers TSD 2013.
Yet,
we’re currently focusing on the phase of data collection. Therefore we’ve
written a basic Android wardriving app which seemed to be the easiest solution.
Not having access to network plans, wardriving is our best shot at mapping cells
and TACs and can be done by everyone. Results will be published on this blog and
in future talks.
The first look at some data makes us believe that TACs can well have a radius of
a few kilometers in town areas but we are currently working on a more detailed
map.
The Backend
Another important part of our research is analyzing the backend structure. As
mentioned above, usually an eNB is located near to the mast. That means that an
attacker potentially accesses the mast, circumvent physical security mechanisms
and then have physical access to the device. But what may be the impact of this?
Okay, the eNB itself may be located close to the antennas where, because of
radiation, nobody would come close to, but somewhere on the ground will be some
access to the backend network. In 4G access to backend network means having
access to an IP network! For our research we focus on two variants:
- Network access to eNB
- Access to the so-called backhaul network
The eNB is a network component like all many others. That means it should be
secured (e.g. following the
ERNW “seven sisters” approach.
But what is happening in the telco world? Well, there is a standard called
3GPP TR 33.805 which defines a
Security Assurance Methodology like product development, lifecycle management,
security compliance testing, vulnerability testing and enhanced vulnerability
analysis. This standard was initially released in 2013, but there are a lots of
eNB in use which were developed earlier and new standards still have to be
deployed in the development process! In our pentesters experience with telco
equipment & networks we’ve seen that there really is a necessity and that
something must be done. Eventually, the telco world is on the right track but we
think that it still will take some time until there is a proper security
assurance methodology in place.
On the other hand once we get access to the backhaul network we have access to
control and user plane of the eNB interface (called S1 interface). On the user
plane GTP (as in 2G) will be used for transporting the traffic, but for control
plane a new protocol called S1 Application Protocol (short: S1AP) was developed.
On both, no authentication or encryption mechanisms are implemented. For
securing control and user plane the standards say that IPSec must be used,
defined in 3GPP TS 33.401:
“In order to protect the S1 and X2 control plane […], it is required to implement IPsec […]. For both S1-MME and X2-C, IKEv2 certificates based authentication […] shall be implemented.”
“In order to protect the S1 and X2 user […], it is required to implement IPsec […] with confidentiality, integrity and replay protection.”
But there is a limitation on that, called “transport mode IPsec is optional for
implementation”. In reality this means that quite often there is no end-to-end
encryption and that security gateways will be used in place. Yet another
component which will be located near to the eNB…
Nevertheless, there is also a nice addition in this document:
“NOTE 1: In case control plane interfaces are trusted (e.g. physically
protected), there is no need to use protection […].”
“NOTE 2: In case S1 and X2 user plane interfaces are trusted (e.g. physically
protected), the use of IPsec/IKEv2 based protection is not needed.”
We do not know how providers will deal with this (standard) but please remember that, as mentioned above, eNBs are located near to the mast and there may be some kind of fences or locks in front of the device. On the other hand, in case an attacker has access to the S1 interface both control and user traffic may be sent. And there are a lot of interesting control messages which may be abused like:
- Radio Access Bearer setup/modification/release,
- UE Context messages,
- Handover signalization,
- Paging,
- Configuration updates,
plus a number of tracing and information gathering messages. To test the functionality of the protocol and if it is implemented securely we have written some scripts for our fuzzing framework dizzy which can be found here. But please understand that we are not publishing scripts for sensitive messages as of Handover Preparation or S1 Context Setup because of abuse reasons. This blog post should not be an guide to “how to own an eNB”, we just want to discuss potential security problems.
eNB as Part of the SON Network
Another very interesting feature in LTE networks is “SON”. SON stands for “Self
Organization Networks” and can be split into two aspects: Self Configuration and
Self Optimization.
“Large scale Plug and Play” is what most of us would probably call the Self
Configuration functionality. Devices like eNBs come with a clean firmware and
some pre-configuration. An on-site technician just has to attach it to the
antenna, network and power! (which results in reduced installation costs.) The
device will then get an IP via DHCP and a configuration file based on its HW ID.
Depending on the actual eNB the installer/technician might have to set up its
geo location, otherwise it might use an internal GPS receiver (mainly used for
timing). One important aspect here is the PCI (see above). As stated before no
two nearby cells may have the same PCI so the LTE back end might actually start
shifting PCIs around and assigning new ones. That all sounds good, but what if
the default configuration is not trustworthy? Especially in times where
information came up that agencies are intercepting deliveries? 😉
Here is a graph on how this process for setting up a private/public key pair usually looks like while purchasing an eNB:
- The manufacturer of the eNB creates both public and private key locally on the device. So the private key never has to leave the machine.
- After this, the manufacturer requests a certificate for its public key from factory CA and stores the certificate locally.
- When the device is sold to an operator, the factory CA certificate used for signing the equipment certificates is handed over to the operator in a “secure way”.
- The customer stores this certificate in his CA pool.
However, getting this certificate handed over from the manufacturer to the
operator means having a signing cert in a high instance. In an attackers point
of he is able to sign his own keys and can fake control and user plane
communication if it is secured with IPSec.
After hardware installation the Self Optimization process starts. The classic
main aspect to be optimized on radio networks is overlap. To achieve this,
adjacent eNBs will communicate with each other and work out optimal RX values
and distribute their transmission to time and frequency domain. So how does this
actually work? There are two scenarios to start with
- eNB1 and eNB2 can directly “see” each other’s transmission over the air
- an eNB requests all received cells from a random UE.
In scenario 1) eNB1 will send a message to the MME asking “Hey there, who’s eNB2
and how can I reach it?”. In case the MME has an entry for eNB2 it will send
contact data (IP) to eNB1 and both eNBs work out everything by themselves.
Now in scenario 2) an UE is used as an information source! Which could
potentially be the one UE that’s in our hands right now. Maybe we can actually
use our UEs to fake the position and signal strength of a certain cell mast,
make to masts that are configured as wanted rethink their transmission rates and
create a signalless black hole in between. Though this is actually one of our
future research topics.
Finally, above all there are Home-eNBs (HeNB), which are essentially femto
cells. You might have on your desk one day, maybe running Linux, maybe being
root-able
and surely using the X2 channel (the interface for communication between eNBs).
So what would happen if my personal HeNB sends fake data to a “real” eNB, saying
“Hey mate, I’m the most awesome eNB in the whole Heidelberg area! Lemme do your
job, you may switch off now”? Most probably it wouldn’t be quite as easy, but
like for S1AP we have written some scripts for faking X2AP (X2 Application
Protocol), too. Some example scripts can be found
here.
So these are some topics and research activities we discussed in our ShmooCon talk. Some of those will be covered in more detail in our Troopers workshop on “Telecommunication Network Security”. Furthermore the annual TelcoSecDay on Tuesday (Mar 18th) might be another opportunity to meet us if you’re interested in this stuff.
Yours,
Hendrik and Brian
P.S.
Talking Darwin: During Saturday’s ShmooCon party Paul and Storm showed a video
we could have used ourselves: Don’t risk doing stupid things, if you haven’t got
seven lives!
And for those of you who have seen our talk, an
insider 🙂