This Week In Security: Bluetooth Hacking, NEC Phones, And Malicious Tor Nodes

August 21, 2020 by 4 Comments

One of the fun things about vulnerability research is that there are so many places for bugs to hide. Modern devices have multiple processors, bits of radio hardware, and millions of lines of code. When [Veronica Kovah] of Dark Mentor LLC decided to start vulnerability research on the Bluetooth Low Energy protocol, she opted to target the link layer itself, rather than the code stack running as part of the main OS. What’s interesting is that the link layer has to process data before any authentication is performed, so if a vulnerability is found here, it’s guaranteed to be pre-authentication. Also of interest, many different devices are likely to share the same BLE chipset, meaning these vulnerabilities will show up on many different devices. [Veronica] shares some great info on how to get started, as well as the details on the vulnerabilities she found, in the PDF whitepaper. (Just a quick note, this link isn’t to the raw PDF, but pulls up a GitHub PDF viewer.) There is also a video presentation of the findings, if that’s more your speed.

The first vuln we’ll look at is CVE-2019-15948, which affects a handful of Texas Instruments BT/BLE chips. The problem is in how BLE advertisement packets are handled. An advertisement packet should always contain a data length of at least six bytes, which is reserved for the sending device address. Part of the packet parsing process is to subtract six from the packet length and do a memcpy using that value as the length. A malicious packet can have a length of less than six, and the result is that the copy length integer underflows, becoming a large value, and overwriting the current stack. To actually turn this into an exploit, a pair of data packets are sent repeatedly, to put malicious code in the place where program execution will jump to.

The second vulnerability of note, CVE-2020-15531 targets a Silicon Labs BLE chip, and uses malformed extended advertisement packets to trigger a buffer overflow. Specifically, the sent message is longer than the specification says it should be. Rather than drop this malformed message, the chip’s firmware processes it, which triggers a buffer overflow. Going a step further, this chip has non-volatile firmware, and it’s possible to modify that firmware permanently. [Veronica] points out that even embedded chips like these should have some sort of secure boot implementation, to prevent these sort of persistent attacks.
Continue reading “This Week In Security: Bluetooth Hacking, NEC Phones, And Malicious Tor Nodes” →

Fire Pit Burns To The Beat With Bluetooth

August 20, 2020 by 3 Comments

Humans have several primal fascinations and perhaps two of the biggest ones are fire and music. While you can picture some cavemen and cavewomen sitting around a fire beating on sticks for rhythm, we think they’d be impressed if the fire danced along with the music. Through the power of Bluetooth, that’s exactly what [Random Tech DIY’s] new fire pit does.

Technically, this is called a Rubens tube, and while it’s an old technology, the Bluetooth is a certainly a modern touch. As you might expect, most of this project is workshop time, cutting MDF and plastic. The audio system is off-the-shelf and drives some car stereo speakers. The results looked good, and although it always makes us nervous building things that carry propane gas, it seems to work well enough from where we’re sitting.

We had to wonder what things you could change that would affect the display. Changing the number of holes, the diameter of the holes, or the gas pressure, for example, would certainly change how the flames look and react to the sound waves.

We have seen other Rubens tube projects, of course. However, we were really interested in the use of these as crude oscilloscopes before the availability of cathode ray tubes. We’ve seen a modern take on that, too.

Continue reading “Fire Pit Burns To The Beat With Bluetooth” →

Separation Between WiFi And Bluetooth Broken By The Spectra Co-Existence Attack

August 7, 2020 by 5 Comments

This year, at DEF CON 28 DEF CON Safe Mode, security researchers [Jiska Classen] and [Francesco Gringoli] gave a talk about inter-chip privilege escalation using wireless coexistence mechanisms. The title is catchy, sure, but what exactly is this about?

