GroverCleveland: f you run a financial operation that large and do shiat like this

I don't care if it's a local pony farm's customer portal, you deserve to be fired if you don't secure your application against the simplest of attacks like this.

I love how they are painting this as some super-sophisticated and unpreventable Swordfish-style attack.

The White House could wish it could spin that hard.

What a crock of sh*t. Admit this was entirely your fault and that the info was taken by the hacking equivalent of a 10-year old.

What Plants Crave: I'm more appalled by the fact that the application was written in way that required an account number be passed from the client to the server at all. That's just, lazy.

/Farking RDBMSes, how do they work?

Since it's just a unique identifier, it's perfectly appropriate (a user may have many card accounts - for instance, last year they "upgraded" me to a more profitable card, so I have two such numbers. Since the account identifier does not contain any secure information - see above - it's legitimate to use that in the URL for a page). The only error is that knowing the account ID is sufficient to gain access to it.

Dilbert's boss is currently walking around asking who broke the HTML. What I'm still waiting for is how high up the ladder the scapegoat will be. No sense in betting on something like whether the CIO or other pooh-bah will be anything but promoted.

Authorization and authentication are not the same thing guys.

Oh yeah!!

These peopel got a BAILOUT too..

SO they where TOO BIG TO FAIL...

Just think if they went bankrupt years ago this might have never happened.

Wow, online banking really IS convenient. You don't even need money. Just the ability to type numbers.

"One expert, who is part of the investigation and wants to remain anonymous because the inquiry is at an early stage, told The New York Times he wondered how the hackers could have known to breach security by focusing on the vulnerability in the browser."

Because they farking noticed their own farking number right in the farking URL?

One expert, who is part of the investigation and wants to remain anonymous because the inquiry is at an early stage, told The New York Times he wondered how the hackers could have known to breach security by focusing on the vulnerability in the browser.

Looking at the actual address bar is an easy way to identify this type of vulnerability. If you don't use a very random method of creating sessions, and instead choose to use the user's account number (or a simple variant of) as the session ID, then guess what? Your system will be breached rather quickly.

The question is this: how many times did it happen in the past that your "crack team" (as in smoking it) didn't catch?

He said: 'It would have been hard to prepare for this type of vulnerability.

Funny, it's one of the first things I learned not to do when in college about 15 years ago. It's an extremely ovbious flaw, and a sign of rushed interface development.

Also, this is not a vulnerability. The use of account numbers in easily derived formats is the vulnerability. The actual vector of attack being used is a threat. The possibility of it happening is a risk. The company was either unaware of the risk, or accepted it. They did not prepare for the threat on a large scale. The actual vulnerability is an easy thing to remedy.

If you're going to play security expert, please know your terminology.

It's now one of the opening chapters in any secure coding course (such as the ones offered by most Universities, SANS, ISC2, etc.). This is what happens when you choose to:

A) off-shore your IT dept to the lowest bidder (which I know that Chase has done for a lot of their enterprise systems)

and/or

B) refuse to spend the money to properly maintain the skills of your employees

The "security expert" should be identified so that the rest of the infosec community know not to use him for consulting in the future.

/actual security professional

dustlesswalnut: i.r.id10t: tricycleracer: They had plain text account numbers in the URL?

Epic fail.

Should be done wiht POST as opposed to GET. Yes. But then, if you are passing something via GET that is plain text, get a hash of everything being passed and send that too. Server parses everything and re-creates hash, if hashes match then life is good.

It doesn't matter how you send the data. GET/POST isn't the issue, it's that their user authentication was only handling the login, and not subsequent page loads.

That way it wouldn't matter how many URLs you attempted; it would only grant access if they user account you're logged in with has access to the account you're attempting to view.

What an amazing lack of foresight and abundance of negligence.

+1. If this was a POST it would be just as much of a problem. You should look into a program called Fiddler. Hashing by itself does nothing to alleviate this problem either, unless of course you add a key to the end of the hash. Your attackers can do a SHA-1 as well. The fix, as dustlesswalnut suggests, is to require authentication for every HTTP request and verify that the requestor owns the account being accessed. I sincerely hope that i.r.id10t doesn't work in any technical/security related field.

All I can say is...

Wow. It took THIS LONG for this to happen? Also, Let me check to see if my bank does the same thing.

Gestalt: If you're working for a financial institution and you're passing account information in through the address bar, your whole department needs to be laid off prosecuted and electrocuted.

WTF...Do you expect forethought and caution from an institution that is so farking negligent that they played a huge (probably the biggest) role in bringing down the entire farking global economy?

