Keeping customer accounts safe from takeover

Yaniv Balmas at Salt Security describes four common account takeover security threats – and how to prevent them

 

Any company with a customer-facing login – from financial institutions to healthcare organizations to eCommerce providers and more – can be a target of an account takeover (ATO) attack.

 

In ATO attacks, perpetrators attempt to change account details, access and steal financial data and other types of digital identity. With access to personal data, attackers can falsely apply for lines of credit, commit insurance fraud, or take over a legitimate account to make purchases online. They can also use stolen data to increase the believability of phishing and spam efforts.

 

Application programming interfaces (APIs) are at the heart of most ATO attacks. By using compromised credentials, attackers can target a service and launch an attack against respective login APIs. Attackers use a variety of techniques to compromise credentials. The most common are:

• Broken authentication
• Credential stuffing
• Brute-force attacks – including password spraying
• Broken object level authorization

Broken authentication

Authentication mechanisms provide easy targets for attackers, especially if the authentication mechanisms are fully exposed or public. In both of those cases, the authentication component can be highly vulnerable to exploitation.

 

With a broken authentication flaw, attackers can log into accounts and perform actions by appearing to be an authenticated user. They gain access to another user’s data and make unauthorized transactions.

 

Even worse, in the case of  broken machine authentication, an attacker can potentially gain access to all of the data that machine identity is entitled to access.

 

Credential stuffing

Credential stuffing relies on lists of compromised username/password combinations. It plays upon the bad user habit of using the same username/password combination across multiple services.

 

In addition, if the username itself is an email address, the chances of a successful credential stuffing attack increase even more.

 

Organizations often defend against credential stuffing attacks by locking out accounts after multiple failed login attempts. However, account lockout also creates a poor user experience, so organizations frequently adopt a more relaxed policy. For example, maybe they only lock the account after 10 bad attempts for a certain amount of time.

 

The bad news is that attackers can usually work around these settings, backing off before an account lockdown and waiting before attack resumption.

 

Brute-force attacks

Brute-force attacks are similar to credential stuffing in that they also prey upon username/password combinations for access. However, in a brute-force attack, attackers compute different alphanumeric and special character sequences until they hit the right authentication combination. Simple and easy-to-guess passwords are at the highest risk.

 

Password spraying is a type of brute-force attack, where attackers “spray” the same password at a list of user names hoping to get account access. This approach can work in situations where applications or account admins use a default password for all new accounts, and the user doesn’t change the password upon first login.

 

Broken object level authorization

According to the OWASP API Security Top 10, broken object level authorization (BOLA) is the most common – and most severe – API vulnerability. BOLA happens when an API does not correctly validate that the identity performing a request has the required privileges to access requested resources.

 

Attackers will manipulate the ID of an object to be sent within an API request to find and exploit API endpoints that are vulnerable to BOLA. These vulnerabilities are quite common in API-based applications because the server component typically doesn’t fully track the client’s state. Rather, the server component usually relies on parameters to determine which objects can be accessed.

 

By failing to enforce authorization at the object level, organizations place themselves at high risk for BOLA. They can be susceptible to data exfiltration, as well as unauthorized viewing, modification, or destruction of data.

 

Fortunately, there are several steps that organizations can take to protect themselves from API account takeover attacks:

 

Recognize that your APIs can be called directly. By sniffing application traffic or reverse engineering front-end code, attackers can discover the URLs of API endpoints. Security teams should ensure strong controls for all channels, whether web, mobile or IoT, as attackers will traverse channels to uncover the most vulnerable path.

 

Be vigilant about authenticating and authorizing API users. Broken authorization and broken authentication represent the most prevalent and destructive API security flaws. Organizations must authenticate API calls where data is sensitive or private and continuously validate the authorization level of authenticated users.

 

Restrict data that isn’t necessary for a front end to function. Attackers can expose API communications of front ends by using intercepting proxies on endpoint devices. This data can be harvested and scraped by attackers for use in ATO attacks. Ensure that you provide only the data that is needed for a front end to function.

 

Baseline typical API behavior. With a baseline of normal API behavior, it’s easier to identify API deviations, such as excessive login errors and attempted manipulation of tokens, user IDs, or API parameters. If organizations rely solely on authentication mechanisms to stop ATO, they remain exposed.

 

Identify attackers with context. Finally and most importantly, organizations must identify attackers through complete context. They need full context of their API traffic – over time – in order to see the correlated activity of an attacker. Only sufficient data baselines can distinguish between “different” and “malicious” activity and connect all the activity of any given entity.

 

Those detailed data baselines can only be generated with cloud-scale big data using artificial intelligence (AI) and machine learning (ML). Anything else is inadequate to capture the full context that is needed to continuously monitor and detect deviations across hundreds and thousands of APIs to spot where and when attackers are trying to gain unauthorized access to accounts.

 

---

 

Yaniv Balmas is VP of Research at Salt Security

 

Main image courtesy of iSTockPhoto.com