Hackers expose 453,000 credentials allegedly taken from Yahoo service (Updated)

SQL injection retrieves user names and passwords stored in plaintext.

Hackers posted what appear to be login credentials for more than 453,000 user accounts that they said they retrieved in plaintext from an unidentified service on Yahoo.

The dump, posted on a public website by a hacking collective known as D33Ds Company, said it penetrated the Yahoo subdomain using what's known as a union-based SQL injection. The hacking technique preys on poorly secured Web applications that don't properly scrutinize text entered into search boxes and other user input fields. By injecting powerful database commands into them, attackers can trick back-end servers into dumping huge amounts of sensitive information.

To support their claim, the hackers posted what they said were the plaintext credentials for 453,492 Yahoo accounts, more than 2,700 database table or column names, and 298 MySQL variables, all of which they claim to have obtained in the exploit.

"We hope that the parties responsible for managing the security of this subdomain will take this as a wake-up call, and not as a threat," a brief note at the end of the dump stated. "There have been many security holes exploited in webservers belonging to Yahoo! Inc. that have caused far greater damage than our disclosure. Please do not take them lightly. The subdomain and vulnerable parameters have not been posted to avoid further damage."

In a statement published by TechCrunch, Yahoo representatives confirmed a breach that hit the site's Contributor Network (previously Associated Content) on Wednesday. The stolen data was contained in an "older file," and only about 5 percent of the exposed credentials were still valid on Yahoo.

"We are fixing the vulnerability that led to the disclosure of this data, changing the passwords of the affected Yahoo! users and notifying the companies whose users accounts may have been compromised," the statement continued. "We apologize to affected users. We encourage users to change their passwords on a regular basis and also familiarize themselves with our online safety tips at security.yahoo.com."

Because many people use the same credentials for multiple accounts, Ars isn't identifying the address of the website that published the disclosure. But at time of writing, the URL wasn't hard to find.

The TrustedSec blog is reporting that the hacked service may be Yahoo Voices, aka Associated Content. That speculation is based on the string "dbb1.ac.bf1.yahoo.com" included in the dump. The subdomain is associated with the voice service, the post said.

Article updated to reflect TrustedSec now says the compromised property is Yahoo Voices. Later updated to add official comment from Yahoo.

Promoted Comments

At this point I guess we should always assume that every password we give to an online service is stored in plain text, and therefore avoid password reuse at all costs. Companies can't be trusted to give a shit about your personal security, and lawmen and/or politicians are too fucking clueless about technology to understand that storing unencrypted passwords should be considered criminal negligence and dealt as such.

SevenFactors wrote:

Given all the resent hacks, not to mention the massive PlayStation Network incident [hopefully they learned & now are encrypting, hashing & salting] One would think that companies who know are stashing users credentials in plain text would be proactive and not wait till they get hacked to then take action.

Well what to expect, Yahoo got stuck in 1998

PSN passwords were encrypted and salted. There's this common misconception that they were not because the initial disclosure of the attack stupidly used ambiguous terms, which they clarified later.

The problem here was SQL Injection (which, btw Dan, is not caused by failure to scrutinize input but rather by NOT using prepared statements and properly binding the user input. There is a difference).

This statement couldn't be more wrong.

Scrutinizing input (white list and/or blacklists) MIGHT stop SQL injection, but it only works if you happen to get it completely right. This damn hard with UTF and more advanced SQL engines. Proving you are doing this correctly is impossible to do. The best you can do is "Mostly Correct". Don't trust your data to "Mostly Correct".

Property binding completely removes user input from the SQL parser, which fixes the issue with no worries.

With respect to a broad range of Web application vulnerabilities, the statement is technically correct. When it comes to specifically SQL Injection, it is not "the most" correct and comprehensive answer one can give.

Proper input validation (aka white listing) can indeed wipe out large swaths of web application vulnerabilities, including SQL Injection -- but it is not guaranteed. When piping user-supplied input into database commands, an additional and essential layer of defense is to use parameterized SQL statements. So even if the input-validation fails, the web app is still protected, from SQL Injection at least.

The same is true of XSS. When printing user-supplied input to the screen, you need to perform context-aware output encoding. Again, input validation "might" save you, but proper output filtering definitely will.

