Car Hacking Research: Remote Attack Tesla Motors by Keen Security Lab

[apacheguy]

It's another layer of protection after gaining access remotely. It would mitigate against overwriting Tesla's code with the atrackers.

Right. It assumes that someone has root and then it asks what can you do with that? With code signing, not all that much at least in the mind a nefarious hacker who wants to kill brakes or disable the drive unit.

But back to @green1 and his original question. How long do we allow Keen Lab to continue their radio silence? They promised disclosure and I don't believe in empty promises. Someone has to hold them to it.

 

[msnow]

Right. It assumes that someone has root and then it asks what can you do with that? With code signing, not all that much at least in the mind a nefarious hacker who wants to kill brakes or disable the drive unit.

But back to @green1 and his original question. How long do we allow Keen Lab to continue their radio silence? They promised disclosure and I don't believe in empty promises. Someone has to hold them to it.

Remembering my theory that there was a "difference of opinion" between Elon's team and Keen wrt the exploit it's possible Tesla got them to sign a NDA in consideration of some sort of compensation. Certainly wouldn't be the first time.

 

[apacheguy]

Yeah, unfortunate IMO. If Kevin Mahaffey and Marc Rogers were presenting at Defcon this year instead of last I'm sure Tesla would have paid them off to keep their mouths shut and cancel their talk.

 

[green1]

If Tesla spent half as many resources improving the software as they do fighting their customers, just imagine how amazing this car would be!

 

[wk057]

Honestly, until the vast majority of the fleet has been updated to a version that includes the patches related to their exploits it would be a bit reckless and irresponsible for a legitimate security research group to release details of the exploit(s). So, really, I would give it at least a couple of months.

Suffice it to say, from what I've gathered based on the changes made to patch the firmware against their efforts, I don't think this exploit is as damning as Keen Labs made it out to be and I wouldn't personally consider it a high impact exploit. It requires specific actions to be taken by the owner/driver inside the car which, while technically done without physical connectivity/modification, still requires some degree of physical access to exploit.

The Keen Labs folks simply aren't going to walk up to any Tesla that hasn't been patched and unlock it or whatever. They put on a good show, but it was misleading at best.

 

[green1]

Honestly, until the vast majority of the fleet has been updated to a version that includes the patches related to their exploits it would be a bit reckless and irresponsible for a legitimate security research group to release details of the exploit(s). So, really, I would give it at least a couple of months.

Suffice it to say, from what I've gathered based on the changes made to patch the firmware against their efforts, I don't think this exploit is as damning as Keen Labs made it out to be and I wouldn't personally consider it a high impact exploit. It requires specific actions to be taken by the owner/driver inside the car which, while technically done without physical connectivity/modification, still requires some degree of physical access to exploit.

The Keen Labs folks simply aren't going to walk up to any Tesla that hasn't been patched and unlock it or whatever. They put on a good show, but it was misleading at best.

I agree with you fully about the impact, but I find it odd that you'd indicate that the "vast majority of the fleet" has not been updated. Considering how aggressively the patch was rolled out, plus the big launch of 8.0 which is now a few versions in, I would expect that at this point there are likely very few cars un-patched, and all of them could easily be patched if the owner wanted to.

As such, I believe this is exactly the time for responsible disclosure to the public.

 

[wk057]

I agree with you fully about the impact, but I find it odd that you'd indicate that the "vast majority of the fleet" has not been updated. Considering how aggressively the patch was rolled out, plus the big launch of 8.0 which is now a few versions in, I would expect that at this point there are likely very few cars un-patched, and all of them could easily be patched if the owner wanted to.

As such, I believe this is exactly the time for responsible disclosure to the public.

Based on what I've gathered, v7.1 (2.36.31) patched one particular aspect (the initial entry vector). Then the initial release of 8.0 closed the remainder of the bug chain that allowed the exploits. Since 8.0 has only recently started to roll out outside the US, I expect it will be some time before the entire fleet is fully patched.

 

[MP3Mike]

I agree with you fully about the impact, but I find it odd that you'd indicate that the "vast majority of the fleet" has not been updated. Considering how aggressively the patch was rolled out, plus the big launch of 8.0 which is now a few versions in, I would expect that at this point there are likely very few cars un-patched, and all of them could easily be patched if the owner wanted to.

But as you well know just because Tesla makes it available doesn't mean the owner pushes the button to install it. (Or that the install succeeds.)

And for those people that didn't install the 7.1 update before 8.0 was pushed, they may wait even longer now to update since some people really don't like 8.0.

 

[MP3Mike]

Based on what I've gathered, v7.1 (2.36.31) patched one particular aspect (the initial entry vector). Then the initial release of 8.0 closed the remainder of the bug chain that allowed the exploits. Since 8.0 has only recently started to roll out outside the US, I expect it will be some time before the entire fleet is fully patched.

I thought the 7.1 update introduced the code signing aspect, which isn't the initial entry vector...

 

[wk057]

