There are some interesting questions afoot, with the news that the Contec CMS8000 medical monitoring system has a backdoor. And this isn’t the normal debug port accidentally left in the firmware. The CISA PDF has all the details, and it’s weird. The device firmware attempts to mount an NFS share from an IP address owned by an undisclosed university. If that mount command succeeds, binary files would be copied to the local filesystem and executed.
Additionally, the firmware sends patient and sensor data to this same hard-coded IP address. This backdoor also includes a system call to enable the eth0
network before attempting to access the hardcoded IP address, meaning that simply disabling the Ethernet connection in the device options is not sufficient to prevent the backdoor from triggering. This is a stark reminder that in the firmware world, workarounds and mitigations are often inadequate. For instance, you could set the gateway address to a bogus value, but a slightly more sophisticated firmware could trivially enable a bridge or alias approach, completely bypassing those settings. There is no fix at this time, and the guidance is pretty straightforward — unplug the affected devices.
Reverse Engineering Using… Strings
The Include Security team found a particularly terrifying “smart” device to tear apart: the GoveeLife Smart Space Heater Lite. “Smart Space Heater” should probably be terrifying on its own. It doesn’t get much better from there, when the team found checks for firmware updates happening over unencrypted HTTP connections. Or when the UART password was reverse engineered from the readily available update. It’s not a standard Unix password, just a string comparison with a hardcoded value, and as such readily visible in the strings
output.
Now on to the firmware update itself. It turns out that, yes, the device will happily take a firmware update over that unencrypted HTTP connection. The first attempt at running modified firmware failed, with complaints about checksum failures. Turns out it’s just a simple checksum appended to the firmware image. The device has absolutely no protection against running custom firmware. So this leads to the natural question, what could an attacker actually do with access to a device like this?
The proof of concept attack was to toggle the heat control relay for every log message. In a system like this, one would hope there would be hardware failsafes that turn off the heating element in an overheat incident. Considering that this unit has been formally recalled for over 100 reports of overheating, and at least seven fires caused by the device, that hope seems to be in vain.
AMD Releases
We wrote about the mysterious AMD vulnerability a couple weeks ago, and the time has finally come for the full release. It’s officially CVE-2024-56161, “Improper signature verification in AMD CPU ROM microcode patch loader”. The primary danger seems to be malicious microcode that could be used to defeat AMD’s Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) technology. In essence, an attacker with root access on a hypervisor could defeat this VM encryption guarantee and compromise the VMs on that system.
This issue was found by the Google Security Team, and there is a PoC published that demonstrates the attack with benign effects.
The Mirai Two-fer
The Mirai botnet seems to have picked up a couple new tricks, with separate strains now attacking Zyxel CPE devices and Mitel SIP phones. Both attacks are actively being exploited, and the Zyxel CPE flaw seems to be limited to an older, out-of-support family of devices. So if you’re running one of the approximately 1,500 “legacy DSL CPE” devices, it’s time to pull the plug. Mitel has published an advisory as well, and is offering firmware updates to address the vulnerability.
Let’s Encrypt Changes
A service many of us depend on is making some changes. Let’s Encrypt is no longer going to email you when your certificate is about to expire. The top reason is simple. It’s getting to be a lot of emails to send, and sending emails can get expensive when you measure them in the millions.
Relatedly, Let’s Encrypt is also about to roll out new six-day certificates. Sending out email reminders for such short lifetimes just doesn’t make much sense. Finally from Let’s Encrypt is a very useful new feature, the IP Address certificate. If you’ve ever found yourself wishing you didn’t have to mess with DNS just to get an HTTPS certificate, Let’s Encrypt is about to have you covered.
Bits and Bytes
There’s a Linux vulnerability in the USB Video Class driver, and CISA has issued an active exploit warning for it. And it’s interesting, because it’s been around for a very long time, and it was disclosed in a Google Android Security Bulletin. It’s been suggested that this was a known vulnerability, and was used in forensic tools for Android, in the vein of Cellebrite.
Pretty much no matter what program you’re using, it’s important to never load untrusted files. The latest application to prove this truism is GarageBand. The details are scarce, but know that versions before 10.4.12 can run arbitrary code when loading malicious images.
Ever wonder how many apps Google blocks and pulls from the app store? Apparently better than two million in 2024. The way Google stays mostly on top of that pile of malware is the use of automated tools, which now includes AI tools. Which, yes, is a bit terrifying, and has caused problems in other Google services. YouTube in particular comes to mind, where channels get content strikes for seemingly no reason, and have trouble finding real human beings at Google to take notice and fix what the automated system has mucked up.
And finally, echoing what Kee had to say on the subject, cryptocurrency fraud really is just fraud. And [Andean Medjedovic] of Canada found that out the hard way, after his $65 million theft landed him in jail on charges of wire fraud, computer hacking, and attempted extortion.
Voila ce que c’est quand on confie la programmation et le codage du firmware a des macaques payés 2 bananes a l’heure……
Assuming you talk about the smart space heaters: I wonder what’s worse: Bona fide heater companies slapping on some smarts they don’t understand the risks of, or Smart Tech™® companies that apply their tech to a heating spiral they don’t understand the risks of.
Or probs companies that don’t understand either.
Or people who replace due diligence and effort with a couple of code fragments pulled from a random hacker on the internet, collect their bonus, and run.
The risks of a IOT type device are barely mitagated if any effort is put in at all it seems by any of the players in that space. So to use those devices securely always seems to mean you need a network engineering degree to keep them safe anyway – a heater company adding to that mess at least won’t burn down folks houses, just contribute to some botnet etc.
So I’d definitively want a tech company slapping a ‘smart’ control on the established brands quality heaters than building their own, or a heater company importing some LLM generated ‘smart’ – as then the product will have proper hardware thermal runaway protections etc built in, and probably in ways that don’t cause any need for service – a reset of the manually resetable fuse perhaps at worse.
The TechBro’s build a heater on the other hand will assume the software can magically fix everything, so will ignore all the decades/centuries of established best practice throwing out all those features that are there for good reason. All the evidence I’ve seen says they will assume everything will always work, that relay will never fail open, the thermistor never drift out or fail, their software will never hang with the heater on full…
That medical device one is particularly horrific. We really need to be careful with Chinese made network connected devices. I bought some IP cameras and chucked them when I found they made connections out to Chinese IP addresses.
Chuck your phone.
install LineageOS (and maybe buy a FairPhone)
You can use those camera if you want to (I’d stick with PoE ones though as wifi cameras are a bad idea in general anyway). Just don’t actually connect them to the internet! Or if you must have a really really draconian filter for the camera network so it can only send and receive the stuff you expect to the places you allowed. Far as I know nobody has caught one being a wifi mesh to find a working exit or anything like that, so as long as you can trust your core networking gear…
Though I do agree that this is pretty crap, and really that sort of BS shouldn’t have made it through the regulatory testing to allow such devices to be imported.
“guidance is pretty straightforward — unplug the affected devices.” – couldn’t you just block that hardwired ip address in your firewall?
Only if you knew the IP address.
202.114.4.119
Best to block Internet access altogether from (medical) IoT devices and only allow what is explicitly needed (and documented) for the device to function.
IANAL but I suspect the medical device that uploads patient data to a remote location without consent would be highly illegal under EU and UK laws.