12 ms·

How Hackers Stole 200,000 Citi Accounts Just By Changing Numbers In The URL

360 points by mmavnn 15y ago

nextparadigms 15y ago
How can a bank this large have such poorly designed security? It's ridiculous. Hopefully, all these latest hacks get everyone else to treat security more seriously. There could be a lot of other banks that do the same thing as Citigroup. So if one gets hacked, at least the others will remember to review their security policies, so it doesn't happen to them, too.
mrcharles 15y ago
How is this even possible? In my very first website I built from scratch using PHP, I paid attention to the possibility of this. I can't say for certain that I fully protected against it, but I tried. That little trick would not have worked. How is it that a bank, of all places, pays money for a web infrastructure, and manages to employ people who don't even think about the most basic of attacks? I've been changing info in URLs since I started using the internet.
- rmc 15y ago
  Diaspora had this problem when they first released their software, and it was written in Rails, a modern framework http://www.kalzumeus.com/2010/09/22/security-lessons-learned-from-the-diaspora-launch/ http://www.kalzumeus.com/2010/09/22/security-lessons-learned...
  - spdy 15y ago
    You cant really compare this with a bank like citygroup. Security is everything the should care about in the first place. They have to protect your money and nobody really cares about fancy features when they just want to wire some money, everything should just be rock solid. I would love to get more information about this breach it sounds to simple to be true.
    - mgkimsal 15y ago
      "Security is everything the should care about in the first place." profits are all they care about. Honestly, stuff like this burns me up. Large orgs like this lobbied for crap like PCI compliance standards to 'protect' data, but they don't have to follow their own rules. Seriously, if PCI compliance is mandated for anyone who stores CC info, why the hell isn't citi being shut down for this sort of breach? 'too big to fail'?
      - walkon 15y ago
        Has it been determined that Citi will not face repercussions for this incident? I think part of the reason PCI DSS was created (by the payment processors MasterCard, Visa, Amex, etc) was to allow for more legal leverage against the banks when determining who has to pay damages in scenarios such as this.
        mgkimsal 15y ago
        No, it hasn't. I'm just jumping the gun in a frothy rage. Something this egregious should have been caught by PCI compliance checks (if not development) in the first place though. I doubt the penalty will be anything severe enough - something like "no cc processing and management for citi for 180 days" might make them take this a bit more seriously.
        walkon 15y ago
        I think PCI is more of a reactive legal tool than it is an effective, proactive way to prevent security breaches. In theory it should catch security vulnerabilities, but I don't know how thorough the compliance checks really are... Yeah, Citi's greater punishment will likely be in the form of a weakened reputation then it will be in actual damages paid.
        mgkimsal 15y ago
        They're long, involved and expensive, although I'm not sure how thorough or really preventative they may be - you're right. For companies just getting started, they probably serve more preventative purposes than they do for already established players who were around before the PCI stuff came around.
  - StavrosK 15y ago
    The framework has nothing to do with not authorizing requests properly. Diaspora had many problems when they first released because apparently they were all inexperienced programmers, like the guy who wrote that in Citi.
- Jach 15y ago
  How indeed.. How can someone be able to architect the system of accounts, connection info, etc. for a bank but not be aware of such things? And it's not even being lazier either. Sigh... To all you 13 year old kids on the road of learning web dev, this is what you're competing against!
- phillijw 15y ago
  Companies are very cheap when it comes to hiring software devs. They can't see the benefit of paying more for a dev that can "do the same thing".
