Is My Unitree G1 Monitoring My Activities?
Security Vulnerabilities in Unitry Robots: The Remote Code Execution Issue
Greetings, everyone. Today, I’m here to discuss a rough day for Jeff the G1 and the entire fleet of Unitry robots, including the H1s, GOTs, B2s, and R1s. Recent discussions around security flaws in these robots have raised alarm bells, revealing a potential vulnerability that allows for remote code execution, affecting not just one robot, but any Unitry robot that can be accessed at close range.
Overview of the Issue
For a bit of background, this isn’t the first time security vulnerabilities have been noted in Unitry robots. A year ago, claims surfaced regarding remote tunneling, which purportedly allowed for unauthorized access from anywhere in the world. However, I found little solid evidence to support those claims, and Unitry dismissed them as overstated.
Today, I aim to provide concrete evidence about the security flaws. As we delve into this, I hope this serves as proof that can be referenced in the future whenever someone questions whether these incidents actually occurred.
What Makes the Current Situation Egregious?
Every Unitry robot features a main board that runs proprietary code, which users cannot access. This main board has Bluetooth Low Energy (BLE) turned on constantly, waiting for connections. The problem arises from hard-coded AES keys that are identical across all units. This presents a security risk since anybody with access to BLE can potentially exploit it.
Initially, users were only intended to update Wi-Fi credentials via Bluetooth. However, some discovered that manipulating these credentials allows for the injection of commands that the robot executes with root privileges. Thus, the situation escalates from poor security practice to a major vulnerability.
Demonstrating the Vulnerability
To showcase this vulnerability, I’m using a device called Unione, which is not affiliated with the manufacturer. I initially believed that the security flaw was patched, but further research proved otherwise.
To demonstrate, I powered up the G1 robot, ensuring it was offline (no Ethernet connection and the remote was switched off). The boot-up sequence began, indicating that Jeff was ready for action.
I proceeded to run a script, hack.py, which injects commands through the Wi-Fi credentials section. By leveraging this BLE vulnerability, I successfully executed a reboot command, demonstrating how easily remote code execution could occur.
The results were immediate; the robot rebooted as commanded without any direct connection via Wi-Fi or external networks. This showcases a concerning level of control that any nearby individual could exert over the robot.
Implications of Remote Code Execution
The consequences of such vulnerabilities are significant. If anyone can execute arbitrary commands on these robots, they could potentially brick them or commandeer them for malicious purposes. This is compounded by the fact that there are ongoing high-profile robot conventions where demonstration robots are utilized.
Unitry’s response to these claims has been inadequate, reiterating that their products are designed for offline use. However, this contradicts the facts; the first setup step for the G1 involves connecting to an app that requires internet access to update Wi-Fi credentials. Thus, their assertion that robots don’t need to connect to the internet is misleading.
Addressing Persistent Telemetry Issues
Another point of contention lies in the claims around persistent telemetry, which suggest that robots continually send data back to the manufacturer. Unitry acknowledged user concerns but has not satisfactorily addressed the underlying issues leading to remote code execution.
The telemetry claims raised legitimate concerns about user privacy and data security. While telemetry is a common feature in many consumer electronics, it must be opt-in with clear user consent and transparency about what data is collected.
Moving Forward
As a concerned consumer and observer of this situation, I’m looking ahead to future developments. I’ve pre-ordered a robot from Kscale, a competitor, and it promises to be truly open-source, offering transparency and access to the code, which I believe is essential in today’s climate.
Unitry is at a crossroads, trying to balance proprietary technology with the glaring security flaws that could tarnish their reputation. They need to address these vulnerabilities and regain users’ trust, not just to protect their products but to ensure user safety.
Conclusion
It’s disheartening to see issues like this emerge in a once-promising platform. As new data comes to light, it’s crucial to hold companies accountable while advocating for more secure, open-source alternatives. If you’re a Unitry robot owner, staying informed and cautious is essential in navigating these vulnerabilities. As we proceed, the onus remains on manufacturers to deliver on their promises of security and transparency.
#Unitree #Spying
Thanks for reaching. Please let us know your thoughts and ideas in the comment section.
Source link
About The Author
🎉🎉🎉 Thanks for the video!!
Make that awesome humans go back since the beginning for active subscribers!
klanker router
This is literally the plot to Atomic Heart btw if you think it's intentional which likely not but still
1. USSR or China in this case makes a bunch of cheap robots
2. Sells them to west and they buy them for some reason and for some reason puts them near important stuff
3. Have plan to execute order 66 on them <– You are here
4. Brain inplants same idea
5. Some random person goes rogue and executes order 66
6. Choas and pandemonium
people are going to spin this as "nefarious Chinese company beholden to the CCP is spying on us" when actually it's just cybersecurity incompetence. I work with hardware security, I've hacked on several IOT devices. These types of bugs appear on products from American companies all the time and no drama is created regarding "NSA hacked all Kindles" or whatever. It's just part of the reality of putting internet in everything and especially prevalent when a company does not value cybersecurity of the products they ship. Unitree definitely needs to step up their game. Regarding the "exfiltrated data", there's absolutely nothing out of the usual about the data they are sending to their servers. Very innocuous and even very mild compared to some of the data other companies (American companies) gather and send from their devices.
answering your points. 15:20 "how can they update this" "anyone can MITM your device becuase the AES keys are hardcoded". An OTA (over the air) firmware update should fix this. Both by them not using hardcoded AES keys anymore and also fixing the incredible command injection over BLE. 19:20 I don't see the problem with their justification. You are connecting the robot to the web (via your adhoc network). As they state it's not a necessary function for the robot to connect ot the internet; but yes it will send telemetry when it IS connected. EVERY device does this, your Kindle does it, you phones do it, etc. I haven't hacked the Unitree but have hacked other IOT devices like I mention on my previous comment. And from the data mentioned on the paper, Unitree is actually very, very tame in terms of data collection. I guarantee your e-book reader, or your Windows, is capturing more data than that. 34:56 you can't tell because it's encrypted data (TLS). at least here they are using good practice and using TLS. 35:35 could be stuff like just acknowledgements (as you suggested), could be an update to adress lists, replies to requests from the robot (like queries about any existing firmware updates available), etc.
Now you can see why my comment a few weeks back about you interacting with this robot with those swords in your back was not so much of a joke. You are an early adopter of extremely capable, on-the-air receiving commands/updates, made-in-china tech being put in production as soon as possible due to internal competition there.
A lot can go wrong. Be extremely cautious, Harrison. We cannot afford to lose you!
you need to mod the g1 to have a physical on off switch for wireless it should be " easy" to do ,, do not rely on software switches on any device
Is this unitree's doing or the company from whom they bought their boards?
oh Jeff…
I would definitely consider disconnecting the Bluetooth module now that this is in the open. The telemetry could be just debug data accidentally left in but…. Stil very worrying.
when are you taking your robot to feed the chickens and chase the squirrels away and actually do shtt on your farm?
do you remember when new iphone was hacked time and time again? it will take some time to patch all the vulnerabilities. there are probably much more to discover. by the way, i miss charles so badly. mucho more fun than this robot. i know charles wont make it into the future as this robot will but it just was so fun … connta talk to my pillow….
isn't an injection attack like hacking 101 ? real sloppy unitree
It's gonna be if police need video footage of it, they will get it
my G1 speaks Chinese sometimes… everything’s probably ok.. guess I just got a learn it myself lol
Great we’re going to get remote controlled block chain kill bots 😅
Can you use it with a mocap suit? I wanna buy one to my moms place and then I can hug them sorta in person
What can possibly go wrong here…
Unlike a phone or PC the robot could actually physically harm you. Having closed off firmware is unacceptable, it must be open source, if you can't audit or patch the robot, you don't own it. I really hope to see K-Scale labs grow, Unitree is not a safe platform to build on.
The hand sequence sounds like home mode
Can someone please lay out a plausible worst-case scenario? Physical danger?
Were I a G1 owner, I'd do the following:
1 Create a sort of preflight procedure to run through on initial setup, and after each software, firmware, or hardware update. This would detect and identify all connections, wired or wireless, and attempt to identify exactly what data is being transmitted to or from the device.
2 Create a separate but similar procedure to go through at the start of each development session.
3 I'd take steps to non-destructively disable BT on the device, and perhaps WiFi too unless I need it for something.
4 I'd disable BT on all other devices within connection range of the robot for now. Or if that wasn't practical then I'd move the robot to a workspace out of range of all the other devices.
send them to WhistlinDiesel he'll kill it.
This the real sexy part of deep learning
It can be safely assumed that there will be robot crimes in the future made by hackers remotely altering your robot.
All this stuff with robots and AI is developing so fast that companies make a lot of mistakes. Everybody has so much FOMO that they willingly release PoCs and development previews as products. Its so dangerous 😬.
Its not AI that will destroy us, its the greed and impatience of humans.
How do u even fuck up so bad that bluetooth command does rce 🙈
Being able to know THAT its a g1 should already be clear from the usually static service uuids tho 🤔
U have rce u can absolutely decrypt those requests if u exfiltrate the tls private keys 🤔 , no ?
Yikes
So if I understand this right, anyone that's nearby can use an always-on bluetooth to change the wifi credentials, which in turn means that:
1a) they can also inject / execute arbitrary shell code (as root) due to a security vulnerability caused by no input sanitizing
1b) they can force it to connect to their own network / access point (e.g. mobile hotspot, portable router, etc)
2) when the connection to said wifi happens, some data (likely telemetry) is emitted to some remote server, and from the server
3) not much can be done, since the whole system is tightly closed down (😢), and any updates can also be man-in-the-middle'd
And the company is downplaying & ignoring at least some of the above. Sounds like a great proposition! /s