Enigmamf: rts: Law enforcement officials said the expertise behind the attack was a 'sign of what is likely to be a wave of more and more sophisticated breaches' by high-tech thieves.


Now I'm not some big city security expert, but this doesn't sound like it required any sort of expertise beyond "for num in `seq 4500000000000000 459999999999999` ; do wget www.citi.com/my_account?$num ; done".

I really hope there's more to it than this or that I'm totally misunderstanding what's being reported here.

They identify your accounts with a 5-digit numerical ID, so it's more like from 10000 to 100000, with EVERY SINGLE NUMBER BEING A HIT!

(Yes, it gets dumber every time you look more closely)

Not every single number in the sequence will be a valid CC number though. They could easily run each one through the Luhn algorithm first to see if they should even bother submitting it to the server. Lower risk of detection and a lot more hits.

Yogimus: All I can say is...

Wow. It took THIS LONG for this to happen? Also, Let me check to see if my bank does the same thing.

I did the same thing mine is clear... it does some generic code thing. like home or something

snocone: Hey, "pretty good security" IS the industry standard.

And for what it is worth, this setup fit the bare-ass minimum they could get away with. They relied on security-through-obscurity in that they did not account for someone altering the numbers in the URL. There was no incentive to address the issue until now. I can guarantee that they knew about it, but the amount it would take to fix the issue would have been more than the management was willing to spend. It took a public shaming for them to even begin to address the issue. This is what large corporations do, the bare-ass minimum. Don't even try to pretend that they are altruistic and actually continuously test their security outside of the minimal requirements. It is the nature of corporations. We have tons of examples of corporations only addressing issues once they explode into a mess. Remember the Pinto?

danny_kay: But if projects of this "quality" go online, it's often not a problem of lazy programmers, as Jake Havechek apparently implied, but a problem of these programmers doing the best they can within the constraints of the project.

Your example is a completely different thing-- your superior wanted a less-than-great feature implemented. Nothing wrong with that-- the web is full of stupid things like that, and apparently, it was exactly what the client wanted.

In the case of TFA, even if it wasn't specifically outlined in the spec, the programmers should have caught it and fixed it. They already had an authentication class, assuming the while site wasn't some gigantic pile of noodly procedural code, and if they had that, they should have been utilizing it everywhere user information was pulled.

As far as stupid projects for stupid clients go, I've got a list a mile long. This is not one of those cases. I can guarantee that no one in management ever said "hey-- make sure we don't check credentials after they're logged in."

meathome: The use of account numbers in easily derived formats is the vulnerability.

Sequential account numbers are not to blame, the lack of a proper authentication is to blame. It really doesn't matter if you end every URL with GET vars containing plain text SS numbers, passwords, usernames, and astrological sign-- the problem is that client-side modification of those values wasn't checked in any way.

danny_kay: But it's also a fact that a) clients demand Java for *serious* stuff and b) tutorials for "scripting languages" often focus on the "fun" stuff, so I'd say that a PHP n00b is more dangerous in a situation like this than a Java n00b (<-- simplified).

a) clients that demand Java demand Java. I've developed countless "serious" systems with it. In most cases, clients with preexisting Java architecture demand it. Most don't care.
b) n00bs of all shapes and sizes are dangerous, and I can agree that it's easier for a n00b to write something that actually does anything with PHP than it is with Java

FTFA: Law enforcement officials said the expertise behind the attack was a 'sign of what is likely to be a wave of more and more sophisticated breaches' by high-tech thieves.

Well, it is true that the sophistication can only go up from here, if what the article says is true.


luckybastard: It's gotta be somewhat more complicated than that, right? Please?


I wouldn't put it past the Daily Fail to have pulled this out of its ass in order to excite readers into thinking that they, too, can become master hackers by changing a digit in their address bars. Or perhaps they might make the explanation up just to troll people like us. A paragon of journalistic integrity, that publication isn't.

I love how everybody is talking about the expense to fix this when the real program is the moranic design in the first place. There are better ways to implement this process that don't involve using my farking account number on the web address.

Isildur: I wouldn't put it past the Daily Fail to have pulled this out of its ass in order to excite readers into thinking that they, too, can become master hackers by changing a digit in their address bars. Or perhaps they might make the explanation up just to troll people like us. A paragon of journalistic integrity, that publication isn't.

This article actually made me angrier than anything I've read all week (which is sort of sad, really) but then I got to thinking about who published it, and now I'm less angry.

It's like reading a tabloid but with the occasional fact thrown in just to f*ck with you.

expert my ass