StrawberryFrog 15y ago
A security guy weighs in on it here: http://idunno.org/archive/2011/06/14/citibank-hacked-ndash-dumb-developers-dumber-security-consultants.aspx http://idunno.org/archive/2011/06/14/citibank-hacked-ndash-d... "This was not sophisticated or ingenious, as reported, this was boringly simple. ... OWASP has had Insecure Direct Object references on it’s Top 10 list for years. It’s in the SDL Threat Modeling tool. Any security firm worth its salt checks for this" Yes, there's a good description of this kind of trivial "hack" in the Open Web Application Security Project Top 10: https://www.owasp.org/index.php/Top_10_2010-A4 https://www.owasp.org/index.php/Top_10_2010-A4
- wccrawford 15y ago
  Yeah. When that first report said 'experts' said how hard it would be to have predicted and prevented this, I choked. Amazingly lame.
  - peterwwillis 15y ago
    Citi has an internal web application pen-testing group. My guess is they were only ever attacking the outward facing apps and not the ones after successful authentication. Even if so, they may have hundreds of apps to test which constantly change, and sometimes attackers just get lucky and find a hole as soon as it pops up.
    - tptacek 15y ago
      My understanding, just to clarify: Citi has a web app pentesting operation, which engages and is among the largest customers for several well-known pentesting firms. Just in case the impression was that Citi has a couple guys in a room doing this stuff. As for constantly-changing apps, let me speak against my own direct financial interests here (we have a product coming out that addresses that problem, so I'd like it to be a big one). Many, if not most, of the large financials we work with or have talked to have a fairly strict process for deploying new code, and the process gates on security review. Not deploying unreviewed code comes pretty close to being part of the due care standard at large modern banks. If I had to gamble on this, I'd bet that this specific code did get reviewed.
aw3c2 15y ago
"Gawker media blog spam". Visit http://www.nytimes.com/2011/06/14/technology/14security.html?pagewanted=all http://www.nytimes.com/2011/06/14/technology/14security.html... instead
- blatherard 15y ago
  Consumerist isn't a Gawker property anymore. They are now owned by Consumers Union, who also publishes Consumer Reports.
- sili 15y ago
  I was actually disappointed by the NYT article. They interview security experts who call the attack "ingenious", "hard to prepare for" and performed by exploiting a vulnerability in a browser. This understates how incompetent the bank's website design is.
  - mmavnn 15y ago
    That was why I linked to this article rather than the NYT. The article linked to, while shorter, contains all of the relevant information and less completely random cluelessness.
    - chriserin 15y ago
      The NYTimes story is the 2nd crime, because they're white washing Citicorp's responsibility. With all the hacking that's been going on recently, the NYT needs a full time cyber security reporter.
narad 15y ago
That's worse than SQL injection. Didn't they build ACL?
- romaniv 15y ago
  ACL is probably part of the problem here. Most ACLs are very inflexible and are "opt in". They probably had ACL to block unregistered user from visiting the page, but it didn't deal with individual accounts.
thibaut_barrere 15y ago
You'll surely enjoy the quote from the linked article: ======= The method is seemingly simple, but the fact that the thieves knew to focus on this particular vulnerability marks the Citigroup attack as especially ingenious, security experts said. ======= Sorry but no, this isn't ingenious - it's really the basics!!!
- john2x 15y ago
  Yeah, the NYTimes article really made it look like the hackers went into a lot of trouble to breach the bank's security.
  - bron 15y ago
    Of course, the hackers were suffering from acute Alzheimer.
  - webjprgm 15y ago
    Of course they did, if they made it look simple then everyone would freak out (or they should, and have mass exodus away from Citi). People are used to hackers finding occasional, difficult exploits.
tnorthcutt 15y ago
I really hope that the reporter who wrote the NYT article either misunderstood the facts, or talked to an ignorant "expert".
fmavituna 15y ago
This is like the first thing you learn in web app security (defender or attacker) and you don't even need to write script a tool such as http://code.google.com/p/fm-fsf/ http://code.google.com/p/fm-fsf/ will scrape the data quickly. Even though it's insanely easy to spot and exploit it's also easy to miss it while coding. But any decent pen-tester will find it. Regardless, unacceptable for a finance company.
- planb 15y ago
  No, I don't think easy to miss because it shouldn't be possible in the first place. At least for a banking software, the web application layer is not the right place to check for this kind of authentication. This makes me wonder how their code must look like...
- dave1010uk 15y ago
  All you need is curl: curl http://example.com/user/[1-100]
leftnode 15y ago
What's worse: every customers ID in the database was stored in the URL or that there was no ACL to test against? If a user is logged in, you have their account ID stored in a session. If they navigate to a page that their account ID can't see (like another person's account), then kick them out. Astoundingly simple.
quattrofan 15y ago
Seriously how do people stay in their jobs allowing crap like this to happen? The CIO or CTO at Citi should get the boot. Until companies like this and Sony start making examples of people, this kind of sloppiness that gives our industry a bad name will continue.
- groby_b 15y ago
  Except the examples that will be made will not involve the CIO/CTO. And even if it did, the guy almost certainly a golden parachute - what does he care? As long as it's cheaper to clean up after the debacle than prevent it in the first place, that's what people will opt for.
  - rubinelli 15y ago
    They probably didn't develop it in-house, so it's just a matter of blaming and changing providers.
  - gnosis 15y ago
    "And even if it did, the guy almost certainly a golden parachute - what does he care?" If he really was fired and the company made a public stink about how much he screwed up, he may well care. Many people at that level care about their prestige, and care about being shamed in front of their peers, even when they don't need to worry financially.
- sdizdar 15y ago
  In majority of corporations responsibility and accountability ends somewhere between VP and CEO.
deleted 15y ago
[deleted]
- rawsyntax 15y ago
  For the record, enabling UUIDs in rails is straight forward. It's not the default though. Why turn on UUIDs? They are not as guessable as normal IDs.
  - dgl 15y ago
    Depending what sort of UUID you're generating that could leak your MAC address to an attacker which could prove useful.
  - fjlaskjd 15y ago
    ghfdfsghjhgfdsfghgfds
mgkimsal 15y ago
In 2000(?) I employed this same 'hack' against Ameritech's online bill viewer, but couldn't get anyone's attention. I called several people at Ameritech, but couldn't get through to anyone who understood anything I was saying. I tried to get ahold of newsmedia, but realized afterwards that the links I was sending did have a session timeout associated, so by the time a reporter clicked a link, they got nothing. Finally, I managed to get in touch with someone at 'fuckameritech.net' (IIRC) - a consumer watchdog (I hesitate to say 'group' - I think it was just one guy) who said "I'll take care of it". He made some contacts - I think got it to a reporter in Chicago, and that afternoon Ameritech's online bill view and pay was taken down (a wednesday IIRC) and it wasn't brought up again until Monday. The 'fix' was not much - they were now hashing the account number in some massively long (128 char?) ID instead of just your account number. But it was all still visible in the URL, which was the bigger problem to start with, because it encouraged 'hackers' like me to change my account number by one digit. I suspect others had noticed this before, tried to contact citi, and couldn't get in touch with anyone who understood what the caller was saying. Companies need separate 'web vulnerability' hotlines to call/contact to report issues like this - perhaps just hidden in the 'view source' - if you're good enough to find the info, you know what you're doing enough to report a problem. Too low a bar?
- FooBarWidget 15y ago
  I imagine that publicizing a web vulnerability hotline would result in more trouble that it would solve. Normal people really don't understand computers. If you somehow give off the message that your system is not perfectly secure or bug-free they would get scared and run off to competitors who are just as bug-ridden but at least appear to be more secure.
  - mgkimsal 15y ago
    While I sort of see, marketing/wording of this could spin this as a positive (assuming it was even something that was publicized - perhaps hidden in the markup is good enough?). We've popularized crime reporting as a social good - mcgruff the crime dog, etc. When will we start taking online safety and security with the same level of seriousness? As much as I don't like the idea, being able to report issues to a state or federal agency might be a way to go.
Shenglong 15y ago
It's funny that this wasn't discovered sooner. I suppose everyone figured a security flaw like this would never exist, and never bothered to try. Irony...
- wladimir 15y ago
  Most likely this was discovered sooner. But people kept the vulnerability to themselves and possibly even profited from it. These kind of vulnerabilities in high-profile sites can go unreported for ages, even up to the point that they are common knowledge in certain groups.
lucraft 15y ago
I'd argue that this wasn't even a hack. This is publicly visible information. No security measures were circumvented.
noduerme 15y ago
So...the first login had to have valid credentials. Someone needed a citibank account to start the scraper-bot. Wonder if the fbi's talked with that guy yet.
- count 15y ago
  I'd bet they used one of the hundreds of thousands of stolen accounts from other services to do this. You know somebody is sharing usernames/passwords with their SOE and Citi accounts.
- adolph 15y ago
  I think the key phrase would be "Someone needed access to a citibank account..." If some Citibank account(s) was compromised in some way, such as phished, then a third party would have the necessary access. It would be bad enough to be a victim of phishing--imagine being a pawn in a large scale attack like that. It would suck.
smackfu 15y ago
I wonder where they got the account numbers from. Citi doesn't show them in the web interface, just last 4 digits.
patio11 15y ago
I'm kind of torn on this. On the one hand, yeah, it is a trivial flaw. On the other hand, so is waving a gun at a teller. That attack has been around for decades and still works a few dozen times a year, because the cost/benefit analysis says that after hardening the banks a little it is easier to just lose a few tens of thousands of dollars every once in a while than it is to give them the Secret Service's attention to physical security. That is hardly the only systemic vulnerability in the banking system. For example, let's suppose I want to compromise your account number and credentials sufficient to take you for every penny you possess. You know what I need? A check of yours. Any will do. Everything I need to create a demand draft against your account is on every check you have ever written. Every employee of every business you have ever paid by check got the keys to your financial kingdom. You may not be aware of it, but since those credentials are assumed compromised, the security is in a) catching me when I use the demand draft to suspiciously drain your account and b) failing that, making you whole out of the bank's pocket. The numbers have been crunched: it is vastly, vastly more efficient to treat fraud as a cost of doing business than it is to tighten the screws 100% The attack surface on software the size and complexity of a bank's is like the Death Star, except any single rivet being out of place will eventually result in this headline. (Step #1 in tightening the screws would be turn off public facing websites, because inexpert users plus compromised machines means that no banking website will ever be secure, even without coding errors. This will never happen, because the provable cost savings of moving customers to online banking roflstomp over the marginal fraud risk.)
- st3fan 15y ago
  The attack surface on software the size and complexity of a bank's is like the Death Star, except any single rivet being out of place will eventually result in this headline. I agree that banking software is probably complicated. But really, this bug is a beginners mistake and it shoul dhave never happened. It is something that the original developers should have known about and also something that the company auditing this code should have seen. There is really no excuse for this.
  - bigohms 15y ago
    This is like the first thing any new hax0r tries. Imagine the joy when it actually worked...
snorkel 15y ago
I know exactly how this occurs because I recently met a "Senior Web Developer" at an established business who was basically their acting architect because he was the their first coder and therefor his non-technical bosses regarded him as some kind of genius because he knows how to unjam the office printer. He didn't know a lick of Unix, didn't understand load balancing, and had very weak SQL skills. He was your typical framework junky who couldn't imagine writing even the simplest web app without a framework to do all the heavy lifting. All he wanted was for me to recommend an even simpler web framework so he wouldn't have to write any SQL at all. No doubt some day his code will be generating headlines like this one, and he will no doubt blame whatever framework he used and his bosses will simply mandate that they switch to a more secure framework pronto, and they'll promote this boob as their Senior Architect to lead the project.
- silverlake 15y ago
  I've met hundreds of these boobs in IT shops around the world. There's a huge skills gap between IT and software devs. IT guys are not given the time nor resources to learn and implement all this stuff. Also, they often don't have the skills or curiosity to figure it out themselves. So they really do need a framework that takes care of it all easily.
- lawnchair_larry 15y ago
  That actually sounds like the right way to do it to me. He shouldn't be writing frameworks. Frameworks are reviewed by a lot of people, and there is a far greater chance of them being bug free than something home-rolled.
lifeisstillgood 15y ago
The big question is why the structure of the IT department lent itself to doing something so stupid You can fire the CIO, you can replace the offshore developers with onshore, or vice versa, but experience says it won't matter. I looked in amazement at googletesting's dependancy graph test suites yesterday, and realised that the playing field is not flat at all. Reading and writing code is the literacy of the 21st C. And the end most big companies are like newspapers owned and managed by illiterates. It does not matter how you rearrange the strucutre or the hierarchy, when the chips are down decisions will be made on what the illiterate management understand is the best way to work. As such it is infinitely unlikely that the decision then will be set up to support what a literate person would decide. Until a generation of coders grows up, or all illiterate companies go bankrupt, this will merely be one of a myriad of pathologies exhibited by large companies run by the illiterate.
yuvadam 15y ago
A naive question here: Suppose I accidentally stumble upon a gaping security hole in my bank's online service (or any other online service for that matter). Am I legally obliged to notify them of that security bug? Can I offer the bank my assistance, for hire, in solving the bug without it constituting blackmail? (i.e. I'd be happy to help you solve this at a $300/hr rate)
- bonzoesc 15y ago
  I've always got the impression that it's more convenient and less risky to not tell anyone; when the flaw is eventually exploited, you don't want to be the one on record as having known about it.
  - mike-cardwell 15y ago
    Or report it anonymously using Tor or a remailer. If you do it anonymously, you also get the benefit of being able to safely threaten the bank that you will release the information publicly if they haven't fixed it within x days.
    - stephen_g 15y ago
      Or you could just send them a real letter (I think an institution like a bank would respond better to that than an email). I'd just tell them that I'm a concerned customer who stumbled upon the flaw. I would never threaten them to release it publicly though - I'd tell them that I'd forward the letter to the relevant government organisation. Where I am in Australia this would be something like the BFSO (Banking and Financial Services Ombudsman) and/or ACCC (Australian Consumer and Competition Commission).
- ctdonath 15y ago
  Legally obligated? no. It's not your system, it's not your problem in that sense. Sure you can offer to fix it, but since you don't know squat about the system (save for a small flaw at the surface) and they have teams of developers who do, they won't be interested in paying you to fix it. Offering to explain the bug for a fee won't be blackmail unless you threaten to reveal the bug to others if they don't pay up. Be a decent chap. Send 'em a nice letter explaining the problem. It's your bank, remember, and they're humans like you; work with your service providers to improve the service. Assume you're not the only one who knows about the problem, that someone who also knows isn't as nice as you, and it's YOUR bank balance that is at risk.
holdenc 15y ago
I have a feeling there's more to it than a clear account number reference in the URL. It was probably a base64 encoded account number or a non-salted hash of the account number (ie. rainbow table-reversible) and the quality assurance analysts probably never questioned this. Disclaimer: I worked in product development making banking software and simple URL hacking was always a standard test.
mbreese 15y ago
If this really was the "hack", you can be sure that Citi is has opened themselves up to a whole world of negligence lawsuits. This is the same as having a vault where any customer could walk in and just browse around the safe deposit boxes. Sure, it might be tough to be authenticated to get into the vault, but once you're there... This is something that should cause the immediate dismissal of the CIO, but sadly, probably won't.
tannerc 15y ago
Is there anything Citi has done right over the past few years? I'm asking honestly and not with sarcasm, because I just haven't seen it.
raganwald 15y ago
This is unacceptable, obviously. It's a massive failure of their security testing protocols. I'm not particularly surprised that an vulnerability like this would get written into the code, it's an easy mistake for an inexperienced developer to make. But I'm not going to pile on the developer. We laud "separation of concerns" in our architecture, and this pattern applies to the organization of software development teams. I don't expect every developer to be aware of every vulnerability. But I do expect that a financial institution has a specialist somewhere that audits the code before it is sent for testing ("white box"), and then I expect them to have an independent audit team probe for vulnerabilities ("black box"). After the inexperienced developer has had his code rejected for various flaws, he will become quite aware of the obvious ways things like this can go wrong. Don't get me wrong, I expect that the vast majority of developers wouldn't make this mistake in the first place. But if you aren't a specialist, it is pure hubris to think that you write code that is hardened against all of the attacks out there. And if you have a vulnerability, it really doesn't matter if it's an embarrassingly simple vulnerability or one that requires sophisticated techniques to uncover and exploit. Either way, you're road kill. High-value targets like banks need two security specialists (the code audit and the penetration test) to accompany the development specialists. That's simple separation of concerns, and it works as well in team organisation as it does in code organisation.
- raganwald 15y ago
  Unrelated anecdote: When working with a substantial financial organisation, there were strict rules prohibiting my team from communicating with the code audit and other security teams. Going for coffee with one of the internal audit people would get you both fired. The external testing was done by a security consulting firm. Their reports were passed on to me with the identifying details stripped out so that I wouldn't even know who they were. Talk about "low coupling!"
  - tptacek 15y ago
    It shouldn't matter to you who the external firm is. Stripping out their contact info, at least in the archives, is probably smart; it makes it easier for the company to keep multiple security firms working on their projects. Which, when you're a huge bank, is what you want to be doing.
TheCondor 15y ago
I've been ranting on this stuff for a couple years now to my friends. There are some alarming trends.. First off, a pen test is often treated the same as an attorney client relationship. If the test turns up particularly costly bad news, I've seen a handful of testers have the relationship essentially severed, received some hard language about talking about it from a lawyer and then received a check from a private account as if the company doesn't want to leave any traces that they actually knew about the problems. (I'm not joking, some medium sized companies have done this) With some of the regulations the big missing piece is openness, there is no transparency into it at all. Any audited company should say who audited them and then after some period of time, 180 days maybe, the audit should be made public. The business risk is that customers will leave, in many cases like Playstation Network, customers effectively can't leave, they've already invested in something and there isn't an alternative. In many other cases it's not typically going to be widely publicized. If the customers can't leave, en mass, there is no business pressure for security and without any transparency the regulations will simply be gamed.
evro 15y ago
I was reading about this yesterday and about an hour later, Citi called me trying to sell me their fraud protection. I replied "Did it help the 200,000+ accounts that were stolen from you?" and hung up.
- khafra 15y ago
  It might have--I mean, when Citi sells you fraud protection for your Citi account, that's basically insurance against either you or them being careless with your account info.
