Can your CANbus be attacked?

[Karh4ck3r]

I have a Charger and have recently joined this forum since I have an interest in being able to modify my car and an interest in data networks. I make my living in the "Information Security" end of business and am very familiar with all types of networks and their associated security (or lack of).

So let us think about this for a moment. From reading much of what is on this Forum, I have concluded that the CANbus is obviously a data network that on the surface would appear to have NO authentication mechanisms. That is to say, if I can send data on that bus, I can pretend to be any module I want. Consider that from a network security point of view for a moment. So you say, "Big deal, its a stand alone network with no outside access." For the most part, you would be right. However, when you start adding modules with wireless data interfaces ... lets say like the "Hands Free" module that puts a kink in the standalone network security model.

My theory: If the wireless hands free module (Bluetooth) has ANY security related design flaws, the potential exists for an unfriendly attacker to inject malicious code into that module via the wireless data interface. Also, in most product development, security is NOT part of the original design, is often an after thought, and at sometimes not considered at all.

Question: For people who understand the CANbus better than I, "Is there anything within the CANbus design that would prevent any module on the CANbus from sending data (spoofing) as if it came from another module?" If your answer is "No" then be afraid, be very afraid.

What does this mean? This means that an attacker who can successfully inject code into the hands free module can begin sending data on the CANbus that can wreak havoc with all the other modules on that bus.

Am I a crazy paranoid person? No, I am an IT professional with 21 years of industry experience, the last 8 of which have been specialized in information security.

Is this just science fiction? No, malicious code injection is very common, there are already viruses written (although not very common...yet) that can transfer between cell phones over bluetooth wireless interfaces. This is done using malicious code injection.

Who would bother to even try this? More people than you think. We humans have a lot of curiosity. Point is, in the near future (or maybe already?), either I, or someone like me is going to start testing the security of the bluetooth interface of the hands free module. People who do find security flaws do NOT always report them to the public or the manufacturer of the device. So, I believe this forum may have an interest in knowing if the HFM is secure.

These are my thoughts and opinions. Please comment.

If you are driving one day and your CD ejects and your radio tunes to a different station, you might want to look around you.




I know what you are thinking, but, I'm pretty sure the Charger police packages do not come with a HFM. Shame on you for thinking like that!

Rob

[linuxkidd]

Very interesting ideas...
And you are 100% correct. There is no security layer on the CAN bus. It does base it's security on the closed network / trusted nodes mentality.

There actually are some 'ill intent' uses of bluetooth handsfree kits that are available in many cars today. The haven't yet ( as best of my knowledge ) breached the data network on the vehicle... But they can do some pretty interesting things.. Some billboards in other countries make use of these 'holes' to spew advertising to your car audio system via the Bluetooth devices. There's software out there for sniffing bluetooth traffic, and decoding the link key that secures these connections. Once this is done, you can inject audio, or possibly more malicious, listen in on the cab of the vehicle. One other interesting tid-bit about the bluetooth module. All Flash updates are done over Bluetooth. I believe that the init of the update is done over CAN Bus, but the actual firmware data flows out in the open air waves...

One other point of entry into the system is the SKREEM module. It is also a wireless interface device that resides on the CAN bus. It handles not only the validation of your key by way of rfid, but is also responsible for listening for the lock / unlock / panic / trunk pop signals from your key... As well as receiving the signal from the Tire Pressure monitoring devices inside the tires of many LX vehicles.

Anything is possible. Given enough time, anything can be hacked. Am I personally concerned that my car will start acting funny due to an attack any time soon... Na... I too am in the Information Security field... and I'm more concerned w/ the bluetooth hacking and someone spying on my conversations ( or most of the time, my music! )... But, with the way these systems operate... You should have some sort of que that something is going on w/ these devices.. ( at least in the LX Line, and w/ the Pioneer bluetooth units ). Now, with a bluetooth headset, if it's not in your ear... maybe not so much..


LK

[TheMatrix]

linuxkidd catch the right point when talking about the Screem module. It is a weak point in the network . I have heard that there is a diagnostic tool which could be use by the Chrysler technician to re-flash an Electronic Control Unit (ECU). It is named StarMobile.Seehttp://www.dcctools.com/en/starmobile/index.html.The Star Mobile could be used to record a lot of parameters of the car.

