What the Flock? It’s probably just some quirk of The Almighty Algorithm, but ever since we featured a story on Flock’s crime-fighting drones last week, we’ve been flooded with other stories about the company, some of which aren’t very flattering. The first thing that we were pushed was this handy interactive map of the company’s network of automatic license plate readers. We had no idea how extensive the network was, and while our location is relatively free from these devices, at least ones operated on behalf of state, county, or local law enforcement, we did learn to our dismay that our local Lowe’s saw fit to install three of these cameras on the entrances to their parking lot. Not wishing to have our coming and goings documented, we’ll be taking our home improvement dollars elsewhere for now.
Unitree have a number of robotic offerings, and are one of the first manufacturers offering humanoid robotic platforms. It seems they are also the subject of UniPwn, one of the first public exploits of a vulnerability across an entire robotic product line. In this case, the vulnerability allows an attacker not only to utterly compromise a device from within the affected product lines, but infected robots can also infect others within wireless range. This is done via a remote command-injection exploit that involves a robot’s Bluetooth Low Energy (BLE) Wi-Fi configuration service.
Unitree’s flagship G1 humanoid robot platform (one of the many models affected)
While this may be the first public humanoid robot exploit we have seen (it also affects their quadruped models), the lead-up to announcing the details in a post on X is a familiar one. Researchers discover a security vulnerability and attempt responsible disclosure by privately notifying the affected party. Ideally the manufacturer responds, communicates, and fixes the vulnerability so devices are no longer vulnerable by the time details come out. That’s not always how things go. If efforts at responsible disclosure fail and action isn’t taken, a public release can help inform people of a serious issue, and point out workarounds and mitigations to a vulnerability that the manufacturer isn’t addressing.
The biggest security issues involved in this vulnerability (summed up in a total of four CVEs) include:
Hardcoded cryptographic keys for encrypting and decrypting BLE control packets (allowing anyone with a key to send valid packets.)
Trivial handshake security (consists simply of checking for the string “unitree” as the secret.)
Unsanitized user data that gets concatenated into shell commands and passed to system().
The complete attack sequence is a chain of events that leverages the above in order to ultimately send commands which run with root privileges.
We’ve seen a Unitree security glitch before, but it was used to provide an unofficial SDK that opened up expensive features of the Go1 “robot dog” model for free. This one is rather more serious and reportedly affects not just the humanoid models, but also newer quadrupeds such as the Go2 and B2. The whole exploit is comprehensively documented, so get a fresh cup of whatever you’re drinking before sitting down to read through it.
They’re back! The San Francisco autonomous vehicle hijinks, that is, as Waymo’s fleet of driverless cars recently took up the fun new hobby of honking their horns in the wee hours of the morning. Meat-based neighbors of a Waymo parking lot in the South Market neighborhood took offense at the fleet of autonomous vehicles sounding off at 4:00 AM as they shuffled themselves around in the parking lot in a slow-motion ballet of undetermined purpose. The horn-honking is apparently by design, as the cars are programmed to tootle their horn trumpets melodiously if they detect another vehicle backing up into them. That’s understandable; we’ve tootled ourselves under these conditions, with vigor, even. But when the parking lot is full of cars that (presumably) can’t hear the honking and (also presumably) know where the other driverless vehicles are as well as their intent, what’s the point? Luckily, Waymo is on the case, as they issued a fix to keep the peace. Unfortunately, it sounds like the fix is just to geofence the lot and inhibit honking there, which seems like just a band-aid to us.
The name of this newly discovered vulnerability is BLUFFS (Bluetooth Forward and Future Secrecy), where forward and future secrecy are important terms that refer to the protection of secure sessions against compromise in the past (forward, FoS) and future (FuS). The CVE presentation notes that the Bluetooth specification does not cover either FuS or FoS. In total two new architectural vulnerabilities were discovered, both of which attack the security key.
The Bluetooth SIG has released a statement regarding this attack method. Although serious, it would seem that the core issue is that some implementations allow for encryption key lengths below 7 octets:
Trunked radio systems can be difficult to wrap one’s mind around, and that’s partially by design. They’re typically used by organizations like police, firefighters, and EMS to share a limited radio frequency band with a much larger number of users than would otherwise be able to operate. From a security standpoint, it also limits the effectiveness of scanners who might not know the control methods the trunked systems are using. But now a global standard for encrypted trunked radio systems, known as TETRA, has recently been found to have major security vulnerabilities, which could result in a lot more headache than disrupted voice communications.
One of the vulnerabilities in this radio system was a known backdoor, which seems to have been protected largely via a “security through obscurity” method. Since the system has been around for about 25 years now, it was only a matter of time before this became public knowledge. The backdoor could allow non-authorized users to snoop on encrypted radio traffic. A second serious vulnerability, unrelated to this backdoor, would further allow listening to encrypted voice traffic. There are a few other minor vulnerabilities recently uncovered by the same security researchers who found these two major ones, and the current recommendation is for anyone using a TETRA system to take a look to see if they are impacted by any of these issues.
Part of the reason this issue is so concerning is that these systems aren’t just used for encrypted voice among first responders. They also are used for critical infrastructure like power grids, rail networks, and other systems controlled by SCADA. This article from Wired goes into much more detail about this vulnerability as well, and we all know that most of our infrastructure already needs significant help when it comes to vulnerabilities to all kinds of failure modes.
Thanks to [cfacer] and [ToniSoft] who sent these tips!
There are a huge number of products available in the modern world that come with network connectivity now, when perhaps they might be better off with out it. Kitchen appliances like refrigerators are the classic example, but things like lightbulbs, toys, thermostats, and door locks can all be found with some sort of Internet connectivity. Perhaps for the worse, too, if the security of these devices isn’t taken seriously, as they can all be vectors for attacks. Even things like this Rigol oscilloscope and its companion web app can be targets.
The vulnerability for this oscilloscope starts with an analysis of the firmware, which includes the web control application. To prevent potentially bricking a real oscilloscope, this firmware was emulated using QEMU. The vulnerability exists in the part of the code which involves changing the password, where an attacker can bypass authentication by injecting commands into the password fields. In the end, the only thing that needs to be done to gain arbitrary code execution on the oscilloscope is to issue a curl command directed at the oscilloscope.
In the end, [Maunel] suggests not connecting this oscilloscope to the Internet at all. He has informed the producer about it but as of this writing there has not been a resolution. It does, however, demonstrate the vulnerabilities that can be present in network-connected devices where the developers of the software haven’t gone to the lengths required to properly secure them for use with the modern Internet. Even things not connected to a traditional Internet connection can be targets for attacks.
A lot of talk and discussion happens anytime a hardware manufacturer releases a new line of faster, more powerful, or more efficient computers. It’s easy to see better and better specifications and assume that’s where all the progress is made. But without improved software and algorithms, often the full potential of the hardware can’t be realized. That’s the reason for the creation of io_uring, an improved system call interface in the Linux kernel. It’s also where [chompie] went to look for exploits.
The reason for looking here, in a part of the kernel [chompie] had only recently learned about, was twofold. First, because it’s a place where user space applications interact with the kernel, and second because it’s relatively new and that means more opportunities to find bugs. The exploit involves taking advantage of a complicated asynchronous buffer system, specifically at a location where the code confuses a memory location being used by the kernel with one which is supposed to be used for user space.
To actually get this to work as an exploit, though, a much more involved process is needed to make sure the manipulation of these memory addresses results in something actually useful, but it is eventually used to gain local privilege escalation. More about it can be found in this bug report as well. Thanks to the fact that Linux is open-source, this bug can quickly be fixed and the patch rolled out to prevent malicious attackers from exploiting it. Open-source software has plenty of other benefits besides being inherently more secure, though.