earlyriser 15y ago
I discovered that my bank, Banque Nationale, used GET to delete transactions from the History. Then somebody could send a mail to the bank clients with an image linked to this Get action and delete the transactions of the client if he was logged into the bank and reading his emails at the same time. It wasn't a big risk, but I don't understand how this went live. I mean if a bank could not get that POST is for C_UD and GET for _R__, then who?
jcoder 15y ago
``security experts'': The attack was "especially ingenious," and "would have been hard to prepare for." The experts are certainly part of the problem.
LandofDerp 15y ago
Why are they hacking? Probably because the economy sucks and they are unemployed and bored. Also, no one is out-smarting anyone. These companies have insecure websites and they don't care. Well, maybe now they have wised up! Secure your server noob.
yaix 15y ago
I have really problams believe that this could be true. Not even a first year student would be that stupid to expose any user id in the URL. And read from it without access right checking. For access to the related account data. How would they even get the idea to do such a thing? And as for the "hackers", I guess legally this was not even a break-in. At least in Germany, for legally being a break-in, a computer system must be "specially secured with the intention of preventing access". Well, this system wasn't. ...still, I have a hard time believing that it could be true.
- prodigal_erik 15y ago
  There's nothing wrong with having a user id in a URL. That's very RESTful (my account is distinct from your account, so they really ought to have different URLs), and can make a lot of sense in cases where users may delegate permission to manage each others' records. It's just trusting that user id without an authorization check that's idiotic.
  - yaix 15y ago
    Its RESTful yes, but with the wrong item of data. To identify a logged in user and give the user access to their private account data, ONLY EVER use a unique and temporal random string. Nothing else. Ever. Storing that random string in the URL may be done but is more insecure, because it will remain in the browser history. Not good if the user in on a public PC. Better store it in a cookie.
    - prodigal_erik 15y ago
      "Who am I", "which users/accounts may I access", and "which user/account do I want to access right now" are different questions, and it's only the latter that belongs in the URL. I agree that secrets in particular must not be exposed in the URL.
  - enobrev 15y ago
    I personally prefer NOT to use Primary Keys in URLs for this exact reason. At the very least you can generate unique and difficult to guess keys that correspond to those IDs. A record ID (user id for example) has no use outside of database joins and therefore is useless in the public domain (url). As well, for public data (obviously not bank data) a data-based-key (song name, restaurant title, whatever) is far more useful in debugging and in logs. Otherwise - you're absolutely right allowing access to protected records - via id, key, or whatever - should absolutely be checked against the authenticated session upon every request.
