Equifax breach

The data breach at credit bureau Equifax has gotten a lot of attention in the last week. It seems that the company has been guilty of at least two significant blunders: unpatched software and default authentication credentials.

Unpatched software

Equifax has at least one web application built on Apache Struts, a category of software called a web application framework. Web developers use frameworks to build their applications, because the frameworks provide components common to many web applications, components that do things like handling input typed into a web form, generating HTML for web pages, etc. Frameworks allow web developers to skip over routine tasks and focus on the business logic specific to the application.

Like any software, frameworks have versions and updates. Equifax was using a version of Struts that had at least one serious and widely-known security vulnerability. When the Struts developers (not Equifax, but the people who make the Struts framework) became aware of the vulnerability, they released an update to the Struts framework. The Struts developers released this update months prior to the Equifax data breach. For whatever reason, Equifax didn’t update Struts on their site.

Default authentication credentials

Equifax hosts a web application that their Argentinian employees use to manage credit report data. That web application had a poor choice of authentication credentials: the username was admin, and the password was also admin. Logging in with those credentials allowed an attacker to retrieve the usernames and passwords of Equifax employees, which would in turn allow the attacker to retrieve Equifax customer information.

How does this happen?

Why didn’t Equifax apply the Struts update? A few possibilities come to mind:

  1. The didn’t know about the update. Equifax must have developers, system administrators, and security analysts. Maybe they were all blissfully ignorant of the update for over four months.
  2. Maybe the update was incompatible with the web application they built on the Struts framework. If that were the case, they should have identified and fixed the problem and then run the update. That might take days, but it shouldn’t take months.
  3. They probably have change control processes that delay an update. They wouldn’t immediately run the update on their live production servers. First they’d load it in a test environment, and then they’d test their application after applying the Struts update. But that should take at most days, and probably hours, especially with an update that addresses serious security vulnerabilities.

None of these is an excuse for waiting months to run the update, and there’s really no defending the admin/admin thing at all.

What this might mean to you

Brian Krebs has been a long-time advocate for security freezes, and I’m considering doing this. The only reason I haven’t done this yet is that it just seems like one more pain in the ass when my day job, the current political climate, and other stuff leave me wanting to do little more than read a book or sit in front of the TV binge-watching The Flash and Supergirl (which is why I haven’t been posting on this blog much lately).

The implications of the Equifax breach to a story-teller are obvious enough. If your character needs to break into a web site or computer network, she should look for out-of-date software or default authentication credentials. This sort of thing isn’t supposed to happen to a big company that should know better about how to protect the personal information of millions of people. But it does happen, which can make it a plausible plot device in your fiction. I see that nmap has a test to look specifically for the Struts vulnerability found on the Equifax site, and there are plenty of open-source tools to run brute-force password attacks.

The implications of the breach on a computer user are obvious, too. This is why it’s so important to run software updates on everything. Criminals are well aware of security vulnerabilities and are actively exploiting them. We all need to be running updates:

1. operating system and application software updates on our computers and mobile devices

2. firmware updates on the routers we use for our broadband internet connections

3. updates to self-hosted blogging software like wordpress (plugins, too)

And we need to be picking good passwords for everything. Did you ever change the password on your broadband router? Does “facebook” appear in your facebook password?

Advertisements

20160619 news roundup

This blog is still an experiment, so I may try different things from time to time. Today I’m going to post a few news items that caught my interest lately. This serves a couple of purposes. It gives me a place to keep these things for later reference, and maybe it’ll provide you or me with something to put in a story.

Don’t use default passwords

The Liberal Party of Quebec uses video conferencing software to facilitate and/or record their meetings. No doubt they would prefer that the content of these meeting be confidential, but whoever set up the software left it with a default password. So it was easy enough for someone to connect to the videoconferencing software and to provide a vendor default password (which is probably in a publicly-available product manual). Someone did this and downloaded and published live and archived meeting content. This is a good illustration of the danger of not changing vendor default passwords.

Never shop for anything. Ever.

It’s getting harder and harder to have much privacy online. Sites like to track us as we browse the web, trying to figure out how ads affect our online shopping habits. And now it may be getting even worse. Facebook is planning to track us using our phones’ GPS and by the wireless access points our phones see (even if we don’t connect to the access points, our phones see them). Facebook can then sell this data to the owners of physical stores: “This many people physically visited one of your brick-and-mortar stores within this many days of viewing your advertisement online.” This is like that scene in Minority Report when the billboards address the Tom Cruise character by name as he walks through a store. I disable location services (GPS) on my phone, and when I think of it I turn off wireless when I’m away from home and work. It saves the battery, and it may help my privacy.

Aliens

For those of us who wonder about humanity’s ability to detect alien spacecraft, here’s an interesting data point. Asteroid 2016 HO3 has been a quasi-satellite of Earth for decades, and it was only discovered in April of this year. It’s probably between 120 and 300 feet in size. Imagine sitting in the stands of an American football stadium and looking at an object (or a space vessel) that starts at one end zone and stretches at least to the 40-yard line (and maybe to the opposing end zone). 2016 HO3 never gets very close (it wanders around between 38 and 100 times the distance between the Earth and the moon), but that might be close enough to get a look at us.

