I often find myself wondering “what could possibly go wrong?” sarcastically when I read about hotel doors that can be unlocked via BLE with an app and all other sorts of products with BLE connectivity. Being familiar and hands-on with the well known security issues of BLE are actually sometimes very useful. I once got a huge discount on an AirBnB stay after I demo-ed a hack on the host’s cute Catskills house’s smart lock, an August smart lock, and helped the host update the app and firmware. All credit to Jmaxzz for the excellent work presented at DefCon, which I simply partially reproduced.

In general, I always tell folks that it is never a good idea to use BLE for connectivity if you are building a product with high security requirements. That’s why, the moment I read about a smart credit card that uses BLE, my first thought was – yes, you guessed it right – “what could possibly go wrong?”. And Mike Ryan made my day with a blog post explaining precisely what could go wrong and, indeed, what did go wrong.

Mike Ryan is possibly the most well known Bluetooth security researcher out there. He is the author of one of my favorite tools, Crackle, which allows bruteforcing and breaking BLE session keys, unless the pairing was fully out of band (something that, by the way, I only know one consumer electronics device doing it: the Apple Watch. In the defense of all other consumer electronics, the last time I did iOS development, the APIs for an out of band pairing were not exposed).

It is interesting how, although some of the hacks against this smart card would be possible bruteforcing the connection by intercepting the pairing process, the issue here is simply a total lack of security and authentication of messages and communication. If an adversary got the hands on one of these devices, it is arguably very easy to pull in plaintext the credit card number, expiration date and cc numbers of all cards stored in the device. One does not even need to run Crackle, just standard Linux Bluetooth tools (bluetoothctl and gatttool).

Very interesting read indeed. And yet again, another example of why it is never a good idea to use BLE for connectivity in consumer electronics with high security requirements.


Although for deep security analysis and experiments I do all Bluetooth and BLE things using either an Ubertooth One or my USRP (either B210 or B205mini **) and gr-bluetooth, I always start any experimentation with a basic sniffer.

Until now, my sniffer of choice was the BLE sniffer by Nordic Semiconductor (you can get the dongle for $25 on Adafruit and install the software). Such a simple and small form factor sniffer that runs great on Windows and Linux. I don’t even need to fire up any Linux VM to start poking around.


It’s user interface is rather archaic, purely shell-based, but it works just great. And it has a nice added feature that, when listing the devices it detects advertising around you, it automatically adds the device name if it’s advertised in plaintext… which is usually the case.


I was going to set up the sniffer in my laptop today when I noticed that Nordic Semiconductor released a new version of their BLE sniffer. And it is a HUGE update and improvement. The new sniffer is actually integrated as a Wireshark plugin and works great. And allows doing all the work within Wireshark, which is great.

You can follow the instructions on how to install it and set it up here. In a nutshell, you’ll need Python 2.7, pyserial (version 3.4 or higher – to upgrade run pip install pyserial –upgrade), Wireshark 2.4.2 or higher (I like to keep my old installations of Wireshark that I have nicely configured to color-code certain things and have specific columns in specific orders for my work on LTE security, 802.11 security, etc, so I keep several installations of Wireshark on my machine and so did I this time), and Segger J-Link v6.16c (which comes in the sniffer’s compressed file).

By the way, in case you run into the same problem, the instructions are not super clear and it took me some time to realize that one has to copy the contents of “root of the uncompressed folder of the sniffer software\extcap\” to the Wireshark extcap folder (to find it run Wireshark, Help->About->Folders). I had initially copied everything into that folder, d’uh!

I did not manage to get this to work with the nRF51 USB dongle (the one I showed above), but it works great with both the nRF51 and nRF52 development kits.

I have one bit of feedback if anyone from Nordic Semiconductor is reading this. The current way to select the device I want to sniff from, by selecting it from the Device section of the Wireshark plugin, is not very useful. The text is tiny, the partial view of the list is to show and, more importantly, now you guys do not include the advertised device name if it’s in the clear! Hopefully this will be fixed in an upcoming release.


