Tesla driving Dell exec found hacker-flaw, not just a plugin issue % Solution: allow drivers to turn off remote access = no hacking %
http://gas2.org/2013/08/27/tesla-model-s-flaw-may-make-it-vulnerable-to-hackers/ Tesla Model S Flaw May Make It Vulnerable To Hackers August 27, 2013 by Christopher DeMorro Forbes [image http://c1gas2org.wpengine.netdna-cdn.com/files/2013/08/tesla-model-s-touchscreen.jpg ] Electric cars stand to improve upon the century-old concept of the automobile in exciting and promising new ways. The Tesla Model S proved this by receiving a five-star crash test rating, and even breaking one of the testing machines. However, Tesla’s decision to use its own API, which has opened it up to the potential to being hacked. The flaw was found by George Reese, a senior executive for Dell and a Tesla Model S owner himself. It’s one of the potential worries all automakers, and not just Tesla, has to take into consideration going forward. However, Tesla’s decision to use its own API, or application programming interface, could allow outside users to remotely activate things like the sunroof, horn, and lights. Users can also cause excessive wear on the electrical systems and batteries, seriously shortening their lifespan. This stems from Tesla’s decision to use an iPhone or or Android app to give Tesla owners access to information and options on their car. As cars and other devices become more and more connected, the potential for hacking and abuse also grows. While none of this is a safety concern per se, car hacking is already starting to become an issue for automakers all over the world ... [© gas2.org] http://www.forbes.com/sites/reuvencohen/2013/08/22/newly-discovered-flaw-may-open-the-tesla-model-s-to-potential-attack-from-hackers/ Newly Discovered Flaw May Open The Tesla Model S To Potential Attack From Hackers by Reuven Cohen, Contributor 8/22/2013 There is an interesting post over at the O’Reilly Broadcast website from George Reese, a Senior Distinguished Engineer and Executive Director of Cloud Computing at Dell DELL -0.18%. He outlines some potentially serious flaws found in the Tesla Model S car’s API or application programming interface. Essentially the exploit may allow remote users to trigger actions in the car. “Once logged in, you can go to https://portal.vn.teslamotors.com/vehicles, for example, and see all cars that the logged in user has registered with Tesla,” says Reese. “It’s important to note that there’s nothing in the API that (can? should?) result in an accident if someone malicious were to gain access. Having said that, there is enough here to do some economic damage both in terms of excess electrical usage and forcing excess wear on batteries.” The post goes onto outline the problems in greater detail, “The authentication protocol in the Tesla REST API is flawed. Worse, it’s flawed in a way that makes no sense. Tesla ignored most conventions around API authentication and wrote their own. As much as I talk about the downsides to OAuth (a standard for authenticating consumers of REST APIs—Twitter uses it), this scenario is one that screams for its use.” Reese notes that this model suffers from the following flaws: It cannot safely operate over any channel but a trusted SSL connection (minor) It requires the sharing of the user’s password with third-parties (major) No mechanism exists for cataloging applications with active tokens (significant) No mechanism exists for revoking the access of a compromised application (major) The automated expiration of tokens in 3 months encourages applications to improperly store your email and password (significant) “There’s no immediate danger from this architectural flaw that compromises the safety of the Model S. However, it does open up the following potential attacks You want to leverage a tool on a web site with some useful functionality. You enter your email/password. They willfully and incorrectly store that information and are subsequently compromised (or worse, they use it themselves). An attacker gains access to a web site’s database of authenticated tokens. It has free access to all of that site’s cars up to 3 months with no ability for the owners to do anything about it. As noted above, the impact of any of these very real attack vectors is pretty much economic. I can target a site that provides value-added services to Tesla owners and force them to use a lot more electricity than is necessary and shorten their battery lives dramatically. I can also honk their horns, flash their lights, and open and close the sunroof. While none of this is catastrophic, it can certainly surprising and distracting while someone is driving. Perhaps the scariest bit is that the API could be used to track your every move.” [2013 Forbes.com] http://broadcast.oreilly.com/2013/08/authentication-flaws-in-the-tesla-model-s-rest-api.html Authentication Flaws in the Tesla Model S REST API By George Reese August 21, 2013 [audio http://app.readspeaker.com/cgi-bin/rsent?customerid=14&lang=en_us&url=http://broadcast.oreilly.com/2013/08/authentication-flaws-in-the-tesla-model-s-rest-api.html ] As many of you know, APIs matter to me. I have lightbulbs that have APIs. Two months ago, I bought a car that has an API: The Tesla Model S. For the most part, people use the Tesla REST API via the iPhone and Android mobile apps. The apps enable you to do any of the following: Check on the state of batter charge Muck with the climate control Muck with the panoramic sunroof Identify where the hell you car is and what it's doing Honk the horn Open the charge port Change a variety of car configuration settings More stuff of a similar nature For the purposes of this article, it's important to note that there's nothing in the API that (can? should?) result in an accident if someone malicious were to gain access. Having said that, there is enough here to do some economic damage both in terms of excess electrical usage and forcing excess wear on batteries. Sidebar: What's an API (application programming interface)? In an oversimplified sense, an API is a set of web pages that something can visit to trigger actions in your car. Once logged in, you can go to https://portal.vn.teslamotors.com/vehicles, for example, and see all cars that the logged in user has registered with Tesla. The Authentication Protocol The authentication protocol in the Tesla REST API is flawed. Worse, it's flawed in a way that makes no sense. Tesla ignored most conventions around API authentication and wrote their own. As much as I talk about the downsides to OAuth (a standard for authenticating consumers of REST APIs—Twitter uses it), this scenario is one that screams for its use. Authentication happens when you call the /login action with the email address and password of the Tesla customer. This is the same email address and password used to log in to www.teslamotors.com. Every customer has one because this web site is where the customer builds their car. The authentication action creates a "token" that is valid for 3 months. Any further requests use that token for validation. You don't use the email address/password again until the token expires in 3 months (assuming you store the token somewhere). This model suffers from the following flaws: It cannot safely operate over any channel but a trusted SSL connection (minor) It requires the sharing of the user's password with third-parties (major) No mechanism exists for cataloging applications with active tokens (significant) No mechanism exists for revoking the access of a compromised application (major) The automated expiration of tokens in 3 months encourages applications to improperly store your email and password (significant) Potential Attack Vectors There's no immediate danger from this architectural flaw that compromises the safety of the Model S. However, it does open up the following potential attacks: -> You want to leverage a tool on a web site with some useful functionality. You enter your email/password. They willfully and incorrectly store that information and are subsequently compromised (or worse, they use it themselves). -> An attacker gains access to a web site's database of authenticated tokens. It has free access to all of that site's cars up to 3 months with no ability for the owners to do anything about it. As noted above, the impact of any of these very real attack vectors is pretty much economic. I can target a site that provides value-added services to Tesla owners and force them to use a lot more electricity than is necessary and shorten their battery lives dramatically. I can also honk their horns, flash their lights, and open and close the sunroof. While none of this is catastrophic, it can certainly surprising and distracting while someone is driving. Perhaps the scariest bit is that the API could be used to track your every move. The core issue, however, isn't how bad an attack could be as a result of these specific flaws. Instead, I'm commenting on the larger picture of the Internet of Things in which everything has an API and everything needs to be secured reasonably. I don't think the Tesla software engineers have given the security of the REST API its proper due and I see a common theme among Internet-connected "things" (the Hue being a good example) of not thinking through the security impacts of what they are doing. What's truly stupid here is that there was no reason for Tesla to write their own API authentication. There are, IMHO, two common models for API authentication: User-to-system (as is the case with the Tesla API) System-to-system OAuth is the proper authentication mechanism for User-to-System authentication, and it's truly unfortunate that Tesla ignored it. Other Notes Applications don't talk directly to the car. They talk via a web portal that processes requests and sends them on to the car. As far as I can tell (with very limited visibility), Tesla keeps a very strong security separation among the various operational components of the car. This is NOT about Tesla in the end. It's about how we should be approaching API design in a world in which everything has an API. Hint: it starts with security and ends with the functionality, not the way Tesla, Hue, and most people are doing it today. Hue has a much easier to exploit flaw, but all an attacker can do is turn on/off lights and change their colors. [© 2013, O'Reilly Media] For all EVLN posts use: http://electric-vehicle-discussion-list.413529.n4.nabble.com/template/NamlServlet.jtp?macro=search_page&node=413529&query=evln&sort=date Here are today's archive-only EV posts: EVLN: Wanxiang bails, Johnson Controls funding A123 bankruptcy case EVLN: Urban/city EVs for the mature/aging driver's needs EVLN: $2M for ASU to develop vehicle-structure-incorporated pack EVLN: BYD T3 Electric Transport Van, Spy Shots EVLN: Volta to install its sponsor-funded/free-to-use EVSE in AZ + EVLN: ZOE's ‘Techies’ award most environmentally friendly fleet EV {brucedp.150m.com} -- View this message in context: http://electric-vehicle-discussion-list.413529.n4.nabble.com/EVLN-Tesla-s-API-remote-hacker-access-shorten-pack-life-tp4664913.html Sent from the Electric Vehicle Discussion List mailing list archive at Nabble.com. _______________________________________________ UNSUBSCRIBE: http://www.evdl.org/help/index.html#usub http://lists.evdl.org/listinfo.cgi/ev-evdl.org For EV drag racing discussion, please use NEDRA (http://groups.yahoo.com/group/NEDRA)
