[HN Gopher] Hacking a Virtual Power Plant
       ___________________________________________________________________
        
       Hacking a Virtual Power Plant
        
       Author : bo0tzz
       Score  : 48 points
       Date   : 2024-08-08 18:52 UTC (1 days ago)
        
 (HTM) web link (rya.nc)
 (TXT) w3m dump (rya.nc)
        
       | uyzstvqs wrote:
       | Great blog post. The company response was really great, but there
       | was no mention of a bug bounty. This would be a perfect example
       | if he got paid for his findings.
        
         | ryan-c wrote:
         | I'm not male and I use gender neutral pronouns.
         | 
         | The bugs I find are usually just ones I stumble across, I don't
         | go looking for them.
         | 
         | Bug bounty programs generally aren't worth the trouble for me
         | anyway - I have to file taxes in both the US and the UK so the
         | paperwork gets really annoying.
        
         | mjg59 wrote:
         | Adding to Ryan's concerns, submitting to a bug bounty program
         | often means accepting terms and conditions that constrain your
         | ability to publicly disclose the issue if the vendor decides to
         | be a dick about it. Depending on how you think your career
         | potentially benefits from freedom to discuss an issue, the
         | long-term financial benefit is potentially greater from not
         | going down the bug bounty path.
        
           | ryan-c wrote:
           | Oh, yeah, I'd forgotten about the NDAs, those are a big NOPE
           | for me.
        
       | ckwalsh wrote:
       | > the legitimate ones I'd initially generated still worked
       | 
       | This spooks me. I take this to mean either:
       | 
       | - They are still using the compromised key for validation,
       | meaning if you have access to any old token, you can still mutate
       | that, maybe needing to play around with the issuing times
       | 
       | - They built an allowlist of all permitted tokens, and check that
       | list first. In which case, might as well use random session ids
       | instead of JWTs, and at the same point where the allowlist is
       | being checked, mutate the request to inject a JWT that the
       | backend can use.
       | 
       | Also, kind of curious why the switch to RSA4096 instead of
       | elliptic curves, since they are generally faster / smaller.
        
         | ryan-c wrote:
         | I think very few customers had ever generated API keys, and as
         | best I can tell they made an allowlist for them.
         | 
         | One of my suggestions to them was to switch to elliptic curve,
         | but I imagine RSA 4096 "just worked".
         | 
         | I suspect they'll rework it later now that it's not "on fire".
        
           | ckwalsh wrote:
           | Ah that makes sense. For sufficiently small values of N, a
           | hardcoded allowlist isn't a problem.
           | 
           | You're probably right that RSA 4096 "just worked", and some
           | library in their stack doesn't have elliptic curve support.
           | And again, if N is small, the verification performance
           | doesn't matter that much.
           | 
           | Nice find and writeup!
        
         | selecsosi wrote:
         | My guess is they are still accepting keys signed with the old
         | 512 key but are currently generating new tokens with a 4096
         | key.
        
       | reboot81 wrote:
       | I do wonder how you got in contact with them? No security.txt or
       | other obvious ways to report a security issue.
        
         | ryan-c wrote:
         | In the footnotes:
         | 
         | > Someone once asked me, as commentary on my ability to figure
         | out email addresses, "Are you a Hacker or in sales?"
         | 
         | Just a bit of OSINT and educated guessing.
        
           | markovs_gun wrote:
           | It's pretty easy to get in contact with someone most of the
           | time if you search for relevant roles on google with
           | site:linkedin.com, or if you want to reach execs, on their
           | business pages. I usually include several combinations of
           | first and last names @company.com so like I will email to
           | JSmith@company.com and JohnSmith@company.com and others. This
           | is useful for escalating customer service complaints if
           | you're just hitting a brick wall with the low level customer
           | service staff.
        
             | ryan-c wrote:
             | Yeah, this is pretty much what I did, except the demo
             | account had an employee's email address in the details so I
             | knew the format.
        
         | ryan-c wrote:
         | They do have a vulnerability policy page, but that was harder
         | to find than figuring out an email address. I did suggest they
         | implement security.txt, as it would have made things easier.
        
       | kkfx wrote:
       | Now imaging the amplitude of a deliberate attack not to personal
       | domestic p.v. productions but en-masse against the grid: most
       | hybrid systems also can inject, p.v. and eventual batteries can
       | inject all together, eventually ignoring grid frequency burst. So
       | far probably those systems are not so common do generate
       | widespread damage, but once they'll be spread it would be easy to
       | generate a large scale blackouts.
       | 
       | Just to say that no proprietary devices should be ever allowed to
       | have remote connections, FLOSS must be mandatory from the early
       | stage of a project to allow third party inspect the codebase not
       | starting with a gazillion SLoC, being de facto unable to
       | understand them, instead of starting from the first SLoC
       | following at the project evolutionary speed.
       | 
       | Nowadays it start to be again damn easy to plan any kind of
       | "unexpected logic" in gazillion of devices, potentially at State
       | intelligence level, from cars to energy systems, TLCs active
       | devices, ... not a new thing at all, but easy enough to be
       | dangerous enough to MANDATE FLOSS if those who care of a nation
       | security have at least an idea of the current role of IT in a
       | society and it's enormous mean attack surface.
        
       | ok_dad wrote:
       | > A major selling point for me was that they have a local network
       | API which can be used to monitor and control everything without
       | relying on their cloud services.
       | 
       | That would be a MAJOR selling point for me, too! Especially
       | because most of the companies that do this for residential are
       | getting a huge portion of the profits using YOUR batteries,
       | rather than getting that profit yourself. Unfortunately, where I
       | live, that is mostly because energy utilities are hostile to
       | anyone except large middlemen installers and their VPPs. It would
       | be simple for them to also allow individuals to sign up for
       | dispatch if they were half-competent. I can't find any companies
       | providing battery systems plus solar that are able to be fully
       | local in my area of the USA, either, even if I wanted to try and
       | go "off grid" using massively overbuilt batteries linked to
       | solar.
        
       | ryan-c wrote:
       | The Ars Technica article may also be of interest - it has a
       | statement from the company.
       | 
       | https://arstechnica.com/security/2024/08/home-energy-system-...
        
       ___________________________________________________________________
       (page generated 2024-08-09 23:00 UTC)