Developers of the entertainment unit in the Hyundai Ioniq didn’t seem to follow the sample code they were using. They reused an RSA code-signing key pair from an example, rather than generating their own.
It’s another class of software supply chain vulnerability—albeit one caused by error, rather than malice. But it’s still a vulnerability, allowing bad actors to socially engineer malware into cars.
It’s only the entertainment unit, right? But it’s a Linux computer with full access to the car’s critical CAN bus. In this week’s Secure Software Blogwatch, we’re frightened by the implications.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: The ending.
Hyundai: ‘Leading by example’
What’s the craic? Thomas Claburn reports—“Software developer cracks Hyundai car security with Google search”:
“Hyundai used a public-private key pair from a tutorial”
"greenluigi1" wanted to modify the in-vehicle infotainment (IVI) system in his 2021 Hyundai Ioniq. … After trying to figure out how to customize firmware updates for the IVI's D-Audio2 system, made by the car company's mobility platform subsidiary Hyundai Mobis, and have them accepted by the IVI, the unidentified car hacker found an unexpected way.
…
But it wasn't going to be that easy: Some part of the supplied data, at least, would need to be cryptographically signed using an RSA private key, and the car hacker didn't have it. [He] found within the firmware image the RSA public key used by the updater, and searched online for a portion of that key. The search results pointed to a common public key that shows up in online tutorials.
…
This means Hyundai used a public-private key pair from a tutorial … allowing "greenluigi1" to track down the private key. Thus he was able to sign Hyundai's files and have them accepted by the updater. … Hyundai has not responded to a request for comment.
What’s the appropriate emoji? Daniel Feldman—@d_feldman—has an opinion:
In which a blogger finds the private key used to sign Hyundai car software updates—by Googling it. They used a key pair from a popular tutorial. 😂😂😂
…
They also used a different key (symmetric) from a NIST reference document. This is not what “industry standard encryption” means. 😂
Horse’s mouth? greenluigi1—“How I Hacked my Car”:
“I now had root access”
Last summer I bought a 2021 Hyundai Ioniq. … I wanted to play around with it and ultimately see what I could do.
…
I could enter its Engineering Mode by going to the Software Update screen. … The logs turned out to be a treasure trove of information. … The firmware files came in a simple .zip file that contained another zip file. The inner zip was named enc_system_package_{version}.zip. … I found a shell script file called linux_envsetup.sh … the script that creates the system update. … Turns out the encryption key in that script is the first AES 128bit CBC example key listed in the NIST document SP800-38A. … After searching for some keywords like “RSA” I found the public [signing] key. … Oh! they used a very common key yet again.
…
I wasted no time in developing my own firmware update with a backdoor. … I ran whoami: … I now had root access to a cool new Linux box, so now I must develop software for it.
So, two keys from example code? Bruce Schneier scoffs—“Hyundai Uses Example Keys”:
This is a dumb crypto mistake I had not previously encountered.
How does something like that happen? fxtentacle speculates:
“Illusion of security”
My personal guess would be that some manager successfully "reduced costs" and got a big promotion and bonus payments by outsourcing all of the development to the cheapest company they could find: … It was likely outsourced to college graduates with no practical experience.
…
[And] most likely the hardware design shop … sent them a firmware example. But management and oversight is in … South Korea. Thanks to that 3-way language barrier, I'm pretty sure the supervisor on this project had no actual clue as to what the hardware and software were doing.
…
In my imaginary set-up … for everyone involved, the illusion of security was "good enough". So here we are, with "good enough" in production.
But seriously, though? This Anonymous Coward has seen it all before:
I have known several contractors and employees who have provided solutions like this (without the documentation to change anything). All have since left the company with glowing references for finding such a "quick, brilliant solution." … You can guess who fixed it, with little to no recognition. :-|
…
Non-technical IT management always like people who do a quick job. Then they give them big pay rises to try to keep them when they threaten to go elsewhere. In the meantime the same management want to know why [I] take so long fixing problems — which were created by the quick-fix merchant's bodges.
Lessons to be learned? u/Terrible_Machine9 sees the irony:
A lecturer will take this article and use it for their first day of school—to highlight the importance of doing your research and looking stuff up to find the solution to a problem.
The moral of the story? lurker has not one, but two:
1. Hyundai seem to have taken all the usual steps to avoid unauthorised entry, then do a version of “password” as their password.
2. Google seems to be doing nicely in their effort at “indexing the world’s information.”
What if Hyundai decides to shoot the messenger? That’s what’s worrying aeno:
How long until they try to sue his ***? The whole story sounds so … stupid, I can't believe no one in the whole production process stood up and said "Wait, shouldn't we make our own keys for encryption?"
…
Honestly, how can they be so stupid?
Importantly, u/NCGThompson asks all the important questions:
The important question is, will using this void the dealer warranty?
Meanwhile, La Gris feels the need to quote Grey’s Law:
“Any sufficiently advanced incompetence is indistinguishable from malice.”
And Finally:
Is this the end for Bill Wurtz?
You have been reading Secure Software Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or ssbw@richi.uk. Ask your doctor before reading. Your mileage may vary. E&OE. 30.
All Stories
Software Supply Chain Security
Dev & DevSecOps
CI/CD Security
Container Security