stef25 15y ago
wouldn't a simple IF( $url_id !== $logged_in_id ) die("No access") fix this?
- slavak 15y ago
  If they saved the $logged_in_id in the session then they wouldn't need to pass it as a parameter in the url. No, this probably indicates their entire architecture is ass-backwards.
defdac 15y ago
The same bank also complains if you want to use more than 9 characters in your password.. That kindof hints about how they store passwords in their database..
- runningdogx 15y ago
  Sadly, other financial services companies do not seem to understand, either. Etrade's password system requires 6 to 32 characters with at least one number according to the password change instructions. They don't mention punctuation, but if you try to include some, they're deemed to be "invalid characters". Go figure. This stuff makes me sad that I signed up for etrade: "Thank you for your message regarding enabling HTTP Strict Transport Security. I have sent a request to our Product Development Team to have this feature added. Due to the high volume of requests, there is no guarantee that this will be implemented." -- etrade representative "ETRADE does not allow certain characters to be used when establishing a password online. There is no specific ETRADE publication providing information on why certain characters are not allowed, such as special characters used for punctuation, etc. We appreciate your feedback concerning the online passwords. I forwarded this suggestion to the Product Development Team for future consideration and implementation. I can not guarantee when or if this change will be able to be made..." -- another etrade representative
anty 15y ago
Did anyone else check if the article was meant to be satiric? This is unbelievable!
jdp23 15y ago
Historically, companies like Citi haven't faced any meaningful consequences for putting their customers at risk by not doing "security 101". Will things be any different this time?
Arxiss 15y ago
How the hell could this happen? I think that 6yr old kid and figure out URL injection... wait a second... citi is a bank???
Sukotto 15y ago
I use citibank for my family accounts so may have been impacted. Has anyone posted a list of compromised account numbers someplace I can check against?
nandemo 15y ago
> Think of it as a mansion with a high-tech security system -- but the front door wasn’t locked tight. It's more like an apartment building with high-tech locks in the front door and apartment doors. But after you unlock the front door, you can unlock any apartment's door with your key! The keys are all identical, only the number printed on the label is different.
bskari 15y ago
What worries me the most is that one expert that the Daily Mail interviewed said "It would have been hard to prepare for this type of vulnerability." The same expert "wondered how the hackers could have known to breach security by focusing on the vulnerability in the browser." http://www.dailymail.co.uk/news/article-2003393/How-Citigroup-hackers-broke-door-using-banks-website.html http://www.dailymail.co.uk/news/article-2003393/How-Citigrou...
gnosis 15y ago
I wonder what Citibank is going to do about this now? Are they going to change their customers' account numbers? That's the minimum that should be done for those accounts which were compromised.
sixtofour 15y ago
I've never worked for a bank, or any company that held sensitive information. I've only worked for companies that sold products to be used internally. Grains of salt are on the table to your left. What this looks like, in the context of all the other serious recent breaches like Sony and the IMF, and from the point of view of someone who's never had to fight this particular battle but knows a little code, is that these corps deployed online apps in the early days when this wasn't a major part of their corporate face. Practices and points of view evolved from an initial environment where there just wasn't as much motivation for criminals to crack apps, because there wouldn't be that much of a market for what they stole. So corps could get away with deploying almost anything, relying on both security through obscurity and security through rarity (breaches were rare due to low profit). People in corporate offices that even knew their corps had these apps would be rare because the prestige of managing these people and apps would be low. The apps we have today would then be direct descendants of the old insecure apps, and in many cases would be built directly on those old apps. Layers of mud, and you can't change the inside layers because old mud is brittle. And now the corps are going up against, not people who are merely exploring or looking for bragging rights, but people working for criminal enterprises that, while not having the global scope of banks, are large enough and focused enough to directly challenge the technical power of the banks. And the banks are working with old, dry mud. Again, grains of salt, but I suspect I'm in the right salt mine.
teyc 15y ago
I wouldn't necessarily blame this on the guy programming this. However, the person who spec'd the application up would be due for a quick demotion. The problem with antiquated bank systems is that the teller is trusted with the access to any account. So when it came to web enabling the old teller application, someone did some screen scraping as a prototype without having a concept of restricting access. There is probably no concept of linking an authenticated account to a restricted set of bank accounts. Instead, they've probably wired it up to CICS directly to retrieve account details. This is why the Quick Fix appears to be obsfucating the account number in the URL. Is there a public report anywhere? Aren't companies required to report all privacy breaches?
shaydoc 15y ago
Its a basic error. Tech Architect should be seeing this in milliseconds. Its a total design flaw. Should not be going straight to SQL with just paramters in a querystring, there should at least be authenticated user account verification checking. Also doesn't say much for the company doing security review, its a basic check. Furthermore to not have a user/onwer id to join on there (no doubt sql back end) is shameful. I mean I can see it now : select x from accounttable where accountnumber = @val how about simply : select x from accounttable where accountnumber = @accno and ownerid = @ownerid

