Software developer cracks Hyundai car security with Google search A developer says it was possible to run their own software on the car infotainment hardware after discovering the vehicle's manufacturer had secured its system using keys that were not only publicly known but had been lifted from programming examples. An unidentified developer posting under the name "greenluigi1" wanted to …
You could run the John Deere version of Doom that was hacked into the Deere "infotainment" (?) console. Take your Ioniq down to the farm and do a paired session!
Classic. There's following the steps in a tutorial EXACTLY, and then there's actually bothering to try and understand what it's really telling you by also applying your brain when reading it. I wonder if this tutorial example made its way onto Stack Overflow, and if so how many other systems have been "secured" the same way...........
and then there's actually bothering to try and understand what it's really telling you
But the whole point of using cut&paste is it saves you the bother of having to actually understand what you're doing.
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", and 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 Muggins takes so long fixing problems - that were created by the quick fix merchant's bodges.
The number of published exploits for weak RSA key pairs is impressive. People re-use key pairs across lots of devices. They use pairs where the primes are too close, so the product can be efficiently factored using Fermat's algorithm. They use pairs where one (or both) of the "primes" is actually composite. There was the Debian broken OpenSSL (a Debian maintainer "fixed" a compiler warning that resulted in low entropy in the CPRNG pool) that, for two years, produced predictable RSA pairs. People use small "export-grade" keys long after that's been required for anything. And so on.
Or people bungle RSA in other ways, such as using a message that's too small or too large; or encrypting the same message multiple times with different keys (using the same exponent), leaving it vulnerable to the CRT. They don't pad properly. They use the same key pair for signing and encryption. And so on.
Cryptography is hard. I've studied it for a couple of decades, and I read a lot of articles about it, but I still don't roll my own implementations – not just of primitives, but of higher-level protocols. And where I need to use it (through a vetted library), I always review authoritative sources on proper use and pitfalls, just to make sure I haven't forgotten something.
The problem in this case seems to be that Hyundai couldn't be bothered to find someone who knew at least enough to be aware of the dangers, or care about them.
There was a case where the RSA private keys in routers had one of their two primes in common. In that case the common factor is calculated as a gcd, and we get the other factor of each key with one division.
And then someone wrote an algorithm that given a billion private keys with primes reused occasionally can find them all in reasonable time.
They probably recruited someone who said they were an expert in the subject - and without getting a technical vet by someone who was an expert.
The problem with expertise is it is often self-assessed. Those who confidently think they know it all - get the jobs. Unlike those who know that the more you know - the more you know you don't know.
This is an ancient problem. Way back in the early '90s I attended a presentation by the CEO of one of the largest tech recruitment groups. At question time I asked him: "do clients ever ask you to identify individual excellence in candidates?"
He responded "No, they never ask for that".
They still don't. What's wanted is low cost labour that doesn't rock the corporate boat, and the result is reduction to the lowest common denominator, which is why 'Dilbert' is funny in a rather sad kind of way.
It's actually really difficult to hire competent engineers. The best engineers on the planet get paid enormobucks for working with ad slingers, social networks, tat stores, and iGear. The next best work on robotaxis, food delivery and crypto. By the time you get down to "building infotainment for Hyundai", its people who can google and just about follow along.
Yes Hyundai could pay more and get better, but they can't compete with Meta paying $350k.
"This just shows security and cryptography are too difficult for the mediocre programmer"
Not just security and cryptography, nor just 'mediocre programmers'
"keys that were not only publicly known but had been lifted from programming examples"
As silicon becomes ever more dependent on soft configuration, it's become amazingly and frustratingly common to find release code containing fragments directly copied and pasted from the example code in chip manufacturers' device data sheets. This is of course not programming' in the true sense - it's 'mashing' - and it often goes horribly wrong. But it seems to be the 'way forward' judging by the evidence, despite the accidents it can precipitate..
Too difficult?
How difficult is it to follow
Generate key pair
Load private key into decryption module.
Upload module to ECU.
Then when the time comes.... Zip file to memory with public key
Call decrypt, check signing.
Even if I do use stack overflow to copy the code from, I do know to generate my own keypair rather than use the example pair
All this says to me is that Hyundai outsourced the programming to the cheapest job shop they could find and took their word for it that the code was right.
Zip file to memory with public key
If you're encrypting your entire firmware image with an asymmetric algorithm, You're Doing It Wrong. If you're using the same key pair for signing and encryption, You're Doing It Wrong.
If you're decrypting before checking the verifier (signature, MAC, whatever), You're Doing It Wrong (per Moxie Marlinspike's Cryptography Doom Principle).
In other words: it's pretty difficult. True, copying keys from public sources is either extremely dumb, or a sign that the developer didn't give a damn, or that someone was supposed to change them and didn't. But actually implementing cryptographic protocols correctly on top of primitives, even if those primitives themselves are used correctly, is not easy.
Not at all.
There is a large aftermarket tuning industry that uses exactly these kind of security holes to allow car owners to repair, modify and customize their own vehicles.
Bizarrely, official car importers even employ these companies to tune engines for local emissions compliance because the vehicle manufacturers won't hand over the encryption keys.
Every time some "security expert" cracks a vehicle and makes a lot of fuss about some imaginary hacker threat, the manufacturers have a crack down and it becomes a lot harder for those of us who work in this industry.
Make no mistake, the far bigger threat to car owners is that the manufacturers will improve their security to the point where they can prevent independent garages from working on your car and lock you into high servicing costs.
Which is probably why the prices of second hand and older cars is currently heading through the roof. Many people are fed up with the unreliability of the electronics in modern cars, and are turning to older models with little or no electronics. Just seen an advert for a 1970 Ford Escort Mexico for £55,000 on ebay.
So someone basically pulled the sample code and keys, whacked it in and due to staff cuts and cost cutting at the dev and QA teams, what few QA team people were left or not out sick with COVID, no one checked the code properly! Classic!
Always do a key search on Google, Github and especially Pastebin just to at least try to make an effort to be sure your keys have not been plastered everywhere OR some numpty didn't rush the code through dev, uat and then prod without proper checks. That would solve 80% of these stupid problems in just 5 mins of quick searches before you even do a more thorough check by asking the infosec team to help you out.
This is not a problem if you search for the public key of an asymmetric key pair.
Though, frankly, I don't see this as necessary. If you have some person in a gatekeeping role who's supposed to check to see if the keys are already "known", just replace that step in the process with generating new keys. The odds of generating already-used keys are vanishingly small, assuming a correct and uncompromised key-generation system and adequate entropy pool – and if you don't have those, you're probably already in bigger trouble.
Google has analytics where you can check how often a term is searched. Not to mention your browser plugins that have access to read the URLs you visit There is definitely some risk in searching for your private key on the internet. It is called private for a reason.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
