Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tesla PowerWall 2 Hack

github.com

Post reply on HN
Print view View original

51–60 of 175 posts

Re: Tesla PowerWall 2 Hack

#51

Post by gpm »

SECProto wrote: post #42
gpm wrote: post #33

Earlier quoted context omitted.

An ISP around here still ships consumer routers with passwords consisting of a random 8 digit hex number, i.e. that could be cracked in a day on a GTX 970m (tested hash rate against my parent's wifi). They also ship with default SSIDs, numbered 100 to 999, so given 900 GPU days of precomputation you could create rainbow tables that allow for cracking every default password/ssid pair. I can tell you from the wifi pass…

> They also ship with default SSIDs, numbered 100 to 999, so given 899 GPU days of precomputation That would be 900 GPU days actually - off by one error

Thanks, fixed.

Re: Tesla PowerWall 2 Hack

#52

Post by [deleted] »

propercoil wrote: post #22

So many people like to nitpick when it comes to Tesla, It reminds me of the Apple critics in the early days of the iphone. They assume Tesla should have the highest standard and be absolutely impeccable with all their products. Just don't buy it if you don't like it. Let the rest of us enjoy a sustainable future with insanely safe full self-driving electric cars.

[deleted]

Re: Tesla PowerWall 2 Hack

#53

Post by FireBeyond »

kortilla wrote: post #30
FireBeyond wrote: post #9

Earlier quoted context omitted.

"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.

> "Responsible disclosure" is an invention of vendors who want you conforming to their policies and timeline No it’s not. It’s an invention of ethical hackers and academic security researchers who are mature enough to realize that dropping 0-days to the public is worse for society than giving the vendor a reasonable opportunity to fix it. “Economics of information security” is a field that publishes some studies abou…

Some interesting commentary:

https://news.ycombinator.com/item?id=14010010

https://news.ycombinator.com/item?id=12308246

> That may feel good to say, but as someone whose job it was to find these kinds of bugs in software from companies ranging from tiny startups to financial exchanges to major tech vendors, this is a kind of carelessness shared by virtually everyone shipping any kind of software anywhere.

> That said, the term "responsible disclosure" is Orwellian, and you should very much avoid using it.

> It's coercive. It redefines language to make any handling of vulnerabilities not condoned by the vendors who shipped those vulnerabilities "irresponsible", despite the fact that third parties who discover vulnerabilities have no formal duty to cooperate with those vendors whatsoever.

> The better term is "coordinated disclosure". But uncoordinated disclosure is not intrinsically irresponsible. For instance: if you know there's an exploit in the wild for something, perhaps go ahead and tweet the vulnerability without notice!

Re: Tesla PowerWall 2 Hack

#54

Post by kerng »

FireBeyond wrote: post #9
mdorazio wrote: 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 think this comment highlights a lack of understanding what responsible disclosure is about. It's there to reach the best possible tradeoffs to protect consumers and force a quick turnaround with fixes. Just publishing vulns, which the vendor might not even see or learn about(!), will not help in getting things improved and puts consumers knowingly at risk at scale.

Re: Tesla PowerWall 2 Hack

#55

Post by nemosaltat »

morpheuskafka wrote: post #46
tedivm wrote: post #34

Earlier quoted context omitted.

The password format is `ST 0001 `. * YY is a year, with the first year being 2015. So right now there's only five options. * L is the revision, of which there is D, E, F, G, H, I- for six options total. * XYZ is literally the last three digits of the SSID, which means you get that for free. With all of this information it will take at most 30 attempts to log into the network.

Could always send out fake registration emails/postcards to collect serial numbers (which most people wouldn't consider especially sensitive info)...

I had a very similar thought regarding gaining API keys for Tesla vehicles after realizing I can get generate API key knowing only my Tesla Account user name and password only.

Honeypot free WiFi at a Tesla Super Charger with a legit looking login page: “Free WiFi for Tesla Customers, Login to your Tesla account to access.”

API End points include vehicle unlocking, speed limit settings, etc. Some are not available while the vehicle is motion, so at least there’s that.

(Full disclose: I own a Model 3)

Re: Tesla PowerWall 2 Hack

#56

Post by londons_explore »

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.

Re: Tesla PowerWall 2 Hack

#57

Post by rmgraham »

chance_state wrote: post #49
vermilingua wrote: post #40

This is the mythical power-grid attack that people have been talking about since the concept of cyber-warfare was first dreamt up. It’s lucky we caught this now, before there are enough PowerWalls to seriously destabilise the grid if this attack were to occur.

> This is the mythical power-grid attack that people have been talking about since the concept of cyber-warfare was first dreamt up. > It’s lucky we caught this now, before there are enough PowerWalls to seriously destabilise the grid if this attack were to occur. I could be misunderstanding you, but do you seriously think that there are not more destabilizing attacks already available? From my reading the US power g…

I think the observation being made was that this is at the scary intersection of consumer IoT non-security and major infrastructure.

Re: Tesla PowerWall 2 Hack

#58

Post by FireBeyond »

kerng wrote: post #54
FireBeyond wrote: post #9

Earlier quoted context omitted.

"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 think this comment highlights a lack of understanding what responsible disclosure is about. It's there to reach the best possible tradeoffs to protect consumers and force a quick turnaround with fixes. Just publishing vulns, which the vendor might not even see or learn about(!), will not help in getting things improved and puts consumers knowingly at risk at scale.

I understand perfectly well what it is. But see my sibling comments, that reflect an agreement with the concept of "coordinated disclosure", rather than "responsible disclosure", which gives an implication that I am being irresponsible if I do not work to the vendor's needs and priorities.

Re: Tesla PowerWall 2 Hack

#59

Post by londons_explore »

vermilingua wrote: post #40

This is the mythical power-grid attack that people have been talking about since the concept of cyber-warfare was first dreamt up. It’s lucky we caught this now, before there are enough PowerWalls to seriously destabilise the grid if this attack were to occur.

Rate of Change of Frequency protection (ROCOF) in embedded storage and generation systems is what will kill the grid in a massive cascading failure.

ROCOF works well to keep things safe when only a small percentage of the grid demand is met by residential solar/powerwalls.

As soon as any significant proportion is residential solar (and thats already the case in some countries at some times of day) it acts as a cascading failure mechanism. As soon as any failure occurs, embedded generation sees a rapidly decreasing frequency, and rather that increase supply as traditional generators would be instructed to do to stabilise the grid, ROCOF protection requires they cease supply, making the issue far worse.

Within a fraction of a second, all embedded generation will disconnect, likely causing a near total blackout nationwide. Since system frequency that ROCOF measures is nationwide, failures won't be local to one geographic area.

I suspect these rules were made when people thought "consumers feeding energy back into the grid will never be more than 0.1% of the total - we'll always have enough spinning reserve to make up for that". Thats no longer the case, and unless the ROCOF limits are changed, and the majority of home solar/wind/powerwalls get a firmware update, expect a few very large blackouts.

Re: Tesla PowerWall 2 Hack

#60

Post by xoa »

astronautjones wrote: post #47
xoa wrote: post #29

I have a couple of PW2s installed, connected via ethernet only (isolated on its own VLAN, though Tesla is total garbage about basics like "what firewall rules are needed"), no cellular here either. But the TEG-$(SERIAL){3} network has always been right there anyway, which is just really lazy design. I happen to be physically far enough away from anyone else that it's very unlikely to be a security issue in practice,…

>Edit to add: HOSTNAME INCLUDES THE FULL SERIAL. I thought I'd take a second look at this and just pulled up the client info for the PW2 Gateway on my network, and hostname is 11XXXXX-00-J--S$(SERIAL). So no local physical access it required, the gateway itself just broadcasts the whole serial, which in light of this is an, interesting, decision. I can confirm that using the hostname with an added S at the front (so…

I guess in practice it doesn't really matter much anyway because while my serial doesn't specifically follow the format described in the link it'd still be utterly trivial to brute force. So that they leak the whole thing onto LAN anyway just turns it into even more of a joke, but I guess would rarely make a real difference. Some of the HN crowd have security monitoring on their own networks that would detect suspicious hammering patterns, have more device isolation, etc, but I strongly suspect the vast, vast majority of PW installs are pure ISP default setting CPE environments. Using crummy default password routers full of their own holes too!
Post reply on HN