Sony's PSN down "for a day or two"

[HaemishM]

This could potentially have more damaging impact than the RROD. This is people's credit card and identity security they are talking about. A bricked console is a PITA, but it can be fixed. You fuck with someone's money, they get stabby.

[Azazel]

Yeah, that's my point. I also had to pay my bank $10 to get a new CC issued, aside from all of my personal details having been compromised. I wonder when I'll find out I have a mortgage, 20k credit card and 10k car loan? Thanks, Sony!

[UnSub]

MS ignoring the RROD issue wasn't a good move, but arguably getting their console out early helped put the Xbox 360 up and over the PS3. Of course, if Sony had been less stupid, it could have hurt MS a lot too.

This is worse. As a 'virtual' service, account security is a 'basic' requirement. As Haemish said, a console breaks, you send it back and get another one or store credit. Here Sony have lost a key part of the actual customer relationship and have handled it badly.

[tgr]

Also this is something that has affected everyone, I still haven't had the RROD on my original 360 (this was when 10 or 20GB was the biggest HD available, I think, I don't remember). Granted, I'm not the one to use the 360 a lot, but it's still 5+ years old.

[Mrbloodworth]

Its increasingly becoming something that is widespread, how many high profile, high sensitive hacks have gone through in the last year? I want to say its a bit unprecedented, its also not just Sony. Thats why I asked before if the current way of doing things is just too old now.

[UnSub]

Its increasingly becoming something that is widespread, how many high profile, high sensitive hacks have gone through in the last year? I want to say its a bit unprecedented, its also not just Sony. Thats why I asked before if the current way of doing things is just too old now.

It's not just that - there's also the realisation of how much money can be in a hack. Or even the threat of an attack.

[Zetor]

