Sony Pictures attacked again, 4.5 million records exposed

LulzSec message to SonyThe same hackers who recently attacked PBS.org have turned their attention back to Sony by releasing the latest dump of information stolen from Sony’s websites.

While the information disclosed includes approximately 150,000 records, the hackers claim the databases exposed contain over 4.5 million records, at least a million of which include user information.

The data stolen includes:

  • A link to a vulnerable sonypictures.com webpage.

  • 12,500 users related to Auto Trader (Contest entrants?) including birth dates, addresses, email addresses, full names, plain text passwords, user IDs and phone numbers.

  • 21,000 IDs associated with a DB table labeled “BEAUTY_USERS” including email addresses and plain text passwords.

  • ~20,000 Sony Music coupons (out of 3.5 million in the DB).

  • Just under 18,000 emails and plain text passwords from a Seinfeld “Del Boca” sweepstakes.

  • Over 65,000 Sony Music codes.

  • Several other tables including those from Sony BMG in The Netherlands and Belgium.

The attackers, LulzSec, stated in their file titled “PRETENTIOUS PRESS STATEMENT.txt”:

"SonyPictures.com was owned by a very simple SQL injection, one of the most primitive and common vulnerabilities, as we should all know by now. From a single injection, we accessed EVERYTHING. Why do you put such faith in a company that allows itself to become open to these simple attacks?"

This sounds like a broken record… Passwords and sensitive user details stored in plain text… Attackers using “a very simple SQL injection” to compromise a major media conglomerate.

Worst of all the hackers are exposing over a million people to having their accounts compromised and identities stolen simply to make a political point.

Sony passwords leakedThe take away for the average internet users is clear. Don’t trust that your password is being securely stored and be sure to use a unique password for every website to limit your exposure if hacks like these occur.

I took a brief look at some of the information disclosed and many passwords used were things like “faithful”, “hockey”, “123456”, “freddie”, “123qaz” and “michael”.

Companies collecting information from their customers have a duty to protect that information as well.

In addition to employing proper encryption to protect against theft or loss, companies should work with reputable penetration testers to validate their security plans.

Interested in some practical help with data security? Download our Data Security Toolkit.

Interested in encrypting your own personal files? Try out Sophos Free Encryption.

LastPass forces users to change master password after network traffic oddity

LastPass Logo
LastPass has issued a statement on its blog (see below) saying it had noticed an anomaly in network traffic for a few minutes to one of its non-critical machines – resulting in the unauthorised transmission of data.

Engineers at LastPass tried to identify the traffic source and failed, so they are forcing its million of users to change their master passwords as a precaution.

The irony here is the LastPass strapline: “The Last Password You’ll Ever Need.” Turns out you might need more than one. Oh well.

Despite this potential security breach, LastPass has a strong reputation among the technology-savvy as a rather good piece of password-management software. It allows users to store the multitude of passwords for their various online activities in an encrypted form, accessible only via their master password.

Following LastPass’s security emergency review, users are prompted to enter their associated email address when they try to enter their master password. LastPass then sends a link in an email notification requesting users enter a new master password.

So far so good, except there a number of disgruntled users whose email password is stored within – you guessed it – LastPass: Catch-22.

The other reported problem for some email users, including some Gmail users, is that LastPass’s automated email notification is getting caught up in spam traps. So, if you haven’t yet received your expected email notification from LastPass, check the spam folder

I think this situation underlines the real importance for strong passwords. Please do not use dictionary words or easy-to-crack passwords for sensitive information, like a master password which protects all of your other passwords.

Not sure what a strong password is, or why it’s important you should choose a unique one? Watch this short Sophos Naked Security video.

(Enjoyed this video? Why not subscribe to the SophosLabs YouTube channel?)

And for what it’s worth, I think LastPass are doing the right thing: they saw something odd. They cannot explain it. There is a risk that sensitive info is in the wrong hands, so they immediately go into action, explain with some detail why they are concerned, and tell you what to do you about it.

True, it is not a pain-free process for its users, but ultimately most users I have talked to are really grateful that they are taking the better safe than sorry approach.

The only concern is that I have heard that they do not plan to email all their users. I think this might be a mistake. For the less technically inclined, having their LastPass software request a new password and not seeing an email communication from the company might raise unwarranted suspicions.

Here is the blog message in full, copied from LastPass’s blog:

May 4, 2011
LastPass Security Notification

We noticed an issue yesterday and wanted to alert you to it. As a precaution, we're also forcing you to change your master password.

We take a close look at our logs and try to explain every anomaly we see. Tuesday morning we saw a network traffic anomaly for a few minutes from one of our non-critical machines. These happen occasionally, and we typically identify them as an employee or an automated script.

In this case, we couldn't find that root cause. After delving into the anomaly we found a similar but smaller matching traffic anomaly from one of our databases in the opposite direction (more traffic was sent from the database compared to what was received on the server). Because we can't account for this anomaly either, we're going to be paranoid and assume the worst: that the data we stored in the database was somehow accessed. We know roughly the amount of data transfered and that it's big enough to have transfered people's email addresses, the server salt and their salted password hashes from the database. We also know that the amount of data taken isn't remotely enough to have pulled many users encrypted data blobs.

If you have a strong, non-dictionary based password or pass phrase, this shouldn't impact you - the potential threat here is brute forcing your master password using dictionary words, then going to LastPass with that password to get your data. Unfortunately not everyone picks a master password that's immune to brute forcing.