There could be some concern there... If you get the way to put data on the can bus using the RF, you could almost do anything. I wish there is no "Air Bag deploy code" possible on the B bus. Imagine a guy with an hacked version of the StarMobile walking down the street and blowing air bags with it<s Evil StarMobile !!!...

A wired attack could be more powerful.

If you take as an example in some kind of GM vehicle you could disarm the factory alarm, if you know the appropriate code to inject on the J-1850 bus. That require a lot of research because the codes changes between the GM different platforms of vehicles. I could also tell that for the GM case there is also some kind of master codes which will work on many J-1850 based vehicles.

For a similar wired attack that could help you to the gain access to the inside of a Chrysler CAN based vehicle its is a bit more complicated... The Chrysler engineer have insert a security check byte for the disarm function. So for an hacker this would meant more work. Once the guy tap into the B bus he will have to try up to 256 different codes to get the car to disarm and unlock. I never tried yet to roll all the different possibilities one after the other. I am a bit skeptical that they put a protection to avoid such kind of brute force attack.

There is a lot of protection mechanism in the Can Network. You could not swap computers as you wish. Some critical Computers will not work in a car which is the same as you.

Karh4ck3r, as an IT security specialist you would probably agree with me that the best bullet proof secured system you could imagine could maybe be hard to implement in real life since its limitation would be set by the convenience of a such bullet proof system.

The banking system could be using an higher encryption level algorithm. but the speed of the transaction and probably the risk management team have conclude that a 128 bits encryption is good enough. Not the best but enough for the situation.

Your car is equipped with critical security devices. As an example the ABS controller the Occupant Classification Module, the Occupant Restraint Controller .
The outbound attack are not the main concern of the vehicle network engineer. The important point is the reliability.
That could explain why they have chosen a Fault tolerant bus.
This kind of Can bus will work as long as one of it's two data bus remain operational. even with one wire cutted, shorted to ground or shorted to power the network will still work.

That is why, up to me, that there is not much network protection in our vehicle.

Is there an Air bag deploy code on the B bus ????!!!!

[Fred]

Our blue-tooth modules: only support the "car-kit" profile so no data transferring there.
I have heard of the earlier Lexus blue-tooth interfaces where the nav ran windows CE IIRC and that could cause some trouble.

If anyone's overly paranoid about this security, well there's always another option, an electronics free carb'd vehicle =)

I would say though that one should be careful which "CAN Vehicle Tuning" software package they choose once this idea becomes mainstream and causes many copy-cat programmers to write ad-ridden programs that use the gps to detect when you're in front of McDonald's and causes your car to stall there for 15 minutes forcing you to stop there.

[este00]

Wow. Thats all I can think of right now... is wow.

LK I expected a little more from you.

Matrix: The starmobile is a unit that sits on the obd2 port, its a date recorder and gateway for the starscan or wireless deal. Its has no more power then a snap-on scantool.

Karh4ck3r: Based on your comments and assumptions I have to assume that regardless of what IT Security expereince you have; You have little understanding of the CAN and microcontrollers used in the chrysler vehicles.

I found some things that were kinda funny to me and I have a minute so I'll elaborate on some things:

For people who understand the CANbus better than I, "Is there anything within the CANbus design that would prevent any module on the CANbus from sending data (spoofing) as if it came from another module?" If your answer is "No" then be afraid, be very afraid.

There is actually a security system in place for important things. Its a seed and key return system that is almost a minimum of 16bits or 65535 combonations with a time delay of 5 seconds between tries (its actually 2 tries then a 10 second delay, then a set max attempts before a longer delay 120 tries to a 20min delay or so). This is only for important things like the door unlock command or panic mode. Everything else is considered unimportant and harmless.

What does this mean? This means that an attacker who can successfully inject code into the hands free module can begin sending data on the CANbus that can wreak havoc with all the other modules on that bus.

