>Email from SingCERT stating vendor "do not consider this to be a vulnerability, as it does not present a cybersecurity risk."

So wirelessly writing custom firmware to someone else's device that is connected via USB to their computer without even needing to pair is not a security vulnerability. Yea.

This is a well written article and easy to digest, worth a skim.

In summary he figured out how to reflash arbitrary firmware on a Creative Sound Blaster Katana V2X soundbar via Bluetooth, without requiring any effective authentication or user interaction.

The soundbar is plugged directly into its host computer via USB, so by adding a descriptor to its firmware he made it recognized as a keyboard. From there it was straightforward to have it send keystrokes to the PC. The soundbar is equipped with a mic, so an adversary could turn it into an eavesdropping device.

He reported it to Creative and SingCERT. Neither him or SingCERT got any meaningful response from the company until 2 months later, eventually saying "they do not consider this to be a vulnerability, as it does not present a cybersecurity risk".

He released a firmware patcher that disables the flawed transport protocol. It's a bit of a sledgehammer that likely also breaks functionality of the official Bluetooth app, but seems like the best he could do without cooperation from the manufacturer.

It is quite common to find device manufacturers, even those of many years standing, who _appear to_ begin with the device and add the software as an afterthought. Paying little attention to security or even the software lifecycle (patches, updates, the changing landscape/ecosystem). I have even known it happen that the device brand subs out the software to a random small developer, who then closes up shop/dies/gets out of that business, and the device company doesnt even have the source code, let alone any ability to further improve/fix the software that drives their device. This leads to layers upon layers of subsequent middleware, UIs, shims etc.

Why think so small? Perhaps the speaker itself can be used as the attacker.

Any script kiddie with an LLM could write a worm that would spread through the supply chain, possibly even hacking speakers right on the factory floor and blasting Rickroll music or something similar.

It would be interesting to see if Creative would still claim that it "does not present a cybersecurity risk".

Edit: Bonus points for closing the security hole and disabling the ability to flash the firmware normally, so that the manufacturer would have to jailbreak the speakers in order to repair them.

The fact that the author had to publish a third-party patch because the vendor didn't consider it a vulnerability is not a great look

If I were in charge of, say, the Mossad, I would have as a significant part of my budget purchasing every single bluetooth device on the market, and set a bunch of underemployed Israeli CS grads to work at finding these vulnerabilities, and then putting them into an easily deployed toolkit. You want an asset with access to, say, an Iranian government office, to be able to walk through the building with a phone and take control of as many machines as possible.

Now that I think about it, I think you have to assume that they probably DO do this...

I write firmware (specifically bluetooth enabled device firmware) and my work has blocked this website.

Can't wait to see a video from a half sloppy channel about this on my youtube front page in roughly 4 business days

People who love tech buy superdupersmart loudspeaker that will connect to every computer in their house; and also somehow control their superdupersmart coffee maker so they can have a fresh coffee brewed when some Miles Davis play.

People who understand tech keep an axe next to their toaster.

Having a guaranteed audio channel makes this so much cooler for exploits -- you can exfiltrate over audio!! I love it. I wonder how many of these were sold. I also imagine based on Creative's response (this is fine) that many other devices in the class have similar security models in place. Def scary.

It's funny to see all the commenters who didn't read the article closely enough or at all. This is basically the bluetooth device equivalent of "left S3 bucket open to public".

That said, really cool work. I honestly thought it would be harder to turn a usb connected device into an exploit vector.

That it's as easy as emulating a keyboard that pops a local terminal and runs a malicious command is actually pretty funny. Though it will be a non-admin terminal so the damage should be somewhat limited. And on Windows, users often just click through any UAC prompt so I bet you'd get full access on many windows boxes.

I also did some reverse engineering, although mine was a soundcard which seemed to use an older version of this software (GUI was different). I used Wireshark to sniff out the LED and EQ packets and then wrote a CLI utility with hidapi library in C.

It doesn't have bluetooth so thankfully something like this wouldn't happen with mine. It's crazy that there's no auth at all for Bluetooth. I was reversing my e-scooter recently (still WIP) and there was a whole bunch of authentication required before its app could control any of it. I am still not confident in its security though

The 'S' in IoT is for 'Security'

So presumably this is cured with device permissions, 'this device may only receive audio data; return confirmations', say. And those Lorraine would need to be at BIOS level, like enrolling devices into SecureBoot, because otherwise for keyboards and mouses you're left with a chicken-egg problem.

Or? There's other mitigations that OS already have in place?

Air-gapped attacks are the most fascinating. Change my mind

Inexistent security, absent security contacts/hard to get in touch with, denial/delay/won’t patch, most functionality to deploy a backdoor is already present, to me equals bugdoor. This is wanted behavior, not an accident, and is a widespread pattern..

> in order to do anything with CTP over USB, you first have to do challenge-response authentication with the device. The key is static [... ]

Is this some legal thing so they can claim that a protection was circumvented? E.g. to void warranty or be able to sue?

This is so refreshing to read. A true throwback in style and content. Makes me nostalgic

While the article only talks about using this as a USB HID keyboard to send attacks, surely if you spent more time creating an evil firmware from scratch you could do much more than this? You could bridge any information from USB -> Bluetooth.

Great research. Thanks for sharing

Wow, that's very creative! /couldn't resist the pun/

This is a cool infection vector for the ai virus from earlier today to use. It could be like NDS feature that it greeted a passerby but now for spreading stuff digitally.

Creative is still around? They always had great hardware, but their software was never what one would consider "great".

what ways are there to protect from malicious HID device?

What an amazing write-up and exploit. Love it!

Good work, and fun to read.

It's crazy that companies just stick their head in the sand, when confronted with serious security issues.

The real question remains: with this hack, did the OP gain full control of Dr. Sbaitso?

Not sure what would count as a vulnerability if this does not.

ebpf usb sniffer you may find useful.

https://github.com/yeet-src/usbsnoop

Haha, I dont have one, only headphones Jokes on you xD

"Hacking the poorly secured, combination wired/wireless, multi-protocol bridge controller you naively attached to your PC's universal IO bus"

Way cool. Thank you for sharing

[flagged]

[dead]

[dead]

[dead]

[dead]

[flagged]

This sounds super cool

Side-channel attacks are getting wild. Every time I think we've completely air-gapped a device, someone finds a way to use acoustic frequencies or hardware resonance to leak data.

Thanks for sharing this. It’s a bit concerning that a consumer soundbar can receive unauthenticated firmware over BLE and then act like a BadUSB-style HID on the host. I’m not sure I agree with the vendor’s "no cybersecurity risk" assessment, considering how much access a trusted keyboard interface typically has.