You are currently browsing the tag archive for the ‘software defined radio’ tag.

(Originally published as a LinkedIn article – Reposted on this blog)

About 10 years ago, I started working on mobile and cellular security research. While most of my work in the early days leveraged costly network testing equipment and a neat lab set-up, I also experimented with a number of open-source implementations of the LTE (Long Term Evolution) PHY layer, which were critical for the work on protocol-aware jamming back in 2011. Everything changed in 2012, though. On December 31st 2011 the first commit for openLTE had been uploaded and for the very first time, there was an open-source implementation of the LTE stack aiming to go beyond the PHY layer. Just a couple of years later, by 2013/2014, after outstanding progress in the development of openLTE, I was in the lab able to test LTE IMSI-catching, taking advantage of unprotected AttachReject messages and tracking devices via mapping MSISDN (i.e. phone numbers) to TMSI to C-RNTI.

During those years, other implementations of the LTE stack became available, though I stuck with openLTE until srsLTE reached a significant level of maturity. Currently srsLTE is by far the best and most widely used – both in academia and industry – tool for LTE security research. srsLTE has been my tool of choice since my career change in Fall 2015, after which I used it to rewrite my IMSI catchers, protocol exploits, and RNTI-based techniques for my January 2016 ShmooCon talk.

Around that time, I wrote an article predicting that the combination of a) low-cost software-radios, b) mature and very stable open-source implementations of the LTE protocol stack, and c) an army of bright, smart and talented grad students, could only have one possible outcome. I predicted – not taking much credit for that prediction, as it was quite clear that it would happen anyways – that within the following few years there would be a number of new academic research labs working in cellular network security projects, and a large number of new exploits identified in cellular networks released in papers at top security conferences.

It has been 3 years since I published that article and, indeed, researchers have found numerous flaws in the LTE protocol by applying formal verification techniques to the LTE standards, hijacked DNS requests and responses at LTE’s layer 2, exploited flaws in the Self Organizing Network protocols of LTE, and tracked devices via their GUTI, to name just a few.

Most of the vulnerabilities identified by researchers so far primarily affect subscribers and mobile devices. However, the latest addition to the srsLTE toolset, srsUE, is already changing the cellular security research landscape. srsUE is an open-source implementation of the UE (User Equipment) LTE stack. As such, it facilitates the same type of security research against the network infrastructure, as opposed to just mobile devices. In other words, it is now possible to fuzz cellular protocols in the uplink against the network infrastructure and, for example, send arbitrary messages to an MME (Mobility Management Entity, one of the core parts of an LTE network).

It is worth noting that some teams in academia have already started experimenting with uplink LTE protocol fuzzing. Recent results indicate the feasibility of crashing network equipment. In addition, an academic research team published an excellent paper identifying a number of previously unknown protocol exploits in LTE that are being assigned CVEs and addressed by the OEMs and operators.

In parallel, the industry is in the midst of the 5G marketing frenzy. 5G is introduced as a panacea to everything that needed to be addressed in previous mobile generations: a revolutionary technology that will empower exciting new applications such as smart vehicles, critical control of remote devices, virtual reality, etc. In that context, the industry has been raving about the security of 5G and its resilience to cyber-attacks. However, a number of recent studies and publications indicate that the marketing statements about 5G security are actually inaccurate and things are not much different than in LTE.

The security research landscape has changed drastically when it comes to cellular network security. The GSM (Global Standard for Mobile communications) standards were drafted in the late 80s and no major vulnerabilities were publicly released until the Barkan attacks against A5/1 and Karsten Nohl’s presentation at the Chaos Communication Congress in 2010. It took over 10 years from GSM to be standardized and deployed to the first security issues being identified. Similarly, the LTE standards were finalized sometime between 2007 and 2008, and operators started deploying LTE networks sometime around 2011. It only took a few years, though, for security researchers to identify and release exploits in late 2015, including the excellent work from an academic team in TU Berlin and the results I myself released at ShmooCon.

