Live data from Hacker News

Tesla PowerWall 2 Hack

github.com

111–120 of 175 posts

Re: Tesla PowerWall 2 Hack

#111
post #95
post #76

Earlier quoted context omitted.

There is no such thing as irresponsible disclosure. You are allowed and encouraged to publish your security research WHENEVER YOU FEEL LIKE. The term “responsible disclosure” is a shady tactic to frame publishing immediately and in full to those affected by the vulnerability as irresponsible. It is not.

> The term “responsible disclosure” is a shady tactic to frame publishing immediately and in full to those affected by the vulnerability as irresponsible. It is not. What? Have you even tried to understand what responsible disclosure is? It is about giving the vendor a chance to protect their consumers before teaching the public how to exploit a vulnerability . The vendor still gets put on blast when the vulnerabilit…

The vendor’s existence and actions are irrelevant to whether or not it’s okay to publish your research at any time. It is never irresponsible to disclose one’s research in public, in full. Vendors don’t factor in to it at all.

Re: Tesla PowerWall 2 Hack

#112
post #2

Did they even try to submit these issues to Tesla? They have a bug bounty program and have been reasonably good about patching issues in vehicle software. If not, this is pretty irresponsible disclosure.

"Responsible disclosure" is an invention of vendors who want you conforming to their policies and timelines (and more). Tesla is also "good" at disabling aspects of people's property (like ethernet ports, or ability to receive future firmware updates) when they dislike what people find "wrong" or otherwise in Tesla software.

I have followed this shift in vocabulary -- now the term for not dropping a 0day is "coordinated disclosure" and usually implies that the researcher has final say on the disclosure timeline. But what I don't understand is why so many folks in infosec pretend as though "responsible disclosure" has always been a dirty word -- from memory, it was the primary term used by the infosec community until only a few years ago.

Re: Tesla PowerWall 2 Hack

#113
post #88

Earlier quoted context omitted.

> That said, the term "responsible disclosure" is Orwellian, and you should very much avoid using it. It seems you disapprove of the phrase "responsible disclosure" because it's ambiguous and can be used as a cudgel. That's no different than the term "Orwellian", which is ambiguous and can be used as a cudgel. All people are saying is that it's better to give the vendor a heads up before releasing an exploit. Maybe t…

>It seems you disapprove of the phrase "responsible disclosure" because it's ambiguous and can be used as a cudgel This is like saying that a glock can be used as a weapon. Yes, it was carefully designed to be one. >We must secure the existence of our people and a future for white children This might also be ambiguous, but we all understand the genocidal connotations.

> This might also be ambiguous, but we all understand the genocidal connotations.

Ah yes, because using the term "responsible disclosure" is very clearly analogous to being a white supremacist.

There's no need to be so ridiculously dramatic -- "responsible disclosure" was objectively the term-du-jour used by the infosec community until fairly recently. And it's perfectly understandable why the community changed their mind (vendors started co-opting the phrase as a method of shaming researchers for doing the right thing), but you are shooting yourself in the foot by being so aggressive about it. Why not just say "we used to use that term, but we use this other term now because of the following reasons"?

Re: Tesla PowerWall 2 Hack

#114
post #101

Earlier quoted context omitted.

I guess you haven't seen this then. https://www.reddit.com/r/EnoughMuskSpam/comments/99sbwa/form...

This is amazing. It is all completely plausible, and clearly includes only the most easily explained horrors, with anything that would require explanation just omitted. It is worse than I would have been able to invent.

IMHO, these stories aren’t unexpected from a tech company that grows 80% year over year, developing and expanding as fast as technology and market forces allow. Yes, there are mistakes and unfortunate incidents in the organization of people and tech priorities here, but this is inevitable in an engineering org that moves this fast. You really need to measure this up against Tesla’s achievements:

Growing high double digits each year for more than a decade in a brutally competitve space, developed 4 hugely successful vehicles, first US auto company to succeed (knock on wood) or grow to significant size (>700,000 cars sold) since Ford, production constrained continuously, did this with almost zero paid marketing, built global networks of dealers, service and chargers, improved the state of battery tech by a multiple and doubled global li-ion battery pack output, built 3 car factories, made electric cars economically viable, incidentally seriously wounded the car dealership model, succeeded with qualitatively different software approach with OTA updates and tight software integration, designed cars with hitherto unparalleled performance in their class, and others that I couldn’t come up with on the spot.

This is only controversial because this is safety-critical tech and it’s uncomfortable to see the development pains of consumer grade software affect it. There’s no evidence that the approach have led to more injuries or deaths than cars do in general, quite the opposite. Tesla cars are safer than competition, the argument can be made that fast deployment is a net win regarding safety. Even in the absence of any other things they have achieved.

