1 million accounts leaked in megahack on banks, websites | Hacker News Reader

1 million accounts leaked in megahack on banks, websites

theregister.co.uk

89 pointsj_col35 comments

"Team GhostShell said the online leaks, which are part of its Project Hellfire campaign, were made in protest against banks"

Hey there, lady trying to make a car payment! Hey, guy checking his balance before he buys groceries! Your bank's a dick, so we ruined your week. Hope that's okay.

Usually when these things are investigated it turns out the targeted company had obvious security vulnerabilities and were too obtuse to correct them. Consider a bank keeping their cash in an open box in the middle of the street. It's wrong to raid the box, but it's also irresponsible on them not to have good security in place.

Yes, and WhiteHats would raise those security concerns with the company, privately, and work with them to get it solved. If the company didn't work to fix them, that's when you raise it publicly.

Not with something high-profile like banks - they should be having their security check all the time, why should someone pentest them for free?

And if clients don't know how secure their bank is, they don't really have a choice other than guessing.

I guess the logic is that these people then go 'hey, my bank clearly isn't secure' and switch to a different bank.

This is the same leak that claimed to have "CIA records", which actually turned out to be from http://ciaservices.com/ instead of the government agency. There's a lot of hype surrounding this that seems to be total bullshit. The "1 million records/accounts" includes a lot of trivial, non-sensitive information, and the targets are mostly low-value to begin with. Seems like someone just ran a bunch of SQL injection attacks on random vulnerable websites and is trying to pass it off as grandiose political activism.

Semes like a linkbaiting headline (of the original article) once again... Don´t see these "1 MILLION" accounts anywhere an neither the mentioned blog post [1] nor the original announcement at pastebin [2] does mention that. (EDIT: The pastebin statements indeed mentions "one million accounts/records leaked", buy thats not quite the same imho (emphasis on "records").

The blog post states explicitly that "a lot of the stolen content did NOT include any sensitive information".

[1]http://blog.imperva.com/2012/08/analyzing-the-team-ghostshel...

[2]http://pastebin.com/BuabHTvr

"What kind of banks got hacked? Banks you never heard of."

You don´t have accounts with MoneyMantra,Mitsukaru, Commerce Bank of Wyoming or the Central Bank of Bangladesh? Great rates!

I live in Wyoming and never heard of the Commerce Bank of Wyoming!

Everything about the Register is linkbait and hysterics.

... and puns.

A small-ish blog post by Imperva security discussing the leak: http://blog.imperva.com/2012/08/analyzing-the-team-ghostshel...

Even if the original article capitalized the "million", it's good practice here to convert to regular capitalization when submitting. It just reeks of loudmouthed sensationalism and linkbaiting. I refuse to clickthrough on such submissions.

Fixed (I just copied-and-pasted the original).

Thanks.

What's megahack? Is it run by Kim Dotcom?

Personally, I'm just happy it wasn't an ULTRAHACK.

It would need to be spoken in an Unreal Tournament voice, too.

I wrote a simple python script to download all the content. Hope to do some analysis on it offline. Please don't mind the newbie coding skills :). I put the script on github at https://github.com/kudithipudi/Misc-Scripts/blob/master/pars...

News stories like this are sometimes hyped but it's better to be safe than sorry.

I wonder if writing sky-is-falling style articles resonates more with people who would otherwise not treat their own online privacy/security as something to take seriously.

Ahhhh, we've come full circle. Back from the days when script kiddies would DoS a site or 'crack' a telnet password, then deface and claim they have street cred.

I would love to find someone who has actual street cred and had their account information released by these chuckleheads, and put them in a room together.

This isn't about politics. I doubt these losers even know anything about the companies they attacked. Fucking douchebags.

However, I should also blame the companies involved here. If they can afford $1000 for some kind of web app firewall they probably could have detected sqlmap raping their site with faulty queries.

That behavior never stopped, in fact it's so common that it's not news anymore which is probably why you haven't heard of it in a while. http://news.cnet.com/Defaced-site-archive-retires/2100-1001_... Who said it was about politics? I should also blame the companies involved... Exactly, this is about making unsafe companies feel unsafe.

I don't find their actions particularly praiseworthy, but if this can be done by a bunch of scriptkiddies, I'm not sure they did anything but slightly move up the inevitable, since organized criminal groups are also running similar scripts.

Organized criminal groups are more scrupulous. They just want your money, or to be information brokers. They won't publish your name, address, phone, social and god knows what else to the world.

I could give an extreme example and say that this kind of information disclosure puts stalking victims at risk, but there's a million more reasons we protect the privacy of individuals. Criminals simply have no reason to do this kind of thing, but the script kiddies think it's hilarious.

At least if the data is published you can search and see if you need to go in to your bank and shout at the manager.

Your bank manager does not make IT policy. Please do not shout at him.

The lamers who released the information could have easily blacked out parts of all of any sensitive information, or disseminated other kinds of proof of their attack. Then you could still be angry at your bank without getting people's personal information.

Posted a couple days ago http://news.ycombinator.com/item?id=4435348 not much discussion though.

> An analysis of the hacks by security biz Imperva reveals that most of the breaches were pulled off using SQL injection attacks.

Client-side encryption, even in JS, would have prevented this, it seems.

If you depend on the client for your security => Game Over

(of course, SSL is kind of dependent on the client, but it's their security not yours in risk)

If you naively depend on the client, sure, it will be game over, but that is true of any naive security.

Endpoint encryption does solve many problems, but it doesn't solve all of them. Take a bank case: sure, you could encrypt your account number and transfer amount on your machine, but the how is the bank supposed to do anything with these random bytes you've sent? If they have the keys (like they do with SSL), we aren't any better off.

With some complex public key crypto, you could maybe make things better, but you would be dependent on everybody treating their private keys well. I'm not convinced big companies could manage that, much less "Joe the Plumber".

Trusting the client is not the same as securing the client.

Edit: I didn't like my initial tone, so I backed off.

There's a great write-up of why doing cryptography in JavaScript isn't a good idea at http://www.matasano.com/articles/javascript-cryptography/. The browser is a very difficult environment to run your code in a trusted way.

No. Query parameterization is how you avoid this. How do you propose that encryption would prevent SQL Injection?

Encryption prevents leaked data from being meaningful. No amount of server-side security, including query parameterization, can guarantee the absence of leaks. Client-side encryption makes leaks much less devastating.

How encrypting user data in JS on the client is different from properly hashing user passwords in JS on the client? It is now accepted that sending and storing passwords in plaintext is bad practice; the logical next step is to encrypt not only passwords, but all data on the client.

Encrypting a password on the client-side means that all a cracker needs to login is the hashed password, which is exactly what they would get from a database dump, thereby bypassing the entire point of hashing the password in the first place. (Yes, I'm aware you could use a different salt on the server than the client, but that would require that the client-side encryption be reversible, which is perhaps even more problematic.)

Reply on news.ycombinator.com