I have had a citibank a/c since 2008 and this is simply not true; there is no cc number in the URL, though it may be part of the POST. Also, the citibank interface is ultra conservative; it even forces me to use that darned web keyboard for entering the password. By the looks of it, it is JSP based and uses https exclusively. So,.....either citibank in the US has a substantially different design (seems unlikely) or the actual breach is so bad that they came up with this lame story to hide it.

Sooo...I should probably consider selling those Citi shares sometime in the near future then?

/Too late already?
//Too late five years ago?
///Dangit...

Enigmamf: danny_kay: iheartscotch: Yeah; it sounds like someone took the intro to php course and decided they could do security. Which wouldn't have been all bad; but they only went to the first three classes

*shudder*

You could be right...

Nothing against PHP or any of the other lightweight languages, but anything that involves money demands a different caliber of application.

You'd be an idiot to think this kind of error is somehow inherent in PHP. Just because you can't see all the client-side pagestate in ASP.Net doesn't mean it can't be hacked... which will trip up more beginners than something obvious like checking that you can't change the ID in the address...


Nerd Fights are hot!

SoundOfOneHandWanking: I love how everybody is talking about the expense to fix this when the real program is the moranic design in the first place. There are better ways to implement this process that don't involve using my farking account number on the web address.

There are only a few ways to get information from the client to the server. Sure, it shouldn't be necessary to leave it up there, but there's nothing wrong with how they passed that data.

SoundOfOneHandWanking: I love how everybody is talking about the expense to fix this when the real program is the moranic design in the first place. There are better ways to implement this process that don't involve using my farking account number on the web address.

And they aren't difficult or time consuming to implement. They could have done this correctly from the get-go with the same amount of work. The programmers were just monumental idiots.

YeYowYa: I hate effin IT's

You hate IT's what? What do they own that you hate.

And you hate bad IT. You like good IT it's just that you never notice when things are done right.

justaguy516: I have had a citibank a/c since 2008 and this is simply not true; there is no cc number in the URL, though it may be part of the POST. Also, the citibank interface is ultra conservative; it even forces me to use that darned web keyboard for entering the password. By the looks of it, it is JSP based and uses https exclusively. So,.....either citibank in the US has a substantially different design (seems unlikely) or the actual breach is so bad that they came up with this lame story to hide it.

It could be a single page buried in the UI that most people never use. One that's been around for ages and never updated. It could be the URL for a PDF statement download. It could be many things, but just because you have to use some POS on-screenkeyboard (which is absolutely 100% not more safe than any other keyboard) doesn't mean it's safe.

Security pictures and passphrases are pointless, too. The average consumer would never think "Man, where's the clipart baseball?!!! I can't log in here, it's not safe!"

dustlesswalnut: SoundOfOneHandWanking: I love how everybody is talking about the expense to fix this when the real program is the moranic design in the first place. There are better ways to implement this process that don't involve using my farking account number on the web address.

There are only a few ways to get information from the client to the server. Sure, it shouldn't be necessary to leave it up there, but there's nothing wrong with how they passed that data.

Accounts are tied to the login. Once you login, the application should already know which account(s) you have access to and keep it on the server. A page should never take that kind of input from a url.

danny_kay: teacher M: Nerd Fights are hot!

Ahem.

Some of us are actually female.

/as I said
//corporate whore
///corporate *attention* whore, to be exact

So only guys can be hot now?

/definitely got the attention whore part right...

Mike_LowELL: Enough is enough. The government needs to take action against the internet. They need to make GUI browsers mandatory and add chkdisk onto every new hard drive. If that doesn't stop it, then they should lock down the internet using the "dir /p" command. That's the only way they're going to stop these miscreants. These hackers are unstoppable. The first attacks are going to be simple. They are going to steal credit card data. They will soon be stealing houses and countries. I just upped my anti-aliasing settings as high as they can go. I'm not taking any chances against these super-hackers.

Just type "format c:" into your browser, it will delete the whole internet.

birchman: dustlesswalnut: SoundOfOneHandWanking: I love how everybody is talking about the expense to fix this when the real program is the moranic design in the first place. There are better ways to implement this process that don't involve using my farking account number on the web address.

There are only a few ways to get information from the client to the server. Sure, it shouldn't be necessary to leave it up there, but there's nothing wrong with how they passed that data.

Accounts are tied to the login. Once you login, the application should already know which account(s) you have access to and keep it on the server. A page should never take that kind of input from a url.

Again, it doesn't matter that the information is there. It might be better practice to not have it up there, but it's not bad practice.

The issue is that the application didn't read from a list of what accounts you had access to, it just let you view whatever.

Account data in the URL is only bad practice if modifying it on the client side allows unauthorized access to accounts.