Important note: Some media coverage on this topic falsely or inaccurately
depicts the attack conditions. To be clear: Any vulnerable device can be
compromised if the attacker is in Bluetooth range. That is the only
precondition.
During our research on Bluetooth headphones and earbuds, we identified several
vulnerabilities in devices that incorporate Airoha Systems on a Chip (SoCs). In
this blog post, we briefly want to describe the vulnerabilities, point out their
impact and provide some context to currently running patch delivery processes as
described at this year’s
TROOPERS Conference.
During our recent research, we experimented with different Bluetooth USB
dongles. There are tons of options, and sometimes, it’s challenging to determine
what chipset a dongle actually contains, what Bluetooth features it supports,
and whether it works on Linux. Inspired by the recent
ESP32 Bluetooth research,
we wondered whether we could turn our Raspberry Pi Pico Ws into a functioning
Bluetooth dongle. We had a few lying around, and the advantage here is that we
know exactly which
Bluetooth controller it uses
– the Infineon CYW43439. It’s also very easy to get one. You can just buy the
Pico W for a few bucks, even cheaper than some Bluetooth dongles. You also have
a controller family that has been researched quite a bit in the
internalblue project. However,
there was one disadvantage. We did not find any code that exposes the CYW43439’s
HCI interface via USB. So we had to write that on our own.
For the realization and introduction of autonomous vehicles, the safe interaction of functions, systems and services as well as their monitoring over the entire product life cycle is essential. An exclusive security-by-design approach is no longer sufficient and must be continuously supported by feedback obtained from in-the-wild operation. This is where the recently successfully completed joint project BMBF UNCOVER comes into play, which targets the requirements of the standards ISO/SAE 21434 (Road vehicles – Cybersecurity engineering) and ISO 21448 (Road vehicles – Safety of the intended functionality (SOTIF)).
This blogpost will be about my first steps with coreboot and libreboot and a life with as few proprietary firmware blobs as possible. My main motivation were the latest headlines about fancy firmware things like Intel ME, Computrace and UEFI backdoors. This post is not intended to be about a as much as possible hardened system or about coreboot/libreboot being more secure, but rather to be able to look into every part of software running on that system if you want to.
Embedded devices often serve as an entry point for an attack on a private or corporate network. The infamous attack on HackingTeam, for example, followed exactly this path as was revealed here. Although the attack may have been for the greater good (refer also to this great keynote), such incidents demonstrate that it is important to properly secure your embedded devices. In a recent blog post, Niklaus presented how he analyzed the security posture of a MAX! Cube LAN Gateway. Moreover, Brian reported a few weeks ago on the security posture of IoT devices (and in particular on one of his cameras). With this post I would like to share my experiences with analyzing another embedded device: the IC-3116W IP camera by Edimax.
Internal workshops are one of the reoccurring events at ERNW, that help us to gain knowledge in areas outside our usual expertise. One of the recent workshops which happened during the week from August 22nd-25th was Hardware Hacking. Held by Brian Butterly (@BadgeWizard) and Dominic Spill (@dominicgs), this workshop took place in two parts. Brian kickstarted the introductory session by guiding us through the fundamental steps of Hardware Hacking. Brian did an excellent job of making things simpler by giving a detailed explanation on the basic concepts. For a beginner in hardware hacking, the topic could be rather intimidating if not handled properly.
We couldn’t be more proud to welcome such a predestined #1 hardware hacking victim, than VICTor is!
Before Brian and I gave a lecture on hardware hacking last week at DHBW Mosbach, we felt, that we needed a custom victim which is fully documented and provides a good “hackability” to the students.
Surely we could also have used some cheap $wifi_ap, but here’s the thing: Would you really want to use a device which you don’t really know? Mostly, there’s a massive lack of documentation regarding the SoCs used…not to mention the unavailability of schematics and layouts.
As we wanted to teach students the basics of hardware hacking effectively, we decided to create something by ourselves.
At times with many many digitally transmittable diseases, protection might be more important than ever. When connecting your smartphone to a rogue charger, or a foreign smartphone to your own laptop, you never now what will happen. You never know what data crosses the lines. But there is help: A USB condom!
As the Troopers 16 Badge was a neat integrated device, we had the challenge to identify something to be soldered for our attendees. The past has shown, that soldering rocks and all of our attendees, all of you, really enjoy it! After some looking around and roaming the Internet, we decided to go for a simple device, which would protect you and your devices in a hostile world. A slim PCB, which will protect your phone when having to connect it to some unknown charger or for situations when “a mate” just wants to connect his/her phone to your laptop for “charging purposes”.
A while back Stefan and I held a little crash course/orientation run on hardware hacking at a German Fachhochschule. Planning to use something “real” we went for a simple electronic safe with a bunch of different vulnerabilities. I guess most security guys who spend a fair amount of time in hotels will understand this choice. As we needed something we could rely on would break, we stripped the device and swapped the original electronics for our own. The result was the “Damn Vulnerable Safe”.
“Welcome to Brazil”, I think, turned to being the most used statement during the past Hackers to Hackers Conference in Sao Paulo. It was used as the main reaction to every speech taking moment, and there were a lot of those! To honor the moments and give you a quick insight into was what going on in Sao Paulo, here is a quick summary of the overall event and our own contribution.