Anyhow, happy BLE sniffing folks!

(**) Looking for the USRP mini link I noticed they sell it now with the case and not board and case separately. Hooray! I wonder when they will do the same for the big brother B210.

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!

Earlier this week, Google Scholar highlighted for me a new paper on mobile security. I am familiar with the work of a couple of the authors, so I downloaded it and read the whole thing. It turns out it is, by far, the best overview/compilation of related work in the literature on mobile security research that I have ever seen.

On top of that, the paper analyzes and digests all the literature in a comprehensive way, deriving a methodology to classify attacks by their underlying and root causes, proposed mitigations and solutions, etc.

I strongly recommend folks interested in the area of mobile security to read this paper and as many of the cited works as possible. I’ve given tutorials and workshops on mobile security in the past, and I always include a suggested reading list at the end. From now on, I’ll suggest folks to read the references of this paper, highlighting some of the key ones.

All in all, I strongly recommend downloading this paper. Really good and well organized compilation of published research work on mobile security.

Rupprecht, David, et al. “On Security Research towards Future Mobile Network Generations.” arXiv preprint arXiv:1710.08932(2017).

On a side note, I am slowly progressing in my new research project. Testing a bunch of new attacks, both active and passive, with a modified version of srsLTE. Pretty awesome tool.

Ever since back in 2010 I started investigating what would happen if a radio adversary jammed specific LTE signaling channels – as opposed to barrage jamming of the entire LTE signal -, I have been very interested in what I referred as to Smart Jamming back in 2013 and again in 2014.

smart_jammingA team in Virginia Tech has been one of the main players in the research field of smart jamming, more commonly known as Protocol-Aware Jamming. Starting with their 2013 paper “Vulnerability of LTE to Hostile Interference“, this team has published a bunch of interesting results in this area, including a paper in which I collaborated with them.

The same team just released a pre-print version of their Milcom paper in which they actually implement smart jamming attacks against downlink signaling channels using off-the-shelf software defined radios and open-source software. It makes me happy every time there is a new excellent work in LTE security which implements and tests exploits, attacks and solutions using open-source software. Over a year ago I wrote a short article on how I anticipated a spike in excellent LTE security research work now that the open-source implementations of LTE have reached a high level of maturity.

In the case of the Virginia Tech paper, they implement their protocol-aware jamming use cases on top of the srsLTE tool, which has always been one of the most complete LTE open-source implementation and might currently be the best one. It is also, to the date, the only tool that provides a full implementation of the UE LTE stack.

Read the paper on smart jamming implementation on SDRs running srsLTE here:

R. Rao, S. Ha, V. Marojevic, J.H. Reed, “LTE PHY Layer Vulnerability Analysis and Testing Using Open-Source SDR Tools”, IEEE MILCOM 2017, 23-25 Oct. 2017.

Happy Saturday!

ps. Dembele better be good. Let’s try to get Coutinho now. Though I feel terrible we are just adding more fuel to the fire of the over-inflated and out of control European soccer transfer market…

As I predicted in an article I wrote last year, the increasingly maturity of the open-source implementations of the LTE stack is fueling more and more exciting work in LTE security. I saw two presentations at Blackhat in the area that will most likely make it to the mainstream media.

Ravishankar Borgaonkar and his colleagues at TU Berlin keep producing exciting work in this area and presented some fresh work on new techniques to track devices in mobile networks. Considering that the team under Prof. Jean-Pierre Seifert are responsible for some of the coolest papers I’ve read in the last 6 years, I was really looking forward to this one.

By tracking and analyzing the AKA sequence number and collecting messages by impersonating a target’s IMSI, one can collect RAND.AUTN pairs to be used later to track that victim. Fun stuff and yet another issue in mobile networks that has been carried over from generation to generation and is likely going to impact 5G networks as well. It could be worst, I guess. LTE networks could, for example, add a plain-text identifier, unique per device, in each packet at the PHY layer. Oh, wait, that actually happens and allows tracking devices as well

