Attacking BaseStations @Defcon24

Hello Guys,
back from my vacation I’d like to give you some impressions about Defcon 24 and our talk “Attacking BaseStations”. Defcon itself had a couple of great talks but was a very crowded location. Anyhow, we had a couple of great discussions with the people before and after our talk.

The talk “Attacking BaseStations” focussed on attack vectors we simulated in our lab. Besides attacking a BaseStation via Radio interface, in this talk we focussed on local and remote interfaces as introduced in “LTE vs. Darwin”. As target of evaluation one of our eNodeB’s came into play, which we purchased on the Internet. Anyhow, the talk covered the following attack scenarios:

1. remote access to S1 connection
2. local access to maintenance interfaces
3. physical access to the device

While testing, we found out that the purchased eNodeB was not erased by it’s last owner – which made it even more interesting and the attack vectors more realistic.

Access to the eNodeB
First, we started with some reconnaissance on S1 network interface to understand how the device is working in general and how it is configured. The interface usually is used for transmission of control and maintenance data. In general, 3GPP TS 33.401 gives a recommendation how this interface should be secured: IPSec is the way to go for user plane, signalling plane, but also O&M (Operation and Maintenance). Our eNodeB had no IPSec configured at all. Still, this is compliant with the standards in case of a trusted/physical protected environment:

"NOTE 1: In case control plane interfaces are trusted (e.g. physically protected), there is no need to use protection according to TS 33.210 [5] and TS 33.310 [6]."
"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."


Similar for O&M interface:

"NOTE 2: In case the S1 management plane interfaces are trusted (e.g. physically protected), the use of protection based on IPsec/IKEv2 or equivalent mechanisms is not needed."


Being able to connect to the S1 interface, it was quite easy to demonstrate some attacks against the control protocol S1AP. This enables us to act as a fake management entity (MME), giving us control about the pre-configured cells on the eNB.

Finished with S1AP, we also took a look to the O&M services, represented by an interface called “LMT”. The LMT is an interface used for initial configuration or as local backup interface for engineers which must access the device (e.g. if it is in a fault-state). In our case this interface was accessible locally and remotely. The typical workflow for such a maintenance proceudre looks like this:

1. eNB gets into a Fault-State of BaseStation (NoService)
2. Engineer moves on-site
3. Engineer connects to eNB with $tool
4. Engineer accesses debug/monitoring information
5. Engineer adjusts configuration and turns eNB up again

The Ericsson eNodeB provides two possibilities:

1. connecting to the OS via telnet/ssh
2. connecting via a special tool called Element Manager

Fortunately, the tool can be downloaded from a webserver of the eNB itself (which btw. is not very secure/stable as it is using a totally outdated Java). The purpose of the tool is to configure or access logfiles of the eNodeB. The problem here is, there is even no security in place – no authentication and no encryption. We also could access some old logs, revealing us the provider’s name and used cell-id.
Nevertheless, one attack vector was left…

Physical access

For this assessment we had to open the device. After we removed a couple of screws we could access the internal hardware and its components. We saw some debug interfaces but, even more interesting for an attacker: an internal flash disc. This disc is used as space for the whole OS, including the eNB’s configuration data. After dumping the card and a quick analysis we found out that a GZIP-based volume is used. As the hardware-architecture is PowerPC, we furthermore had to flip high and low bytes. Afterwards, we were able to extract system and configuration files of the eNB – including the system password file and private keys of the system (which would also give us access to IPSec, even it was not configured on our device).

In summary, the eNodeB has a very interesting but not very secure architecture:

1. No IPSec configured
2. Unsecure LMT tool
3. Unsecure Services (e.g. webserver)
4. Weak Management Credentials for SSH/Telnet
5. Extractable Memory

For more, just take a look to our slides here 🙂

Best,
Hendrik & Brian