We’re always a wee bit suspicious about articles that announce some sort of “World’s first” accomplishment. With a couple of hundred thousand years of history, most of which wasn’t recorded, over which something like 117 billion humans have lived, any claims of primacy have to be taken with a grain of salt. So when the story of the world’s first instance of a car being hit by a meteorite came across our feed, we had to check it out. The car in question, a Tesla, was being driven in South Australia by veterinarian Andrew Melville-Smith when something suddenly crashed into its windshield.
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.
When all else fails, blame it on the cloud? It seems like that’s the script for just about every outage that makes the news lately, like the Wyze camera outage this week that kept people from seeing feeds from their cameras for several hours. The outage went so far that some users’ cameras weren’t even showing up in the Wyze app, and there were even reports that some people were seeing thumbnails for cameras they don’t own. That’s troubling, of course, and Wyze seems to have taken action on that quickly by disabling a tab on the app that would potentially have let people tap into camera feeds they had no business seeing. Still, it looks like curiosity got the better of some users, with 1,500 tapping through when notified of motion events and seeing other people walking around inside unknown houses. The problem was resolved quickly, with blame laid on an “AWS partner” even though there were no known AWS issues at the time of the outage. We’ve said it before and we’ll say it again: security cameras, especially mission-critical ones, have no business being connected with anything but Ethernet or coax, and exposing them to the cloud is a really, really bad idea.
Our first story this week comes courtesy of the Pwn2own contest. For anyone not familiar with it, this event is held twice a year, and features live demonstrations of exploits against up-to-date software. The one exception to this is when a researcher does a coordinated release with the vendor, and the update containing the fix drops just before the event. This time, the event was held virtually, and the attempts are all available on Youtube. There were 23 attacks attempted, and only two were outright failures. There were 5 partial successes and 16 full successes.
One of the interesting demonstrations was a zero-click RCE against Zoom. This was a trio of vulnerabilities chained into a single attack. The only caveat is that the attack must come from an accepted contact. Pwn2Own gives each exploit attempt twenty minutes total, and up to three attempts, each of which can last up to five minutes. Most complex exploits have an element of randomness, and exploits known to work sometimes don’t work every time. The Zoom demonstration didn’t work the first time, and the demonstration team took enough time to reset, they only had enough time for one more try.
BleedingTooth
We first covered BleedingTooth almost exactly six months ago. The details were sparse then, but enough time has gone by to get the full report. BleedingTooth is actually a trio of vulnerabilities, discovered by [Andy Nguyen]. The first is BadVibes, CVE-2020-24490. It’s a lack of a length check in the handling of incoming Bluetooth advertisement packets. This leads to a buffer overflow. The catch here is that the vulnerability is only possible over Bluetooth 5. Continue reading “This Week In Security: Pwn2own, Zoom Zero Day, Clubhouse Data, And An FBI Hacking Spree”→
Robot locomotion is a broad topic, and there are a multitude of choices for the budding designer. Often, nature is an inspiration, and many ‘bots have been built to explore the motion regimes of various insects and animals. Inspired himself by the common inch worm, [jegatheesan.soundarapandian] decided to build a robot that moved in a similar way.
The build consists of a series of 3D printed linkages, with servos fitted in between. This allows the robot’s body to articulate and flex in much the same way as a real inch worm. By flexing the body up, shifting along, and flexing back down, the robot can slowly make its way along a surface. An Arduino Pro Mini is the brains of the operation, being compact enough to fit on the small robot while still having enough outputs to command the multiple servos required. Control is via a smartphone app, using MIT’s AppInventor platform and the venerable HC-05 Bluetooth module.
It’s a fun build, and we’d love to see it go further with batteries replacing the tether and perhaps some sensors to enable it to further interact with its environment. We’ve seen other creative 3D-printed designs before, too – like this spherical quadruped ‘bot. Video after the break.
If you think about building a moving machine, you probably will consider wheels or tracks or maybe even a prop to take you airborne. When [nwlauer] found an earthworm in the garden, it inspired a 3D-printed robot that employs peristaltic motion. You can see a video of it moving, below.
The robot uses pneumatics and soft plastic, and is apparently waterproof. Your printer’s feed path has to be pretty rigid to support flexible filament without jamming. There’s also some PVA filament and silicone tubing involved.
Anyone who worked in the tech field and lived through the Y2K bug era will no doubt recall it as a time seasoned with a confusing mix of fear and optimism and tempered with a healthy dose of panic, as companies rushed to validate that systems would pass the rollover of the millennium without crashing, and to remediate systems that would. The era could well have been called “the COBOL programmers full-employment bug,” as the coders who had built these legacy systems were pulled out of retirement to fix them. Twenty years on and a different bug — the one that causes COVID-19 — is having a similarly stimulative effect on the COBOL programmer market. New Jersey is one state seeking COBOL coders, to deal with the crush of unemployment insurance claims, which are killing the 40-year-old mainframe systems the state’s programs run on. Interestingly, Governor Phil Murphy has only put out a call for volunteers, and will apparently not compensate COBOL coders for their time. I mean, I know people are bored at home and all, but good luck with that.
In another throwback to an earlier time, “The Worm” is back. NASA has decided to revive its “worm” logo, the simple block letter logo that replaced the 50s-era “Meatball” logo, the one with the red chevron bracketing a starfield with an orbiting satellite. NASA switched to the worm, named for the sinuous shape of the letters and which honestly looks like a graphic design student’s last-minute homework assignment, in the 1970s, keeping it in service through the early 1990s when the meatball was favored again. Now it looks like both logos will see service as NASA prepares to return Americans to space on their own launch vehicles. Wait a minute, what happens when we stand this thing upright?
Looking for a little help advancing the state of your pandemic-related project? A lot of manufacturers are trying to help out as best they can, and many are offering freebies to keep you in the game. Aisler, for one, is offering free PCBs and stencils for COVID-19 prototypes. It looks like their rules are pretty liberal; any free and open-source project that can help with the pandemic in any way qualifies. Hats off to Aisler for doing their part.
And finally, history appears to have been made this week in the amateur radio world with the first direct transatlantic contact on the 70-cm band was made. It seems strange to think that it would take 120 years since transatlantic radio became reduced to practice by the likes of Marconi for this accomplishment to occur, but the 70-cm band is usually limited to line of sight, and transatlantic contacts at 430 MHz are usually done using a satellite as a relay. The contact was between stations FG8OJ on Guadaloupe Island in the Caribbean — who was involved in an earlier, similar record on the 2-meter band — and D4VHF on the Cape Verde Islands off the coast of Africa, and used the digital mode FT8. The 3,867-km contact was likely due to tropospheric ducting, where layers in the atmosphere form a refractive tunnel that can carry VHF and UHF signals much, much further than they usually go. While we’d love to see that record stretched a little more on each end, to make a truly transcontinental contact, it’s still quite an accomplishment, and we congratulate the hams involved.
