Back in 2016, Tesco Bank and its customers were victims of an attack where more than 9,000 accounts had money stolen – over £2 million in total. The attack has recently been in the news again after the bank’s security practices were reviewed by the National Cyber Security Centre, who found security issues severe enough that the bank was later fined over £16 million by the Financial Conduct Authority.
Along with the fine, details have emerged about the vulnerability which was surprisingly simple. It originated with the way the bank distributes debit cards. Most cards have a 16 digit card number e.g. 0000-0000-0000-0000. Cards numbers are distributed to card issuers (like Tesco bank) in BINS, so Tesco can issue card numbers anywhere between 6340-0100-0000-0000 and 6340-0199-9999-9999.
The issue is that Tesco didn’t randomly distribute card numbers in this range, but used a system to select card numbers which was guessable by the attackers. The exact system hasn’t been published, but it was presumably the case that by knowing a few card numbers, attackers were able to guess the system used to generate them and work out other valid card numbers belonging to account holders.
Enumerating credit cards
This process is known as enumeration, specifically using knowledge about a particular system to obtain all of a particular type of data or functionality within a system.
In this example, the attackers were performing credit card enumeration, at it’s simplest, this might be a credit cards being issued in numerical order, e.g. if the attackers know 0000-0000-0000-0001 is a valid card number and 0000-0000-0000-0002 is a valid card number, it’s a good bet 0000-0000-0000-0003 is a valid card number along with 0000-0000-0000-0005, 0000-0000-0000-0006, etc.
It’s likely that Tesco’s system to distribute card numbers was more complicated than this, and just knowing the card number isn’t necessarily enough to extract funds from the debit card attached to this number, so the actual attack was likely significantly more sophisticated than this, but enumeration is a common enough attack that we specifically test for it when completing application security testing on behalf of clients.
Other types of enumeration
In particular, username enumeration and file enumeration are common vulnerabilities we come across in web applications.
File enumeration is a way of accessing files or other resources made available by an application, but not directly linked to from anywhere in the application. An example would be where files are stored not by their name, but by a number e.g. http://www.example.com/file/1 and attacker can check this location to see if a file is accessible, they can then continues to try the address for files 3, 4, etc. until they have retrieved every file in the application. This may not be a problem if every file is supposed to be publicly accessible, but if any of the files contains confidential information and it’s not correctly secured an attacker can obtain it very easily.
User enumeration is the process of finding valid users on a web application, often as a first step to obtaining access to an account by then trying to guess the password. Sometimes this can be completed in the same way as file enumeration e.g. when user profiles are in the form http://www.example.com/user/1, though there are also other techniques such as testing against known lists of common usernames to see if these are registered in the application or not. Again, user enumeration won’t necessarily make an application vulnerable to attack on its own, but it can be used in conjunction with other attacks, such as trying common passwords for a username in an attempt to guess the correct one.
A number of well-known web applications are vulnerable to user enumeration and file enumeration if not configured correctly, so it’s worth reviewing your applications to check if they might be vulnerable.