To counter that potential threat, we're going to force everyone to change their master passwords. Additionally, we're going to want an indication that you're you, by either ensuring that you're coming from an IP block you've used before or by validating your email address. The reason is that if an attacker had your master password through a brute force method, LastPass still wouldn't give access to this theoretical attacker because they wouldn't have access to your email account or your IP.

We realize this may be an overreaction and we apologize for the disruption this will cause, but we'd rather be paranoid and slightly inconvenience you than to be even more sorry later.

We're also taking this as an opportunity to roll out something we've been planning for a while: PBKDF2 using SHA-256 on the server with a 256-bit salt utilizing 100,000 rounds. We'll be rolling out a second implementation of it with the client too. In more basic terms, this further mitigates the risk if we ever see something suspicious like this in the future. As we continue to grow we'll continue to find ways to reduce how large a target we are.

For those of you who are curious: we don't have very much data indicating what potentially happened and what attack vector could have been used and are continuing to investigate it. We had our asterisk phone server more open to UDP than it needed to be which was an issue our auditing found but we couldn't find any indications on the box itself of tampering, the database didn't show any changes escalating anyone to premium or administrators, and none of the log files give us much to go on.

We don't have a lot that indicates an issue occurred but it's prudent to assume where there's smoke there could be fire. We're rebuilding the boxes in question and have shut down and moved services from them in the meantime. The source code running the website and plugins has been verified against our source code repositories, and we have further determined from offline snapshots and cryptographic hashes in the repository that there was no tampering with the repository itself.

Again, we apologize for the inconvenience caused and will continue to take every precaution in protecting user data.

The LastPass Team.

The New York Yankees and DSLReports.com responsible for 30,000 more data loss victims

Yankees helmet courtesy of Mr T. in DC's Flickr photostreamThis message may repeat. This message may repeat. For those of us old enough to have fond memories of the phonograph, the phrase “broken record” may come to mind.

Yes, more user information has been leaked and in a totally preventable fashion. A season ticket sales representative for the New York Yankees accidentally emailed a spreadsheet to “several hundred” affiliates with the personal details of over 21,000 Yankees ticket holders.

Screenshot of letter from New York Yankees

According to the Yankees, the spreadsheet contained customers’ names, addresses, phone numbers, fax numbers, e-mail addresses and other information like their seat numbers and which ticket packages they purchased.

Implementing data loss prevention (DLP) for sensitive customer data is easy to do. There are at least three ways this could have been prevented…

1. Encrypt the spreadsheet to prevent accidental disclosure
2. Implement endpoint DLP software to watch for the transfer of sensitive data to instant message, email and other communication tools
3. Scan outgoing email messages for personally identifiable information to prevent accidental disclosure.

Later this afternoon DSLReports.com disclosed that they had been the victims of a SQL injection attack that succeeded in stealing usernames and passwords. Justin, the owner of DSLReports, wrote in a forum message that a “sql injection attack by a botnet on wednesday afternoon obtained a large number of email / password pairs.”

DSLReports logoStrangely, Justin stated that he had notified account holders who either created their accounts in the last 12 months, or had logged in over the last 12 months. This seems like a terrible practice. Many users have had accounts for more than 10 years and may not even remember having created one.

To not notify everyone who may have been affected seems to be a lapse in judgement, but it gets worse. All of the passwords in DSLReports’ database were in clear text. No hashing, no salting, totally unencrypted.

Once again we find that if we re-use passwords for seemingly unimportant websites, we may be putting our reputations at risk. You can count on the attackers trying to use these email addresses and passwords on as many popular sites as possible.

They may only use them to spread forum spam, but do you really want your name/profile/identity associated with this kind of activity?

Creative Commons image of New York Yankees helmet courtesy of Mr. T in DC’s Flickr photostream.

Amazon.com Security Flaw Accepts Passwords That Are Close, But Not Exact

An Amazon.com security flaw allows some customers to log in with variations of their actual password that are close to, but not exactly, their real password.

The flaw lets Amazon accept as valid some passwords that have extra characters added on after the 8th character, and also makes the password case-insensitive.

For example, if your password is “Password,” Amazon.com will also let you log in with “PASSWORD,” “password,” “passwordpassword,” and “password12345.”

Wired has been able to confirm the flaw, which was first reported on Reddit. It appears to affect only older Amazon.com accounts, which have not had their passwords changed in the past several years.

Amazon did not respond to a request for comment.

Observers on Reddit speculate that Amazon was using the unix crypt() function to encrypt older passwords, in addition to converting them to uppercase, before storing them in its servers. While encrypting stored passwords is a wise idea, crypt() truncates longer passwords, discarding anything after the 8th character. (It’s also relatively easy to crack, as Gawker Media recently found out when its crypt()-encrypted database of user passwords was published by hackers.)1

Since newer passwords are not affected by the flaw, Amazon appears to have corrected the problem for new passwords — but without updating the older, stored passwords.

The fix is straightforward for those with older passwords: Simply log on to Amazon.com, and change your password. You can even then change your new password back to your old password, and you’ll magically be safer than you were before.

1This story originally misstated Gawker’s password security scheme. In fact, its passwords were stored using the same crypt() function mentioned in this story, and were only published after being decrypted by hackers.

Photo: An Amazon.com employee grabs boxes off the conveyor belt to load in a truck at their Fernley, NV warehouse. Scott Sady/AP.