>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.
"You can just make it type words, what's the risk in that?"
Makes you wonder what other peripheral companies out there are also operating with seemingly no security team. There must be other vulnerabilities like this just waiting to be discovered.
My brother was awoken one morning at 2am because some neighborhood kids connected to his bluetooth speaker and blasted fart sounds on loop at max volume, and that's literally only the absolute tippy top of the malicious bluetooth use iceberg.
Oh yeah, for some reason the companies with the highest risk products seem to be the ones that care less about security. Don't even get me started with "smart" bulbs and cameras that each individually connect to your local network and the Internet. You have 5 lightbulbs? That's 5 different devices you need to track, keep updated and trust the in the vendor firmware's security.
This quote on risk seems to completely misunderstand the concept of risk. First we have a vulnerability ( IMHO that is equals a hazard), then we assign both impact and probability and only then we get risk. By definition there are IMHO always vulnerabilities with low impact or low probability and thus low risk. While CVEs have some score, the actual risk and later accepting those risks before or after mitigations is up to the use case to define. No risk => no vulnerability is flawed reasoning by design. No vulnerability => no risk, I think is the only thing we can agree on.
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".
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.
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.
That would've been a cool PoC to work on as well, but seems a fair bit more complicated than the BadUSB-style attack I ended up doing. Would've had to do a lot more RE to figure out how to interact with the whole microphone subsystem, I think.
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.
If you can "just type stuff", it is absolutely trivial to download absolutely any payload you want as long as you have network access and your antivirus doesn't stop it.
>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.
"You can just make it type words, what's the risk in that?"
Makes you wonder what other peripheral companies out there are also operating with seemingly no security team. There must be other vulnerabilities like this just waiting to be discovered.
My brother was awoken one morning at 2am because some neighborhood kids connected to his bluetooth speaker and blasted fart sounds on loop at max volume, and that's literally only the absolute tippy top of the malicious bluetooth use iceberg.
Oh yeah, for some reason the companies with the highest risk products seem to be the ones that care less about security. Don't even get me started with "smart" bulbs and cameras that each individually connect to your local network and the Internet. You have 5 lightbulbs? That's 5 different devices you need to track, keep updated and trust the in the vendor firmware's security.
> "smart" bulbs
Thankfully I don't think I've seen these for sale.
What sensors would they have that could be exploited by an attacker?
Probably most of them. It's not exactly an area with a great focus on quality, let alone security.
This quote on risk seems to completely misunderstand the concept of risk. First we have a vulnerability ( IMHO that is equals a hazard), then we assign both impact and probability and only then we get risk. By definition there are IMHO always vulnerabilities with low impact or low probability and thus low risk. While CVEs have some score, the actual risk and later accepting those risks before or after mitigations is up to the use case to define. No risk => no vulnerability is flawed reasoning by design. No vulnerability => no risk, I think is the only thing we can agree on.
Yeah, but we already sold the device, so it's someone else's problem. Now if they were paying us a subscription fee..
AND being able to further reprogram the device to gain control of the PC.
This is negligence of the highest kind.
The vendor response is the more worrying part
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".
Flash worm into device and RMA it. Boom.
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.
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
Can't wait to see a video from a half sloppy channel about this on my youtube front page in roughly 4 business days
Do you know that if you turn off saving YouTube history, you can have no front page at all?
I guess you can still be first to Linkedin and get all of the fame.
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.
That would've been a cool PoC to work on as well, but seems a fair bit more complicated than the BadUSB-style attack I ended up doing. Would've had to do a lot more RE to figure out how to interact with the whole microphone subsystem, I think.
I guess you could just construct a wav file from the shell and then play it. Agreed doing it all on device sounds challenging.
Air-gapped attacks are the most fascinating. Change my mind
Great research. Thanks for sharing
The real question remains: with this hack, did the OP gain full control of Dr. Sbaitso?
Good work, and fun to read.
It's crazy that companies just stick their head in the sand, when confronted with serious security issues.
Way cool. Thank you for sharing
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.
If you can "just type stuff", it is absolutely trivial to download absolutely any payload you want as long as you have network access and your antivirus doesn't stop it.