Subscribe for our latest security news and tips and get your 15% discount!
Pacific Gas and Electric Database Exposed
According to the U.S. Department of Homeland Security, electric utility companies are part of the nation’s “critical infrastructure.”
UPDATE (Jun 1st): This post has been updated to include statement from PG&E
Last week I discovered a data breach involving Pacific Gas and Electric, a very large electric utility company in California. The publicly exposed database appeared to be PG&E’s asset management system. Among other things, it contained details for over 47,000 PG&E computers, virtual machines, servers, and other devices. All of it completely unprotected. No username or password required for viewing.
Follow the latest security news and data breaches at MacKeeper Security Research Center with Chris Vickery.
We’re talking about IP addresses, operating systems, hostnames, locations, MAC addresses, and more. This would be a treasure trove for any hostile nation-state hacking group. That’s not to mention the 120 hashed employee passwords, or the plaintext NTLM, SOAP, and mail passwords.
Does anyone recall a recent example of hackers crippling an electric utility? I do: https://www.wired.com/2016/03/inside-cunning-unprecedented-hack-ukraines-power-grid
Before going any further I want to let you know that PG&E’s IT department is trying to claim that the database was “fake”. However, I want you to also know that nearly every data breach that I find is initially claimed to be fake. It’s a quick, easy excuse when your company is caught with its pants down and, if it works, you get off free and clear. But that excuse isn’t going to work this time.
Fictitious databases do not generally have areas specifically marked development, production, and enterprise. Fictitious databases do not generally have over 688,000 unique log record entries. This database did.
Sure, it’s theoretically possible to create software that could generate massive amounts of fake data, but companies don’t do that. Even if a database is for development purposes only, they tend to fill it with real production data. They do that because production data is easily available and free. Companies generally do not pay people to sit around and create great swaths of false data when plenty of data already exists to use. I’ve seen it over and over again.
To be clear, I absolutely do not believe PG&E’s claim that this is all fictitious data. They sure took it down quickly after I notified them on Thursday, May 26th.
PG&E didn’t bother to ask me if I downloaded a copy of this open, publicly exposed database. I’ll tell you now that I did. I still have it.
Ultimately, I would like to provide it to the US Department of Homeland Security so that they can 1) determine whether or not the data is genuine; and 2) take appropriate actions in the event that hostile actors also found the database.
So, if you work for DHS and you’re reading this, please contact me at firstname.lastname@example.org if you are interested in verifying the data set and taking appropriate measures to remediate in the event that other parties also obtained a copy.
- With this incident, it is important to know that none of PG&E’s systems were directly breached in any way and no customer or employee data was involved.
- A PG&E vendor was hosting an online demonstration using PG&E asset management data to show the capabilities of a platform that they were developing for us. This data contained information on PG&E’s technology assets, such as computers and servers.
- Our initial review indicated that the data was non-sensitive, mocked-up data. We based this feedback on an initial response from the vendor stating that the information in the database was demo or “fake” data. Following further review, we learned that the data was not fake and removed access.
- We continue working with all of our vendors to have appropriate procedures in place at all times to protect PG&E data in those instances when they have it.
Attention - Portions of this article may be used for publication if properly referenced and credit is given to MacKeeper Security Researcher: Chris Vickery.