This is so far from reality that I have to now assume that you have never programmed for a state-machine or rtos microcontroller. There is a long answer to this but I'm not that patient to try and explain it, you get the cliff notes version... Chrysler can network is a very large state machine, where every normal message is always being sent at a specific timed interval. In this way the bus load is never much less or much greater then its load at any given point in time. This means that inside every micro holds variable to be sent of the bus in ram, its data is updated however often but its transmission of the bus is a constant interval (say 10-500ms). This means module A can only ever send ID:500 DLC: 2 Data1: XX Data2: YY. Where XXYY is some relevant vehicle data, like a fule level, or configuration message. A 'hack' (as someone who considers themselves and actual hacker I use that term loosely) to the HFM or Radio+HFM can not start sending user specified data onto the bus b/c it has no function to do so. Perhaps you could alter some data that the module is prepared to send, but in the actual scheme of things, I doubt it. More on that later. Super short answer is not going to happen.

Am I a crazy paranoid person? No, I am an IT professional with 21 years of industry experience, the last 8 of which have been specialized in information security.

No, your not crazy. Just misinformed.

Is this just science fiction?

You're getting there. Comparing a 'hack' or any modification to the vehicle's data/bus to a cellphone hack is really reaching. The HFM does nothing more then route the voice transmision of a call throught the cars stereo and mic, and store contact/address data. It would be FULLY possible to inject data into the address book even over the vehicles speakers.... Maybe you could even use some crazy ascii chars or spoofing/slamming function that crashes/freezes the HFM. But not do any damage to the vehicle or comprimise data on the bus. Besides, there is security in place for this too, Chrylser's HFM does not openly solicite itself as a bluetooth node nor does it accept data (like a cellphone does) unless it receives it from a known phone. It only 'knows' a phone after completing a phone pairing op. So.... MAYBE you could make a module that spoofs phone paring, and MAYBE you could distract someone long enough to pair your module to thier car, and MAYBE... Just MAYBE then you could freeze up thier HFM or make the phone book have naughty entries or something.

So, I believe this forum may have an interest in knowing if the HFM is secure.

Prepare to be bored out of your mind. Even if you are a really smart cat and figure out the can data by logging it, (Look around here to see how well thats going, and some of these guys are pretty smart) you'd be ultimately be very disappointed.

If you are driving one day and your CD ejects and your radio tunes to a different station, you might want to look around you.

Uh... You're kidding right? Aside from the horrible range that chrysler's bluetooth has.... eh nevermind. I'm not being aggresive or anything, but you have very little understanding of how this whole system works.

And you are 100% correct. There is no security layer on the CAN bus. It does base it's security on the closed network / trusted nodes mentality.

Really Lk..... Come on. He's no where near 100, maybe 20% at best. See above for a little info on the identification these modules share. See, regardless of what the original posted suggests, Chrysler did think a little about security. The fact that CANC is isoloated from B isolated from D is, well, physical security is the best form of security. Next you have the fact that very very few people have figured out much of the bus on thier own by logging it. People who don't have to log it, well lets say have other things in mind. So protection by confusion. Then you have the the seed and key, ie one module asks for a seed, the other gives him one, then requesting module then sends a matching key, if its legit the auth was complete. In the case of door locks I believe I've seen 3 byte seeds and keys, that I believe rarely repeat. Thats 16,777,215 possible combonations for you just to once unlock the door.... Not sure how this would even be helpfull since you need the key in ingition and access to CAN-C... good luck.

There's software out there for sniffing bluetooth traffic, and decoding the link key that secures these connections.

See above, closed to unknown attempts. I did a little bluetooth programming for a project awhile back, didn't really like the fault tollerance and message balancing so I never got into it too much. Can't really go further without really a few things. Not gonna happen today. Already typing a novel.

All Flash updates are done over Bluetooth. I believe that the init of the update is done over CAN Bus, but the actual firmware data flows out in the open air waves...

I find this a little odd, but I could understand if it were the case. The HFM has a very small amount of resources devoted to CAN. It would probably be fasted to load via rf. I can promise you these are not open air waves. The same seed and key return is done at the very least on the can init side. But most likely also on the rf side.

One other point of entry into the system is the SKREEM module. It is also a wireless interface device that resides on the CAN bus. It handles not only the validation of your key by way of rfid, but is also responsible for listening for the lock / unlock / panic / trunk pop signals from your key...

