News is breaking that banking giant HSBC disclosed a security incident exposing an undisclosed number of customers’ data. This is just the latest security incident reported by HSBC, which experienced DDoS attacks in January 2016 and July 2016, in addition to leaking customer data in April 2015 and March 2010.
The security incident appears to fit the characteristics of a credential stuffing attack, also known as brute-force password-guessing attempts. This is when hackers try usernames and password combos leaked in a data breach at other companies. HSBC has confirmed that some of these attacks were successful, and attackers have gained access to customer details, including full names, mailing addresses, phone numbers, email addresses, dates of birth, account numbers, account types, account balances, transaction histories, payee account information and statement histories.
Cybersecurity experts have commented on the incident below.
Bryan Becker, Application Security Researcher at WhiteHat Security:
“It looks like the breached accounts are a result of ‘credential stuffing.’ This just means the attackers try to use as many username and password combinations as possible, which they’ve obtained from previous breaches in the hopes that users will use the same password on multiple sites. One recommendation that can help users is to sign up for free at this website:https://haveibeenpwned.com/. This site is run by Troy Hunt, a well-respected security researcher, and will notify you any time your account shows up in a breach, so you know to change your passwords. Of course, the best solution is to use a password manager and have a different login for every site.
From the organization’s point of view: credential stuffing seems like a suspicious explanation for a bank-account breach. Generally speaking, banks require some sort of two-factor authentication, and that should stop any credential stuffing attack in its tracks. This begs the question of either: Why wasn’t HSBC using two-factor authentication, OR (if they were) what was the real cause of the breach?
If you want to secure your own application against these types of attacks, there are two steps you can take – enforce two-factor authentication and check users passwords against a database of previously leaked passwords in order to prevent reuse as recommended by NIST (Note: this must be done when the password is created! Never store the password in plain-text in any situation. Besides being extremely unsafe, it’s potentially illegal).”
Oscar Tovar, Vulnerability Verification Specialist at WhiteHat Security:
“An attacker can brute force passwords by first gathering a list of potential victims, which happens when attempting to use a register account function or reset password function. These two forms of functionality are prone to leak whether a username is valid or not. An attacker may then compile a list of valid usernames to proceed to the next step of an attack. Once an attacker has a collection of possible targets, they will then attempt to brute force their login. If a web application does not have any form of anti-automation put in place, then this leaves them exposed to this kind of attack. This opens up the discussion on how these attacks can be prevented. The remediation for the first step would be to never expose any customer information in any shape or form without proper validation.
For example, a password reset functionality may ask for the username of the account that requires the password reset. A safe implementation of this functionality would require the application to respond indifferently to valid and invalid usernames. This may be something along the lines of, ‘An email has been sent with instructions on resetting your password. If you did not receive the email within 10 minutes, please try again.’ A generic message such as this would prevent an attacker from gathering any knowledge on the users of the application. The second point to address would be the use of anti-automation. Anti-automation may mean blacklisting IP addresses with a large amount of requests sent in a small time frame, locking an account with multiple failed login attempts, or the use of a CAPTCHA. Properly implementing any of these features on the login of an application should be considered non-negotiable and extremely important.”
Jacob Serpa, Product Marketing Manager at Bitglass:
“As one of the world’s largest banking and financial services organizations, consumers trust HSBC with the well-being of their information. The attackers are believed to have gained unauthorized access to the compromised accounts from credential-stuffing attacks. This could have been prevented if the company used dynamic identity management solutions that can detect potential intrusions, require multi-factor authentication, and integrate with existing systems for managing user access.”
.
Rusty Carter, Vice President of Product Management at Arxan Technologies:
“This highlights that every company is vulnerable to a breach and there’s a constant flow of attacks from the endpoint that are leading to successful theft.
Companies need to treat the web and the browser application itself as a critical access point for enterprise security. Many companies stop at the network perimeter and are subsequently breached by their own APIs browser/web apps and mobile applications that have been compromised.
Consumers need to increase their vigilance as well. Reused passwords lost in one breach then become a free ticket to your other accounts. Consumers should employ unique passwords for every site and service they use and change them at least once a year (unless there’s a breach then of course sooner). Secure, paid service or locally run password managers make this easier in many cases than using a password you’ll remember. Consumers can create a long and complex passphrase to access their devices or password manager to keep their passwords secure and use complex password generators to create unique passwords per site. This is fundamental today to maintaining any personal security online since a shared password may be just days away from being compromised on one of your online accounts.”
Ilia Kolochenko, CEO at High-Tech Bridge:
“Unless the scope, circumstances and total number of affected customers become known, it would be premature to make any categorical conclusions.
Allegedly, only US customers are affected, thus it may indicate that the breach occurred via an authorized third-party or careless employee.
Data leaks caused by negligent third-party providers – become more and more frequent these days. An abandoned US-based web system with a limited set of customers’ data – can also be among the possible attack vectors. Often large companies deploy demo systems to production for legitimate testing purposes, consequentially forgetting about them, leaving the unprotected systems and data externally accessible.
The bank’s reaction is relatively prompt, proposed remediation seems to be technically adequate for the incident. This will, however, unlikely exonerate them from private lawsuits and, perhaps, even a class action by disgruntled customers and privacy watchdogs.”
Corin Imai, Senior Security Adviser at DomainTools:
“This is simply the latest in a long line of breaches indicating that we as an industry have room for improvement in how we handle and protect sensitive data. Financial institutions have been making large strides in protecting customer data since it is among the most valuable data to steal, and potentially the most damaging type of PII to be exposed. It appears that HSBC is taking the proper steps in notification and handling of impacted customers.”
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.