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 🙂