This week, details came out about how identity thieves captured information for around 200,000 Citigroup customers' information. According to the New York Times article and many articles that reference it, "The case illustrates the threat posed by the rising demand for private financial information from the world of foreign hackers."
Wrong. This case illustrates the threat posed by total negligence and/or ignorance of your Web Apps and Security teams and flaws in your internal quality assurance processes. That is, if the report I read is correct (otherwise, shame on whoever else is responsible for this, and also on the dirty rotten thieves).
Sure, cyber security is a huge and growing concern. But this case illustrates the old adage (modified here to reflect scale) that an ounce of prevention is worth 200,000 pounds of cure.
URL hacking is the oldest trick in the Web apps hacker's book. To frame our discussion, we will consider the "3 A's of security":
- Authentication: Is this user who they say they are?
- Authorization: Is this authenticated user authorized to access the requested resource?
- Access: Does the requested resource require authorized access only by certain authenticated users?
One common URL hacking method is known as the SQL Injection attack, where you change the URL's search parameters by inserting additional SQL commands into those parameters. This type of attack can be mitigated in your Web application (on any major Web server platform and application framework) by simply using appropriate query parameters (both on the application level and database level for added layers of security) and carfully checking escape characters, rather than simply grabbing your URL parameters and sticking them without prejudice into your SQL statements. It also helps to use a limited database user account rather than your RDBMS administrator's account (never do that!!). By limited, I mean that the database user account can only perform CRUD (Create, Read, Update, Delete) functions or less (preferably just Read), and only on specific tables for most access.
How do the "3 A's of security" apply here? SQL injection attacks exploit the failure of a Web application's architecture to properly control access required to modify SQL commands and/or authorization for the database user employed by the application.
In the case of the Citigroup exploits, the attack is much simpler to carry out—and to prevent. If this story is reported correctly, the hackers just had to change an ID number in the URL to get to other customer accounts. This would mean that Citigroup's application page execution process goes something like this:
- Receive request.
- Is the user authenticated (logged in)?
No problem here...
- If yes, proceed (probably handled by checking a Session object or client Cookie).
- If no, redirect to login form.
- What is the user's account number? Grab it from the URL!
BAD move. Here, access (is it restricted?) and authorization (is this user authorized?) should be checked.
- Return the account information the user asked for (regardless of who the user actually is).
Not a planned step, but it is the result.
No level of SSL encryption, firewall hardening, and password complexity will make one iota of difference when you allow the passing of account ID by URL. This is equivalent to having a Citibank branch with dozens of armed security guards, biometric security access, and 12" thick bullet-proof glass guarding the bank, but having your vault door open and giving customers a skeleton key to all other customer accounts. You might as well put a sign that says "Security is on the Honor System."
Citigroup is a very large enterprise with a very large I.T. infrastructure (I know because I've been perusing their job postings for SharePoint and ASP.NET architects). Somewhere, the bureaucracy that is in place to ensure quality and security has broken down and actually prevented them from seeing this very simple but obviously damning security hole.
My professional advice to Citigroup would be to reexamine your Application and Enterprise Architects and your Security auditors. This should have jumped out at them long before it became a nightmare for both customer and corporation.