Very interesting presentation on exploiting CS fallback for voice traffic. Despite a device is well authenticated and secured on LTE, in CS fallback mode, calls will be delivered over, often, GSM. Sniffing the paging channel and replying with spoofed paging response messages, the authors are able to intercept phone calls.

This is a very cool exploit that I was already familiar with. Actually, I am looking forward to seeing the video of the presentation or reading the authors’ paper on this. Based on just the slides, this looks very similar and reminds me a lot to a really cool paper: Let Me Answer That For You: Exploiting Broadcast Information in Cellular Networks. By the way, this paper is by the team under, guess who, Jean-Pierre Seifert. I told you these guys do cool work!


As I said last year, more and more exciting research in LTE security and exploits. I wish I could say the same about myself, but having a full-time job (a really good one that I love and with which I am involved now in security of many other wireless technologies as well as corporate network security, data mining and machine learning and other fun stuff), going to a ton of rock concerts (follow me @rgoestotheshows), playing soccer twice a week, never missing an FC Barcelona game (the greatest soccer team in the world) and – specially – being about to become a dad for the first time, keep me VERY busy.

When I find some time, I work on the paper on my radio adventures at the Mobile World Congress scanning 802.11, BLE&Bluetooth, LTE and cloning my badge. I promised myself I would have it ready before next year’s Mobile World Congress 🙂 I am also starting to work in a new project/collaboration testing a whole new bunch of LTE protocol exploits. Some really FUN stuff. This time I have a team with me and we are actually aiming to submit papers to conferences, so things should be happening on this project soon. Stay tuned. Same bat-channel.

Ps. Please, Neymar, do not go to PSG!

I was just reading the newest post by Google’s Project Zero. They just released a report on a massive bug that allows remote code execution by exploiting a vulnerability on the 802.11 Broadcom SoC used in most smartphones.

Actually, the bug is not massive (it is, after all, just a simple buffer overflow because boundaries are not well checked when processing a specific type of packet), but its consequences are massive indeed. The vulnerability is specific to the parsing of certain messages in 802.11z TDLS, a mode of P2P ad-hoc communication. The report published by Gal Beniamini is just the first part of the overall project, and it “just” shows up to remote code execution on the Broadcom wifi SoC, but it hints that it can be leveraged to gain remote code execution ability in the application’s processor:

In the next blog post, we’ll see how we can use our assumed control of the Wi-Fi SoC in order to further escalate our privileges into the application processor, taking over the host’s operating system!

Long story shirt, this vulnerability results in a massive vulnerability. Theoretically (I am eager to see the second part of this report!), an attacker can take over a smartphone’s OS by simply sending malformed WiFi frames, achieving full device takeover by WiFi proximity alone. The good news is that this bug has been patched already both for iOS devices and Android devices, so I’d say you go ahead and update your mobile’s OS if you haven’t in a while.

I strongly recommend folks to read the report by Gal Beniamini, as it is excellently written and easy to understand and follow. It’s actually a great reference/introduction to buffer overflows and how to leverage them for malicious intent. The overall exploit is rather complex, but very nicely explained step by step in the report.

Fun stuff!

I recently was approached by the FCC regarding an open call for feedback regarding 5G security and current security challenges in mobile security. The document that I submitted seems to be already in the public domain and can be accessed from here:

Some key challenges in securing 5G wireless networks

Direct link to the PDF.

I got this from a friend earlier today: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/eUAKwjihhBs/rpxMXjZHCQAJ (Google Chrome – Intent to deprecate and remove trust in existing Symantec-issued Certificates)

It seems that, since a series of failures from Symantec to properly validate certificates (an issue that seems to be affecting over 30000 mis-issued certificates), Google Chrome is starting to deprecate and distrust Symantec-issued certificates.

