A compromised femtocell without local break-out offers some attack possibilities dis- cussed in Section 5.4, which should be examined further. Most prominently these are the integrity attacks against the untunnelled signalling messages that could offer up new attacks. Also, a compromised femtocell can make fuzzing attacks over UMTS protocols against handsets possible, which to our knowledge have not been attemp- ted before.
We also see some ways to improve our attack against the Vodafone SignaalPlus Plug&Play femtocell. It might be possible to reactivate the JTAG connectors. This would allow a degree of control on the processor that our current attack does not provide.
Our attack could also be extended in using the TPM as an oracle, in order to ana- lyse the data sent through the IPSEC tunnel which are not part of the 3G traffic, so all the management data. We are able to execute arbitrary code on the femtocell, which makes this approach possible, but due to a lack of time we were unable to perform this attack.
5.7
Conclusions
We have provided the first comprehensive security analysis of a femtocell without local break-out in Section 5.4. We have shown that a compromised femtocell enables attacks that directly impact several security goals:
• Subscriber identity confidentiality • Signalling integrity
• Availability
Several attacks already exist without a compromised femtocell, but we argue that some of these are much easier to exploit with the use of a compromised femtocell. This resulted in easier implementation of attacks against several security goals:
• Subscriber identity authentication • Subscriber identity confidentiality • Signalling confidentiality
• Availability
Several attacks using older model femtocells with local break-out, are not possible in our model of a femtocell without local break-out. Of these, the eavesdrop attack on subscriber data probably has the most impact. So, the security of a cellular network with femtocells is improved when the femtocells do not support local break-out; in essence the provider places less trust in a femtocell.
Our analysis resulted in two new attacks, which to our knowledge were not pub- lished earlier: (i) the IMSI-harvest attack discussed in the section on Subscriber iden- tity confidentiality (page 82) and (ii) fake Public Warning System messages, discussed in the section on Signalling integrity (page 83).
5.7 Conclusions
We also show a practical attack on a modern femtocell without local break-out. A dump of the code of the femtocell enabled us to learn the port-knocking sequence that allows the femtocell to go into an insecure recovery mode, which retrieves a file and executes it. With a couple of days of effort, we were able to gain root access to this device and were able to execute arbitrary code on it. We gained fewer capabilities than previous hacks of older femtocells (which did implement local break-out). Our femtocell was also secured against earlier known attacks.
We made some interesting observations while examining the femtocell. First of all, in accordance with GPL, Vodafone provides a link to source code. However, the provided source code is not the code that actually runs on the femtocell. It appears to be code meant for an older version of different hardware by Alcatel-Lucent, instead of the current version by Sagemcom. This is clearly a violation of GPL and it forced us to dump the contents of the memory chip for analysis.
Secondly, it seems strange to disable SSH access, but to allow access to the femto- cell through the secrecy of a port-knocking sequence, which is poor security, since the secret sequence cannot be stored securely. However, the benefit of the port-knocking defence is that this will only work locally, since most devices will be placed in a NAT environment in a subscriber’s home, so the router would already block most ports. SSH on the other hand might be accessible over the internet. This would have been especially worrying, since we found that all devices of this type we bought had the same (hashed) root password.
Both our theoretical and practical analysis suggest the security of femtocells is improving. None of the weaknesses from earlier models were present in the new femtocell. Though the main improvement is that the providers place less trust in the femtocell devices, because the femtocells do not provide local-breakout. One should always assume that a femtocell will eventually fall under control of an attacker, so the less trust that is placed in the femtocell, the better. Femtocells without local break-out are a definite improvement, as are femtocells that do not check the membership of the closed subscribers group themselves.
However, femtocells with local break-out are still available on the market and as long as these can connect to the core network, femtocells without local break-out add little security. Even with these femtocells without local break-out some attacks re- main possible when a femtocell gets compromised, though these attacks typically have a lower impact.
Responsible Disclosure
We informed Vodafone Netherlands of our findings. They informed us that recent models of their femto cell do not expose the recovery mode. We could confirm that our attack indeed no longer works on these models.
Chapter6
Fuzz testing GSM implementations
The previous chapters in this thesis have mainly focused on the protocol specifica- tions and cryptography layer of mobile telephony. Finding weaknesses in the spe- cifications can have major impact, because all the equipment has to follow the spe- cifications quite narrowly to allow cooperation between different vendors. However, looking at the implementations of these vendors can reveal completely new vulner- abilities. Even though the specifications are to be followed, these are also notoriously complex, with very many options, of which a large part is hardly ever used. Also spe- cifications tend to only provide the scenarios for correct input, leaving the incorrect cases up to individual programmers to handle.
There are not as many vendors of so-called baseband stacks, the software layers running the wireless part of mobile telephony networks, as you might expect. There are only around 5 major vendors for baseband stacks running on mobile phones, at the time of writing. These are Qualcomm, Broadcomm, MediaTek, NVIDIA and Intel. So, finding a vulnerability in one of their products could potentially threaten many con- sumer phones. Unfortunately, all these stacks are closed-source, making meaningful security research much harder.
This chapter focuses on our research efforts in fuzz testing the implementations of the mobile telephony protocols. This research showed that basic forms of fuzz test- ing – effectively random, automated testing – can quickly reveal many bugs in the software implementing the GSM stack in mobile phones. Fuzzing could reveal most of the security vulnerabilities present in this software in an efficient way.
This chapter is based on the article Security Testing of GSM Implementations, presen- ted at the International Symposium on Engineering Secure Software and Systems, ESSoS 2014 [175]. Besides some changes in the introduction for a better integration with the rest of the thesis, and moving some information to chapter 2, the background chapter, nothing changed with regards to the original publication.
6.1
Introduction
With current, off-the-shelf, hardware and open-source software it is possible to run your own GSM cell tower to which real phones will connect, since in GSM the net- work does not authenticate itself to the phones. This opens up the possibility to verify the implementations of the GSM stack of phones by the technique known as fuzzing. Fuzzing has been used a lot to find security holes on internet equipment. Thanks to low level access offered by Ethernet cards it was easy to simply try out all kinds of pos- sible messages, mostly those just outside of the specifications, and see what happens when these are received by network equipment. Fuzzing mobile phones has mostly happened in the hackers scene of security research, with few academic publications. Naturally, there are many interfaces in mobile phones which can be fuzzed. Just think of every type of input that a phone can receive, such as WiFi, Bluetooth, NFC, installed apps or the SIM interface. All of these inputs can be interesting input vectors for fuzz testing. We focused on fuzzing the GSM baseband stack. This is the part of the phone which handles all the GSM traffic. It is available in every phone, implements a hugely complicated standard and is remotely accessible over the air, which could easily lead to dangerous attacks.
The GSM system comprises many entities, such as the mobile phones and cell towers, but also many more back-end components. Our fuzzing research only fo- cuses on mobile phones. Naturally, fuzzing the network components of a GSM net- work can have a much larger impact. However, availability of commercially used net- work components that are not currently running inside an operational GSM network is very limited. Thus we limited ourselves to the readily available mobile phones. In this chapter we discuss our efforts and results in fuzzing two specific parts of the GSM specification: SMS messages and CBS messages.
The well-known Short Message Service (SMS) was added shortly after the initial release of GSM and the first SMS message was sent in 1992 [89]. The first version of SMS allowed the exchange of short text messages between GSM users, but SMS has gone a long way since then. Not only can SMS be used to exchange text messages, but nowadays also pictures, sounds and many other types of data can be sent over the SMS. The current SMS standards also allow segmentation of messages that are too long to fit into a single message, enabling users to transmit much longer messages. The current SMS specification is found in [61, 67].
The lesser-known Public Warning System (PWS) actually started out as the Cell Broadcast Service (CBS), which was developed in parallel to the SMS service as a re- sponse of mobile developers to the competing paging services being offered in 1990. It allows providers to broadcast messages to all phones currently connected to a cer- tain cell, i.e. all phones connected to a single transceiver on a cell tower. The original business case was to provide news, weather and traffic information to mobile users, though this never found any wide spread popularity. This lead to both mobile net- work operators and mobile developers neglecting the implementation of the service in their equipment. However, this service has been gaining importance in the last years, because it can be an ideal method for governments to broadcast information in the event of an emergency to all phones in the vicinity. Several countries define and implement their own warning system that rely on the CBS to deliver emergency information. Due to the diversity of technical specifications of each warning system,