360 points by mmavnn 15y ago

How can a bank this large have such poorly designed security? It's ridiculous. Hopefully, all these latest hacks get everyone else to treat security more seriously. There could be a lot of other banks that do the same thing as Citigroup. So if one gets hacked, at least the others will remember to review their security policies, so it doesn't happen to them, too.

mrcharles 15y ago

How is this even possible? In my very first website I built from scratch using PHP, I paid attention to the possibility of this. I can't say for certain that I fully protected against it, but I tried. That little trick would not have worked. How is it that a bank, of all places, pays money for a web infrastructure, and manages to employ people who don't even think about the most basic of attacks? I've been changing info in URLs since I started using the internet.

rmc 15y ago
Diaspora had this problem when they first released their software, and it was written in Rails, a modern framework http://www.kalzumeus.com/2010/09/22/security-lessons-learned-from-the-diaspora-launch/ http://www.kalzumeus.com/2010/09/22/security-lessons-learned...
- spdy 15y ago
  You cant really compare this with a bank like citygroup. Security is everything the should care about in the first place. They have to protect your money and nobody really cares about fancy features when they just want to wire some money, everything should just be rock solid. I would love to get more information about this breach it sounds to simple to be true.
  - mgkimsal 15y ago
    "Security is everything the should care about in the first place." profits are all they care about. Honestly, stuff like this burns me up. Large orgs like this lobbied for crap like PCI compliance standards to 'protect' data, but they don't have to follow their own rules. Seriously, if PCI compliance is mandated for anyone who stores CC info, why the hell isn't citi being shut down for this sort of breach? 'too big to fail'?
    - walkon 15y ago
      Has it been determined that Citi will not face repercussions for this incident? I think part of the reason PCI DSS was created (by the payment processors MasterCard, Visa, Amex, etc) was to allow for more legal leverage against the banks when determining who has to pay damages in scenarios such as this.
      - mgkimsal 15y ago
        No, it hasn't. I'm just jumping the gun in a frothy rage. Something this egregious should have been caught by PCI compliance checks (if not development) in the first place though. I doubt the penalty will be anything severe enough - something like "no cc processing and management for citi for 180 days" might make them take this a bit more seriously.
        walkon 15y ago
        I think PCI is more of a reactive legal tool than it is an effective, proactive way to prevent security breaches. In theory it should catch security vulnerabilities, but I don't know how thorough the compliance checks really are... Yeah, Citi's greater punishment will likely be in the form of a weakened reputation then it will be in actual damages paid.
        mgkimsal 15y ago
        They're long, involved and expensive, although I'm not sure how thorough or really preventative they may be - you're right. For companies just getting started, they probably serve more preventative purposes than they do for already established players who were around before the PCI stuff came around.
- StavrosK 15y ago
  The framework has nothing to do with not authorizing requests properly. Diaspora had many problems when they first released because apparently they were all inexperienced programmers, like the guy who wrote that in Citi.
Jach 15y ago
How indeed.. How can someone be able to architect the system of accounts, connection info, etc. for a bank but not be aware of such things? And it's not even being lazier either. Sigh... To all you 13 year old kids on the road of learning web dev, this is what you're competing against!
phillijw 15y ago
Companies are very cheap when it comes to hiring software devs. They can't see the benefit of paying more for a dev that can "do the same thing".

StrawberryFrog 15y ago

A security guy weighs in on it here: http://idunno.org/archive/2011/06/14/citibank-hacked-ndash-dumb-developers-dumber-security-consultants.aspx http://idunno.org/archive/2011/06/14/citibank-hacked-ndash-d... "This was not sophisticated or ingenious, as reported, this was boringly simple. ... OWASP has had Insecure Direct Object references on it’s Top 10 list for years. It’s in the SDL Threat Modeling tool. Any security firm worth its salt checks for this" Yes, there's a good description of this kind of trivial "hack" in the Open Web Application Security Project Top 10: https://www.owasp.org/index.php/Top_10_2010-A4 https://www.owasp.org/index.php/Top_10_2010-A4