I thought the 7.1 update introduced the code signing aspect, which isn't the initial entry vector...

It also patched the webkit library where the initial exploit vector appears to be.

Edit: The chain looks like this to me:

Exploit webkit (patched in 2.36.31) -> exploit non-public privilege escalation vector (patched in 2.36.106) -> exploit a part of the update process related to signed code (patched in 2.36.31).

 

[apacheguy]

Honestly, until the vast majority of the fleet has been updated to a version that includes the patches related to their exploits it would be a bit reckless and irresponsible for a legitimate security research group to release details of the exploit(s). So, really, I would give it at least a couple of months.

Suffice it to say, from what I've gathered based on the changes made to patch the firmware against their efforts, I don't think this exploit is as damning as Keen Labs made it out to be and I wouldn't personally consider it a high impact exploit. It requires specific actions to be taken by the owner/driver inside the car which, while technically done without physical connectivity/modification, still requires some degree of physical access to exploit.

The Keen Labs folks simply aren't going to walk up to any Tesla that hasn't been patched and unlock it or whatever. They put on a good show, but it was misleading at best.

I would be inclined to agree with you if this were a severe remote vulnerability. However, as you note it requires specific actions to be taken by the operator and thus I do not see the harm in disclosing details sooner rather than later.

Remenber the Defcon talk? It was mere days after Tesla pushed the OTA fix for those vulnerabilities.

It also patched the webkit library where the initial exploit vector appears to be.

Edit: The chain looks like this to me:

Exploit webkit (patched in 2.36.31) -> exploit non-public privilege escalation vector (patched in 2.36.106) -> exploit a part of the update process related to signed code (patched in 2.36.31).

Seriously? I'm super impressed if they found a non-public kernel vulnerability that allowed privilege escalation. Doesn't that mean that this affects other Ubuntu systems as well and don't they need to report that to the Linux community?

 

[wk057]

I would be inclined to agree with you if this were a severe remote vulnerability. However, as you note it requires specific actions to be taken by the operator and thus I do not see the harm in disclosing details sooner rather than later.

Remenber the Defcon talk? It was mere days after Tesla pushed the OTA fix for those vulnerabilities.

The Defcon guys basically released no real details. Same showmanship the Keen Labs guys already have done. To date no one has released any real details on *how* to exploit anything on the S/X. (This is not a bad thing.)

Seriously? I'm super impressed if they found a non-public kernel vulnerability that allowed privilege escalation. Doesn't that mean that this affects other Ubuntu systems as well and don't they need to report that to the Linux community?

Where'd the kernel come into this? Never said anything about the kernel. That exploit is Tesla-specific.

 

[green1]

The Defcon guys basically released no real details. Same showmanship the Keen Labs guys already have done. To date no one has released any real details on *how* to exploit anything on the S/X. (This is not a bad thing.)

I disagree. The defcon people did release a lot of detail, sure it wasn't a step by step for the layman, but anyone reasonably skilled in the art could have easily followed their footsteps based on what they released. The only thing stopping people was that Tesla has already patched the vulnerability. The only real difference is that the defcon people exploited fully local vulnerabilities, whereas keen have a somewhat remote one (though you rightly point out earlier, it does require user action to exploit)

 

[apacheguy]

Where'd the kernel come into this? Never said anything about the kernel. That exploit is Tesla-specific.

Gotcha.

***update***

My confusion stemmed from Andy Greenburg's article:

"When Tencent KeenLab team shared its attack technique with Tesla earlier this month, Tesla quickly created patches for the browser vulnerability and the Linux kernel flaw."

 

[apacheguy]

The Defcon guys basically released no real details. Same showmanship the Keen Labs guys already have done. To date no one has released any real details on *how* to exploit anything on the S/X. (This is not a bad thing.)

Hmm. Pretty sure I could've hacked my way in with the info they released. The firmware URL was used to download a bundle and that bundle contained a Shadow file. Crack the shadow and you have the passwords. The password corresponded to tesla1 which also happens to be a sudoer. From root on the IC, a text file can be read containing the CID root login. Seems straightforward. What am I missing?

 

[wk057]

I disagree. The defcon people did release a lot of detail, sure it wasn't a step by step for the layman, but anyone reasonably skilled in the art could have easily followed their footsteps based on what they released. The only thing stopping people was that Tesla has already patched the vulnerability. The only real difference is that the defcon people exploited fully local vulnerabilities, whereas keen have a somewhat remote one (though you rightly point out earlier, it does require user action to exploit)

Hmm. Pretty sure I could've hacked my way in with the info they released. The firmware URL was used to download a bundle and that bundle contained a Shadow file. Crack the shadow and you have the passwords. The password corresponded to tesla1 which also happens to be a sudoer. From root on the IC, a text file can be read containing the CID root login. Seems straightforward. What am I missing?

