You can buy (on the usual dodgy places) a briefcase with a multi-car unlocker which will unlock lots of different cars if turned on in a car park, allowing you to then empty out the contents of any car that does then unlock.
And since there is no smashed window, insurance won't pay out either.
Replay attacks like these won't work for what happened to you, most likely the manufacturer of your car opted for an insecure unlocking protocol (i.e. a static key programmed into the remote) that's easily brute forceable. These were common for ages, and I don't understand why (especially technical) people trusted wireless unlocking technology.
Modern systems have some form of protection against brute force and replay attacks but personally I don't trust them.
It's not like keys for pin tumbler locks are very secure either.
I think the main drawback of wireless unlocking is that hacking it is less conspicuous. If you have a device that can unlock a car in 10 times the time it takes with the legitimate key that looks suspicious if you spend that time holding an object to a keyhole, it's completely unnoticeable if you stand a couple meters away on a parking lot doing it wirelessly. Even worse with a method that works on 10% of cars: with a physical keyhole you go from car to car, looking very suspicious, with a wireless device you just stand there and go to the first car that unlocks.
Picking a car lock without setting off a loud alarm is a huge hassle and with the right setup it'll probably leave marks of entry at least. I've seen enough LPL videos that I trust physical car locks as much as I do house locks.
I agree with the inconspicuousness of wireless hacking, but I wouldn't even call it the main drawback: the main drawback is that many insurance companies won't pay a dime if there are no signs of entry at all. Break a window, steal an entertainment system, and the original owner probably gets some money for window repair and a new part. Do the same thing digitally and the insurance company will probably tell you to pound sand.
That would be hard-coded on the vehicle side, but this looks more like a simply signal jammer that is described in this attack. They simple jam the RKE Lock command when you're leaving your car, you don't pay attention to the light signalization for the successful Lock and move on. They come and still anything valuable from the inside.
25 years ago, a (then) friend had a nice car, bought it new. IIRC it was a BMW. He was hypervigilent about its condition. One night some thieves broke into his car and did some damage. Replacing the window wasn't a worry -- that can be replaced good as new, but they had put some dings in the hood somehow.
He was worried that insurance wouldn't replace the hood but would just pay someone to try to knock them back into shape, which was unacceptable to him. So he went and bashed up the hood himself with a bat. The insurance claims guy came out to inspect it and said: we'll replace the window and we'll have a shop hammer out out the damage in the hood.
The technique described is a replay vulnerability. The attacker must record you unlocking your vehicle. What you describe sounds different, but even more scary.
Isn't it potentially a replay attack the poster is describing?
In a simple form it seems like this:
The attack is you have a briefcase that contains specific RF transceiving components in it. You turn the brief case on in a hidden place, leave it, it records data, you come back to it later, and then press a button(s) that replays those RF signals.
Perhaps, there's some very weak cars that don't even need a replay, but are vulnerable to a master key, or bruteforce, or something else.
And since there is no smashed window, insurance won't pay out either.
If you have comprehensive insurance (which is what would cover a stolen car), they'll pay whether or not it was broken into, you left the keys in it, or even if you left the engine running while unattended.
As long as you have comprehensive coverage, you can file a claim if your car is stolen while left running. Comprehensive can still pay to replace your vehicle if it's stolen while your keys are inside it or if you left it running.
Car insurance won't pay for any personal effects stolen from the car, that would be covered by homeowners insurance, but as long as you have a police report, they'll cover it. I had a bicycle stolen from my (unlocked) car while parked in a garage -- homeowners insurance just asked for the police report, then sent me a check for the bike. They d
While it won't be true for all and can often be configured, many keyless entry systems nowadays lock the doors once key leaves vicinity of the car whether you remember to lock the doors or not.
Fundamentally, a cryptographic system that allows a key fob to authenticate itself with one-way communication to a car and does not require a real-time clock in the key fob is hard and maybe impossible to get right. One can certainly do better than what Honda did, but anything that checks all the boxes one would like needs some way to prevent replay even over many keypresses with no successful unlocks, and that needs either something visible to the car to change when the owner presses the button 100 times far away from the car (e.g. the time) or needs a form of communication in which the key isn’t simply broadcasting bearer tokens to the world.
These are another case where the sound engineering principle of KISS is forgotten. First introduce a more complex solution, find that it's broken, then keep adding more and more layers of complexity in the hardware, software and protocol to try to patch the problems that the initial complex solution introduced.
Meanwhile, my Honda has a physical key without a transmitter and the car has no receiver. There's nothing to intercept and I can go swimming with the key with no ill effect. No batteries to replace and if I need a new key it's $5, not $400. It's a brilliantly simple solution!
So someone can pick a lock on your door and hotwire your car and steal it. But with this attack they can only get access to the car. Hotwiring if there is an immobilizer is not possible.
Sure they can, but as pointed out elsewhere in the thread you have to physically go to the car and jimmy the locks to break in, which can (depending on circumstances) attract attention.
Attacks which can be performed by sitting a safe distance away while pretending to do something else can be more widespread as there's so little risk to the attacker.
Yup, but the real problem here is the chosen re-synchronization strategy of the Rolling code when de-sync occurs (performed by the BCM/vehicle) that is done in backward. This is described in the article, but most of the comments here seem not to read the details.
Also Honda does offer bidirectional fobs, that make this attacks a lot harder (still not impossible if the same resync strategy is used)
I would argue that both problems are real. Yes, Honda’s resynchronization system is very weak, and a good system would require the owner to actually repeatedly press the button to resync and/or should only ever resync forward. But one-way protocols are also inherently vulnerable to long-range replay attacks if the owner can be convinced to push the bottom near the attacker even if they’re far from the car, and this is not really excusable for a device costing at least $10 (retail) talking to a car that costs thousands of dollars. A microcontroller with a bidirectional radio is cheap. Heck, an NFC device communicating using backscatter modulation that works with no battery is cheap enough for this application. You can find them in disposable subway tickets!
What is a bidirectional fob doing resyncing at all? There is absolutely no need for any sort of state in a bidirectional if any reasonable protocol is used. The fob should not even need writable nonvolatile memory.
1) long range replay attack are what is a real issue, and is solved by bi-dir fobs. Only thing keeping them out of the market as a default is price. Issue described in the article is far less of a concern than what you mentioned, I put it in the category of Intel's Spectra - where if you already have such physical access to the device/CPU, there are easier ways...
2) Price - just the MCU is more than 10+ USD. Those MCUs are basically ASICs with a lot of stuff integrated (plus - automotive rating). Precise and stable OCX doesn't come cheap either...
3)There is no single chip solution in the automotive market that would integrate all functions (LF Rx, RF Tx+RX, transponder Rx+Tx). Additionally, RF bi-dir + passive LF is power hungry, and getting a year out of your standard CR2032 forget about it - so a more expensive power source needs to be used...
4)NFC is basically just only one of the aforementioned functions - similar to transponder Rx+Tx.
5) Oh it needs writable nonvolatile memory for a lot of reasons... - configuration to cover different vehicle/market/protocol variants, DTC, Secret Keys for pairing, unless you want your fob replacement price to skyrocket...
Regarding fob price - keep in mind it's not just the electronics, although automotive MCUs have harder requirements to satisfy (op. range of temperature, voltage, very low quiescent current, very low ppm failures). Mechanics are expensive, although deceiving when you look at them. Keep in mind they go through some pretty nasty tests - including (and I kid you not) a washing machine test - basically testing if it will survive a washing machine.
Why is it not a schoolbook example of public key crypto?
"I am fob", "Checks out, I am car", "Checks out, please open", "Ok".
Add some details such as nonces but not nothing out of the ordinary compared to things like mTLS or mobile phones that we use every day. What am I not seeing?
Your example involves two-way communication. These cheap key fobs are one-way. It’s more like:
(Press button) “hey, I’m the fob!”
(Press button) “hey, I’m the fob!”
There’s no communication back from the car because these systems are physically incapable of it.
Also, without some elaboration, your example is vulnerable to a replay attack too, but it’s not conceptually hard to fix. A simple arrangement that probably works (but would want a proof!) is:
“Hey, I’m fob #123”
“Hey fob #123, I’m the car. The challenge is abc. Answer after 5ms.”
“Hey car, HMAC(‘abc’, our secret) = ‘xyz’)”
And the car answers and also checks that the answer was received no more than 5.0000001 ms later. There are more clever variants of this sort of thing in the literature, and I don’t think cars use them because the manufacturers don’t seem to care. (The main problem with the scheme above that I’m immediately aware of is that it requires very good timing. If the microcontroller in the fob takes nearly 5ms to calculate the MAC and the goal is 100ns of allowable latency (100 ms is about 100 light-feet), then the timing precision needed is 20 ppm. Getting precision that good on a cheap key fob may be challenging. For that matter, getting that level of precision in the car, which may be rather hot, may cost more than the manufacturer wants to pay. More clever schemes don’t need this kind of precision. Also, my silly scheme has the fob broadcasting its identity every time a button is pressed, which isn’t great.)
Of course, hence "nonces and stuff", but that's nothing out of the ordinary compared to what we use every day.
I am surprised these things contains no receiver. Receiving is the easy part in a transducer, and there commercial off-the-shelf solutions to this for about a dollar. But that would explain it.
RSA SecureID has been doing this for decades and decades. They use a not-tremendously-accurate battery backed quartz RTC with some drift compensation built into the server side.
There are a ton of other options though. Atomic clock signals are broadcast nationwide in the US. GPS, Glonass, etc. signals broadcast the time. Cellular networks broadcast the time.
It's unclear if the authors actually responsibly disclosed this, although they did make some attempts at contacting Honda, it's unclear how long they waited for a reply.
> What does Honda think about this Rolling-PWN Bug?
> We have searched through the Honda official website, but we can not find any contact info for report Vulnerability. Seems Honda motor DOES NOT have a department to deal with security related issue for their products. And a person who works at HONDA has told us "The best way to report the Honda vulnerability is to contact customer service". Therefore, we filed a report to Honda Customer service, but we have not get any reply yet.
Is the obligation to find a security disclosure contact really on an individual researcher who already did free work for them, or is it on Honda to make it easy? I do not blame them at all.
If corporations deprioritize security, that doesn’t mean we should shift responsibility onto individuals.
What would the illegal part be in this instance? They're not illegally accessing Honda's services, which is what most security researchers can end up sued about. This is a local replay attack using the researcher's own hardware. I don't see why they would possibly need to inform Honda first.
Responsible disclosure for issues like these is more of a curtousy to show good intent and to protect people by allowing the manufacturer to roll out patches. Honda doesn't seem interested in protecting their customers and they seem unwilling to get into contact with these people, so if it's true that they tried to contact Honda, that's enough of a curtousy for me, at least.
> What would the illegal part be in this instance?
I don't know exactly what country they're located in, but I'm assuming that filming yourself unlocking random peoples car in the wild can be classified as breaking into something, especially if a corporation would like to hide a story and have government contacts they can engage in the silencing.
I don't see anything wrong with what they did, they went above and beyond to test Honda's systems for Honda, in exchange for nothing. But I do worry about courts not being as technically adept as me, and not seeing it like this.
Opening random cars is probably a crime, but do we have reason to believe they weren't testing on their own car?
They go out of their way not to make the details public to prevent car theft so I think any decent court should see that they're operating in good faith. A bad court may sentence them regardless, but I don't think responsible disclosure would've helped them in that situation either.
> Opening random cars is probably a crime, but do we have reason to believe they weren't testing on their own car?
Yes, we do, since one of their videos are labeled "field test" which I presume means "testing random vehicles found in the wild".
> We have successfully tested the latest models of Honda vehicles. And we strongly believe the vulnerability affects all Honda vehicles currently existing on the market. Please see the field test video down below.
> so I think any decent court should see that they're operating in good faith [...] A bad court may sentence them regardless
I hope so too, for the sake of the authors. Overall, they did the only thing they could do in this situation, since Honda doesn't seem to be receptive to security disclosures at all.
Given that the author(s) live in China and has been doing similar tricks for like, forever. I don't think most of the "crime" or "court" things in this thread make any sense to them.
Yup, not necessarily good, just I don't see them in immediate trouble.
Laws are lacking for these cases in China, OTOH you don't face fair judgement if someone decided to f-u :( see WooYun[1] for an example. tl;dr China had their own HackerOne/BugCrowd and it's even founded earlier than both, only to have it killed in 2016 because it annoyed the wrong guy.
You might could get them on unauthorized access to a computer system, but I believe this would technically fall outside most places' law regarding breaking into a vehicle since they didn't actually open the vehicle.
But that's a criminal matter, in a crime that doesn't target Honda. Getting police to prosecute that without naming any victims would he hard, if it's even legally possible in their jurisdiction. Getting anywhere would involve some legwork from Honda to find the victims, and convincing the relevant parties to prosecute, before you get to a court case at all.
Looks like they published various videos of them exploiting the vulnerability in public space. Supposedly, OSINT techniques could at least uncover these locations.
CVE-2021-46145
The keyfob subsystem in Honda Civic 2012 vehicles allows a replay attack for unlocking. This is related to a non-expiring rolling code and counter resynchronization.
I have a 2013 Honda Civic Si (USA) and it does not have a keyless start system (you have to put the key into the ignition to start it). Also, like any manual car I've driven, you have to press the clutch in or it won't start. To unlock, a button on the keyfob must be pressed. As far as I can tell, this means my car is not affected but I'm not sure. If it's not, then the statement that it affects all Hondas after 2012 is incorrect.
Yeah I suppose that's one way to do it. I go for the combo of having a garage and driving a manual, which is itself a theft prevention device in the US these days
Also, like any manual car I've driven, you have to press the clutch in or it won't start.
This is such an infuriating trend in modern cars, especially hybrids. I can never tell when the damn thing is done starting up so at least ten percent of the time I take my foot off too early and it just goes "Try again, bitch."
Dude RKE is not the keyless you think, your probably thinking of passive keyless. This is pressing your LOCK/UNLOCK button, and if you have buttons on your FOB than you have this issue.
"Honda has no plan to update older vehicles at this time"
Could this be legal? What would happen if your car is stolen because of that? Under french law, I think that it would be a "hidden defect" that the manufacturer has to cover for.
That's from earlier this year (CVE-2022-27254), hopefully they changed their mind as of late (however, seems unlikely). If not after that incident became public, maybe by now when even more vulnerabilities are becoming public.
> After each keyfob button pressed the rolling codes synchronizing counter is increased. However, the vehicle receiver will accept a sliding window of codes, to avoid accidental key pressed by design. By sending the commands in a consecutive sequence to the Honda vehicles, it will be resynchronizing the counter. Once counter resynced, commands from the previous cycle of the counter worked again. Therefore, those commands can be used later to unlock the car at will.
Could the counter and clock resynchronization schemes in RFC 6238 "TOTP: Time-Based One-Time Password Algorithm" and RFC 4226 "HOTP: An HMAC-Based One-Time Password Algorithm" have similar bugs? In implementation if not in principle?
Does anyone know if it's actually common for these vulns to be exploited by thieves?
I've heard of people using amplification attacks where they simply amplify the key fob from a distance (https://cbsaustin.com/news/local/car-thieves-are-hacking-key...), but using a replay exploit like this seems like it's a lot less common. Lately the big thing locally (south central Texas) has been catalytic converter thefts more than stealing anything inside the car though.
One can only hope that it's these sort of events which slowly pushes to having more legislation and responsibility to the provider of digital services (i.e., Honda) if things go wrong (e.g., goods inside or even vehicle stolen).
While I am 99% sure the politicians will write crappy legislation, over time it should become better and ensure that the purveyor of compromised SW is responsible for their sloppy work. It took decades but seatbelts, crash tests etc etc made us all massively safer when driving and we probably need the same minimum across some digital services.
For example, one person claims that such a vulnerability means that the insurance company won't pay, for it leaves no smashed windows if you are robbed.
However, all it takes is one person going to court, publicizing it enough, and winning against the insurance company.
What happens? The insurance company, naturally, starts to increase rates for owners of that brand of car.
It has to pay out more often, for that car has a weakness, and this is the result.
This has happened before, with cars that didn't have physical steering wheel ignition locks, back in the 80s.
The result? Sales dropped for those cars, no one wants to pay 50% more for insurance, and manufacturers quickly worked to fix the issue.
It's a sad thing though, to see a relentless stare at the daily, short term bottom line, without thought to other factors, and long term profit.
Way to drive away customers, and crash a reputation! Brands to steer clear of, to be sure!
>The result? Sales dropped for those cars, no one wants to pay 50% more for insurance, and manufacturers quickly worked to fix the issue.
In all cases the margins were razor thin. Poorly equipped cars were stolen marginally more and likewise cost a trivial amount more to insure.
But personal new car buying is 500% driven by consumers using emotion driven logic to magnify tiny differences so sales dropped, somewhat, maybe. It's hard to separate this from the variable of older products and cheaper products generally selling less well than the new hotness. Column locks went on to become standard as OEMs refreshed product lines and did mid-life facelifts.
Same thing happened when EMV was first rolled out. There was replay attack fraud, but the cardholder was blamed for it. But once you get enough complaints, it forces insurance and gov oversight into action as you describe.
Article from Brian Krebs on EMV implementation issues back in 2014 timeframe for example:
https://krebsonsecurity.com/2012/09/researchers-chip-and-pin...
How is a car a digital service? Is this system using some type of software? Sure, but that doesn’t make it a digital service.
Also, where do you live that businesses selling goods to you are not liable if they don’t work as expected? This is not a software problem, the problem here is that a key doesn’t work as expected. The fact that it may “have software” somewhere doesn’t make the problem go away.
Is there a link to more detailed technical description?
From the description it almost sounds like validation for counter synchronization is separate from validation for command execution and it
doesn't take into account requirement of counter in the message being bigger than counter in last valid message. Thus allowing to rollback the counter and making previously recorder messages valid again.
> 9: Is there more technical information about Rolling-PWN?
> You can follow the author on Twitter [@kevin2600] (https://twitter.com/kevin2600). However, we will not be releasing any tools required to go out and steal the affected vehicles. At a later stage, we will release technical information in order to encourage more researchers to get involved in the car security research.
BTW, my 2019 Honda 'vehicle' config menu lets me enable/disable remote start.
It's been possible forever to unlock most cars by replay. I care a lot more about the crim driving it away. This news implies only that an enabled remote start can be compromised, not that every so-equipped Honda less than 10 years old is at risk. Just de-config your remote start.
Compromising an OEM remote starter is not really a big problem anyway. The vehicle still will not allow you to shift out of park, and any modern system will only start the vehicle a limited number of times for a limited duration. They're inherently designed for unattended operation.
Question for folks who are knowledgable in the subject:
Which car manufacturers have good security when it comes to those wireless keys? Are there any?
I feel like most of those things are either designed by regular developers who lack the hacker mindset; or maybe they do have it, but product management cuts corners to have better 'ease of use' etc.
Nope, it's still just a bucket of bolts kept running but just barely. It's now got a paperclip under the hood to keep the rad fan on and a couple of functional nickels under the dash as part of the breaking system.
That one claims (without sufficient proof) that Honda does not implement rolling code in the fobs, completely opposite of this article that implies a wrong re-synchronization strategy implemented on the vehicle side.
I bet it works similar to the garage door opening hack (opensesame by Samy Kamkar) and utilizes De Brujin Sequence. You don't need a briefcase for such. A small Raspberry Pi with a Yard Stick One is suffice.
opensesame is clever, but it only works on fixed code schemes decoded with a shift register or equivalent. This vulnerability affects rolling code schemes.
Older Hondas are notorious for being able to be stolen by putting a screwdriver in the key cylinder and giving it a swift whack with a hammer. They don't assign those CVEs though.
Source: Aforementioned 2000 CRV stolen once (Chicago =D) AND RECOVERED. Totally still working just dinged up a bit. They left it parked in front of a hydrant with the doors and windows open! Insurance totaled it, but said I could keep it.
That's the story of why I still have and drive a 22 year old, 5-speed, 2000 CRV. Hard to sell with the 'rebuilt' title, still runs great though. Dented up like a truck, but only has 135k miles. It's a keeper. My 'city' car.
Not my '98 Civic. Then again, pretty much any Honda key from that era can open up any Honda from that era - so it's not like Honda has ever been very concerned about security.
I wish theives would use sophisticated methods like this.
Instead I have to pay the decutable for broken car windows or replace it out of pocket.
If a thief is caught stealing (unlikely) the consequences are minimal. So little insensitive to use sophisticated methods.
Of course there are those that want undetected access to a vehicle for reasons other than stealing. But I'm not worried about that personally because I'm not important enough to be targeted.
HN two days ago helped me identify a random electronic dingus in my Honda as a dealer-installed remote entry and remote start thing from a brand called "Karr" which is in all likelihood a complete piece of junk, security-wise. I'm not even going to get worked up over OEM implementation details if dealers are installing backdoors.
> A rolling code system in keyless entry systems is to prevent replay attack.
More specifically: rolling codes are used to prevent replay attack while allowing the remote fob to be only a transmitter, not a receiver, which saves on costs.
If there was bi-directional communication there are obviously better ways to secure the fob/car (like regular challenge/response).
As someone whose car windows were broken 7 times in 13 months in San Francisco, I hope all the criminals get this device. I never have anything in my car, and the idiots doing the smash and grabs could reduce both our headaches by just investing in this thing.
Subaru really sold a car without a remote locking key/fob in 2018?? Almost every Subaru ever in the past 10 years has a key with remote lock/unlock functionality just like the one in the Rolling-PWN example linked above. In North America you'd have to try really hard to buy the cheapest new car you could find to get a dumb key, and even then it probably has remote central locking and potential vulnerabilities to replay attacks.
Your chance of getting a new car any time in the last decade that has no remote central locking and no potential replay attack surface is very, very low - this attack vector has been proven in many car key fobs for a long time.
We have dubbed that door vulnerability "cp4t hangar" and the ignition vulnerability "5crew 6r1ver" and have registered them in the common vulnerability database for credit and publicity purposes.
You can buy (on the usual dodgy places) a briefcase with a multi-car unlocker which will unlock lots of different cars if turned on in a car park, allowing you to then empty out the contents of any car that does then unlock.
And since there is no smashed window, insurance won't pay out either.