Arg... The SKREEM doesn't work like that. Inside each key is a little philips chip, battery, and antenna. The way it works is that when a key is learned to the car a rather large chunk of data is downloaded into the key. A data table. When you press the key for a learned vehicle the chip sends packet containing the ID, Command, and Security packets. A total of 32-64 BYTES of data. Cool thing is, when you are in a parking lot of Chrylser cars and press your button, they all wake up their SKREEM. It checks the ID of the incoming packet. If it does not match an ID (4 bytes i think, maybe that is known to that vehicle, nothing will happen. Now, if it does match and the command is ok (lets say unlock doors) it will then check out the data that was recieved for the security packet. This is all done on the die of a matching philips chip. If its OK, then the SKREEM sends a packet to the cluster asking for unlock, the cluster starts seed and key then bla bla bla we're back to where we started. If you can find a flaw in that system you would be a multimillionaire. I am not saying its impossible. But its so unlikely that its pretty stupid to worry about.

By the way, Tire monitoring is not just LX, its all of dcx's line. Manditory for 08. All new models or models with refreshes since 04 have it now.

linuxkidd catch the right point when talking about the Screem module. It is a weak point in the network .

Actually its the or the second strongest point on the network. But uh.... good guess ? It might loose out to the FCM, but I'd guess they are equally secure.

I wish there is no "Air Bag deploy code"

There is not. Its federal law that there can be no magic remote trigger of the air bag system.

he will have to try up to 256 different codes to get the car to disarm and unlock

Thats a 1 byte code (0x00 to 0xFF). I'd be willing to bet 00 doesn't ever come up so 255 is way more likely. Like I stated before, Chrylser's systems are never less the 2 bytes and always have a time to retry limit. No getting around it. I saw one instance where the time set and based off a charged capcitor, so one start they charge it then let it drain through a huge resistor, like 1M or so. So even if you pulled the power and restart you still need to wait the time for it to discharge before trying again. That was a long time ago though, I think now they force a delay on start before the module will allow any attempts

That could explain why they have chosen a Fault tolerant bus.

No... The FT bus was a bad idea and they are moving away from it. No one seemed to realize that it would make modules exclusive of either bus (sometimes a fuel pump module might be can-c or can-b perhaps). It wont change today, but its pretty soon. FT is for physical errors like a wire came out from its connector and one 1 bus line of its differential pair was still intact. Its just a special transceiver and termination method.


So thats all I have. Sorry if I offended anyone but like I said, I was some funny stuff. Had to fix it. Woot, I now have the record for longest message on canhack! And I didnt proof read any of it.,

Lates, Its sushi time!

[linuxkidd]

Hey! Go enjoy your sushi!

No offense taken here man... I learned a bit from your post. Didn't know about the forced delays, etc.. But, I was certain something similar existed ( mainly after I locked up the NAV unit trying to feed it a channel update from my 'simulated' sirius device. )

I'm not so certain on all of the seed / return key exchanges however... Mostly because of the Aftermarket Alarm system interfaces that exist ( like the one installed in my Charger ). If it were a changing seed / key exchange, I'd be impressed that someone had made a module to to the Lock / Unlock / Trunk pop / Onboard Security System Arm/Disarm this soon... I'm really leaning more toward just a simple request / response. I could be dead wrong on this, but it will take some captures on the charger w/ the alarm interface to be certain.

