Early 2005 saw many prominent companies publicly disgraced by exposures of stolen customer information, including Lexis-Nexis, whose database was hacked and 310,000 personal records accessed, and ChoicePoint, who lost 145,000 full identities to social engineers who set up 50 dummy accounts and simply requested the information.
These types of breaches, however, are not new. Insiders will tell you that hackers extract customer identities all the time.
What is new is that 16 state data protection laws, spawned by California's CA-1386, effective in July 2003, are forcing public disclosure when there's an exposure of consumer data, including addresses, telephone numbers, driver's licence numbers, social security numbers, medical data, tax IDs and credit/bank account information.
The federal version is already working its way through Congress (HR-4127), and the European Union and Japan have strong data privacy laws in place already.
As organisations are forced to go public with data loss and exposure, identity theft is no longer just a consumer issue. It's now a top business priority because reporting a single breach or exposure could cost your organisation its loyal customers and shareholder confidence. For example ChoicePoint's stock dropped 15 per cent immediately following the social engineering attack on its systems.
Organisations handling any type of consumer identity information should secure that data as if it were their own money. Otherwise your organisation could join Victoria's Secret, the State of Minnesota, Gateway computers, Petco, FTD.com,Tiffany.com, Abbey National Bank and dozens of other brand names in sending notifications to affected customers in compliance with these laws.
How does it happen?
One of the most startling things about web-based identity theft is how simple some of the attacks are. Although hackers are contriving new attacks every day, web attacks generally fall into a couple of categories.
The most common attack is formfield injection. Form-field injection takes advantage of the free-text input on web-based forms such as those asking for names, addresses or other data input. Think about it: when users fill in a form to update their billing address and credit card number, they are being given permission to write to a database which - by definition - contains everyone's credit cards and billing addresses! And the only thing restricting the commands that they send to that database is the logic of the web application itself.
In a properly-written web application, the inputs in form fields should be validated, so that a field for names only accepts standard language character sets, or a field for phone numbers only accepts positive integers, and so on. This prevents users from entering in SQL queries or other database commands. The input validation, however, is left to developers, who have many other priorities, including performance, functionality, deadlines and so on.
As a result, web applications are often written that fail to validate the data input into each one of these fields. Even if a web application validates 9,999 of the 10,000 fields it contains, hackers only need to find that one which, for whatever reason, the developer didn't adequately validate.
This was precisely the type of vulnerability that the University of Southern California discovered in July 2006, according to published reports. They realised that their online application system (which is set up to accept student information and write it to a database) was not properly validating all the entries in all of the form fields. As a result, hackers could enter and execute SQL commands, accessing a database of over 320,000 student records.
A slightly more sophisticated version of this attack was used on Japan's top price comparison site, Kakaku.com, just two months earlier. According to Japanese press accounts, a hacker accessed the site as a normal user (gaining all the credentials needed simply by signing up for the service) then began entering nonsense data into the form fields.
By looking at the error messages and other responses sent back from the server, the hacker was able to determine what commands could be executed where, and began downloading personal information on thousands of users from the Kakaku.com databases.
However form fields are not the only place to manipulate web applications. Any request sent to the server from the web page can be tampered with. A request for my account information can be changed to look like a request for your account information.
Because the web is fundamentally stateless, each request for information comes to the server completely out of the blue. Any context about who a user is and what they are requesting must be contained within the request, whether it's in a cookie, a hidden field or even in the URL.
The nice thing about web browsers like Explorer and FireFox is that they make it very easy to see exactly what request is being sent to the server, and to change those requests locally if desired. Just in case that isn't easy enough, you can download free web proxies like Paros (www.parosproxy.org), which advertises, 'All HTTP and HTTPS data between server and client, including cookies and form fields, can be intercepted and modified.'
The simplest example of this is the well-publicized vulnerability discovered at PayMaxx during the tax season in 2006. One of the leading payroll companies at the time, PayMaxx decided to provide online access to employee W-2 forms.
The problem was that the mechanism separating one employee's request from another employee's request was all too transparent. In fact it's a very common web vulnerability: putting database queries in the URL.
You see this any time a URL ends with something like ?user=123456789. When you see that, you know the web application is passing a query back to the database (indicated by the ? mark) and is asking for the record where the user ID is 123456789. The first thing a hacker will do is try to change that number in the URL, essentially making a query for a different user record.
In the case of PayMaxx, this proved quite simple; apparently over 25,000 user records were given sequential numbers, so simply adding one to the number you were assigned would produce the next employee record, adding one more would produce the next, and so on. Trend Micro publicly admitted to the exact same type of vulnerability after a promotional offer invited users to 'Confirm and update your details' on a page generated with an obvious 'UserID' query in the URL.
If changed, this query could pull up any user's personal information. Sometimes the manipulation of requests is more complicated. For instance a few years ago it was reported that users of FTD.com had determined how to change the cookie values sent to the server, effectively appearing as other users. This attack is called 'cookie poisoning' and was used a year later at Gateway computers, according to public sources.
A related, but subtly distinct, category of attack is to ask for parts of the web application to which you have no rights whatsoever. This type of attack has different names, including 'forceful browsing', 'exploitation of predictable resource location' or 'insufficient authorisation'. Regardless of the name, the attack consists of nothing more than asking for web pages to which you should not have access.
Web servers, not surprisingly, are very good at serving web pages. So good, in fact, that they will serve up pretty much any page a user asks for, unless they are told not to. Hackers therefore will barrage a web server with requests for commonly placed admin pages, configuration files and password locations. Often this is as simple as adding /admin or /includes or /config to the end of a URL, or requesting other common file locations.
The most famous example of this is the Minnesota State Police Department, who were hosting an online crime reporting system. Like many such systems, both external users (reporting crimes) and internal users (police offers viewing those reports) had browser-based interfaces to the same web application. The only difference was that the police officers' view had a slightly different web address. Unfortunately users figured out that by simply adding one word to the end of their URL, they could view the (much more interesting) police officer's application.
Arbella Insurance was the victim of this type of vulnerability. They inadvertently published (in the footer of a printed legal form) the web address of their access point to the Registry of Motor Vehicles. Intended only for Arbella actuarial use, the web address www.arbella.com/RegistryAccess/entry - it's no longer active) could be used by anyone to access the entire DMV database of drivers, home addresses, driver's licence numbers and driving records.
More common types of vulnerabilities involve configuration files and password files on web servers. In fact, rather than look for these common files on each and every site, many hackers will now just run Google searches for them. Called 'Google hacking' this type of attack is nothing more than a clever search looking for files with names like CONF and DAT. There is even a very popular website devoted to crafting and sharing such search terms, so hackers can share their latest Google hacks.
Customer revolt
The volume of media reports related to online identity theft has unsettled users enough to document a steady decline in consumer confidence in online commerce.
More than half of 655 people surveyed by Cyota said they're afraid to do any form of e-commerce due to fears of phishing identity theft; 92 per cent of US consumers are reluctant to share information online because of identity theft concerns, while 61 per cent are less likely to use a credit card online, and 50 per cent don't trust financial institutions to protect their data, according to a Forrester survey.
Identity theft concerns are also causing existing online customers to withdraw from online transactions at a rate that's far outpacing new consumers entering into online commerce. Because of identity theft fears, 13 per cent of 1,486 international respondents to Entrust's June 2005 Internet Security Survey have decreased or outright ceased banking online, while 12 per cent have decreased or stopped all forms of e-commerce in the last 12 months. Meanwhile, according to the report, only 4 per cent of those surveyed were new to getting online.
'Identity theft is impacting global e-commerce,' says Bill Conner, CEO of Entrust, during the unveiling of survey findings. 'The message from consumers is clear - secure our identities and we will vote with our wallets.'
According to the Federal Trade Commission (FTC), 3.2 million consumers are victims of identity theft each year, with combined losses of $5 billion. The costs to consumer victims is mostly in legal fees and time spent trying to reclaim their good names and good credit - an average 600 hours to restore each stolen identity, which translates to $16,000 in lost potential revenue, according to the Identity Theft Resource Centre.
More than reputation and customer loss, businesses and organisations touched by identity theft are also shouldering $50 billion a year in direct costs - or ten times that of consumer costs - to deal with identity theft's aftermath, according to the FTC.
For example a hospital is denied payment for services rendered against a fake medical identity, or a store is out the value of the merchandise that's been purchased on a fraudulent transaction after the issuing banks catch on to the fraud and reverse the charges. Merchants also pay an additional 'charge back' fee (usually $25) to cover the issuing bank's administrative costs in reversing the charges.
'The cost of identify theft to financial institutions goes far beyond the identifiable funds that not recovered. Their business is based on a strong sense of trust and confidence with their customers. If their customers do not trust them they will not do business with them,' explains John Pironti, principal security consultant at Unisys Inc.
Protecting customer assets
Increasingly companies realise that they must protect their customer data assets in the same way that they protect their financial assets.What are the best practices for securing web applications? There are two important principles in web security: layering and what I call 'outrunning the bear'.
The first notion, a layered security approach, is nothing new in the realm of security. No technology and no organisational process offers a magic bullet that can remove risk from online business. Rather, good web application security requires defence in depth, with security built into many layers of the organisation and IT infrastructure. The following are some best practices that can be applied throughout the development life cycle:
- Secure coding initiatives:
Building better web applications begins with raising awareness among developers. Many developers aren't even aware of the basic security issues around web architecture, let alone the importance of vigilant input validation throughout the coding process. Major consultancies offer excellent programs in secure coding. - Vulnerability scanning and application penetration testing:
One of the best ways to raise awareness of application vulnerabilities in an organisation is to conduct thorough vulnerability testing, including - but not limited to - the use of a good scanner. These can show the vulnerabilities in web applications in order to highlight the need for increased coding vigilance and some type of remediation. - Web application firewalls:
Once awareness is raised, many organisations are choosing to implement web application security on a network device where the policies can be centrally managed, maintained and audited. Increasingly these are being integrated with best-of-breed L4-7 appliances for optimum performance.
When implementing various layers of security, of course, it is important to weight the costs of the security against the benefits. Organisations can consume significant resources securing code, implementing web application firewalls and maintaining their security policies. The important thing to remember is that no web application - indeed no organisation or system of any kind - can ever be 100 per cent secure.
The best approach is what I call 'outrunning the bear'. Since web applications today are the 'path of least resistance' to hackers, the goal of a web security program should be to become secure enough to encourage hackers to go elsewhere. Once a web application proves difficult enough to resist the most common forms of attack - even a targeted attack from a sophisticated hacker - the web is no longer the weak link in the security equation.
I liken it to the story of the two campers who encounter a bear in the forest. One camper begins to lace up his running shoes, and his companion says: 'What are you doing? You can never outrun a bear!' To which the camper replies: 'I don't have to outrun the bear, I just have to outrun you!'
Of course, a web security program must be able to tighten according to the risk profile of the assets and the nature of the threat involved. Some government agencies will go to extraordinary lengths to reduce the risks of their online presence, while commercial enterprises want a more cost-effective solution to simply deter most hackers. Once the building blocks are implemented (educated developers, penetration testing and web application firewalls) you have created a place for application security policies to reside, and those policies can be tuned to meet the security requirements of the organisation.
Identity theft is not a new phenomenon. It existed long before online commerce and will continue to exist as long as business relies on trusted relationships of some sort. However today web applications present a critical vulnerability for most organisations, and the front lines in the battle against identity theft. It is, therefore, imperative that security professionals understand the nature of the threat and put in place measures to mitigate that threat, or they are doing a great disservice to their customers, and themselves.