I believe there’s also an element of envy, or misunderstood beliefs that the best tech approach is taking things slowly. Yes, in isolation. But then market forces will crush you because someone else was faster, or because you missed the window of opportunity for making things so dramatically better that you manage to unbalance the local maximum of the status quo.

[Edit: To everyone who downvotes this: For the sake of enlightening discussion, could you please express your disagreement in words rather than the downvote button? Note that I'm talking about GP's linked commentary on Tesla's engineering mishaps in general, not this specific vulnerability].

Re: Tesla PowerWall 2 Hack

#115
post #2

Did they even try to submit these issues to Tesla? They have a bug bounty program and have been reasonably good about patching issues in vehicle software. If not, this is pretty irresponsible disclosure.

These issues seem fairly obvious to me. Anyone interested in powerwall vulnerabilities would find them trivially. In this case I think the value is in embarrassing Tesla for their gross negligence so they do better in this area before shipping. When you disclose such things quietly with the vendor, it mostly just saves their face. Not everyone values saving Tesla's face.

It can also give you a five- or six-figure payout and prevent unsuspecting customers of being hit by a disrupting and damaging attack, causing unnecessary economic damage. IMHO, choosing the priority of embarrassing someone rather than give them a 24-hour window of notice to avoid this would be a shitty move.

This should be short-term trivially fixable by pushing a password update that sets unique passwords based on a SN -> password mapping stored in a DB at the vendor. You don't need more than 24 hours to do that.

Re: Tesla PowerWall 2 Hack

#116
post #77

Is there an alternative to the powerwall that is functionally similar, in terms of power density and utility, but doesn't have things like a network stack and other wifi / IoT / "smart" features ? We are just about to install lithium battery backups in our home and, of course, the Tesla powerwalls are an obvious choice, but I don't look forward to having to disable/reenable the network connectivity on them, manually,…

What is the reason you can't store excess on the grid?

Punitive pricing, or at best you're at the mercy of the grid operators and power companies.

Re: Tesla PowerWall 2 Hack

#117
The criticism of this security vulnerability has been well covered at this point, so I'd just like to point out that this should be trivially solvable in a few hours by changing all passwords from HQ.

It'd be quite irresponsible of this researcher if they didn't give notice beforehand (don't know if they have).

Re: Tesla PowerWall 2 Hack

#118
post #111
post #95

Earlier quoted context omitted.

> The term “responsible disclosure” is a shady tactic to frame publishing immediately and in full to those affected by the vulnerability as irresponsible. It is not. What? Have you even tried to understand what responsible disclosure is? It is about giving the vendor a chance to protect their consumers before teaching the public how to exploit a vulnerability . The vendor still gets put on blast when the vulnerabilit…

The vendor’s existence and actions are irrelevant to whether or not it’s okay to publish your research at any time. It is never irresponsible to disclose one’s research in public, in full. Vendors don’t factor in to it at all .

Their customers do, though, and that's the whole point. Without giving people a short, reasonable time to patch, you're part of the problem, not part of the solution. For what it's worth, you are also coming across as something of a zealot, rather than a reasonable person who sees the world in shades of grey.

Re: Tesla PowerWall 2 Hack

#119

The only bug here is the default password. After authentication, the fact you can make it charge or dump power into the grid is by design. If I wanted the grid to suffer, I can do this by plugging in and unplugging a multi-kilowatt heater every few milliseconds too. Residential properties have a fuse (usually 60-100Amps), and anything you can do without blowing that fuse won't damage the grid.

Charging or dumping a single powerwall will not damage the grid. However, if someone causes many of them to do so in sync, the current grid control systems are definitely not going to cope well with that sort of behavior.

To do that the attacker would need to connect to hundreds (thousands?) of Powerwalls at the same time and figure out the password for each of them. Which means being close enough to each of them to access the Wifi and also figuring out their serial number somehow. How would they do that?

Re: Tesla PowerWall 2 Hack

#120

The only bug here is the default password. After authentication, the fact you can make it charge or dump power into the grid is by design. If I wanted the grid to suffer, I can do this by plugging in and unplugging a multi-kilowatt heater every few milliseconds too. Residential properties have a fuse (usually 60-100Amps), and anything you can do without blowing that fuse won't damage the grid.

Tesla has full control over every PowerWall, which means a rogue employee at Tesla would be able control all of them simultaenously. Given what we know about security at Tesla, I have little faith that their internal systems are advanced enough to prevent this.
Post reply on HN