I remember last year that a bunch of online services lost compatibility with Chrome as they were using Symantec-issued certificates). As highlighted in the notice from the link above, this is a problem that is not new (see this post on Google’s Security Blog from 2015).

Quoting the notice from Google, Chrome is proposing the following steps:

  • A reduction in the accepted validity period of newly issued Symantec-issued certificates to nine months or less, in order to minimize any impact to Google Chrome users from any further misissuances that may arise.

  • An incremental distrust, spanning a series of Google Chrome releases, of all currently-trusted Symantec-issued certificates, requiring they be revalidated and replaced.

  • Removal of recognition of the Extended Validation status of Symantec issued certificates, until such a time as the community can be assured in the policies and practices of Symantec, but no sooner than one year.

This is a pretty big deal and could result in a big mess of services stopping to work with Chrome… for a good reason, though, as this is clearly to ensure the security and trust in the certificates used to anchor the Internet’s security infrastructure.

If you are a SysAdmin, they are requesting feedback on this proposal.

Folks are starting to talk about this on reddit and other forums. I expect this to be in the news tomorrow… or not. After all, they are not fully distrusting Symantec, but putting them in some sort of “probation period”.


Update (03/24/17): As expected, if you google today “Chrome Symantec certificates” you get a ton of news stories on this…

I was reading this morning a new paper on the topic of LTE IMSI catchers: https://arxiv.org/pdf/1702.04434.pdf

Mjølsnes, Stig F., and Ruxandra F. Olimid. “Easy 4G/LTE IMSI Catchers for Non-Programmers.” arXiv preprint arXiv:1702.04434 (2017).

Although this is old news, it is exciting to see that the recent discovery and implementation of LTE IMSI catchers by the team of Prof. Seifert at TU Berlin (Oct 2015 – https://arxiv.org/pdf/1510.07563.pdf) has sparked the interest in this area. The paper also mentions the DoS threats that were introduced by the same team in [1]. I have done some work and implementation of LTE IMSI catchers and the DoS exploits myself in the past as well ([2] and [3]).

I was giving a talk on this topic last week at UC Irvine, trying to encourage graduate students to focus their PhD research in this area as there is still a lot of work to be done. We need the talented minds of graduate researchers to come up with new threats and, more importantly, solutions to these threats.

Back to this new paper, it is a great overview of IMSI catchers and it is great that the authors implemented the IMSI catcher using an alternative tool (Open Air Interface). I found interesting, though, that they state that implementing an IMSI cather on openLTE requires source code modification such that it is not a viable option for “non programmers”.

Although the claim of their implementation being for non-programmers is obviously correct, their LTE IMSI catcher uses very similar software and the same computing equipment as the ones in [1,2,3]. I would argue that adding 3 lines of code to openLTE is something a non-programmer could do as well. This is what the authors of [1] did. The only modification required at openLTE (as I have explicitly stated at every talk I have given) is mostly to add an fprintf statement where openLTE parses the AttachRequest message or the TAU/LocationArea Update message. Although one can do slightly fancier things.

Anyhow, maybe I am too optimistic and expecting a non-programmer to add an fprintf statement in openLTE is perhaps asking too much 🙂

Regardless, this new paper is great and very interesting and an excellent reference on this topic. I am wondering if they will be presenting their work at a conference soon?

I look forward to more and more research in this area.

[1] Shaik, Altaf, et al. “Practical attacks against privacy and availability in 4G/LTE mobile communication systems.” arXiv preprint arXiv:1510.07563(2015).

[2] Jover, Roger Piqueras. “LTE security and protocol exploits.” ShmooCon (2016).

[3] Jover, Roger Piqueras. “LTE security, protocol exploits and location tracking experimentation with low-cost software radio.” arXiv preprint arXiv:1607.05171 (2016).

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

  • 144,170 hits

Twitter feed

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