[BreachExchange] Plain wrong: Millions of utility customers’ passwords stored in plain text

Destry Winant destry at riskbasedsecurity.com
Tue Feb 26 00:12:10 EST 2019


https://arstechnica.com/tech-policy/2019/02/plain-wrong-millions-of-utility-customers-passwords-stored-in-plain-text/

In September of 2018, an anonymous independent security researcher
(who we'll call X) noticed that their power company's website was
offering to email—not reset!—lost account passwords to forgetful
users. Startled, X fed the online form the utility account number and
the last four phone number digits it was asking for. Sure enough, a
few minutes later the account password, in plain text, was sitting in
X's inbox.

This was frustrating and insecure, and it shouldn't have happened at
all in 2018. But this turned out to be a flaw common to websites
designed by the Atlanta firm SEDC. After finding SEDC's copyright
notices in the footer of the local utility company's website, X began
looking for more customer-facing sites designed by SEDC. X found and
confirmed SEDC's footer—and the same offer to email plain-text
passwords—in more than 80 utility company websites.

Those companies service 15 million or so clients (estimated from GIS
data and in some cases from PR brags on the utility sites themselves).
But the real number of affected Americans could easily be several
times that large: SEDC itself claims that more than 250 utility
companies use its software.

Most of the information in this story came to Ars directly from X, who
was frustrated with the extreme indifference of the companies involved
after several months of continued effort to work with them. I
confirmed the technical details of X's claims by examining many of the
affected sites myself, and by reviewing X's communications with their
own utility company and with SEDC. EFF Senior Information Security
Counsel Nate Cardozo (who will famously be leaving to help WhatsApp
clean up its privacy issues) and EFF attorney Jamie Williams have been
advising X concerning legal and ethical disclosure responsibilities
during the entire process—because even today, the threat of legal
action may come before a potentially flawed company offers anything
resembling thanks or takes the necessary steps towards better security
hygiene.

Ars reached out to X's utility company and to Mark Cole (SEDC's
General Counsel), but we received no response from either.

Plain-text passwords

X did not attempt to discover any direct exploits into any of the
utility firms or into SEDC's own payment site. There's no smoking gun
here that says "somebody can just grab all these passwords and run."
That said, website compromises are much like entropy: they trend
toward the maximum. Once a website is breached, the first thing
attackers do is to dump the password database.

This isn't generally necessary to access accounts on the compromised
site itself; once you've got root in the infrastructure, odds are
pretty good you can already do whatever you'd like in that site. But
what makes those user passwords so valuable is their use as pivot
points.

Most users, unfortunately, re-use passwords between different websites
and Internet-accessible accounts with wild abandon. They may change it
up a little bit—add a number on the end here, stick a special
character in the middle there—but this doesn't actually add a
significant degree of security. Modern penetration tools (like Burp
Intruder) automatically "fuzz" passwords as necessary when the
attacker attempts to use them to access other, more valuable
resources.

These exploitable resources include just about anything from which you
can make money; eBay accounts, Amazon accounts, even World of Warcraft
accounts are popular targets for an attacker looking to make a quick
buck. Even more worryingly, if a user re-used their email password (or
some variant thereof) to log into the compromised website, the
attacker can leverage access to the user's email account to reset the
passwords to just about anything else the user accesses online.

This is romper-room security stuff for 2008, let alone 2018. Arguably,
the utility firms that contracted with SEDC for billing software and
services are large enough—and responsible for enough customers'
data—that they should be aware of and diligent about this kind of
problem themselves. In reality, most companies are an awful lot like
end users: they don't know, or care, as much about security as the
typical Ars Technica reader might like.

If you find yourself wondering—"What's so bad about storing passwords
as plaintext?"—it comes down to this: passwords are among the most
important data assets any organization has. In much the same way,
companies get fire insurance with the hope they'll never use it,
organizations must have robust hashing regimens to protect passwords
in the event there is ever a breach. This point has come up on Ars
again and again over the years, and it's explained well by password
cracking expert Jeremi Gosney in this story about a 2015 hack against
LastPass:

If we could trust computers to keep secrets a secret, then we wouldn’t
have to worry about protecting sensitive data at rest. But we can’t,
so we do. Password databases can be compromised through a myriad of
vectors—up to and including physical theft—and you have to plan for
the eventuality that your database will be compromised. How you
protect the data in the database is what really matters, and this is
precisely why we have password hashing, and this is also why the
threat model for password hashing starts with a compromised password
database. Think of password hashing as an insurance policy. The
stronger the password hashing is, the more time you buy for yourself
and your users in the event of a breach: time to identify and contain
the breach, time to notify your users, and time for your users to
update their passwords.

What about SEDC? No company that bills itself as "cyber security
experts" should need the security implications of plain-text password
storage explained to them. This software shouldn't have been written
this way in the first place, and the response to the disclosure of
this vulnerability should have been rapid, courteous, and sincere—not
a protracted, hostile back-and-forth with legal counsel.


More information about the BreachExchange mailing list