wccrawford 15y ago
Yeah. When that first report said 'experts' said how hard it would be to have predicted and prevented this, I choked. Amazingly lame.
- peterwwillis 15y ago
  Citi has an internal web application pen-testing group. My guess is they were only ever attacking the outward facing apps and not the ones after successful authentication. Even if so, they may have hundreds of apps to test which constantly change, and sometimes attackers just get lucky and find a hole as soon as it pops up.
  - tptacek 15y ago
    My understanding, just to clarify: Citi has a web app pentesting operation, which engages and is among the largest customers for several well-known pentesting firms. Just in case the impression was that Citi has a couple guys in a room doing this stuff. As for constantly-changing apps, let me speak against my own direct financial interests here (we have a product coming out that addresses that problem, so I'd like it to be a big one). Many, if not most, of the large financials we work with or have talked to have a fairly strict process for deploying new code, and the process gates on security review. Not deploying unreviewed code comes pretty close to being part of the due care standard at large modern banks. If I had to gamble on this, I'd bet that this specific code did get reviewed.

aw3c2 15y ago

"Gawker media blog spam". Visit http://www.nytimes.com/2011/06/14/technology/14security.html?pagewanted=all http://www.nytimes.com/2011/06/14/technology/14security.html... instead

blatherard 15y ago
Consumerist isn't a Gawker property anymore. They are now owned by Consumers Union, who also publishes Consumer Reports.
sili 15y ago
I was actually disappointed by the NYT article. They interview security experts who call the attack "ingenious", "hard to prepare for" and performed by exploiting a vulnerability in a browser. This understates how incompetent the bank's website design is.
- mmavnn 15y ago
  That was why I linked to this article rather than the NYT. The article linked to, while shorter, contains all of the relevant information and less completely random cluelessness.
  - chriserin 15y ago
    The NYTimes story is the 2nd crime, because they're white washing Citicorp's responsibility. With all the hacking that's been going on recently, the NYT needs a full time cyber security reporter.

narad 15y ago

That's worse than SQL injection. Didn't they build ACL?

romaniv 15y ago
ACL is probably part of the problem here. Most ACLs are very inflexible and are "opt in". They probably had ACL to block unregistered user from visiting the page, but it didn't deal with individual accounts.

thibaut_barrere 15y ago

You'll surely enjoy the quote from the linked article: ======= The method is seemingly simple, but the fact that the thieves knew to focus on this particular vulnerability marks the Citigroup attack as especially ingenious, security experts said. ======= Sorry but no, this isn't ingenious - it's really the basics!!!

john2x 15y ago
Yeah, the NYTimes article really made it look like the hackers went into a lot of trouble to breach the bank's security.
- bron 15y ago
  Of course, the hackers were suffering from acute Alzheimer.
- webjprgm 15y ago
  Of course they did, if they made it look simple then everyone would freak out (or they should, and have mass exodus away from Citi). People are used to hackers finding occasional, difficult exploits.

tnorthcutt 15y ago

I really hope that the reporter who wrote the NYT article either misunderstood the facts, or talked to an ignorant "expert".

fmavituna 15y ago

This is like the first thing you learn in web app security (defender or attacker) and you don't even need to write script a tool such as http://code.google.com/p/fm-fsf/ http://code.google.com/p/fm-fsf/ will scrape the data quickly. Even though it's insanely easy to spot and exploit it's also easy to miss it while coding. But any decent pen-tester will find it. Regardless, unacceptable for a finance company.

planb 15y ago
No, I don't think easy to miss because it shouldn't be possible in the first place. At least for a banking software, the web application layer is not the right place to check for this kind of authentication. This makes me wonder how their code must look like...
dave1010uk 15y ago
All you need is curl: curl http://example.com/user/[1-100]

leftnode 15y ago

What's worse: every customers ID in the database was stored in the URL or that there was no ACL to test against? If a user is logged in, you have their account ID stored in a session. If they navigate to a page that their account ID can't see (like another person's account), then kick them out. Astoundingly simple.

quattrofan 15y ago

Seriously how do people stay in their jobs allowing crap like this to happen? The CIO or CTO at Citi should get the boot. Until companies like this and Sony start making examples of people, this kind of sloppiness that gives our industry a bad name will continue.

groby_b 15y ago
Except the examples that will be made will not involve the CIO/CTO. And even if it did, the guy almost certainly a golden parachute - what does he care? As long as it's cheaper to clean up after the debacle than prevent it in the first place, that's what people will opt for.
- rubinelli 15y ago
  They probably didn't develop it in-house, so it's just a matter of blaming and changing providers.
- gnosis 15y ago
  "And even if it did, the guy almost certainly a golden parachute - what does he care?" If he really was fired and the company made a public stink about how much he screwed up, he may well care. Many people at that level care about their prestige, and care about being shamed in front of their peers, even when they don't need to worry financially.
sdizdar 15y ago
In majority of corporations responsibility and accountability ends somewhere between VP and CEO.

deleted 15y ago

[deleted]

rawsyntax 15y ago
For the record, enabling UUIDs in rails is straight forward. It's not the default though. Why turn on UUIDs? They are not as guessable as normal IDs.
- dgl 15y ago
  Depending what sort of UUID you're generating that could leak your MAC address to an attacker which could prove useful.
- fjlaskjd 15y ago
  ghfdfsghjhgfdsfghgfds

mgkimsal 15y ago

In 2000(?) I employed this same 'hack' against Ameritech's online bill viewer, but couldn't get anyone's attention. I called several people at Ameritech, but couldn't get through to anyone who understood anything I was saying. I tried to get ahold of newsmedia, but realized afterwards that the links I was sending did have a session timeout associated, so by the time a reporter clicked a link, they got nothing. Finally, I managed to get in touch with someone at 'fuckameritech.net' (IIRC) - a consumer watchdog (I hesitate to say 'group' - I think it was just one guy) who said "I'll take care of it". He made some contacts - I think got it to a reporter in Chicago, and that afternoon Ameritech's online bill view and pay was taken down (a wednesday IIRC) and it wasn't brought up again until Monday. The 'fix' was not much - they were now hashing the account number in some massively long (128 char?) ID instead of just your account number. But it was all still visible in the URL, which was the bigger problem to start with, because it encouraged 'hackers' like me to change my account number by one digit. I suspect others had noticed this before, tried to contact citi, and couldn't get in touch with anyone who understood what the caller was saying. Companies need separate 'web vulnerability' hotlines to call/contact to report issues like this - perhaps just hidden in the 'view source' - if you're good enough to find the info, you know what you're doing enough to report a problem. Too low a bar?

FooBarWidget 15y ago
I imagine that publicizing a web vulnerability hotline would result in more trouble that it would solve. Normal people really don't understand computers. If you somehow give off the message that your system is not perfectly secure or bug-free they would get scared and run off to competitors who are just as bug-ridden but at least appear to be more secure.
- mgkimsal 15y ago
  While I sort of see, marketing/wording of this could spin this as a positive (assuming it was even something that was publicized - perhaps hidden in the markup is good enough?). We've popularized crime reporting as a social good - mcgruff the crime dog, etc. When will we start taking online safety and security with the same level of seriousness? As much as I don't like the idea, being able to report issues to a state or federal agency might be a way to go.

Shenglong 15y ago

It's funny that this wasn't discovered sooner. I suppose everyone figured a security flaw like this would never exist, and never bothered to try. Irony...

wladimir 15y ago
Most likely this was discovered sooner. But people kept the vulnerability to themselves and possibly even profited from it. These kind of vulnerabilities in high-profile sites can go unreported for ages, even up to the point that they are common knowledge in certain groups.

lucraft 15y ago

I'd argue that this wasn't even a hack. This is publicly visible information. No security measures were circumvented.

noduerme 15y ago

So...the first login had to have valid credentials. Someone needed a citibank account to start the scraper-bot. Wonder if the fbi's talked with that guy yet.

count 15y ago
I'd bet they used one of the hundreds of thousands of stolen accounts from other services to do this. You know somebody is sharing usernames/passwords with their SOE and Citi accounts.
adolph 15y ago
I think the key phrase would be "Someone needed access to a citibank account..." If some Citibank account(s) was compromised in some way, such as phished, then a third party would have the necessary access. It would be bad enough to be a victim of phishing--imagine being a pawn in a large scale attack like that. It would suck.

smackfu 15y ago

I wonder where they got the account numbers from. Citi doesn't show them in the web interface, just last 4 digits.

patio11 15y ago

I'm kind of torn on this. On the one hand, yeah, it is a trivial flaw. On the other hand, so is waving a gun at a teller. That attack has been around for decades and still works a few dozen times a year, because the cost/benefit analysis says that after hardening the banks a little it is easier to just lose a few tens of thousands of dollars every once in a while than it is to give them the Secret Service's attention to physical security. That is hardly the only systemic vulnerability in the banking system. For example, let's suppose I want to compromise your account number and credentials sufficient to take you for every penny you possess. You know what I need? A check of yours. Any will do. Everything I need to create a demand draft against your account is on every check you have ever written. Every employee of every business you have ever paid by check got the keys to your financial kingdom. You may not be aware of it, but since those credentials are assumed compromised, the security is in a) catching me when I use the demand draft to suspiciously drain your account and b) failing that, making you whole out of the bank's pocket. The numbers have been crunched: it is vastly, vastly more efficient to treat fraud as a cost of doing business than it is to tighten the screws 100% The attack surface on software the size and complexity of a bank's is like the Death Star, except any single rivet being out of place will eventually result in this headline. (Step #1 in tightening the screws would be turn off public facing websites, because inexpert users plus compromised machines means that no banking website will ever be secure, even without coding errors. This will never happen, because the provable cost savings of moving customers to online banking roflstomp over the marginal fraud risk.)

st3fan 15y ago
The attack surface on software the size and complexity of a bank's is like the Death Star, except any single rivet being out of place will eventually result in this headline. I agree that banking software is probably complicated. But really, this bug is a beginners mistake and it shoul dhave never happened. It is something that the original developers should have known about and also something that the company auditing this code should have seen. There is really no excuse for this.
- bigohms 15y ago
  This is like the first thing any new hax0r tries. Imagine the joy when it actually worked...

snorkel 15y ago

I know exactly how this occurs because I recently met a "Senior Web Developer" at an established business who was basically their acting architect because he was the their first coder and therefor his non-technical bosses regarded him as some kind of genius because he knows how to unjam the office printer. He didn't know a lick of Unix, didn't understand load balancing, and had very weak SQL skills. He was your typical framework junky who couldn't imagine writing even the simplest web app without a framework to do all the heavy lifting. All he wanted was for me to recommend an even simpler web framework so he wouldn't have to write any SQL at all. No doubt some day his code will be generating headlines like this one, and he will no doubt blame whatever framework he used and his bosses will simply mandate that they switch to a more secure framework pronto, and they'll promote this boob as their Senior Architect to lead the project.

silverlake 15y ago
I've met hundreds of these boobs in IT shops around the world. There's a huge skills gap between IT and software devs. IT guys are not given the time nor resources to learn and implement all this stuff. Also, they often don't have the skills or curiosity to figure it out themselves. So they really do need a framework that takes care of it all easily.
lawnchair_larry 15y ago
That actually sounds like the right way to do it to me. He shouldn't be writing frameworks. Frameworks are reviewed by a lot of people, and there is a far greater chance of them being bug free than something home-rolled.

lifeisstillgood 15y ago

The big question is why the structure of the IT department lent itself to doing something so stupid You can fire the CIO, you can replace the offshore developers with onshore, or vice versa, but experience says it won't matter. I looked in amazement at googletesting's dependancy graph test suites yesterday, and realised that the playing field is not flat at all. Reading and writing code is the literacy of the 21st C. And the end most big companies are like newspapers owned and managed by illiterates. It does not matter how you rearrange the strucutre or the hierarchy, when the chips are down decisions will be made on what the illiterate management understand is the best way to work. As such it is infinitely unlikely that the decision then will be set up to support what a literate person would decide. Until a generation of coders grows up, or all illiterate companies go bankrupt, this will merely be one of a myriad of pathologies exhibited by large companies run by the illiterate.

yuvadam 15y ago

A naive question here: Suppose I accidentally stumble upon a gaping security hole in my bank's online service (or any other online service for that matter). Am I legally obliged to notify them of that security bug? Can I offer the bank my assistance, for hire, in solving the bug without it constituting blackmail? (i.e. I'd be happy to help you solve this at a $300/hr rate)

bonzoesc 15y ago
I've always got the impression that it's more convenient and less risky to not tell anyone; when the flaw is eventually exploited, you don't want to be the one on record as having known about it.
- mike-cardwell 15y ago
  Or report it anonymously using Tor or a remailer. If you do it anonymously, you also get the benefit of being able to safely threaten the bank that you will release the information publicly if they haven't fixed it within x days.
  - stephen_g 15y ago
    Or you could just send them a real letter (I think an institution like a bank would respond better to that than an email). I'd just tell them that I'm a concerned customer who stumbled upon the flaw. I would never threaten them to release it publicly though - I'd tell them that I'd forward the letter to the relevant government organisation. Where I am in Australia this would be something like the BFSO (Banking and Financial Services Ombudsman) and/or ACCC (Australian Consumer and Competition Commission).
ctdonath 15y ago
Legally obligated? no. It's not your system, it's not your problem in that sense. Sure you can offer to fix it, but since you don't know squat about the system (save for a small flaw at the surface) and they have teams of developers who do, they won't be interested in paying you to fix it. Offering to explain the bug for a fee won't be blackmail unless you threaten to reveal the bug to others if they don't pay up. Be a decent chap. Send 'em a nice letter explaining the problem. It's your bank, remember, and they're humans like you; work with your service providers to improve the service. Assume you're not the only one who knows about the problem, that someone who also knows isn't as nice as you, and it's YOUR bank balance that is at risk.

holdenc 15y ago

I have a feeling there's more to it than a clear account number reference in the URL. It was probably a base64 encoded account number or a non-salted hash of the account number (ie. rainbow table-reversible) and the quality assurance analysts probably never questioned this. Disclaimer: I worked in product development making banking software and simple URL hacking was always a standard test.

mbreese 15y ago

If this really was the "hack", you can be sure that Citi is has opened themselves up to a whole world of negligence lawsuits. This is the same as having a vault where any customer could walk in and just browse around the safe deposit boxes. Sure, it might be tough to be authenticated to get into the vault, but once you're there... This is something that should cause the immediate dismissal of the CIO, but sadly, probably won't.

tannerc 15y ago

Is there anything Citi has done right over the past few years? I'm asking honestly and not with sarcasm, because I just haven't seen it.

raganwald 15y ago

This is unacceptable, obviously. It's a massive failure of their security testing protocols. I'm not particularly surprised that an vulnerability like this would get written into the code, it's an easy mistake for an inexperienced developer to make. But I'm not going to pile on the developer. We laud "separation of concerns" in our architecture, and this pattern applies to the organization of software development teams. I don't expect every developer to be aware of every vulnerability. But I do expect that a financial institution has a specialist somewhere that audits the code before it is sent for testing ("white box"), and then I expect them to have an independent audit team probe for vulnerabilities ("black box"). After the inexperienced developer has had his code rejected for various flaws, he will become quite aware of the obvious ways things like this can go wrong. Don't get me wrong, I expect that the vast majority of developers wouldn't make this mistake in the first place. But if you aren't a specialist, it is pure hubris to think that you write code that is hardened against all of the attacks out there. And if you have a vulnerability, it really doesn't matter if it's an embarrassingly simple vulnerability or one that requires sophisticated techniques to uncover and exploit. Either way, you're road kill. High-value targets like banks need two security specialists (the code audit and the penetration test) to accompany the development specialists. That's simple separation of concerns, and it works as well in team organisation as it does in code organisation.

raganwald 15y ago
Unrelated anecdote: When working with a substantial financial organisation, there were strict rules prohibiting my team from communicating with the code audit and other security teams. Going for coffee with one of the internal audit people would get you both fired. The external testing was done by a security consulting firm. Their reports were passed on to me with the identifying details stripped out so that I wouldn't even know who they were. Talk about "low coupling!"
- tptacek 15y ago
  It shouldn't matter to you who the external firm is. Stripping out their contact info, at least in the archives, is probably smart; it makes it easier for the company to keep multiple security firms working on their projects. Which, when you're a huge bank, is what you want to be doing.

TheCondor 15y ago

I've been ranting on this stuff for a couple years now to my friends. There are some alarming trends.. First off, a pen test is often treated the same as an attorney client relationship. If the test turns up particularly costly bad news, I've seen a handful of testers have the relationship essentially severed, received some hard language about talking about it from a lawyer and then received a check from a private account as if the company doesn't want to leave any traces that they actually knew about the problems. (I'm not joking, some medium sized companies have done this) With some of the regulations the big missing piece is openness, there is no transparency into it at all. Any audited company should say who audited them and then after some period of time, 180 days maybe, the audit should be made public. The business risk is that customers will leave, in many cases like Playstation Network, customers effectively can't leave, they've already invested in something and there isn't an alternative. In many other cases it's not typically going to be widely publicized. If the customers can't leave, en mass, there is no business pressure for security and without any transparency the regulations will simply be gamed.