The one thing I am curious for your input on ( well, the thing that first springs to mind ). On this particular interface ( Bypasskit.com's XK-532 ), the module doesn't seem to handle the first lock / unlock signal appropriately. I believe it has to do with the fact that the CAN-B side is asleep, and it's not getting a proper wake sequence before the XK-532 tries to send the Lock/Unlock signal. Any thoughts on this?? It only occurs if there's been no activity w/ the vehicle for a few seconds.. ( as little as 15 seconds, as much as 60 seconds that I've noticed ). I usually get around this by issuing a second command, or, I remote start the vehicle, and then unlock it..

Anyway... Thanks for the Extensive post!!

LK

[este00]

I like the red tuna myself,

There are a lot of speeling errors and missed/misplaced words in that post but I think even I learned something after reading that

The bypasskits learn themselves as a key. Thats how they work. All they did was take a factory key and grab its antenna, and philips transponder chip and put it on a stay in vehicle board. Then they have they'r own keyfob that translates messages to the module in the vehicle.

So you press the key, the key sends the 'user wants unlock' message to the bypass box, that gets the message and uses the factory-like key circuit to send a message to the philips chip which has already been learned to the car (see the note about "Requires: 2 Factory Keys"), that sends a message to the skreem saying "i am a factory key and am requesting unlock", which then the skreem authenticates itself with the cluster or fcm (depending on vehicle). Done, now for an instant they are free to send any message they wish b/c the auth is cleared already.

You need two keys or a starscan to program another key into the system. So think of the bypass box as a key.

Its moderately tough to do, but it all makes sense once its figured out

[TheMatrix]

There is two part for the bypasskit unit.

First part is the transponder itself (the single PCF7936ASM)

By the way they don't use the PCF7941 that is the chip you guys have in your OEM Dodge keyfob-remote.

This transponder (PCF7936ASM) is required in order to be able to remote start the engine without having a valid key in the ignition.

For convenience they use the 2 valid key process to program the NEW Philips transponder.

For the door lock part ...

They have succeed in emulating the can protocol via a microchip pic.
They listen on the bus and wait that you turn the key to the ignition position in order to record the 2 byte signature check for the remote actuated function. That makes 65536 possibilities .

Once they have catch those 2 byte they are ready to transmit the remote function on the bus (without any transceiver which is BAD) .

They are too poor engineer to use RF and probably too greedy too since they don't want to use a can transceiver ....

If you look to their install guide you will see also that they tap onto only one of the 2 wire of the b bus. They rely on the fact that the bus is fault tolerant and if their unit go banana they wont freeze the bus since there is still a valid node.

Wait this Fall we will do the release of an other unit which will be better than this one.

idatalink.com


I learned some real good stuff here , respect guys !

[Karh4ck3r]

Wow, I'm glad I came back to check in on this thread. este00 gave up some really good information and I appreciate it. The only part of his argument that doesn't hold up is where he claims that something is too difficult or has too many possible combinations to get past. I remember hearing this same argument about buffer over flow attacks years ago. I've seen too many "not possible" attacks over wireless data connections demonstrated to be willing to make that assumption. A bluetooth connection on the head unit is not necessarily limited to the handset profile just because the manufacturer says that it is. If you consider that bluetooth is just another network layer, you have to believe that the person who wrote the software (or firmware) for that network layer made absolutely no mistakes that would allow an attacker to exploit it. este00 is much more confident in programmers that he has never met that I would be.

My claim still stands. If you know what codes to send over the CAN bus and can find a path to send them, its a done deal.

Obviously the bypass manufacturers have figured out how to send the appropriate codes onto the CAN bus to make things happen. And it is good to know that if I want I can buy a bypass kit to find out the codes I need.

I think este00 is an embedded systems programmer with little or no security background and doesn't really understand what I mean when I say "code injection". State machines and real time operating systems are not magic and are subject to bad programming just as any other software. His main premise is that he doesn't think it is possible therefore it can't be done! That said, este00 is the one of if not THE biggest contributor to this site, seems very smart, and I have contributed nothing so I hope my wording isn't offensive to him. I'm way behind the curve on understanding the CAN bus and will greatly benefit from his contributions. I hope when I get up to speed (yah, I procrastinated for a couple years) I will have something to contribute too.

Not trying to make people worry, but just to think about it. After all, this is merely a "theoretical" attack like buffer overflows were way back when. Also, the likely hood that someone would go through the trouble to figure it out is fairly slim and if they did, it may not work on more than one car model or year.

P.S. I have removed my factory head unit that had a direct connection to the CAN bus and replaced it with an aftermarket unit that uses bypass modules instead. So now I have a piece of hardware for testing!

[nopoint]

i bought one of these bypass, successfully installed it in my Caravan 07. Data immobilizer bypass is working really well, no need for a transponder or anything like that just one key that's all.. so i want to buy some equipment to sniff whats happening on the bus when the bypass module "speak" to the PCM. anyone can recommend me the right hardware? thanks.