Over many years now we’ve covered right-to-repair stories, and among them has been a constant bête noire. The American farm machinery manufacturer John Deere whose instantly recognisable green and yellow tractors have reliably tilled the soil for over a century, have become the poster child for inappropriate use of DRM. It’s enough to make any farmer see red, but there’s a story from CNN which shows another side to manufacturer control. A Deere dealership in Melitopol, Ukraine, was looted by invading Russian forces, who took away an estimated $5m worth of farm machinery. The perfect crime perhaps, save for the Deere computer system being used to remotely disable them leaving the crooks with combine harvesters they can’t even start.
To start our week of vulnerabilities in everything, there’s a potentially big vulnerability in Android handsets, but it’s Apple’s fault. OK, maybe that’s a little harsh — Apple released the code to their Apple Lossless Audio Codec (ALAC) back in 2011 under the Apache License. This code was picked up and shipped as part of the driver stack for multiple devices by various vendors, including Qualcomm and MediaTek. The problem is that the Apple code was terrible, one researcher calling it a “walking colander” of security problems.
Apple has fixed their code internally over the years, but never pushed those updates to the public code-base. It’s a fire-and-forget source release, and that can cause problems like this. The fact that ALAC was released under a permissive license may contribute to the problem. Someone (in addition to Apple) likely found and fixed the security problems, but the permissive license doesn’t require sharing those fixes with a broader community. It’s worth pondering whether a Copyleft license like the GPL would have gotten a fix distributed years ago.
Regardless, CVE-2021-0674 and CVE-2021-0675 were fixed in both Qualcomm and MediaTek’s December 2021 security updates. These vulnerabilities are triggered by malicious audio files, and can result in RCE. An app could use this trick to escape the sandbox and escalate privileges. This sort of flaw has been used by actors like the NSO group to compromise devices via messaging apps. Continue reading “This Week In Security: Android And Linux, VirusTotal, More Psychic Signatures”→
[Daljeet Nandha] from [RoboCoffee] writes to us, sharing his research on cryptographic signature-based firmware authenticity checks recently added to the Xiaomi Mi scooter firmware. Those scooters use an OTA firmware update mechanism over BLE, so you can update your scooter using nothing but a smartphone app – great because you can easily get all the good new features, but suboptimal because you can easily get all the bad new features. As an owner of a Mi 1S scooter but a hacker first and foremost, [Daljeet] set up a HTTPS proxy and captured the firmware files that the app downloaded from Xiaomi servers, dug into them, and summarized what he found.
Confirming this update will indefinitely lock you out of any third-party OTA updates
Unlike many of the security measures we’ve seen lacking-by-design, this one secures the OTA firmware updates with what we would consider the industry standard – SHA256 hash with elliptic cryptography-backed signing. As soon as the first firmware version implementing signature checks is flashed into your scooter, it won’t accept anything except further firmware binaries that come with Xiaomi’s digital signature. Unless a flaw is found in the signature checking implementation, the “flash a custom firmware with a smartphone app” route no longer seems to be a viable pathway for modding your scooter in ways Xiaomi doesn’t approve of.
Having disassembled the code currently available, [Daljeet] tells us about all of this – and more. In his extensive writeup, he shares scripts he used on his exploration journey, so that any sufficiently motivated hacker can follow in his footsteps, and we highly recommend you take a look at everything he’s shared. He also gives further insights, explaining some constraints of the OTA update process and pointing out a few security-related assumptions made by Xiaomi, worth checking for bypassing the security implemented. Then, he points out the firmware filenames hinting that, in the future, the ESC (Electronic Speed Control, responsible for driving the motors) board firmware might be encrypted with the same kind of elliptic curve cryptography, and finds a few update hooks in the decompiled code that could enable exactly that in future firmware releases.
One could argue that these scooters are typically modified to remove speed limits, installed there because of legal limitations in a variety of countries. However, the legal speed limits are more nuanced than a hard upper boundary, and if the hardware is capable of doing 35km/h, you shouldn’t be at mercy of Xiaomi to be able to use your scooter to its full extent where considerate. It would be fair to assert, however, that Xiaomi did this because they don’t want to have their reputation be anywhere near “maker of scooters that people can modify to break laws with”, and therefore we can’t expect them to be forthcoming.
Java versions 15, 16, 17, and 18 (and maybe some older versions) have a big problem, ECDSA signature verification is totally broken. The story is a prime example of the dangers of unintended consequences, the pitfall of rolling your own crypto, and why to build a test suite for important code. In Java 15, the ECDSA verification code was re-written, moving the code from C++ to a Java-native implementation. The new code misses an important check, that the initialization and proof values are both non-zero.
OpenSSH has minted their 9.0 release, and it includes a pair of security changes. Unlike most of the releases we cover here, this one has security hardening to prevent issues, not emergency fixes for current ones. First up, the venerable scp/rcp protocol has been removed. Your scp commands will now use SFTP under the hood. The more interesting security change is the new default key exchange, the NTRU algorithm. NTRU is thought to be quantum-hard. Continue reading “This Week In Security: OpenSSH, Git, And Sort-of NGINX 0-day”→
Tesla vehicles have a charging port that is under a cover that only opens on command from a charging station. Well, maybe not only. [IfNotPike] reports that he was able to replay the 315MHz signal using a software defined radio and pop the port open on any Tesla he happened to be near.
Apparently, opening the charging port isn’t the end of the world since there isn’t much you can do with the charging port other than charging the car. At least, that we know of. If history shows anything, it is that anything you can get to will be exploited eventually.
The Cyclops Blink botnet is thought to be the work of an Advanced Persistent Threat (APT) from Russia, and seems to be limited to Watchguard and Asus devices. The normal three and four letter agencies publicized their findings back in February, and urged everyone with potentially vulnerable devices to go through the steps to verify and disinfect them if needed. About a month later, in March, over half the botnet was still online and functioning, so law enforcement took a drastic step to disrupt the network. After reverse-engineering the malware itself, and getting a judge to sign off on the plan, the FBI remotely broke in to 13 of the Watchguard devices that were working as Command and Control nodes. They disinfected those nodes and closed the vulnerable ports, effectively knocking a very large chunk of the botnet offline.
The vulnerability in WatchGuard devices that facilitated the Botnet was CVE-2022-23176, a problem where an “exposed management access” allowed unprivileged users administrative access to the system. That vague description sounds like either a debugging interface that was accidentally included in production, or a flaw in the permission logic. Regardless, the problem was fixed in a May 2021 update, but not fully disclosed. Attackers apparently reversed engineered the fix, and used it to infect and form the botnet. The FBI informed WatchGuard in November 2021 that about 1% of their devices had been compromised. It took until February to publish remediation steps and get a CVE for the flaw.
This is definitely non-ideal behavior. More details and a CVE should have accompanied the fix back in May. As we’ve observed before, obscurity doesn’t actually prevent sophisticated actors from figuring out vulnerabilities, but it does make it harder for users and security professionals to do their jobs. Continue reading “This Week In Security: Vulnerable Boxes, Government Responses, And New Tools”→
