Jul 8, 2015
W.Petefish There is slated to be an interesting talk at DEFCON this year. Supposedly there are going to be 6 exploits revealed at DEFCON. (with only one of them having been patched)
I will be going there for the talk and other fun with friends. If y'all show up, look for me and some of the crew... I should be reachable by you HAM radio operators on 146.520 (simplex).
The brief for the talk is the image.
DEFCON is notable for posting the talk on youtube after the conference, so keep a watch on the DEFCON youtube channel.�
Jul 9, 2015
docrice Very cool. Definitely attending this talk (hopefully the lines to get into the room won't be too ridiculous).
I worry that my car will become an instant target after the talk is over.�
Jul 9, 2015
Saghost "We will also be releasing a tool that will allow Model S owners to view and analyze the telemetry in real time."
This sounds interesting - I wonder how much more information it'll give that the car screens generally don't...
Walter�
Jul 9, 2015
mwulff I worry about Tesla not patching all 6 vulnerabilities before the talk. This could be a marketing disaster for Tesla.
Not to mention the huge hassle a hacked Model S would incur on the owner.
Luckily the car does not allow remote activation of any driving functions, but it could be annoying as hell.�
Jul 9, 2015
frosken I'm definitely attending this. I hope it's more of a curious angle on the technology of the TMS and not an attacking talk.�
Jul 9, 2015
jaguar36 They still have a month or so, if the vulnerabilities have been disclosed to them already they could easily get a patch out before then.
I don't think it would really ever be an issue for an owner. Most of these vulnerabilities are quite complicated and in general anyone with the skill to do them couldn't be bothered to actually use them. Not always though. It also depends on what the vulnerabilities are. If its just allowing someone to remotely get some of your car data, that's not a big deal. If its honking the horn and unlocking the car, that's a bigger deal, although not really something to be concerned about. If it allows the car to be put into drive, that could be a major issue.
Marketing is where the real issue will be. The local news will undoubtedly pick the story up and run with it regardless of the extent or practicality of the vulnerabilities.�
Jul 10, 2015
strider I'll be in Vegas that week but will be presenting at our company's Sales Kick-Off so won't make any talks.
I'm mostly interested in whether there are any remote vectors besides attacking someone's MyTesla password - if so then . All of the other "car hacks" that I have seen require physical access to the inside of the car. If I have to get access to the Ethernet port under the dash it's not a "hack" any more. It's like saying I can "hack" your TV and make it change channels. I just have to do into your house and access the TV.If I can get physical access to sa piece of technology I can break into it, period. Please update the thread after the talk.
�
Jul 10, 2015
evme The question comes down to the seriousness of these hacks, like say breaking into the mobile app isn't really that serious per say.�
Jul 10, 2015
SeminoleFSU It is though. They can open your car and steal your things.. or start it, have a joy ride, etc...�
Jul 13, 2015
strider And even drive the car now that they have the App-start feature. However, if the hack is simply, "brute force the user's MyTesla password" then that isn't a "hack." Hopefully we'll find out in a few weeks.�
Jul 13, 2015
Duma I look forward to hearing what gets reported but I would not get overly concerned yet.
From prior DEFCONs, it appears that the Bluetooth stack in cars has a number of vulnerabilities, which is an issue that is not unique to Model S. Moreover, that might enable getting something running on the console display, which could be a pain but is still a far cry from compromising the code running on the other processors that handle the actual operation of the car. Legitimate issue but not too impressive unless they do more than crash the bluetooth controller.
The distributed computing (multiple processors) makes it surprisingly difficult to take over control of the car. Even the most sophisticated attacks to date (on Prius and Ford Explorer) needed access to the internal bus and mostly confused the other processors by sending an overload of messages.
The App seems like another likely attack vector and worst case, one can disable the App access to the car until Tesla can push out a fix. This would be a pain in the short term, but is a reasonable mitigation.
Finally, any hack that just accesses telemetry data (and that seems to be a big part of the talk) is a privacy issue rather than a direct threat. However, since the telemetry data includes vehicle location, this does have some risks if someone takes a particular interest in you or your car.
- - - Updated - - -
See the attached link for more information about Tesla at DEFCON.
http://www.forbes.com/sites/thomasbrewster/2015/04/28/tesla-opening-car-to-hackers/�
Jul 13, 2015
docrice Since it's Vegas in the summertime, I fully intend to remotely pre-cool the car before I walk back to it. I would hate to have to disable remote functionality due to paranoia. On the other hand, it would suck to see the car not there when I walk out to the parking lot.
Maybe I'll bring a car-size Faraday cage with me.�
Jul 14, 2015
spentan I'm most probably gonna go. Will valet at Rio as usual, Valet Mode is usually a safe bet. (Valet Lots are generally secure too)�
Jul 14, 2015
steph280 Maybe they found a way to hack a standard MS into a P model?
One can only dream...�
Jul 14, 2015
perkiset Really looking forward to what they have to say. I've been a Global Moderator for the Syndk8 for more than 9 years, but just about to become a rank n00b to Tesla. I'm only too aware of what can be done with the right exploits.
This thread definitely raised my eyebrows.�
Jul 14, 2015
invisik I guess turn off your communication in the car for a few days after the talk, if you're that worried.
-m�
Jul 14, 2015
wk057 The RWD Model S has two drive unit types: Standard (for the 40, 60, and 85) and Performance (for the P85, P85+, and P85D rear). Not sure a software hack will do the drive unit swap.�
Jul 14, 2015
Ingineer And on the D cars, (70/85) they basically have 2 of the same motors, albeit with a different drive ratio, one in front, one in rear. Smaller than the standard RWD only motor though.
I'll likely be attending DEFCON as well.�
Jul 16, 2015
lklundin Model S at DEF CON hacker convention August 6-9
The program for this year's DEF CON includes a presentation "How to Hack a Tesla Model S":
DEF CON 23 Hacking Conference - Speakers
In an attempt to heighten the level of an anticipated discussion of that event here, I will try to clarify a couple of things that may not be clear to the typical Model S owner:
1) With one likely exception, Tesla Model S as a topic at DEF CON is a _good_ thing for Tesla Motors and for Tesla Model S owners. a) It gives Tesla Motors renewed media attention and public awareness for free. b) It promises to give the public
an understanding of what information the data the Model S collects and what Tesla does with this data, which is important in terms of a (prospective) owner's right to privacy. c) It promises to disclose to the public a handful of so called zero-day software vulnerabilities in the Model S, which is good since this will in turn allow Tesla to improve its software. Starting with 19th century lock smiths it has been a subject of debate if and how security vulnerabilities should be disclosed. A commonly held view is that if they are _not_ disclosed to the public, the vulnerabilities are less likely to be fixed, criminals will still know about them and exploit them to the detriment of the owners and prospective owners will not be able to appreciate the security of competing products in the market. A zero-day vulnerability is a vulnerability that is being disclosed to the public with zero days of advance notice to the producer, in this case Tesla. In the case of Model S and DEF CON, it means that in three weeks not only Tesla Model S owners, but also criminals and others can expect to to able to compromise the software in a Tesla Model S. Tesla Motors will thus be in a race to push out an update to their cars and depending on the severity of the type of compromise and the complexity in fixing the issues, we can expect Tesla to react rather quickly to this disclosure. A segment of IT security researchers hold the view that it is more responsible to give prior notification to a software vendor (such as Tesla Motors de facto is) before disclosing a software vulnerability, i.e. to avoid disclosing zero-day vulnerabilities in favor of so called responsible disclosure. As such it is hardly good news for Tesla Motors and the typical Model S owner, if zero-day vulnerabilities are in fact going to be disclosed. An advantage for courageous Model S owners is that the zero-day disclosure gives them the prospect of "jail-braking" their Model S, i.e. giving them the freedom to modify the software in the car, but at the risk of causing it to malfunction - quite possibly with a voided warranty to boot.
2) The typical Model S owner may not appreciate the significance of the fact that the Model S uses Linux and apparently also Ubuntu on top. Apart from cars, Linux is the most widely used operating system in the world, found in everything from smart phones, routers, PCs to servers and supercomputers, there is even a rifle scope that uses Linux. Linux (and Ubuntu) is protected by copyright laws in all countries (that have signed the Bern Convention, including the USA and France where one inquisitive Model S owner appears to reside). The copyright holders of Linux are its contributors, which include major IT-players such as Google. All copyright holders of Linux/Ubuntu have agreed to give the users of Linux (e.g. a Model S owner) wide ranging freedoms in using the software, on certain conditions that are also imposed on anyone who redistributes Linux/Ubuntu (e.g. Tesla Motors when they sell a Model S with Linux/Ubuntu inside). The conditions are called the "GNU Public License" (GPL) and are enforceable under copyright law. The conditions stipulate among other things that when Tesla Motors redistributes Linux (i.e. sells a car), they have to give "prominent notice" to the recipient (i.e. the buyer). So all Model S owners should have a note from Tesla that their car uses Linux/Ubuntu, mentioning the GPL. Another condition is that if Tesla has made modifications to the Linux/Ubuntu in the cars they sell, they are required to make this software available to the buyer. (Tesla like others are allowed to distribute their own separate pieces of software together with Linux/Ubuntu in certain ways, without having to use the GPL for these separate pieces of software. For example the Tesla specific software that draws the images on the Model S touchscreen does not necessarily have to be distributed under the GPL). A third condition is that Tesla is not allowed to take away the freedoms that the copyright holders have granted the Linux recipient (i.e. Model S owner). This implies among other things that Tesla is not allowed to forbid reverse engineering of the Linux versions they have sold. What exactly would happen if Tesla refuses to honor its warranty after a Model S owner causes his car to malfunction after having modified the Linux inside may be something for the courts to decide.
I realize that the perspective of this posting is probably somewhat unusual for this forum, but hope it is still considered interesting - and I look forward to learn more about the Model S from the DEF CON presentation.
All the best.�
Jul 16, 2015
bollar Already under discussion here: Security from the frontlines... (OR How to Hack A Model S talk at DEFCON))�
Jul 17, 2015
lklundin Sorry about that. PS. When I enter e.g. "DEFCON" in the forum search field and press the search icon, I get nothing. Perhaps Javascript from some third party site is required. Oh well.�
Jul 17, 2015
jerry33 To have a chance at finding anything you have to use advanced search, and even then chances of success are small.�
Jul 17, 2015
spottyq The best way to find some information on any particular website is to use the keyword "site:�" in google. (example : site:www.teslamotorsclub.com defcon.)
Regarding the security vulnerabilities, I am also dubious� But I hope if the security vulnerabilities they found are serious that they will warn Tesla beforehand.�
Jul 21, 2015
lklundin Tesla not the only automaker at DEFCON
In addition to Tesla, Chrysler and its "Uconnect system" will get some attention at DEFON:
DEF CON 23 Hacking Conference - Speakers
This story in Wired
http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/
sounds so reckless that I actually hope it does not accurately reflect how the Uconnect vulnerability was demonstrated...
But if the DEFCON program is accurate, then it has a talk that will put a non-Tesla automaker in a very bad light...
It will be interesting to see how the different automakers react to having issues with their software exposed
- if I were Tesla, I would change
Bugcrowd | Your Elastic Security Team, better security testing through bug bounties and managed security programs
to offer some real money as a reward for responsible disclosure of real problems, since _up to_ 1k$ is nothing compared to the cost a vehicle software problem can incur.
Further, the offering of a juicy bounty is not only one more way of getting media attention, it also implies that Tesla considers its software trustworthy, which is a good signal to send.
In that light an e.g. 50k$ bounty would make sense. To me.�
Jul 21, 2015
Zaxxon Well, it could always be much worse.�
Jul 21, 2015
brucet999 I'm imagining a talented and recently divorced computer geek whose wife was awarded the Model S in the property settlement.�
Jul 21, 2015
neroden The only hacks which I consider vulnerabilities are hacks committed (a) remotely, and (b) with app remote access disabled in the menu. Any such hacks are actually dangerous. Anything else... meh. "Local" hacks, of course, are things we want to be able to do to soup up our cars (once they're out of warranty).�
Jul 21, 2015
thecloud Remote access is actually quite a useful feature; think for a moment about having the ability to turn on the A/C before returning to your car on a sweltering summer day, knowing whether your car has finished charging, and so on. You should be able to leave remote access enabled in your car and still be secure, assuming you chose a suitably strong password. Why would such an attack not be considered a vulnerability?�
Jul 22, 2015
HankLloydRight Also realize that all Remote Access calls go through Tesla servers and do not connect directly to the car, likely limiting the ability to really hack the car through remote access.�
Jul 22, 2015
bmc Also realize that all Teslas are on the AT&T cellular network.
Even though all remote access calls should go through Tesla servers, this doesn't mean that the car isn't exposed to the open internet.
A bad actor with your car's IP address and the right credentials or authentication bypass will be able to make a call to all available API functions. If they are able to find further vulnerabilities, they could also perform functions that are not directly accessible through the "public" API as well.
I'm guessing this last part is what we are going to see at DEFCON�
Jul 22, 2015
muleferg In USA Today 7/22 there is an article about 2 guys hacking into a Jeep driving down the road at 70 mph.�
Jul 22, 2015
travwill Yeah, was on the nightly NBC news last night as well. This was a bit melodramatic but sure glad it was a Chrysler/Jeep! My parents already think the Tesla is going to be hacked all the time since I bought it ;-) This is going to be become a key safety concern and issue for autonomous driving especially in the next 5-10 years though - needs tackled.�
Jul 22, 2015
Zaxxon If only I had poster that story yesterday in this very thread.�
Jul 22, 2015
FlasherZ I also posted a thread yesterday morning in the cars & transportation section:
Security in the Connected Car era... Jeep remotely victimized
I don't believe that Tesla is immune, but I think it's in a much better position than the other manufacturers. A significant number of those Jeeps will remain unpatched for a very, very long time, given that it requires either a USB stick upgrade or a visit to the dealer.�
Jul 22, 2015
PatD Correct - sniff the traffic on your wifi network when your Tesla is connected and you will see plenty of traffic goes directly out over the Internet (Browsing, music, etc.) Makes sense that all remote access capabilities are only through the VPN communicating with Tesla servers, but this car definitely has an IP address on the AT&T network. When you're out and about (Not on wifi), go to www.whatismyip.com and you'll see your IP (Which should be a private address on AT&T's network.)�
Jul 22, 2015
FlasherZ It's known that Tesla uses OpenVPN to talk to the mothership, and that the "front door" is locked (talking to the car directly via IP address).
I discussed in the other thread how I think a real weak point to be exploited in ALL connected environments is unauthenticated/unsigned firmware updates. I believe it's highly likely that several of the modules used in the car are from suppliers who haven't thought to secure their firmware. That's my speculation as to what DEFCON goes after.�
Jul 22, 2015
lagann Nowhere does it say these are remote vulnerabilities. You might need physical access to the car for them.�
Jul 22, 2015
Jeff P Well, not necessarily. A lot of stuff has a public IP address, but it doesn't mean that you can get in there and mess around. As a software architect, I would probably build a lot of security into the communication between the car and Tesla's servers for control issues, even if none of them are particularly dangerous (like steering or braking). Lots of certificates, VPN, token exchanges, etc... there's a lot you can do that would make it crazy hard or impossible for the car to answer to anyone other than the mothership. The only attack vector that makes me nervous is getting new firmware installed, which I believe you have to confirm, and I assume the confirmation prompt has some kind of check for signed code or something.
Mostly talking out of my rear... I don't know how their magic works.�
Jul 22, 2015
wk057 The car's AT&T IP is useless also, as Tesla still uses the encrypted VPN connection over this link. Even if you MITM attacked via AT&T you wouldn't get anywhere.�
Jul 22, 2015
schonelucht That is to assume that the implementation is flawless. If I were looking at hacking a car, side channel attacks would be one of the first things to look at.�
Jul 22, 2015
Ingineer Yes, Tesla seems to have architected the system well, but as recent events have shown with all the zero-day vulnerabilities in open-source software, you can't take anything for granted. All they'd need is some strange race condition, buffer overflow or the like, and someone could get into the center display. It appears that Tesla has taken steps to ensure that the critical systems are somewhat isolated, and that the updates are performed by the Gateway ECU which is a separate embedded system, but with so many interconnected systems and so much complexity, there's bound to be a few weaknesses.
It really would deter a lot of potential "hackers" if they'd release an API and let sandboxed apps run on the center display. Then users would be able to develop cool new extensions without as much risk to Tesla.�
Jul 22, 2015
cryptyk I think it's more connected than you would suspect. Think about the things the main display can do:
enable or disable emergency braking
adaptive cruise
power the car off
parking brake control
enable or disable valet mode
set charge settings
enable and disable tow mode
etc
I think there are a lot of things you wouldn't want app developers doing to your car
You might suspect that each component exposes only a known set of functionality and checks for valid conditions, etc. You might also be surprised that developers are lazy and "if the main display checks that the car is stopped before applying the parking brake, we don't have to check it in the e-brake code"�
Jul 22, 2015
PatD I don't know enough about the cellular side of things, so I might be completely wrong, but. . . I'm not sure I'd agree here (Without more info.) Look at the Jeep hack that was reported. They did it was a Sprint burner. I'm wondering how possible it would be with an AT&T burner on the same network as the Tesla. Yes, they use an encrypted VPN, but that's for talking with the Tesla servers. Tesla's are still talking to the Internet without the VPN to access browsing, music, etc. So not all traffic is going over the VPN. If there's an opening, someone's going to figure out a way in if there's even the smallest crack (Pun not intended, but well taken!)�
Jul 23, 2015
Jeff P But that's kind of the point... I'm not convinced that the car would respond to anything other than Tesla's servers for actual control functions. I worked on a system like that last year. Sure you could likely get in front of the target system, but it wouldn't listen to you unless you could spoof the certs at the mothership, which is insanely unlikely. As for the other stuff that uses resources from the Internet, I'd be shocked if these were not a completely different, sandboxed system.�
Jul 24, 2015
bmc Until we see the actual hack, a lot of this is just pure speculation on our parts.
However, regardless of how this specific hack works, I am always going to be a little worried that there isn't a complete air gap between functions that control the critical functions of the car and the internet connected portions of the car.
Under ideal circumstances, you're right, the car has been designed to only respond to requests from authenticated and authorized source. However, the MO of a hacker to find routes that were overlooked in the original design. Without a physical gap, this will always be a battle of good vs. evil.
With all that being said:
1. I accept the little bit of risk that this exposes me to vs the convenience and utility that the overall connected nature of this car provides to me. This is the same as me using online banking, keeping my email on google's servers, etc.
2. I have complete confidence that Tesla's engineers are much better than those of the other car manufacturers. Hackers often go after the easiest targets. Hopefully they will stick to hacking Jeeps.
3. I'm convinced that events like DEFCON, where they effectively red team the car and share their findings with Tesla, actually increase the security of the car. I'd rather not have the vulnerabilities and 0-days only known to a smaller community.�
Jul 24, 2015
lagann I still have my money on most of them being local hacks that need physical access to the car, so, like a hack an owner can do, not some remote bimbo. One of them might be remote, and I have a feeling it would be really limited.�
Jul 24, 2015
FlasherZ Unfortunately, you don't get software update capability with an air-gap.
It's made more secure when you guarantee that *every* module has a secure firmware update path. If just one module has an insecure firmware update path, you simply push your own firmware to it that, in turn, accepts commands to send to the CAN bus via more firmware updates. Even if you separate the drivetrain CAN bus (and it seems as if it is), you still have tens of modules on which you must ensure security; that, or you have to secure and validate the CAN bus messages - which is an order of magnitude more difficult and will take a much longer time.�
Jul 24, 2015
kyalami According to this evening's national news, Chrysler has issued a recall on over 1 million vehicles that are vulnerable to the recently published hack using the U-Connect entertainment system.....gonna be expensive.�
Jul 24, 2015
Ingineer It's absolutely amazing to me that a company would release any kind of connected telematics system without having a remote software upgrade system in place. Of course one could posit that keeping the physical need to upgrade prevents an attacker from altering the software remotely. However, on a system that clearly has no real/effective air-gap, firewall or sandbox, this simply fails to make sense. No Chrysler/Fiat is going to pay the price. How many other systems like this are out there waiting to be discovered?
They should immediately hire those security researchers and see if they can find a way to "hack" in and patch the software. That would save them a bunch of $.�
Jul 24, 2015
strider But I doubt the web browser proxies through Tesla to access the Internet. So in that case you have a direct connection between the car and the OCS (origin content server ie web server) and possibly get the user to click on and load malicious code. So there is a vector there. The question as you posit is how separated the browser, radio, etc is from the rest of the system. There was a thread on the internal ethernet network inside the car. Haven't checked that thread in a long time, but IIRC lots of things had access to that network for the screens to communicate w/ each other. So if someone were to exploit the browser or radio they would have remote access to the internal ethernet network.
Here it is:
Successful connection on the Model S internal Ethernet network�
Jul 25, 2015
Jeff P You would think, right? Believe it or not, that kind of automation is rare outside of the really good software shops. It's downright non-existent in a lot of what I call "big dumb companies," where software is not their primary business (or at least, it is but they don't think so).
Again, I would be shocked (or very disappointed, at least), if the browser was not sandboxed in a way that made it unlikely or damn near impossible to leverage any kind of vulnerability into the operation of the car. I mean, think about the way phones and tablets work... the apps are bound to their own little box, including the browser.�
Jul 25, 2015
wk057 I've poked around at the browser. It won't connect to any of the on-VPN or in-car LAN IPs or anything that the old firmware leaked info about previously. The in car browser actually won't even connect to addresses defined in RFC1918 even if it's local. To get to pages on my in-house server (for my solar status stuff) while on WiFi I have to make a fake route to a non-local IP.
The browser also doesn't seem to connect to nonstandard ports entered in the address bar.
Overall it seems pretty locked down and I doubt there is much meat there for any real hack.�
Jul 27, 2015
W.Petefish Do the people attending the talk wanna meet up before hand? Say the TM booth in the vendor area?
Again, I will be reachable on 146.520 if y'all feel like chatting during the con.�
Jul 27, 2015
Ingineer Fun idea!
I'll bring my HT and monitor 146.520.�
Jul 31, 2015
W.Petefish DEFCON this year is not at the Rio... it is split between Paris and Ballys.
Anywho, the talk is in track 2 at 1400 local time on friday.�
Aug 5, 2015
lklundin Reaction to security issues: Chris Evans formerly of Google joins Tesla Motors
Chris Evans, formerly responsible for the security of Google's chrome browser, has tweeted that he joins Tesla Motors to lead security there:
Chris Evans on Twitter:
This is likely a reaction to the increased interest that Tesla has gotten from security researchers - as well as the apparently appalling state of security in cars from other vendors, that Tesla is so different from.
While probably everybody else are now wondering about last nights earnings statement and the 50.000 versus 55.000 projection, I am looking forward to see how the Model S fares in tomorrow's DEF CON presentation...�
Aug 6, 2015
1208 As long as Tic Tac Toe is installed on the Tesla it should prevent itself form doing something wrong.�
Aug 6, 2015
Majerus http://uk.reuters.com/article/2015/08/06/us-tesla-motors-hacking-idUKKCN0QB1AN20150806
That seems bad, "Cybersecurity researchers said they took control of a Tesla Motors Inc Model S car and turned it off at low speed, one of six significant flaws they found... "�
Aug 6, 2015
bollar It also says that a patch will be distributed to all vehicles by Thursday.
The Firmware Update Tracker does show that 2.5.21 has a very rapid rollout -- 144 cars report receiving it in the past week. Faster than any other release.�
Aug 6, 2015
Ingineer I got 2.5.21 on Tuesday. In DEFCON badge line now.
- - - Updated - - -
From a Financial Times article:
�
Aug 6, 2015
tom66 A browser level vulnerability (i.e. tell users to go to a specific website for Tesla "app" like a trip planner) could be used to gain access to the touchscreen controls via privilege escalation. From there, it's just a simple matter to access other features.�
Aug 6, 2015
Johan Hmm... they had to gain physical access to the car first and plug in an ethernet cable. I think that would be the big security problem? This doesn't scare med a lot....�
Aug 6, 2015
darthy001 Any streaming options for this defcon presentation? Would be very interesting to watch.
I've been on the receving end of a few of these kind of reported vulnerabilities by whitehat firms, and find whitehat hackers to be very "good" at using words like critical and similar for issues I would not categorise as such even if said vulnerabilities should of course be fixed promptly.
Needing physical access, as FT-article hints to, to the interior of the car would get in the "nothing to see here, move along"-category for me personally to be honest. I would have no problem with that until the flaw has been corrected.�
Aug 6, 2015
FlasherZ I posted the link to Wired's article in the Connected Car thread:
Security in the Connected Car era... Jeep remotely victimized
WebKit *could* be used, but they had to use physical access. You'd have to get the driver to surf to a malicious page, though, to make it work remotely.�
Aug 6, 2015
darthy001 Oh that bit regarding webkit is very interesting. Hopefully this could lead to some changes interms of browser version etc. Just hope the hardware can handle it�
Aug 6, 2015
FlasherZ The quote from the article said that Tesla already had the browser walled off, but did so even more when working with this team. It seems they might double down on the existing browser.
- - - Updated - - -
In addition, it seems that updates aren't signed by Tesla, but at a minimum the cars do require that the updates come *from* Tesla's infrastructure, so they'd have to compromise Tesla's update servers to get rogue firmware installed:
I suspect we'll be seeing signed firmware coming in the next year or so.�
Aug 6, 2015
darthy001 @flasherz I hope you are wrong' but you probably arent.. After a while that will take a lot of resources and lead to an unusable browser for any website built on newer tech... But that is mostly the case already�
Aug 6, 2015
jaguar36 Any hack that requires physical access really isn't a big deal. If you have physical access to any car, you're already be able to disable it, or even take control of it.�
Aug 6, 2015
tom66 It would be worrying if they are able to start the car without the key. As an example many BMWs have been stolen via an OBD-II connector. The thieves break into the car, either by smashing a window or prying the door open, then start it and program a new key via OBD-II.�
Aug 6, 2015
FlasherZ I'm a bit surprised because it was reported that Tesla had disabled the ability to send traffic via the Ethernet port unless the appropriate security code was entered - so I guess that's untrue:
Successful connection on the Model S internal Ethernet network - Page 29�
Aug 6, 2015
brkaus Also in big news: Researchers have found that ICE cars can be disabled by crimping the fuel line while the car is in motion, possibly causing safety issues. They noted that physical access is required. They also determined that turning the key off or cutting the wire to the fuel pump has similar results.
But seriously, hacking is still a bit of a concern even with the physical access requirement. No telling what could be hacked given enough time once access is gained.�
Aug 6, 2015
jaguar36 Could be they were able to just brute force the security code.�
Aug 6, 2015
lagann So what this is saying is that they could only do the remote vulnerability once they had done the physical vulnerability. Still not as scary as someone randomly just connecting to your car from the web.�
Aug 6, 2015
apacheguy Yeah, big deal. I don't care about vulnerabilities that require physical access except when I can use them for personal use (ie, jailbreak).�
Aug 6, 2015
FlasherZ While this is certainly not a big discovery, IMO, Tesla does need to learn from what they did find out:
* Firmware updates are unsigned / unauthenticated... this is one of the biggest attack vectors that is getting attention lately. There are a lot of subsystems within the car that have access to critical CAN buses, and I can see a path that leads you to drivetrain CAN bus manipulation if you string a bunch of stuff together
* Entertainment system / touchscreen is important - if you compromise it, you can do anything the operator can do.�
Aug 6, 2015
mkjayakumar I can put a mechanical contraption that would cut a fuel line or some such thing inside an ICE car that can be remotely triggered through a cell phone. Is that considered hacking?
Or how about I get access to someones userid and password through social engineering and steal their money from their bank account - is that also considered hacking?
this is pretty lame.�
Aug 6, 2015
donv So is hot-wiring a 1960s car considered to be "hacking"? Because this sort of sounds like a similar thing...�
Aug 6, 2015
mkjayakumar http://www.wired.com/2015/08/researc...eslas-already/
�
Aug 6, 2015
FlasherZ The updates may be signed, but the firmware pushes to some of the connected modules may not be.
E.g., Tesla signs the bundle and the car validates that signature; however, the car may unbundle the firmware package and begin pushing updates to modules. The TPMS module might not have the ability to validate firmware -- it may not be signed/authenticated. That could be used as a vector, then - someone develops a new piece of firmware for the TPMS module that permits it to generate arbitrary CANbus messages to the drivetrain; the attacker uses his privilege escalation on the touchscreen to push that firmware to the TPMS, which in turn gives him a method to tunnel CANbus commands through the gateway (masked as TPMS pressure inquiries or something similar).
That's all speculation, of course, but it's the vector that's getting the most attention nowadays in embedded systems.�
Aug 6, 2015
darthy001 good, I could not really believe my eyes about that one. Not signing updates seems like the worst rookie mistake ever.�
Aug 6, 2015
wk057 Fortunately with the update bundles signed they'd still have to find an approach to get into the system in the first place to replace the firmware on modules aside from hacking Tesla's servers that hold the signed updates.�
Aug 6, 2015
FlasherZ I'm leaving out the case where they compromise Tesla's servers.
The question is where on the car the signature validation is done. If it's done on the touchscreen - the attackers had root. They simply bypass the Tesla bundle validation checks and download/directly push their own unverified firmware to the unsecured module(s) using the same method Tesla does.
From this thread:
Successful connection on the Model S internal Ethernet network - Page 21
...there's an interesting snippet that suggests the .102 IP address on the bus (the gateway) may handle the elements of firmware push (at least I see filenames there that would indicate charger and battery management firmware being updated). So then you have to look at where the bundle signature validation is taking place and how the touchscreen (which handles the networking) gets the firmware updates to the gateway - does the touchscreen push the entire large firmware bundle, meaning you'd have to compromise the gateway to bypass signature checks? or does it unbundle on the touchscreen and start handing individual component firmware images to the gateway to start applying to modules, in which case you might be able to bypass the bundle signature checks, fetch your own module firmware, and make the TPMS module do what you want to do?�
Aug 6, 2015
jvonbokel I think they disabled the one open port that was discovered, but the researchers appear to have used the port that the instrument cluster connects through.�
Aug 6, 2015
wk057 Well, I think the compromised servers is part of what was referred to regarding unsigned updates.
As for the internal layout, I'm pretty sure the "gateway" is just a small processor that is physically part of the MCU housing. I'm not sure exactly the specs on it, but I've checked out data dumped from various flash chips and an SD card on the gateway and MCU. I'm reasonably certain the actual update process is handled by the gateway but the firmware package is downloaded by or via the MCU (which has internet access). It would make sense for the gateway to verify the signature in this case.
However the gateway would need to communicate with the other modules to update their firmware. I'm doubtful there is signature verification at this level.�
Aug 6, 2015
FlasherZ Right, and that's the attack vector that is getting the most attention right now from embedded systems attackers -- the USB controller chip hacks, the HD firmware hacks, etc. are all relying upon insecure firmware updates that can easily hide information. The question I ask is - if you can gain root on the touchscreen (say, via the WebKit attack vector mentioned), could that turn into compromise of the drivetrain via arbitrary CANbus messages?
A lot of the talk today is about how Tesla walls off the MCU from the drivetrain... but I can see how you might circumvent that by researching some of the modules and pushing your own firmware to that module that would give you the ability to send to the CANbus -- IF you can get past Tesla's bundle signature checks. You might be able to accomplish that with root on the touchscreen if the conditions are right (if the MCU unbundles the firmware and does the signature checking).
I surely hope it's not the MCU that's doing the unbundling of firmware and validation of signatures -- I hope it's via a separate, dedicated processor (a/k/a "the gateway") on which it is far more difficult to acquire superuser.�
Aug 6, 2015
LetsGoFast It appears that the attack was a pretty complicated one involving a cascade of small vulnerabilities, so it may well be that the Ethernet bus was shut down effectively until they compromised some other component. Mahaffy wrote a generally quite complementary blog post about his experiences.�
Aug 6, 2015
wk057 As far as I could tell in testing with a salvage vehicle was that the MCU has no CAN access. Everything you do on the MCU that could affect anything with the drive system or anything important was sent as a request to the gateway, which appears to handle the CAN communication. I have no idea what the criteria the gateway has for honoring these requests, but it would stand to reason that hacking the MCU would at most just get you ethernet comm with the gateway, which can already be done physically if you feel like removing the dash.�
Aug 6, 2015
FlasherZ Ahh, but the MCU *could* have CAN access if it used the software update mechanism to reach the CAN bus, and I'm offering how you do it if you can compromise the MCU remotely.
Let's assume the following scenario:
The attacker learns that a module (let's just say TPMS) is made by ABC Corp. and does not use validated or signed firmware from ABC Corp. The attacker learns about the microcontroller and its CANbus connection, and disassembles the firmware to learn what it does and the messages it sends. He formulates a new firmware that - instead of accepting firmware image update commands and dropping to the bootloader to update - instead uses information inside a fake image to send arbitrary CANbus messages.
Okay, so now he needs to get this firmware onto the TPMS module.
Let's assume for a moment that Model S does signature validation on the MCU - that's easier for an attacker to work with. The attacker gains superuser access, downloads his special TPMS firmware onto the MCU, and pushes it via the gateway to the firmware updater, just as Tesla would do. It's not subject to Tesla's bundle signature or server source requirement because he already has superuser access and are pushing the individual image via the gateway (bypassing Tesla's unbundling and validation checks). The gateway happily pushes the attacker's new firmware to the TPMS module. As the module's firmware updates are insecure (unsigned / unvalidated from ABC Corp.), it happily installs the new code onto the TPMS module and restarts it. Meanwhile, the attacker installs a trojan that actively makes a connection out to a command & control server.
Now, the attacker wants to send an arbitrary CANbus message. From the command & control server he sends a packet containing whatever magic he needs, along with the arbitrary CANbus command he wants to execute. The trojan on the MCU receives that, then formulates a special firmware image update and sends it to the gateway. To the gateway, it appears that there's another image upgrade to the TPMS module. The TPMS module's special attacking firmware ignores the whole image update process and instead takes the firmware update (a cloaked CANbus message), and dumps it onto the CANbus.
This is the easiest scenario to imagine. It's foiled with a number of different architectural components:
First, if the "gateway" functionality is what does the unbundling and signature validation, having superuser access on the MCU doesn't accomplish anything because you won't be able to send a properly-signed bundle to the "gateway". But it's unclear whether Tesla handles signature validation on the MCU (which would render it vulnerable) or on the gateway.
Second, Tesla could always layer insecure/unsigned module updates in its own signature wrapper that is confirmed by the gateway - like the first case, it would take away the ability for the attacker to sign the firmware update and it would be ignored, not pushed by the gateway.
Third, the gateway could always refuse to update firmware on modules unless the car was in update mode. The gateway would reject any image update messages if the car was deemed to be "active" in any way, and this would eliminate the vector. (That said, it would still be vulnerable to an attack whereby the hacked TPMS code stores the CANbus message to be dumped onto the bus at a later time when the car is active.)
Fourth, Tesla could insist all module suppliers sign and validate firmware updates in their modules as a condition for being a supplier.
Fifth, Tesla could sign and validate CANbus messages so that the TPMS couldn't inject a "hit the brakes hard" message.
- - - Updated - - -
EDIT: The bottom line is that there is a way to connect through the systems to get a message to the CANbus, if one works hard enough.�
Aug 6, 2015
lklundin In addition to the much praised wireless firmware updates from Tesla, their supercharger infrastructure is unique, and the supercharger unit is doing at least some kind of communication with the car (to determine battery state and whatever).
So let's say that Tesla becomes aware that their wireless firmware updates can be compromised (via a man-in-the-middle attack or whatever these clever but bad people can come up with).
Then, if Tesla were able to push out firmware updates via the supercharger unit (that they are in control of), then they could
1) send out a general message (via their website or snail mail or whatever) instructing Tesla owners to switch off the wireless antenna of their car, and
2) instruct the Tesla owner to go to a supercharger station and connect - and get the firmware update via the cabled connection there,
3) Optionally, once the firmware installation is complete, it could instruct the Tesla owner to re-activate the wireless antenna.
I would not be surprised if a software company like Tesla had thought about using their supercharger infrastructure as a trusted connection to the Tesla vehicles.
Since this is pure speculation on my part, I would be curious if anyone actually knows about this.�
Aug 6, 2015
Ingineer The gateway is a 32bit freescale microcontroller. It resides in the same box as the MCU (touchscreen), but is otherwise totally separate. It's connected via Ethernet to the Tegra3 Linux box, and it has access to all the cars CAN and LIN buses. When Tesla sends an update, the Linux box downloads the bundle only from Tesla's servers and only from over the VPN. Once downloaded it verifies the bundle and if it's valid, sends it to the gateway as a tarball. (and of course updates itself and the IC via ethernet) The tarball has firmware for all the cars various embedded systems and is fully CRC32'd. If you were to gain access to the gateway, you could most definitely compromise the other systems, but it's unlikely without physical access.
The gateway also stores information unique to each car, such as the VIN and the VPN keys, so if an attacker had these they could impersonate the car, but not the other way around without Tesla's private key (asymmetrical crypto). If you impersonate the car probably the worst you could do is grab firmware tarballs.�
Aug 6, 2015
FlasherZ Can you help me understand what you mean by "fully CRC32'ed"? Since that's just a data verification function, it seems a malicious attacker with control of the MCU untar it, make his own bundle with his own compromised firmware, perform the CRC32 calcs to make the check work, then export that to the gateway? Or is it more than CRC32, and the tarball is signed crypotgraphically, so that the gateway validates it and the MCU couldn't modify it?
(I'm amazed at the level of detail you know about the makeup of the system.)�
Aug 6, 2015
Ingineer The CRC32 is an integrity thing, not a security feature. The Gateway is secured such that you don't have access to it. (at least not anymore after 2.5.21 supposedly) Tesla has also closed the trick used to gain control of the MCU, so you'd have to get past that fix too.
Again, with physical access you can probably manipulate these things, but we're talking a complete remote hack of some sort, which was only theorized in any event.
I'm at DEFCON and going to see the presentation tomorrow. I'll report back.�
Aug 6, 2015
apacheguy Does the firmware get pushed to the gateway at time of install or as soon as the download has been verified and then it gets queued? Any idea as to how one could hypothetically clear a downloaded update from memory and then reload it at a later time?�
Aug 7, 2015
Johan Reading this thread makes me think back to the early days of firmware 4.xx.... Oh, that would have been like the Wild West in the early 19th century: Acres upon acres of untouched green pastures (for hackers that is).�
Aug 7, 2015
FlasherZ Right (integrity vs. security) - so this means that if you had control of the MCU, you could (at least based on this information) bypass Tesla's bundle signatures, roll your own tarball including your hacked TPMS code (see example earlier), generate proper CRC hashes for it, then send it to the gateway and have it installed on the module for use later.
Looking forward to hearing what they learned in more detail.�
Aug 7, 2015
apacheguy @Ingineer - any interest in live blogging the talk?�
Aug 7, 2015
apacheguy Blog is up:
Hacking a Tesla Model S: What we found and what we learned | Lookout Blog
---update---
Kind of disappointed. Was really looking forward to the tool they were going to release to let us get access to all to this diagnostic info. Turns out it's just a fancy UDP capture tool and the exploits have already been patched rendering it useless. Not to mention I'd have to dismantle the MCU to rip the VPN keys off the flash memory since they didn't bother to release those either.�
Aug 7, 2015
pgiralt This was great:
Tesla engineers are Monty Python fans: there is a script in the car which makes a request to hxxp://firmware-bundles.vn.teslamotors.com:4567/custom-packages/knights-who-say. The response body contains thousands of lines of the word �ni��
Aug 7, 2015
wk057 The VPN keys are car specific, so, need to get your own keys from your own car's SD card.�
Aug 7, 2015
Ingineer Yes, not a scary hack at all, physical access means you can do anything. Why shut off the car with all this when you can cut the brake lines, etc.�
Aug 7, 2015
apacheguy Right. IMO, security risk is like 2/10. This is definitely not something a valet is going to pull off while they have your car for a couple hours. This requires technical knowledge, dismantling complex car components, having special Ethernet connectors, cracking into Tesla's VPN, obtaining a rolling code, broadcasting another code somehow derived from the first to wake up the blocked service port, then finally logging into the MCU using the token, and injecting malicious code. Extremely far fetched.
As Ingineer points out they might as well cut the brake lines or loosen a few bolts if they're going to all that trouble.�
Aug 8, 2015
FlasherZ They "welcome further research" on the aspects I thought they would be addressing... even with a gateway, I'd be looking at methods to traverse that gateway, one of them being the software update mechanisms (as I describe above).
�
Aug 8, 2015
apacheguy Probably cuz they didn't want to brick their car which is understandable. I myself have zero concerns about someone sending a malicious update to the car. I don't install any update until I've checked it out on TMC and believe me, Tesla would pull the update within 24 hours at any rate.�
Aug 8, 2015
redi All true. But still some pretty basic admin/network "issues" noted once inside the perimeter. These undoubtedly will be hardened going forward but these are the typical soft inside used once another vector through the hard outside is discovered.�
Aug 8, 2015
FlasherZ My point upthread is that Tesla may not know about an update, if it's possible for someone to bypass Tesla's signatures through root on the CID. Certainly they didn't want to brick the car - but maybe there's something cheap enough for researchers to get their hands on.
Here, they had root on the CID from physical access, and were not able to figure out remote exploit vectors. It sounds like Tesla did some more jailing/walling of the browser to help limit that as an infection vector. But - like the researchers concluded in their point about "hard shell, soft chewy center" - we have to assume that at some point it may be possible for someone to gain root access in the CID, and figure out what can be limited there.
So yes, this particular hacking effort was not a big deal, and I hope it causes Tesla to look more closely at closing some other potential holes (at a minimum, having the IP/CAN gateway do some sort of validation of update sources, if it already does not do that). I'm happy that they have convinced the researchers that this is a relatively safe car.�
Aug 8, 2015
W.Petefish There is also a TM/SpaceX party tonight... it may only be by invite...�
Aug 8, 2015
wk057 Honestly I think any hack that involves more than 30 seconds of physical access to the car is not a real hack. If it can't be done completely remotely, or at the very least after a sneaky person manages to plug something into a diagnostic port during a valet or something similar, then other physical "hacks" are more effective as others have mentioned (cutting the brake lines, loosening an important bolt or two, etc etc).
I don't consider a hack that involves removing parts of my dash to pull off any hack that I would have even the slightest bit of concern about in the real world. So I really hope people don't read too much into the headlines on this particular "hack." While impressive that they were able to get so far with physical access, this isn't useful to anyone at all as far as causing mayhem like a "legit" hack would have the potential to.
If they come back later with a hack that if I visit a particular website on the in dash browser, or load a particular file or song on a USB drive, and that gives them OTA remote access to something... then I'll be concerned. But I don't see any avenue where that would be possible.
I think if some entity really wanted to hack the Model S remotely they would have to do so by bribing or blackmailing key Tesla employees, or personally infiltrating the same.�
Aug 9, 2015
jerry33 Right. Social Engineering beats any security system.�
Aug 9, 2015
tls So, I was at DEFCON and saw this talk and I came away seriously unimpressed. But not for the reasons you might think.
For background, I have spent my career (25+ years) bouncing back and forth between the computer security and embedded Unix worlds. I've spent hundreds, maybe thousands, of hours thinking about how to build systems that are resilient in the face of attacks like this, and a fair bit of time breaking into competitors' gear to see how they did it.
I walked out of this talk with a few main things in mind:
1) The researchers "just happened to" have set themselves ground rules that "just happened to" prevent them from investigating any lines of attack on the car that would have been really technically hard. Setting the rule that they wouldn't alter persistent state (in-memory attacks only) meant they didn't have to -- because they "weren't allowed to" -- investigate propagation of compromise via the firmware bundles that the CID holds for other devices. Setting the rule that they would attack infotainment systems only meant that they didn't have to conduct any kind of remote-oracle attack on the gateway and its VAPI interface, or even figure out what it was or see whether it had any other vulnerabilities, such as boot-time vulnerabilities. It also meant they didn't have to really dig into the boot process for any of the elements of the system to see whether there were a vulnerability there that could allow persistent compromise after a single remote attack, or loading of unsigned firmware, etc.
Every one of these lines of attack was used in Miller & Valasek's Jeep work, every one represented an impressive technical achievement, and every one of them yielded results. So from my point of view, why didn't these guys achieve remote compromise of the Model S? Because -- giving them the benefit of the doubt, I'll say it was accidental and probably more aimed at not having to buy their friend a new $100K car -- at the outset, they set ground rules that ensured they would not do the very hard work that might have produced that result.
I think unfortunately it's telling that they also gave up "after a few hours" at the task of exploiting a known remote code execution bug in the browser (a remote exploit!) "because they had an easier way already" via physical access. Is it a big pain in the tuchas to bootstrap a browser you can crash remotely (and know why, and know memory's being overwritten) into a remote shell on a system with a funny architecture and oddball C runtime? Sure. Once you can reproduce the crash, do you know as a security researcher it's possible? Pretty much yes, and if you already have another means of access to the system it's trivial to confirm this. What's in between? Potentially, weeks and weeks of fiddly, unpleasant, technically demanding work. They just didn't do it.
2) The presenters' repeated (and somewhat disrespectful, in my opinion) comparison of their work to the Jeep work really just made them seem inexperienced with embedded systems and vehicle systems, and unaware of the details of the Jeep work (which had been presented at Black Hat several days earlier). It didn't say much about the architecture of the Jeep, the Tesla, or about either parties' attacks.
For example, there was repeated, emphatic praise of the Tesla "architecture" and slagging of the Jeep. But in fact, architecturally, these two systems for mediating user input/output and communicating on the CANbus with vehicle systems are strikingly similar. In particular, both cars embed in the "head unit" a separate processor which takes abstract commands from the touchscreen and performs all CANbus communication. In the Jeep, this "gateway" is connected to the infotainment system CPU by an SPI bus. In the Tesla, it's connected by an Ethernet. Neither car actually allows any user-exposed CPU to perform CANbus messaging - in fact, since the Tesla has far more other stuff connected to the bus (Ethernet) that can talk to the gateway, thus far more attack surface, I'd have to say "advantage-Jeep!" on this one.
So why did the Jeep guys manage to do arbitrary CANbus messaging while the Tesla guys did not? The answer seems pretty clear: they actually bothered to try! They reverse-engineered all four of the gateway's firmware, the managed firmware update process for devices other than the touchscreen, the touchscreen-to-gateway protocol, and the car's CANbus messaging. If the Tesla guys attempted to do any of these things, they would appear to have failed -- though they did expressly say they did not try to do some of them because of their "ground rules".
I think it is a pretty fair suspicion on my part that had Miller & Valasek had a go at these interfaces on the Tesla as they did on the Jeep, they would have found something. This stuff is freaking hard to get right (having gotten my fair share of it wrong myself, in my career, and likely to do so again).
So -- given the known browser bug, equivalent in effect to though more challenging to exploit than, the Jeep's exposed DBus port -- why wasn't there a remote compromise of the Model S that allowed arbitrary CANbus messaging, like there was for the Jeep? My take on it is that nobody did the (potentially very) hard work, for whatever reason. Not to say there wasn't similarly hard work on the Jeep. If you want to disassemble and patch a bunch of nasty Super-H code using a buggy tool, be my guest.
3) There was a serious Tesla reality distortion field in effect. They had JB Straubel up on stage and DEFCON staff and presenters alike lavished him and the company with praise (in fairness, Miller & Valasek said some really nice things about Jeep too, but nobody had a Jeep exec up to the front to do shots). Tesla brought a car to the "car hacking village" and unlike all the other cars there, nobody was allowed to remove any interior or exterior trim -- in fact, for most of the first day nobody was allowed to even sit in the car without a Tesla employee in the passenger seat. Tellingly, when things calmed down a little bit I did some brief experimentation with the vehicle and determined that every wireless interface had been disabled, including Bluetooth. The booth staff looked extremely uncomfortable when I asked why.
(Just to be clear, to me the reason why seems pretty obvious: they didn't want someone fuzzing their Bluetooth stack or further probing the browser, and if the car hadn't had -- guessing here -- all its antennas snipped, both those things would surely have happened)
4) One thing the presenters got right: OTA upgrade is a lifesaver. If for no other reason, because it means there need be no readily exposed port that would allow an easy attack on the vehicle by someone who does have physical access. Unfortunately, it does also represent additional remote attack surface. If Tesla ever has its OpenVPN servers (or any of the infrastructure behind them) popped -- look out. But we accept this risk with regard to almost every modern device in our lives, so it does not seem so different to accept it for our cars.
The bottom line for me: this was an interesting investigation that probably would have yielded far more dramatic and scary results if conducted as aggressively as the Jeep work -- or, really, any work by top security researchers. As it was, it was so constrained, and the results so limited, that if it weren't for the wow-Tesla-sexy factor I'm not sure it would have even been accepted (it probably would have been, but then again, similar attacks on other cars have been demonstrated for years now). Also unfortunately the Tesla RDF was not an entirely positive thing.
Any way you slice it a system with the complexity of the Model S has a lot more attack surface than something simpler like a modern ICE vehicle. That means Tesla has a lot more work to do to defend it. I'm confident they can, but at present we have little data to know whether they actually have or will.�
Aug 9, 2015
wk057 Thanks for the view from the front lines. I had come to many of the same conclusions.
Anyone want to go in on a used or salvage Model S and actually try some no-ground-rules (aside from not physically destroying the car) hacks?�
Aug 9, 2015
vvanders I think one striking difference between the Jeep hack and Tesla is the level of engagement and willingness to work with researchers and provide a bounty program.
I remember when the Jeep hack leaked Chrysler was threatening legal action rather than hiring them.�
Aug 9, 2015
tls I don't think anyone doubts Tesla's good intentions! I am perhaps a little more jaded about the entire public-relations process around them than you're inclined to be. Given the costs associated with actually doing the security engineering behind the scenes, I'd say that what's on offer in the bounty program is de minimus. But so are most bug bounty programs.
I would have been a lot more impressed if Tesla hadn't effectively vaccinated the car they brought to the show against any on-site research! How many people exactly are going to actually be able to pony up the cost of a Model S, have the skills to do research that could potentially destroy it, but cross the motivational threshold because of up to $10K from a bug bounty? You're still $90K in the hole and the population who could do this stuff is not large in the first place. The sub-population that's unfazed by a $100K cover charge? Way smaller.
Never mind that if you're serious about this, you can forget about using that beautiful car as your daily driver. You'll have it torn apart as your work in progress far too much of the time. So if you love the Model S (like I do) and want to actually drive yours, you'll need to be able to afford two if you're going to make one the target of your research.
A bug bounty for a browser or an operating system is more than a little different: it doesn't cost $100K to play that game.
Sure. Jeep's initial response had nothing like the slickness of Tesla's. Of course -- though it hardly reduces their responsibility -- Jeep also seem to have been blind-sided by a component supplier. It was Harman-Kardon's box that exposed that "run anything!" port to the Internets.
It bears consideration though that, unless I misunderstood their talk, in the course of their experimentation M&V may have actually exploited security holes in other people's cars without permission (though likely without intending to do so) (If you were there, or have the video of the Black Hat talk, I'm referring to the part about suddenly realizing "hey, that car's in Oklahoma somewhere!". I didn't see the rerun of the talk at DEFCON so if they clarified this and I have it wrong, my bad). That alone is pretty likely to get lawyers riled up.
Obviously some of R&M's "ground rules" for their Model S work were aimed at avoiding anything like that. Unfortunately the actual rules they chose avoided a lot more, as did their decision to not take the bull by the horns and dig in to the remote vulnerability they did notice.�
Aug 9, 2015
W.Petefish I may or may not be working with someone on it.�
Aug 10, 2015
jvonbokel You probably have more knowledge from seeing their talk, but from what I understood of the articles I read online, they were able to scan for vulnerable cars by connecting a laptop to Sprint's network through a burner phone. It didn't sound like the attempted anything on any of those cars, but they used that method for their attack on the Jeep that was the subject of their research to prove that it could be done without physical access. It was implied that it might be difficult to find a specific car, but I got the impression that if they scanned and logged vulnerable cars over time, they could build a database of all vulnerable cars and target individuals from that list.�
Aug 10, 2015
Majerus Why not just rent one from enterprise?�
Aug 11, 2015
W.Petefish See my above comment. PM works well.
My workings have other things in mind... but even then, ethics are something that are needed to be adhered to. Follow the BCP for everything you discover. The first duty a penetration tester does when a vulnerability is found is report it. I should hope that everyone here has that same ethical standard on mind.�
Aug 11, 2015
apacheguy Depends on the vulnerability. If it's critical enough that it allows remote exploitation and affects the drivetrain I agree. If it requires several days of tinkering with the car, reporting to the manufacturer before releasing to the public is just plain silly. We wouldn't have jailbroken cellphones otherwise. There are perfectly legitimate and safe circumstances where vulnerabilities can be exploited.�
Oct 16, 2015
apacheguy Dutch user just posted about an exploit giving root AND diag screen access on the CID
Hacking v7
How come we aren't all over this? Note that the OP has 2.5.36, which should have patched all known vulnerabilities.�
Không có nhận xét nào:
Đăng nhận xét