After actually finally gaining access to my first CID/IC pair which was on a pre-Defcon firmware....... I think the shadow file method they noted is a bit misleading. Yes, the passwords in the shadow file in the firmware dump are completely lame (and still are as far as I know). The password for the root account is "root" and the password for the tesla account is "tesla" and finally the nvidia account password is "nvidia". *But,* those passwords don't actually work for logins because they're !'d out (locked), and they have been like this even in the earliest firmwares I've since gotten a hold of (2012). The only passwords that actually work to get into the CID are the tokens for tesla1 and tesla2, which up until recently were in fact stored in plaintext on the CID and also sync'd with the IC, and the only way into the IC was with an ssh private key stored on the CID. So... yeah. I don't think anyone was going to be able to duplicate those efforts based on the info they provided. Lots of showmanship by these security groups, for sure, but no one is really giving up a usable way into the Model S. Good tidbits, like knowing the existence and location of the plaintext tokens, but you weren't getting into a car based on their info, even one with outdated firmware.

Personally, I sacrificed an IC and CID by desoldering the flash chips (boot flash and eMMC) and resoldering them to a custom board in order to directly access the data contained with the hope of finding a way in. Obviously I found a few.

From the WIRED article.

Interesting. Well, the kernel doesn't appear to have changed at all for quite some time, so, not sure where that info comes from.

Edit: Actually, I think I know where Wired would get that idea now that I think about it. But, not my place to disclose.

 

[S'toon]

After actually finally gaining access to my first CID/IC pair which was on a pre-Defcon firmware....... I think the shadow file method they noted is a bit misleading. Yes, the passwords in the shadow file in the firmware dump are completely lame (and still are as far as I know). The password for the root account is "root" and the password for the tesla account is "tesla" and finally the nvidia account password is "nvidia". *But,* those passwords don't actually work for logins because they're !'d out (locked), and they have been like this even in the earliest firmwares I've since gotten a hold of (2012). The only passwords that actually work to get into the CID are the tokens for tesla1 and tesla2, which up until recently were in fact stored in plaintext on the CID and also sync'd with the IC, and the only way into the IC was with an ssh private key stored on the CID. So... yeah. I don't think anyone was going to be able to duplicate those efforts based on the info they provided. Lots of showmanship by these security groups, for sure, but no one is really giving up a usable way into the Model S. Good tidbits, like knowing the existence and location of the plaintext tokens, but you weren't getting into a car based on their info, even one with outdated firmware.

Personally, I sacrificed an IC and CID by desoldering the flash chips (boot flash and eMMC) and resoldering them to a custom board in order to directly access the data contained with the hope of finding a way in. Obviously I found a few.



Interesting. Well, the kernel doesn't appear to have changed at all for quite some time, so, not sure where that info comes from.

Edit: Actually, I think I know where Wired would get that idea now that I think about it. But, not my place to disclose.

You know, I really admire your tech skills.

 

[green1]

After actually finally gaining access to my first CID/IC pair which was on a pre-Defcon firmware....... I think the shadow file method they noted is a bit misleading. Yes, the passwords in the shadow file in the firmware dump are completely lame (and still are as far as I know). The password for the root account is "root" and the password for the tesla account is "tesla" and finally the nvidia account password is "nvidia". *But,* those passwords don't actually work for logins because they're !'d out (locked), and they have been like this even in the earliest firmwares I've since gotten a hold of (2012). The only passwords that actually work to get into the CID are the tokens for tesla1 and tesla2, which up until recently were in fact stored in plaintext on the CID and also sync'd with the IC, and the only way into the IC was with an ssh private key stored on the CID. So... yeah. I don't think anyone was going to be able to duplicate those efforts based on the info they provided. Lots of showmanship by these security groups, for sure, but no one is really giving up a usable way into the Model S. Good tidbits, like knowing the existence and location of the plaintext tokens, but you weren't getting into a car based on their info, even one with outdated firmware.

Personally, I sacrificed an IC and CID by desoldering the flash chips (boot flash and eMMC) and resoldering them to a custom board in order to directly access the data contained with the hope of finding a way in. Obviously I found a few.



Interesting. Well, the kernel doesn't appear to have changed at all for quite some time, so, not sure where that info comes from.

Edit: Actually, I think I know where Wired would get that idea now that I think about it. But, not my place to disclose.

I think you should re watch the defcon talk. They talk specifically about how they got the private key among other things.

 

[Ingineer]

My assessment is the same as Wk's and I agree with Green1. Since reveal of an exploit this soon could allow an owner in that held back on updating to the last few versions, that would be reason enough for Tesla (and/or Keen) to avoid disclosure.

Tesla doesn't want it's customers gaining root and running amok inside the systems, as they have to warranty and support most of the cars out there. Even after warranty runs out, they probably are still concerned about the ramifications of bad publicity if someone's tinkering goes wrong in some way and it results in something bad happening. Of course just because I understand this policy, doesn't mean I agree with it or like it.

 

[green1]

It's reason for Tesla, it's not a reason for keen. Keen's only incentive would be if Tesla is paying them to stay quiet, which is highly disappointing because they could much better use that money to improve their product instead of fighting against their own customers.