You are currently browsing the tag archive for the ‘cybersecurity’ tag.

A few days ago I read about NCC Group’s Sniffle tool, a BLE sniffer for Bluetooth 4.X and 5. Given my interest and previous track record at looking into the security of BLE devices, I could not stop myself from testing it.

The tool is available on NCC Group’s Github, along with quite good documentation. It was not hard to install all the prerequisites and set up everything following their documentation. My environment is pretty well set up for this type of experimentation and devices, so from Python to PySerial, I did not have to do much. All the TI-specific tools should be installed in their default folders suggested upon install (when running the .run files) and one will not have any major issues.

So far, I have been able to run the sniffer on the TI CC26x2R Launchpad Board. The firmware loads without issue and the board is ready to use. Note that, as I will describe below, I have been having a bit of stability/buggyness issues with the sniffer. Whenever something acts up a bit, the best thing to do is to reload the firmware. That seems to get things fixed for me most of the times.


Once the firmware is loaded, it is easy to start running captures. Given the simplicity of the radio it’s running on, the sniffer can only scan one channel at a time, so you are either scanning ADV channels (37, 38 and 39) or following a connection. Therefore, unless you happen to catch an actual connection establishment, you should expect to only see ADV-related messages on your first captures.


Once you are all set up, it is highly recommended to dump the traffic being captured to a pcap file using sniffle’s -o option. Looking at one of the captures I took, I see the expected advertising traffic. A whole bunch of Apple devices (in my experience, always very “loud” at sending ADV-related traffic) from my neighbors, some smart TVs (including mine; it’s been the subject of my research before and I know like the back of my hand the characteristics of its ADV packets) and some interesting devices that I will explore when I have more time.


Now that I am all set up, I will start taking actual captures of devices connecting and will test how reliable Sniffle’s ability to follow connections is. By the way, once you capture a full initial pairing and connection establishment, you should be able to process the pcap with Crackle to bruteforce the LTK session key and decrypt traffic. This is possible unless the pairing is being done with the Out of Band method. In my experience, the only device that I have observed in the wild using OOB pairing is the Apple Watch, though.

While using Sniffle I have noticed some instability. Every now and then I get weird errors raised by sniffle when having trouble parsing certain packets. See example above for a crash when it parses a packet that, allegedly, has an incorrect length field. I have observed similar parsing errors happening from time to time. When this happens, sniffle seems to get stuck when you try running it again. The quickest fix is to reload the firmware.


Once I have some time I will continue playing with sniffle. With two kids now, time is a very scarce resource! 🙂

EDIT (10/04/2019): Correction to myself. Bluetooth 5 *should* be using Diffie-Hellman for the handshake to derive STK which encrypts the handshake to exchange LTK. If that is the case, even when sniffing a full initial pairing+connection, one could not be able to brute force anything. I have to find myself a Bluetooth 5 device and capture that traffic. I’ll update when I have some time.

(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.

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:

Blog Stats

  • 144,595 hits

Twitter feed

Error: Twitter did not respond. Please wait a few minutes and refresh this page.

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