To understand this security flaw, or group of security flaws, we first need to know what wireless coexistence mechanisms are. Modern devices can support cellular and non-cellular wireless communications standards at the same time (LTE, WiFi, Bluetooth). Given the desired miniaturization of our devices, the different subsystems that support these communication technologies must reside in very close physical proximity within the device (in-device coexistence). The resulting high level of reciprocal leakage can at times cause considerable interference.

There are several scenarios where interference can occur, the main ones are:

  • Two radio systems occupy neighboring frequencies and carrier leakage occurs
  • The harmonics of one transmitter fall on frequencies used by another system
  • Two radio systems share the same frequencies

To tackle these kind of problems, manufacturers had to implement strategies so that the devices wireless chips can coexist (sometimes even sharing the same antenna) and reduce interference to a minimum. They are called coexistence mechanisms and enable high-performance communication on intersecting frequency bands and thus, they are essential to any modern mobile device. Despite open solutions exist, such as the Mobile Wireless Standards, the manufacturers usually implement proprietary solutions.

Spectra

Spectra is a new attack class demonstrated in this DEF CON talk, which is focused on Broadcom and Cypress WiFi/Bluetooth combo chips. On a combo chip, WiFi and Bluetooth run on separate processing cores and coexistence information is directly exchanged between cores using the Serial Enhanced Coexistence Interface (SECI) and does not go through the underlying operating system.

Spectra class attacks exploit flaws in the interfaces between wireless cores in which one core can achieve denial of service (DoS), information disclosure and even code execution on another core. The reasoning here is, from an attacker perspective, to leverage a Bluetooth subsystem remote code execution (RCE) to perform WiFi RCE and maybe even LTE RCE. Keep in mind that this remote code execution is happening in these CPU core subsystems, and so can be completely invisible to the main device CPU and OS.

Join me below where the talk is embedded and where I will also dig into the denial of service, information disclosure, and code execution topics of the Spectra attack.

Continue reading “Separation Between WiFi And Bluetooth Broken By The Spectra Co-Existence Attack” →

Unbricking A $2,000 Exercise Bike With A Raspberry Pi Zero And Bluetooth Hacks

August 4, 2020 by 17 Comments

Really, how did we get the point in this world where an exercise bike can be bricked? Such was the pickle that [ptx2] was in when their $2,000 bike by Flywheel Home Sports was left without the essential feature of participating in virtual rides after Peloton bought the company. The solution? Reverse engineer the bike to get it working with another online cycling simulator.

Sniffing Flywheel Bluetotooth packets with Bluetility

We have to admit we weren’t aware of the array of choices that the virtual biking markets offers. [ptx2] went with Zwift, which like most of these platforms, lets you pilot a smart bike through virtual landscapes along with the avatars of hundreds of other virtual riders. A little Bluetooth snooping with Bluetility let [ptx2] identify the bytes in the Flywheel bike’s packets encoding both the rider’s cadence and the power exerted, which Zwift would need, along with the current resistance setting of the magnetic brake.

Integration into Zwift was a matter of emulating one of the smart bikes already supported by the program. This required some hacking on the Cycling Power Service, a Bluetooth service that Zwift uses to talk to the bike. The final configuration has a Raspberry Pi Zero W between the Flywheel bike and the Zwift app, and has logged about 2,000 miles of daily use. It still needs a motor to control the resistance along the virtual hills and valleys, but that’s a job for another day.

Hats off to [ptx2] for salvaging a $2,000 bike for the price of a Pi and some quality hacking time, and for sticking it to The Man a bit. We have to say that most bike hacks we see around here have to do with making less work for the rider, not more. This project was a refreshing change.

[Featured images: Zwift, Flywheel Sports]

[via r/gadgets]

Aesthetic DIY Bluetooth Speakers

July 30, 2020 by No comments

DIY Bluetooth speaker projects are always a staple here at Hackady. In our latest feature of DIY audio builds, we have [Patrick’s] vinyl cylindrical speaker.