Speaking for myself, given the sheer number of SQLi issues still in circulation, I'd easily take more of their coding option.

I cannot believe that SQL injection attacks are still successful. Who are these programmers that haven't heard about parameterized queries? I guess they're the same developers who continue to store un-hashed passwords.

This stuff isn't hard, folks. I implemented password storage just recently with unique salts, key stretching and Sha1 hashing just a few months ago; it took about 4 hours to get working.

Passw0rdpassword1password x2 for one guy on his hotmail and gmailpasswordnopasswordpasswordpasswordpassword17password11password2password12

I could go on for much longer.

What's the service even for? This obviously isn't Yahoo mail accounts. Maybe people intentionally picked lousy passwords because they just didn't care. I know I've done this before when forced to sign up for some account I couldn't care less about. Remember the RockYou.com breach? It made me cringe that so many people published researched papers on the weak passwords that were exposed. Really? It was RockYou. 90% of the accounts were probably one-time use and thrown away.

Passw0rdpassword1password x2 for one guy on his hotmail and gmailpasswordnopasswordpasswordpasswordpassword17password11password2password12

I could go on for much longer.

What's the service even for? This obviously isn't Yahoo mail accounts. Maybe people intentionally picked lousy passwords because they just didn't care. I know I've done this before when forced to sign up for some account I couldn't care less about. Remember the RockYou.com breach? It made me cringe that so many people published researched papers on the weak passwords that were exposed. Really? It was RockYou. 90% of the accounts were probably one-time use and thrown away.

Looks like mostly gmail, hotmail and yahoo email accounts. Didn't want to publish the whole things here on Ars. Many of them have their first and last names attached to the email so were probably not throwaway email accounts.

Looks like mostly gmail, hotmail and yahoo email accounts. Didn't want to publish the whole things here on Ars. Many of them have their first and last names attached to the email so were probably not throwaway email accounts.

You're assuming those same passwords are used for the mail accounts, and not just this site. I'm fairly sure Gmail would reject most of those variations of the word 'password' as a password.

There's a few others popping up here with leakedIn style sites, but I thought I'd still let you all know that we've updated the full breach into our repository on Should I Change My Password if anyone is wanting to check if they are included without downloading the file.

Oh, good, I'm not on the list. The ONLY reason I use Yahoo email is because it's hopelessly linked to my ATT DSL account. I made the mistake of linking them back in the days when Yahoo was actually worth more than a chuckle at their article commentary.Then again, maybe they don't store DSL passwords in plain text.

So it's not just yahoo.com credentials that have apparently been compromised ... the article is a bit misleading ...

Second this - it's not 'yahoo accounts' that got compromised, it's a yahoo service for which people create logins/passwords.

karadoc wrote:

KeePass rocks.

Absolutely! I've been slowly transitioning all my services to max length/max security passwords and storing them into KeePass synced with SugarSync. I need to sit down with my GF this weekend and teach her how to use it, because she uses a simple password (albeit with some letters - woohoo) for many of the services she uses. Even though my login wasn't on the list, I changed my password anyway.

dacjames wrote:

I cannot believe that SQL injection attacks are still successful. Who are these programmers that haven't heard about parameterized queries? I guess they're the same developers who continue to store un-hashed passwords.

This stuff isn't hard, folks. I implemented password storage just recently with unique salts, key stretching and Sha1 hashing just a few months ago; it took about 4 hours to get working.

Seriously, even a fresh-out-of-college kid would go "this is not secure, let me consult Google/StackOverflow".

Telekenesis wrote:

Some amazing passwords there:

Passw0rdpassword1password x2 for one guy on his hotmail and gmailpasswordnopasswordpasswordpasswordpassword17password11password2password12

I could go on for much longer.

How about "poop"?

On the other side of the spectrum, I was curious to see what kind of secure passwords people are using.

1qaz2wsxlkout4no1mtfbwy013wp0uleg5ego (that's a pretty good one, but use capital letters too, man)akash[290689]babi (is that your birthday in there?)hh2jqywd3wddwb

The winner, an apparent KeePass user:zQbXThY_}}pR,Z%&lt;93s&#039;

Not sure if it's OK to post these here, but these have been linked many times plus I'm not posting the accounts. Mods, please delete this part if it's against the rules.