And today I learned that NASA has a Planetary Defense Coordination Office. They even have an organizational chart.

Passwords: salts, hashes

In the previous post we saw that network and web site accounts with reasonable security use hash functions to protect passwords.

But even using a hash function isn’t enough, because the bad guys have rainbow tables. A rainbow table is a list of common passwords (like Password123) and their hash values. So if a site suffers a data breach exposing account data, a simple hash function won’t be much of a barrier, because the criminal can compare the hash values (in the breach data) against a rainbow table and recover many of the weaker passwords.

To counter rainbow tables, sites typically salt users’ passwords: when someone creates a password, the site generates some random characters (the salt), appends that to the user’s password, runs the salted password through the hash function, and then stores the hash value and the salt. When the user tries to log in, the site takes the password they typed, appends the salt stored with the user’s account, sends that through the hash function, and compares the hash values.

Salting hashes sets the bar a lot higher, because the criminal would need to compute a new rainbow table for each password (because each password will have a different salt).

This is why I get frustrated with fiction that makes it look easy to crack passwords. Any account worth hacking will likely be protected by some or all of the following safeguards:

  1. salted and hashed passwords
  2. a password policy enforcing complexity rules (e.g., your password has to be at least eight characters, has to include numbers and punctuation characters, and can’t look too much like a word)
  3. active response locking an account after too many failed attempts
  4. two-factor authentication (you log in with your username and password, but then the site won’t give you access until you enter a code it sends to your cell phone)

Active response in particular makes guessing passwords impractical. If your character is trying to break into a network or web site account, too many failed attempts are going to end up locking the target account. Your character is better off trying to steal the password with a phishing attack, social engineering, using a keylogger, exploiting a flaw in the “forgot my password” feature, or even a security camera pointed at the keyboard.

And an account protected by two-factor authentication is nearly unassailable, because your character would need the target’s password and their cell phone. Social engineering might be best here.

Passwords: this isn’t a game show

Have you ever seen a movie where someone is running a computer program to crack a password (or a missile launch code), and it discovers one character at a time? It looks like a Wheel of Fortune contestant correctly guessing a letter or buying a vowel. This is a trope I think writers and screenwriters should avoid.

Passwords don’t work like Wheel of Fortune. If they did, it would mean that each individual character is stored separately, and it would take around the same (boringly brief) length of time to guess each one.

When you sign up for a account on a web site that has reasonable security, the site takes the password you provided and puts it through something called a one-way hash function. The hash function turns your password into a hash value: it transforms something like

Password123

into something like

b2e98ad6f6eb8508dd6a14cfa704bad7f05f6fb1

or

Password124

into

ae5b6bf3a00dabe4bcb06918044f3032c6e7c80c

Hash functions (there are many of them–I used sha1sum for these examples) have several important features:

  1. It works the same way every time (sha1sum always hashes Password123 to b2e98ad6f6eb8508dd6a14cfa704bad7f05f6fb1).
  2. It’s very difficult to find two passwords that have the same hash value, but it’s not impossible. (This means that a hash value does not uniquely determine a password.)
  3. You generally can’t work backwards from the hash value to recover the password (it’s different from encryption, which allows you to decrypt the encrypted value).
  4. A minor change in the password (changing 3 to 4 above) drastically affects the hash value.

So when you set your password, the site hashes your password and saves the hash value, not the original password. Next time you log in, it uses the same hash function to hash the password you just typed in and compares that hash value to the hash value stored next to your username. If the hash values match, then you typed the correct password, and the site gives you access. If they don’t match, you get the “invalid password” message.

That’s one of the many reasons that the Wheel of Fortune thing is so absurd. The site checking the password you just typed doesn’t even know the original password. It’s checking one hash value against another–the whole thing matches or the whole thing fails. So even if a criminal compromises the site through some security vulnerability and manages to download the username/password database, they get a bunch of stuff they can’t read.

In the next post we’ll see that hashing passwords is better than storing passwords in clear text, but that it’s still not sufficient.

Tumblr password breach

And now Tumblr is saying that they’ve had a data breach potentially exposing the passwords of 65 million accounts. Like the LinkedIn and MySpace breaches, this appears to be a few years old, and Tumblr is forcing passwords resets on the accounts it thinks is affected. Still, it wouldn’t hurt to reset your Tumblr password.

MySpace password breach

There’s a story going around that someone is trying to sell a collection of SEVERAL HUNDRED MILLION MySpace passwords (and that it’s the same person who is selling 100+ million LinkedIn passwords). As with the LinkedIn case, this may be a data breach from months or even years ago.

Still, if you have a MySpace account, or if you’ve re-used a MySpace password elsewhere, this might be a good time to change your password.