He found a pretty inexpensive Bluetooth audio amplifier on AliExpress. However, the amplifier module oddly enough had a few missing components that were critical to its operation, so he had to do a little bit of re-work. Not something you generally expect to do when you purchase a pre-made module, but he was certainly up to the task.

He noticed the board amp module was missing a battery protection circuit even though there was space on the board laid out for those components (maybe an older board revision?). To remedy this problem, he added his own battery protection circuit to prevent any unwanted catastrophes. Secondly, he noticed a lot of distortion at high volumes and figured that some added capacitance on the power supply would help fix the distortion. Luckily, that did the trick.

Finally, and not quite a mistake on the manufacturer’s part this time, but an improvement [Patrick] needed for his own personal use. He wanted the amp module’s board-level LED indicator to be visible once the enclosure was fitted around the electronics. So, he used the built-in status trigger as a digital signal for a simple transistor circuit powering a much brighter ring LED that could be mounted onto the enclosure. That way, he could utilize the firmware for triggering the board-level status indicator for his own ring LED without any software modifications to the amp module.

Now, all that was left was to construct the enclosure he had 3D-printed and fit all the electronics in their place. We’ve gotten pretty used to the always impressive aesthetics of [Patrick’s] designs, having covered a project of his before, and this build is certainly no exception. Great job!

While you’re here, take a look at some other DIY Bluetooth speaker projects on Hackaday.

Continue reading “Aesthetic DIY Bluetooth Speakers” →

Bluetooth Development Board Goes The Distance

June 15, 2020 by 13 Comments

Have you ever come across an interesting chip or component that you wanted to experiment with, only to find that there doesn’t seem to be a development board for it? Spinning up your own board is a lot easier today than it has been in the past, but it’s still a bit of a hassle to do it just for your own personal use. This is why [Nikolaj Andersson Nielsen] has decided to release RFCat, his custom long-range Bluetooth development board, onto the community.

The board is based around a module from MeshTek that’s essentially an amplified version of the Nordic nRF52832. According to [Nikolaj], this gives the module 30 times the transmit power of the base model chip.

RFCat is compatible with the Arduino IDE and uses the Adafruit nRF52 bootloader, making it easy to write your own code to take advantage of all this new-found power. Primarily you’d be programming the board over USB-C, but it also supports Serial Wire Debug (SWD) and over-the-air updates that can be triggered with a physical push button on the device.

If you want to get an RFCat of your own, it’s available on Tindie now. The amplified modules were originally intended for building Bluetooth mesh networks, but we’re sure there are other interesting applications out there just waiting to be discovered.

Continue reading “Bluetooth Development Board Goes The Distance” →

Bluetooth Takes Keyboard From DIY To Super Fly

May 28, 2020 by 8 Comments

They say you should never cheap out on anything that comes between you and the ground, like tires, shoes, and mattresses. We would take that a little further into the 21st century and extend it to anything between you and work. In our case, ‘buy nice or buy twice’ includes keyboards and mice.

[Marcus Young] is a fan of ortholinear ergonomic comfort, but not of cables. He gave [adereth]’s dactyl keyboard some wings by using a Bluetooth micro, and the Pterodactyl was born. Of course, the two halves still use a TRRS cable to communicate, and wires are required to charge batteries, but it’s the principle of the thing.

That’s not all [Marcus] did to make the dactyl his own — it also has a modified full-fat base that gives him all the room in the world to wire up the keyswitch matrix compared to the original streamlined design.

Instead of the usual Teensy, Pro Micro, or Proton-C, the pterodactyl has a Feather 32u4 in its belly. [Marcus] is clacking on Holy Panda switches which we’ve been meaning to try, and individual PCBs for each switch, which seems like it might negate gluing the switches in place so they survive through keycap changes. Check out [Marcus]’ write-up to see what he learned during this build.

This isn’t the first modified dactyl we’ve seen flying around here, and it won’t be the last. Here’s one with a dual personality — both halves can work together or alone.

Via r/mk