This trend of identifying protocol vulnerabilities sooner and sooner after the inception of a new mobile generation also applies for 5G. The first release of the 5G specifications was published in March 2018. Just a bit over a year later, the research community has identified protocol vulnerabilities in the 5G-AKA (Authentication and Key Agreement) and privacy breaches in 5G. It is worth highlighting here that 5G mobile networks are not even deployed commercially yet, though over the last year there has been half a dozen papers published highlighting critical vulnerabilities in the technology that is supposed to drive mobile systems and innovation for the next 10 years. More importantly, a recent study highlights the fact that 5G protocols are still vulnerable to the great majority of exploits existing in LTE as they carry over the main root cause of threats against LTE.

The greatest common divisor of most vulnerabilities identified in LTE over the last 5 years is what the research world refers to as pre-authentication messages. Unlike other layer 2 protocols, cellular networks rely on an implicit reciprocal trust between Alice and Bob prior to executing the authentication cryptographic handshake. In other words, a UE blindly trusts any base station that appears to be legitimate and the base station blindly trusts anything that looks like a commercial UE even before they have mutually authenticated. Needless to say, it is trivial to configure a rogue base station or rogue UE to look like a real one.

Security threats spawn from the fact that, by spoofing or intercepting such pre-authentication messages, an adversary can turn a smartphone or mobile IoT device into a connectionless brick or silently downgrade any UE to an insecure connection over GSM. IMSI catchers, commonly referred to as Stingrays or cell site simulators, are actually possible in LTE because of the exact same reason. The message that instructs a UE to disclose its IMSI in the clear is a pre-authentication message that can be trivially spoofed and directed to all UEs in a geographical region. Note that this is possible by literally just adding a couple extra lines of code to srsLTE. Spoofing presidential emergency alert messages is also possible because many messages in LTE cannot be properly identified and attributed.

Stingrays have been for years the security threat in cellular networks that attracts the most attention from the media, especially since the discovery last year of evidence of numerous Stingrays in the Washington DC area. This might be the motivation behind the proposal in 5G for a solution to prevent IMSI catchers. This specific solution, if implemented, would indeed prevent certain IMSI catcher style attacks in 5G. As such, it has been the cornerstone of the industry’s elevator pitch praising 5G security. Unfortunately, this security feature in 5G appears to be defined, as many others, as optional, leaving it up to the operator whether to implement it or not. The history of previous generations indicates that optional features rarely get fully implemented. This is one of the reasons why the implementations of the same cellular protocols end up being dramatically different from operator to operator.

After years of cellular security research, many scientific publications at top security conferences, and numerous exploits and vulnerabilities, all with one single clear root cause, it is interesting that the industry and standardization bodies have not yet tackled the pre-authentication message challenge. After all, there are mature and widely deployed technologies in the Internet that allow endpoints to validate the identity of a server before needing to perform a cryptographic handshake. TLS (Transport Layer Security) and its deprecated predecessor, SSL (Secure Sockets Layer), are perhaps the best-known examples. These technologies have made possible the rise of eCommerce and other modern applications, providing the necessary tools to authenticate communication endpoints prior to any handshake by means of digital certificates.

A number of security researchers, myself included, have been advocating for the application of digital certificates or related technologies to cellular networks for years. An excellent recent paper implements a proof of concept of the application of X.509 certificates in cellular networks, presenting very promising results. This is the first time, to the best of my knowledge, that such a study is published.

Leveraging digital certificates in cellular networks would require architectural changes from the ground up at a very large scale and, unfortunately, this is unlikely to occur. There is little incentive in the industry to make large changes to a security architecture that has remained rather unchanged for many years.

The cellular industry and the technology behind it are tightly driven and regulated by the 3GPP (3rd Generation Partnership Project) standards, which could and should be the driving force behind such a paradigm change in how security and trust are established in cellular networks. However, the strongest forces sitting around the table at standardization meetings are the cellular industry itself, both telcos and OEMs, which seems like a clear conflict of interest. As a result, the outlook of the state of affairs in mobile network security is not likely to change in the short term.