evro 15y ago

I was reading about this yesterday and about an hour later, Citi called me trying to sell me their fraud protection. I replied "Did it help the 200,000+ accounts that were stolen from you?" and hung up.

khafra 15y ago
It might have--I mean, when Citi sells you fraud protection for your Citi account, that's basically insurance against either you or them being careless with your account info.

earlyriser 15y ago

I discovered that my bank, Banque Nationale, used GET to delete transactions from the History. Then somebody could send a mail to the bank clients with an image linked to this Get action and delete the transactions of the client if he was logged into the bank and reading his emails at the same time. It wasn't a big risk, but I don't understand how this went live. I mean if a bank could not get that POST is for C_UD and GET for _R__, then who?

jcoder 15y ago

``security experts'': The attack was "especially ingenious," and "would have been hard to prepare for." The experts are certainly part of the problem.

LandofDerp 15y ago

Why are they hacking? Probably because the economy sucks and they are unemployed and bored. Also, no one is out-smarting anyone. These companies have insecure websites and they don't care. Well, maybe now they have wised up! Secure your server noob.

yaix 15y ago

I have really problams believe that this could be true. Not even a first year student would be that stupid to expose any user id in the URL. And read from it without access right checking. For access to the related account data. How would they even get the idea to do such a thing? And as for the "hackers", I guess legally this was not even a break-in. At least in Germany, for legally being a break-in, a computer system must be "specially secured with the intention of preventing access". Well, this system wasn't. ...still, I have a hard time believing that it could be true.

