1 million user accounts (including passwords, email and home addresses, and data of birth)

All admin account details and passwords

75,000 music codes

3.5 million music coupons

In addition, there was even opt-in data that was accessible,
which gives even more information about Sony's customers and their preferences.

The part that amazes LulzSec (and us for that matter) is
that fact that Sony stored all 1 million user passwords in simple plain text
files -- no encryption whatsoever was used. "It's just a matter of taking
it," stated LulzSec in a press release. "This is disgraceful and
insecure: they were asking for it."

The group went on to express its disdain for Sony and its
security practices (or lack thereof):

Our goal here is not to come across as master hackers, hence
what we're about to reveal: 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?

LulzSec has provided evidence of their latest
"Sownage" on its site, which can be accessed here.

Comments

Threshold

Username

Password

remember me

This article is over a month old, voting and posting comments is disabled

Its not the fault of IT,DB or Web Dev. As i said before Sony is a mesh of (outsourced) companies. Different companies probably did the different parts of the web site/DB/network and systems infrastructure. And i bet they did it according to Sony requests.

Encrypted data ? Adds too much overhead on multi-sites, whether its a replication, backups or just IO. You save on CPU,HDD and RAM. Weak Security ? Lousy contract.

They entered by a simple SQL injection. Afterwards they just went nicely through the network and systems infrastructure and basically downloaded everything in plain text. Sony just saved major dollars on R&D(DB,Web), deployment and infrastructure (network and systems) and maintenance (Network/Systems/DB/Web).

IT are the gatekeepers yes, but i believe there is none in this case. You might have one problem, a crack on your armor in one point, but from what I've read, Sony had no armor. This was almost child's play.

SQL Injection attacks can be avoided with simple input scrubs on the data. Anyone running a popular website should be sanitizing user input fields and stripping unauthorized commands.

When I program a site that accepts user data, I use a simple exclusion process where the data for the particular field must conform to a specific format else it is rejected. So for example, the ZIP code field could be like 10 alphanumeric chars only, and everything else would return an error.

It's not really hardcore security that will cause overhead...it's common sense.

I a am more a Network and sys admin, but as far as i know, web implementation on a larger scale is segmented on different "sites" with different "parts" of the site in a layered approach. One of the reasons we do this is to load balance between "sites" and another is security. You can't Query/DDoS the total DB/Web, because of its layered approach.

I've been a sys admin for some time now, or working indirectly through various forms, and honestly while attacks are quite frequent, never had this type of problems. And surely not this massive.

Load balancing happens on the back end, and smart companies would use a reverse proxy like nginx...but that is the infrastructure level and SQL injection is an application level attack.

SQL injection is an exploit within HTML code and the server's particular script engine (i.e. PHP,ASP,CF) where the hacker can actually use non-santized input fields to execute arbitrary SQL queries.

For example, if you have a field for "first_name" on a web form which gets POSTed to the server, the value of "first_name" could be an arbitrary SQL query if the data is not cleaned by the application first, simply by issuing a command that tells the script to execute only the submitted "hack" code while ignoring the actual remaining code within the script. Since all script engines have standard SQL functions built in, that's how you can access passwords and dump the entire database.