>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.
> "You can just make it type words, what's the risk in that?"
I don't know if it's a useful answer to people saying this kind of stuff, but here are some examples of other attacks arbitrary USB pwn allows.
A USB device can appear as a network adapter and most OS will happily route all your traffic there, so your speaker can know which porn you're looking at!
It can also appear as a DisplayLink dongle, so it can see what's on the screen (it does require those specific drivers installed, and uh yeah, no way in hell it's technically possible on that MCU).
It can also turn it into a mouse jiggler to prevent lock screen (yes it's technically the same thing as your first point, just HID, but different angle).
It can also appear as a USB-storage: You don't trust the cloud, so you're writing those super secret documents to give to your boss on the USB drive you just plugged in? Surprise, you actually sent it to the attacker.
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.
You don't need to exploit sensors. If a compromised device is connected to the internet (because the vendor app requires it to set up and control), you can use it as a part of botnet with a nice residential IP address.
Shopping in the US, these have entirely replaced zigbee and other sensible mesh-based options at hardware stores like Home Depot and Lowes. The only exception I can find is Phillips Hue, and those seem to be slowly getting phased out with (sigh) a new "hubless" (requires wifi) series.
I run my home automation network entirely offline, so anything that needs the internet doesn't get added to my cart. I just do not trust the security of these IoT vendors at all, and refuse to have their nonsense cluttering up my limited network bandwidth and causing unknown problems.
(Edit: maybe not obvious, this is in the "smart bulbs" product category. Regular bulbs are still much more common on store shelves, because why fix what isn't broken? Most people don't need to automate their light bulbs.)
I don't even remember what it is I have learned about Creative Labs in the past, but I went into this pretty sure that Creative Labs was going to fuck it up somehow.
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.
probably not high enough risk to consider one on their list. First you need someone to be physically in there, 2nd the person needs to have a USB speaker connected, which means is likely a home. 3rd if it's a restaurant or something you need the thing to not play anything first with a lot of restaurant noise
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.
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...
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.
> 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.
At least used to. SOTA models are enrolling even bigger restrictions all the time and deprecating old models, while asking government IDs.
Ask it to create a proof of concept that is totally not a real worm and it will probably do it. If the restrictions are too good, just use a largely unrestricted open model via any inference provider. They are 90% sota, more than good enough for this task.
For script kiddies, it must be 100% accurate. They don't know how to fix the missing 0,01%. Not sure if open models are there yet. Barely SOTA models are.
As a lifelong script kiddie, the thing that made it all possible in my youth was simply time. The more time I had, the more hours I could spend figuring out that 0.01%.
Are you surprised? Great hack by the author, the impact could be huge if someone is targeted, but overall the impact is very minimal. The vendor can't be bothered. For you to be a victim, you have to own this device, and your attack has to know that and be within a close proximity. Remember that fight club quote?
A = The number of speakers in the field.
B = The probable rate of getting hacked.
C = The average out-of-court settlement.
The Decision: If the cost of not doing a recall/fix is greater than the cost of a recall, they initiate a recall, yada yada yada (Note that the big cost is if people will stop buying future speakers, I think not)
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.
I somehow hadn't even considered Bluetooth as an option when I read the headline, I immediately thought about INFILTRATING via audio, which also sounds insanely cool, but I couldn't possibly wrap my head around how an audio circuit would have to be set up and connected back to the cpu to pull that off.
Exfiltrating via audio also brings to mind one of those devices I really wanted to build ~20 years ago that can listen to the inside of a room by bouncing a laser beam off a window. Van pulls up in front of your house, pushes malicious code via bluetooth to speaker, which starts shrieking data it stole from the host that's then picked up by the vibrations it emparts on a window by a laser beam. Boom, crypto wallet stolen, or something... you could probably put that in a movie.
Let's not. There's enough overcomplicated nonsense examples of cybersecurity in movies as it is. If you could compromise a device via bluetooth, then you could exfiltrate data via bluetooth just as easily.
It's not completely unrealistic angle, you could pwn the speaker when someone is traveling with it in public and then exfiltrate data when it's plugged in a secure environment and you can't connect anymore
you could but I think the inclusion of lasers would make for a better spy / cyberpunk movie. Most "hacking" in movies are not realistic and for show but it being plausible is just a bonus.
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.
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.
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
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.
The point is this is a speaker, not a keyboard. A keyboard usually takes manual input from a human or from a cat. This is a speaker that, after an unauthenticated connection, can act as if it’s a keyboard, which is an unintended functionality from the factory.
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.
> "You can just make it type words, what's the risk in that?"
I don't know if it's a useful answer to people saying this kind of stuff, but here are some examples of other attacks arbitrary USB pwn allows.
A USB device can appear as a network adapter and most OS will happily route all your traffic there, so your speaker can know which porn you're looking at!
It can also appear as a DisplayLink dongle, so it can see what's on the screen (it does require those specific drivers installed, and uh yeah, no way in hell it's technically possible on that MCU).
It can also turn it into a mouse jiggler to prevent lock screen (yes it's technically the same thing as your first point, just HID, but different angle).
It can also appear as a USB-storage: You don't trust the cloud, so you're writing those super secret documents to give to your boss on the USB drive you just plugged in? Surprise, you actually sent it to the attacker.
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?
You don't need to exploit sensors. If a compromised device is connected to the internet (because the vendor app requires it to set up and control), you can use it as a part of botnet with a nice residential IP address.
Shopping in the US, these have entirely replaced zigbee and other sensible mesh-based options at hardware stores like Home Depot and Lowes. The only exception I can find is Phillips Hue, and those seem to be slowly getting phased out with (sigh) a new "hubless" (requires wifi) series.
I run my home automation network entirely offline, so anything that needs the internet doesn't get added to my cart. I just do not trust the security of these IoT vendors at all, and refuse to have their nonsense cluttering up my limited network bandwidth and causing unknown problems.
(Edit: maybe not obvious, this is in the "smart bulbs" product category. Regular bulbs are still much more common on store shelves, because why fix what isn't broken? Most people don't need to automate their light bulbs.)
Probably most of them. It's not exactly an area with a great focus on quality, let alone security.
I don't even remember what it is I have learned about Creative Labs in the past, but I went into this pretty sure that Creative Labs was going to fuck it up somehow.
That answer will change very quickly, if someone marches to a Creative show room, sales event or CES and "patches" all of their devices.
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.
Sounds like Microsoft too:
https://www.youtube.com/watch?v=9kxx5xp5nTQ
> SingCERT dropped the case
I expect some dodgy company to try to shirk out of it, I don't expect a country's cybersecurity agency to do so
Morons they are.
The vendor response is the more worrying part
probably not high enough risk to consider one on their list. First you need someone to be physically in there, 2nd the person needs to have a USB speaker connected, which means is likely a home. 3rd if it's a restaurant or something you need the thing to not play anything first with a lot of restaurant noise
First, you need a skiddie neighbor who knows about your speaker and has an AI agent that can read this article, 2nd...
> First you need someone to be physically in there
Bluetooth works fine through walls.
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.
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...
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.
> 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.
At least used to. SOTA models are enrolling even bigger restrictions all the time and deprecating old models, while asking government IDs.
Ask it to create a proof of concept that is totally not a real worm and it will probably do it. If the restrictions are too good, just use a largely unrestricted open model via any inference provider. They are 90% sota, more than good enough for this task.
For script kiddies, it must be 100% accurate. They don't know how to fix the missing 0,01%. Not sure if open models are there yet. Barely SOTA models are.
As a lifelong script kiddie, the thing that made it all possible in my youth was simply time. The more time I had, the more hours I could spend figuring out that 0.01%.
Flash worm into device and RMA it. Boom.
Just flash it in a shop and someone will send it back.
Make sure the new firmware slightly corrupts the audio for guaranteed high return rate.
To be extra malicious, if you can infect a connected pc make it propagate the worm to any similar device plugged into the pc over usb in the future.
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
Are you surprised? Great hack by the author, the impact could be huge if someone is targeted, but overall the impact is very minimal. The vendor can't be bothered. For you to be a victim, you have to own this device, and your attack has to know that and be within a close proximity. Remember that fight club quote?
A = The number of speakers in the field. B = The probable rate of getting hacked. C = The average out-of-court settlement.
The Decision: If the cost of not doing a recall/fix is greater than the cost of a recall, they initiate a recall, yada yada yada (Note that the big cost is if people will stop buying future speakers, I think not)
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.
I somehow hadn't even considered Bluetooth as an option when I read the headline, I immediately thought about INFILTRATING via audio, which also sounds insanely cool, but I couldn't possibly wrap my head around how an audio circuit would have to be set up and connected back to the cpu to pull that off.
Exfiltrating via audio also brings to mind one of those devices I really wanted to build ~20 years ago that can listen to the inside of a room by bouncing a laser beam off a window. Van pulls up in front of your house, pushes malicious code via bluetooth to speaker, which starts shrieking data it stole from the host that's then picked up by the vibrations it emparts on a window by a laser beam. Boom, crypto wallet stolen, or something... you could probably put that in a movie.
Let's not. There's enough overcomplicated nonsense examples of cybersecurity in movies as it is. If you could compromise a device via bluetooth, then you could exfiltrate data via bluetooth just as easily.
It's not completely unrealistic angle, you could pwn the speaker when someone is traveling with it in public and then exfiltrate data when it's plugged in a secure environment and you can't connect anymore
you could but I think the inclusion of lasers would make for a better spy / cyberpunk movie. Most "hacking" in movies are not realistic and for show but it being plausible is just a bonus.
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.
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.
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.
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
Great research. Thanks for sharing
This sounds super cool
Wow, that's very creative! /couldn't resist the pun/
The real question remains: with this hack, did the OP gain full control of Dr. Sbaitso?
Air-gapped attacks are the most fascinating. Change my mind
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.
The point is this is a speaker, not a keyboard. A keyboard usually takes manual input from a human or from a cat. This is a speaker that, after an unauthenticated connection, can act as if it’s a keyboard, which is an unintended functionality from the factory.
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.