[aleaksah] got himself a Mi Smart Kettle Pro, a kettle with Bluetooth connectivity, and a smartphone app to go with it. Despite all the smarts, it couldn’t be turned on remotely. Energized with his vision of an ideal smart home where he can turn the kettle on in the morning right as he wakes up, he set out to right this injustice. (Russian, translated) First, he tore the kettle down, intending to dump the firmware, modify it, and flash it back. Sounds simple enough — where’s the catch?
This kettle is built around the QN9022 controller, from the fairly open QN902X family of chips. QN9022 requires an external SPI flash chip for code, as opposed to its siblings QN9020 and QN9021 which have internal flash akin to ESP8285. You’d think dumping the firmware would just be a matter of reading that flash, but the firmware is encrypted at rest, with a key unique to each MCU and stored internally. As microcontroller reads the flash chip contents, they’re decrypted transparently before being executed. So, some other way had to be found, involving the MCU itself as the only entity with access to the decryption key.
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.