There are a few reasons for this (I was holding a training about itsec / secure coding for ericsson programmers yesterday, and this conversation eerily reminds me of it ):
- technical: Security testing is Hard. Most companies don't care about it at all ('I only need to check that my program works when accepting valid input!'), and even for those that do, their developers might not have the "hacker mindset" to know what kind of malformed input to look out for, how to do threat modelling / misuse cases / attack trees, how to set up negative test cases, fuzz testing, taint analysis, etc.
- scale: You have x people doing security testing on your product for y months (and yes, x/y are both often 0) and you need to fix every single vulnerability. The hackers have tens of thousands of specialists who only need to find one exploitable vulnerability to run your day. They also have until the end of time to find these vulnerabilities. No pressure, guys!
- market forces: Secure development is expensive. This means your product will be more expensive to make, you have to sell it for more and... so what? Yeah, you can spend crazy amounts of money/time to get certified by Common Criteria and get a spiffy EAL4 rating, which means bugger-all to 98% of your customers (quiz time: raise your hands if you heard about Common Criteria and/or knew what EAL4 meant without googling it). Oh yeah, and if you're billing your product at extra secure, expect the most skilled hackers to view breaking it as some kind of achievement, which means you're making things even harder for yourself!
- lack of responsibility: Development companies don't need to care about data loss / theft etc resulting from their systems getting compromised. They'll release a patch x days after the discovery of the vulnerability (and if they're lucky, the one who discovers the vulnerability discloses it to them before exploiting it for profit), but the onus is on the end-user to keep their systems patched. You didn't apply the patch that came out just 2 hours ago? Tough, some script kiddie may have already exploited the fact that you are still running an old / vulnerable version.

The only positive development is forcing companies to publicize data breaches in detail (like this one), which is a good start... it SHOULD start some kind of feedback loop that eventually forces developers to give a crap about security. Me, I'm still waiting to see some hard data on how exactly the Sony attack took place instead of some random rumors.

Also, see http://www.schneier.com/blog/archives/2011/05/interview_with_20.html

[Samwise]

taint analysis, etc.

[KallDrexx]

SonyMusic.gr, Sony BMG's Greek presence, has been hacked. The site fell prey to an SQL injection attack, with the hackers releasing thousands of account names, e-mail addresses, and unencrypted passwords.

 

[01101010]

So who did Sony piss off that badly? Jeezus Christ... 

[Samwise]

Blood in the water.

[Yegolev]

Hide yo wife, hide yo kids....

[Amaron]

So who did Sony piss off that badly? Jeezus Christ... 

Did you miss that bit where they pissed over the entire cracker community before all this started?

[Tale]

Now they've hacked Sony Music Japan and Sony Ericsson: http://news.cnet.com/8301-27080_3-20065816-245.html

[Morat20]

Dear "Professional Computer People":

IF YOU AREN'T HASHING PASSWORDS, YOU IS DOING IT WRONG.

Do I need to make a lolcat for it? Is that what it'll take? Some cat or walrus sitting here with "I haz a salted and hashed password" bucket?

This isn't Rocket Science. I know rocket scientists. They have to do math and shit. YOU merely need to call already written functions! Hell, in some cases you just need to go into your DB settings and schema and click a damn checkbox.

Maybe if I add "Am aware of all internet needs to hash passwords" to my resume, I can ask for more money.....

[Zetor]

Refer to my earlier post ('taint analysis' and 'fuzz testing' included... can't say I haven't seen Sam's reply coming btw ): developers and their companies don't give a shit about security because they don't think they need to. Film at 11.

[Yegolev]

So who did Sony piss off that badly? Jeezus Christ... 

Did you miss that bit where they pissed over the entire cracker community before all this started?

I think I missed that.

[Yegolev]

Sony feels so bad about losing my personal info that they would like for me to sign up for an affiliate offer.

[Paelos]

Sony feels so bad about losing my personal info that they would like for me to sign up for an affiliate offer.

There are going to be case studies written on this one.

[fuser]

Welp with the store still offline you cannot use the code with Dirt3 that unlocks the DLC of multi-player. (Codemasters uses the $10 DLC as a control on reselling the game, a free one time use code is in the box).

[kildorn]

SQL Injection? REALLY? Are we doing that again? Didn't we all have like, a solid week of why you never let your webserver send direct arbitrary SQL?

I'm also amused that the dump seems to imply they're running MS SQL Server?

[KallDrexx]

I'm also amused that the dump seems to imply they're running MS SQL Server?

Erm, there's nothing wrong with running MS Sql Server...

[tgr]

I'm also amused that the dump seems to imply they're running MS SQL Server?

Don't make me sneer at mysql.

[HaemishM]

Aren't SQL injection attacks fairly easy to prevent? Wouldn't you think that a company with an IT budget the size of Sony should have someone that could do that?

[KallDrexx]

Aren't SQL injection attacks fairly easy to prevent? Wouldn't you think that a company with an IT budget the size of Sony should have someone that could do that?

They are ridiculously easy to protect from, and the solutions for it are well-known for every language known to man.

[Zetor]

Aren't SQL injection attacks fairly easy to prevent? Wouldn't you think that a company with an IT budget the size of Sony should have someone that could do that?

They are, they should, and they don't. Sadly, they're not alone...

edit: people are also writing C code with buffer overflows in them, don't know how C handles integers, use hardcoded passwords, etc etc... all this in 2011. Everything old is new again! 

[Fordel]

SQL Injection? REALLY? Are we doing that again? Didn't we all have like, a solid week of why you never let your webserver send direct arbitrary SQL?

I'm also amused that the dump seems to imply they're running MS SQL Server?

Is little Bobby Tables running loose again?

[Lantyssa]

Heh.  I loved that one.

[fuser]

They are ridiculously easy to protect from, and the solutions for it are well-known for every language known to man.

This is the company that had unpatched version of Apache with known exploits on core auth servers. Very easy for them to have an unpatched MVC framework if they had one at all.

People are just systematically scanning anything Sony related and having a fun time.

[Tale]

Saw a tweet by a hacker: "I would like to congratulate Sony for holding the best and most enjoyable CTF ever".

[Sheepherder]

Aren't SQL injection attacks fairly easy to prevent? Wouldn't you think that a company with an IT budget the size of Sony should have someone that could do that?

It's like the first goddamn thing they teach you in high school programming - how to take a string of number and letters, cut some of that shit out, then concatenate the remainder all back into a whole.

[Zetor]

Actually, the proper way to defend against sqli is to NOT concatenate user input into the sql query at all, but use prepared statements instead. If you're trying to cut some stuff out from the input ("things that look like sql commands"), inventive hackers can find ways to get around your rules ('DR/**/OP DATABASE' is a quick-and-dirty example, see some more here) and you may end up filtering valid input as well. If you're going to do filtering, use whitelisting: reject all queries that do NOT fit a predefined schema. Blacklists = Bad, Whitelists = Good.

e: of course, "use prepared statements" is among the first things you learn when they teach you SQL... and a lot of developers still don't know how to use them.

[kildorn]

But my code is SPECIAL and may do all sorts of fancy off the cuff queries I couldn't possibly list out!

<-- just got done with an email thread that was basically declaring that as the reason for not letting the DBAs know what queries were going to come out of a new utility app.

[Sheepherder]

Actually, the proper way...

Yes, but my impression as a layman was correct.

So, dissecting that article, it seems like the correct method is to add an additional layer of abstraction between your database and your user interface that enforces bounds and type?

[Tarami]

Actually, the proper way to defend against sqli is to NOT concatenate user input into the sql query at all, but use prepared statements instead. If you're trying to cut some stuff out from the input ("things that look like sql commands"), inventive hackers can find ways to get around your rules ('DR/**/OP DATABASE' is a quick-and-dirty example, see some more here) and you may end up filtering valid input as well. If you're going to do filtering, use whitelisting: reject all queries that do NOT fit a predefined schema. Blacklists = Bad, Whitelists = Good.

e: of course, "use prepared statements" is among the first things you learn when they teach you SQL... and a lot of developers still don't know how to use them.

You use an O/RM.

I had a nice rant going but, eh, not really the place.