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.
Editor’s Pick: Promoted Reader Comment
IntergalacticWalrus | Ars Praetorian jump to post 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.
Last edited by IntergalacticWalrus on Thu Jul 12, 2012 8:42 am
563 posts | registered Nov 17, 2009
mohaine | Ars Centurion jump to post El Chupageek wrote:
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.
301 posts | registered Jun 15, 2004
source:http://packetstormsecurity.org/news/view/21233/Hackers-Expose-453-000-Credentials-Allegedly-Taken-From-Yahoo-Service.html