prodigal_erik 15y ago
There's nothing wrong with having a user id in a URL. That's very RESTful (my account is distinct from your account, so they really ought to have different URLs), and can make a lot of sense in cases where users may delegate permission to manage each others' records. It's just trusting that user id without an authorization check that's idiotic.
- yaix 15y ago
  Its RESTful yes, but with the wrong item of data. To identify a logged in user and give the user access to their private account data, ONLY EVER use a unique and temporal random string. Nothing else. Ever. Storing that random string in the URL may be done but is more insecure, because it will remain in the browser history. Not good if the user in on a public PC. Better store it in a cookie.
  - prodigal_erik 15y ago
    "Who am I", "which users/accounts may I access", and "which user/account do I want to access right now" are different questions, and it's only the latter that belongs in the URL. I agree that secrets in particular must not be exposed in the URL.
- enobrev 15y ago
  I personally prefer NOT to use Primary Keys in URLs for this exact reason. At the very least you can generate unique and difficult to guess keys that correspond to those IDs. A record ID (user id for example) has no use outside of database joins and therefore is useless in the public domain (url). As well, for public data (obviously not bank data) a data-based-key (song name, restaurant title, whatever) is far more useful in debugging and in logs. Otherwise - you're absolutely right allowing access to protected records - via id, key, or whatever - should absolutely be checked against the authenticated session upon every request.

stef25 15y ago

wouldn't a simple IF( $url_id !== $logged_in_id ) die("No access") fix this?

slavak 15y ago
If they saved the $logged_in_id in the session then they wouldn't need to pass it as a parameter in the url. No, this probably indicates their entire architecture is ass-backwards.

defdac 15y ago

The same bank also complains if you want to use more than 9 characters in your password.. That kindof hints about how they store passwords in their database..

runningdogx 15y ago
Sadly, other financial services companies do not seem to understand, either. Etrade's password system requires 6 to 32 characters with at least one number according to the password change instructions. They don't mention punctuation, but if you try to include some, they're deemed to be "invalid characters". Go figure. This stuff makes me sad that I signed up for etrade: "Thank you for your message regarding enabling HTTP Strict Transport Security. I have sent a request to our Product Development Team to have this feature added. Due to the high volume of requests, there is no guarantee that this will be implemented." -- etrade representative "ETRADE does not allow certain characters to be used when establishing a password online. There is no specific ETRADE publication providing information on why certain characters are not allowed, such as special characters used for punctuation, etc. We appreciate your feedback concerning the online passwords. I forwarded this suggestion to the Product Development Team for future consideration and implementation. I can not guarantee when or if this change will be able to be made..." -- another etrade representative

anty 15y ago

Did anyone else check if the article was meant to be satiric? This is unbelievable!

jdp23 15y ago

Historically, companies like Citi haven't faced any meaningful consequences for putting their customers at risk by not doing "security 101". Will things be any different this time?

Arxiss 15y ago

How the hell could this happen? I think that 6yr old kid and figure out URL injection... wait a second... citi is a bank???

Sukotto 15y ago

I use citibank for my family accounts so may have been impacted. Has anyone posted a list of compromised account numbers someplace I can check against?

nandemo 15y ago

> Think of it as a mansion with a high-tech security system -- but the front door wasn’t locked tight. It's more like an apartment building with high-tech locks in the front door and apartment doors. But after you unlock the front door, you can unlock any apartment's door with your key! The keys are all identical, only the number printed on the label is different.

bskari 15y ago

What worries me the most is that one expert that the Daily Mail interviewed said "It would have been hard to prepare for this type of vulnerability." The same expert "wondered how the hackers could have known to breach security by focusing on the vulnerability in the browser." http://www.dailymail.co.uk/news/article-2003393/How-Citigroup-hackers-broke-door-using-banks-website.html http://www.dailymail.co.uk/news/article-2003393/How-Citigrou...

gnosis 15y ago

I wonder what Citibank is going to do about this now? Are they going to change their customers' account numbers? That's the minimum that should be done for those accounts which were compromised.

sixtofour 15y ago

I've never worked for a bank, or any company that held sensitive information. I've only worked for companies that sold products to be used internally. Grains of salt are on the table to your left. What this looks like, in the context of all the other serious recent breaches like Sony and the IMF, and from the point of view of someone who's never had to fight this particular battle but knows a little code, is that these corps deployed online apps in the early days when this wasn't a major part of their corporate face. Practices and points of view evolved from an initial environment where there just wasn't as much motivation for criminals to crack apps, because there wouldn't be that much of a market for what they stole. So corps could get away with deploying almost anything, relying on both security through obscurity and security through rarity (breaches were rare due to low profit). People in corporate offices that even knew their corps had these apps would be rare because the prestige of managing these people and apps would be low. The apps we have today would then be direct descendants of the old insecure apps, and in many cases would be built directly on those old apps. Layers of mud, and you can't change the inside layers because old mud is brittle. And now the corps are going up against, not people who are merely exploring or looking for bragging rights, but people working for criminal enterprises that, while not having the global scope of banks, are large enough and focused enough to directly challenge the technical power of the banks. And the banks are working with old, dry mud. Again, grains of salt, but I suspect I'm in the right salt mine.

teyc 15y ago

I wouldn't necessarily blame this on the guy programming this. However, the person who spec'd the application up would be due for a quick demotion. The problem with antiquated bank systems is that the teller is trusted with the access to any account. So when it came to web enabling the old teller application, someone did some screen scraping as a prototype without having a concept of restricting access. There is probably no concept of linking an authenticated account to a restricted set of bank accounts. Instead, they've probably wired it up to CICS directly to retrieve account details. This is why the Quick Fix appears to be obsfucating the account number in the URL. Is there a public report anywhere? Aren't companies required to report all privacy breaches?

shaydoc 15y ago

Its a basic error. Tech Architect should be seeing this in milliseconds. Its a total design flaw. Should not be going straight to SQL with just paramters in a querystring, there should at least be authenticated user account verification checking. Also doesn't say much for the company doing security review, its a basic check. Furthermore to not have a user/onwer id to join on there (no doubt sql back end) is shameful. I mean I can see it now : select x from accounttable where accountnumber = @val how about simply : select x from accounttable where accountnumber = @accno and ownerid = @ownerid