It took over 10 years for researchers to find security flaws in the GSM protocol, just a few years for the first protocol exploits to be identified in LTE and, in the case of 5G, researchers are already highlighting vulnerabilities before the technology is deployed and available for consumers. Despite the challenges and lack of incentives for the industry, this might finally be the time to start addressing security weaknesses inherent to cellular protocols since their very inception. Until that happens, though, I look forward to excellent cellular security research from bright grad students and hackers alike, and to reading future papers they publish.

Advertisements

I was setting up today my new Windows7 laptop. And, as every single Windows laptop I’ve had before, I set up a Linux VM on it. Although on my other laptop I run a paid VMWare Workstation Pro license, in this particular license I am running the free VMWare Workstation 14 Player.

I currently have two VMs set-up, a custom Ubuntu one that I use mostly for development and tests and a Kali-Linux one. If you are interested in radio security, you must install the kali-linux-sdr and kali-linux-wireless packages. Such a convenient way to get all your favorite tools nicely installed on your machine.

By the way, when setting up the Kali image, for some reason, the apt sources were not properly configured and I could not apt-get install kali-linux-sdr and kali-linux-wireless. A quick update of /etc/apt/sources.list fixed the issue. You can get the url to the various package repositories here (note: several of the ones listed do not actually work).

Anyhow, once all my sdr and radio tools are ready to run, I got to the main issue at hand. It is quite well known that running USB devices from within a VM is prone to errors and rather imperfect. Things seem to work fine when, upon plugging my USRP B210, it would be recognized by the driver and connected to the VM.

Running uhd_usrp_probe appeared to work well, as it loaded the firmware onto the USRP, but then it just couldn’t locate the device anymore. For some reason the VM gets lost in translation as, once the firmware is loaded, the USB device essentially changes and the VM loses it. And it took me quite some time to get it to work. I was close to leaving it for another day until I found a solution that worked well on both the Kali and Ubuntu images. Instead of running uhd_usrp_probe or any other application that probes and uses the USRP, the trick is to run first the b2xx_fx3_utils tool. Its path might be different depending on how you installed UHD, but in the Kali image it is in /usr/lib/uhd/utils. After running this tool the firmware is updated on the USRP and, from that moment on, everything works just fine. You will need to do this trick each time that you unplug the USRP and plug it again, as the firmware will need to be updated again.

When I thought I was done, I am actually facing a new challenge. Installing OpenLTE on Kali doesn’t work as cmake cannot find the UHD libraries. Most likely a permissions or weird installation path on Kali for UHD. But this is one that I’ll procrastinate in fixing as I switched to doing all my development and experimentation for my LTE exploits security research with srsLTE.

Ever since becoming a father I’ve had very little time for research, but I have some new LTE protocol exploits in the kitchen being cooked. Once I have enough time to put together results and a talk, you’ll see me on the road to talk about it. I’m aiming for Spring time.

Happy new year everyone!

EDIT: A lot of people has been asking me about this. What this fixes is the USRP itself being used from within a VM. This does not fix the ancient issue of VMWare with USB3 drivers. If you need to run something with the USRP that requires USB3 (e.g. an LTE base station at full 10MHz and ~30Msps), that will be VERY hard to do from within a VM. You are much better off by creating a partition to run native Linux on your laptop for that.

If anyone ever manages to get the USRP over USB3 working from within a VM, please please please let me know!

About me:

Born in Barcelona, moved to Los Angeles at age 24, ended in NYC, where I enjoy life, tweet about music and work as a geek in security for wireless networks.
All the opinions expressed in this blog are my own and are not related to my employer.
About me: http://rogerpiquerasjover.net/

Blog Stats

  • 143,118 hits

Twitter feed

Enter your email address to follow this blog and receive notifications of new posts by email.

Advertisements